From prvs=3560071543=lyong@ciena.com Wed Aug 1 06:47:44 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1079111E8110 for ; Wed, 1 Aug 2012 06:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.441 X-Spam-Level: X-Spam-Status: No, score=-98.441 tagged_above=-999 required=5 tests=[AWL=4.224, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhVtDHmpUSZI for ; Wed, 1 Aug 2012 06:47:42 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 7846711E810E for ; Wed, 1 Aug 2012 06:47:42 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q71Dj4bb003079; Wed, 1 Aug 2012 09:47:33 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 16f5m100ay-20 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 01 Aug 2012 09:47:32 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT01.ciena.com ([::1]) with mapi; Wed, 1 Aug 2012 09:47:16 -0400 From: "Ong, Lyndon" To: "adrian@olddog.co.uk" , "ccamp@ietf.org" Date: Wed, 1 Aug 2012 09:47:14 -0400 Thread-Topic: [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQJG0ydQ2iZ1PPA/LaXiFWLC86ukfJZRWGeAgADTQWA= Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> In-Reply-To: <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-19076.007 x-tm-as-result: No--64.857500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-01_04:2012-08-01, 2012-08-01, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208010121 Cc: "dimitri.papadimitriou@alcatel-lucent.be" , "jplang@ieee.org" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 13:47:44 -0000 Hi Adrian, Thank you for the fast evaluation of the errata. It sounds like the correc= tion that I suggested has ended up overspecifying the method to do reversio= n with full rerouting when it is very possible to support a form of reversi= on that doesn't involve maintaining the old LSP. >From your response I believe that you do agree that it was not the intent o= f the original specification text to imply that reversion with full rerouti= ng is not allowed (or to require that the old LSP always be torn down in fu= ll rerouting), so hopefully with some more discussion we can determine if t= here is anything that could be done to make that clearer. Best regards, Lyndon -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Tuesday, July 31, 2012 6:28 PM To: ccamp@ietf.org Cc: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel-lucen= t.be; stbryant@cisco.com; lberger@labn.net; dbrungard@att.com; Ong, Lyndon Subject: RE: [Technical Errata Reported] RFC4872 (3304) Hi CCAMP, I find that this erratum is raised against two sections one of which I supp= lied text for. If this get contentious, I will call on Stewart to call cons= ensus and handle the Erratum in the system. In my opinion, this proposal goes further than the intention of the authors= /WG in publishing 4872. With regard to the proposed addition to section 11... The use of mb4b is already in scope. The existing text says "The new LSP re= sources can be established using the make-before-break mechanism," so there= is no need to re-state "The new LSP can be established without tearing dow= n the old LSP". I think your concern here is whether the old LSP is ever torn down. I think= that you are worried that if the old LSP is torn down, it might be impossi= ble to perform reversion because, after repair, an attempt to revert (also = using mb4b) might find that key resources have been "stolen" by some other = LSP. I don't see this as at all different from the issue of the protection = LSP itself. That is, it is of the nature of LSP Rerouting as a protection m= echanism that: a. protection may fail because of lack of resources b. reversion may fail b= ecause of lack of resources *If* reversion is so important, I don't quite see why protection is not imp= ortant. If protection is important then you should be using a proper protec= tion mechanism and not waiting for post facto rerouting. Furthermore, if yo= u require that the LSP be retained for restoration, why are you not using a= protection mechanism?=20 But the general paradigm here is that you are willing to use the best avail= able LSP when it is set up in the first place, the best available LSP when = you re-route after failure, and the best available LSP when you "revert". Lastly, it *does* remain an _option_ to retain the failed LSP in order to s= witch back. Nothing in the old text precludes that, although I understand t= hat there is an implication that it might be expected to be torn down. So I conclude that the proposed addition to section 12 is not what the auth= ors/WG intended. We should discuss further. Adrian > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 31 July 2012 17:39 > To: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel-=20 > lucent.be; stbryant@cisco.com; adrian@olddog.co.uk; lberger@labn.net;=20 > dbrungard@att.com > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC4872 (3304) >=20 >=20 > The following errata report has been submitted for RFC4872, "RSVP-TE=20 > Extensions in Support of End-to-End Generalized Multi-Protocol Label=20 > Switching (GMPLS) Recovery". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 >=20 > -------------------------------------- > Type: Technical > Reported by: Lyndon Ong >=20 > Section: 11 & 12 >=20 > Original Text > ------------- > Section 11 says: >=20 >=20 > (Full) LSP rerouting will be initiated by the head-end node that has > either detected the LSP failure or received a Notify message and/or a > PathErr message with the new error code/sub-code "Notify Error/LSP > Locally Failed" for this LSP. The new LSP resources can be > established using the make-before-break mechanism, where the new LSP > is set up before the old LSP is torn down. This is done by using the > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > can share resources at common nodes. >=20 > Section 12 says: >=20 > [No text on reversion for (full) LSP Rerouting.] >=20 > Corrected Text > -------------- > Section 11 should say: >=20 >=20 > (Full) LSP rerouting will be initiated by the head-end node that has > either detected the LSP failure or received a Notify message and/or a > PathErr message with the new error code/sub-code "Notify Error/LSP > Locally Failed" for this LSP. The new LSP resources can be > established using the make-before-break mechanism, where the new LSP > is set up before the old LSP is torn down. This is done by using the > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > can share resources at common nodes. The new LSP can be established > without tearing down the old LSP in case of reversion (see section 12)= . >=20 > Section 12 should say: >=20 > For "(full) LSP Rerouting", reversion implies that the old LSP is not > torn down by the head-end node after the new LSP is established. For > reversion, the head-end node re-activates the old LSP after this has > recovered. >=20 >=20 >=20 > Notes > ----- > Current text in RFC 4872 describes reversion in the cases of 1+1=20 > bidirectional Protection, 1:N Protection with Extra Traffic and=20 > Rerouting Without Extra Traffic, > however it has no description of reversion with (Full) LSP Rerouting. > For (full) LSP Rerouting, the description in Section 11 instead=20 > implies that the old > LSP is torn down. This has led to some confusion as to whether=20 > reversion with > (full) LSP Rerouting is allowed or not allowed by the RFC. We believe=20 > this was not > intentional. The additions would make it clear that reversion can be=20 > supported with (Full) LSP Rerouting. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please=20 > use "Reply All" to discuss whether it should be verified or rejected.=20 > When a decision is reached, the verifying party (IESG) can log in to=20 > change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > -------------------------------------- > Title : RSVP-TE Extensions in Support of End-to-End General= ized Multi- > Protocol Label Switching (GMPLS) Recovery > Publication Date : May 2007 > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, = Ed. > Category : PROPOSED STANDARD > Source : Common Control and Measurement Plane > Area : Routing > Stream : IETF > Verifying Party : IESG From jdrake@juniper.net Wed Aug 1 07:08:50 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A5F21F8870 for ; Wed, 1 Aug 2012 07:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.52 X-Spam-Level: X-Spam-Status: No, score=-4.52 tagged_above=-999 required=5 tests=[AWL=1.479, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uC98KfgMPtz8 for ; Wed, 1 Aug 2012 07:08:49 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id C0B2521F8831 for ; Wed, 1 Aug 2012 07:08:45 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUBk4bKZvRH+DypC5fzvrSQHfxxIoR0Ln@postini.com; Wed, 01 Aug 2012 07:08:48 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 1 Aug 2012 07:07:32 -0700 From: John E Drake To: "adrian@olddog.co.uk" , "ccamp@ietf.org" Date: Wed, 1 Aug 2012 07:07:31 -0700 Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQJG0ydQ2iZ1PPA/LaXiFWLC86ukfJZRWGeAgADeuYA= Message-ID: <5E893DB832F57341992548CDBB333163A5A8E92CB0@EMBX01-HQ.jnpr.net> References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> In-Reply-To: <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jplang@ieee.org" , "dimitri.papadimitriou@alcatel-lucent.be" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 14:08:50 -0000 I don't see any problem with the existing text. Sent from my iPhone > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Adrian Farrel > Sent: Tuesday, July 31, 2012 6:28 PM > To: ccamp@ietf.org > Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org; > dbrungard@att.com > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >=20 > Hi CCAMP, >=20 > I find that this erratum is raised against two sections one of which I > supplied text for. If this get contentious, I will call on Stewart to > call consensus and handle the Erratum in the system. >=20 > In my opinion, this proposal goes further than the intention of the > authors/WG in publishing 4872. >=20 > With regard to the proposed addition to section 11... > The use of mb4b is already in scope. The existing text says "The new > LSP resources can be established using the make-before-break > mechanism," so there is no need to re-state "The new LSP can be > established without tearing down the old LSP". >=20 > I think your concern here is whether the old LSP is ever torn down. I > think that you are worried that if the old LSP is torn down, it might > be impossible to perform reversion because, after repair, an attempt to > revert (also using mb4b) might find that key resources have been > "stolen" by some other LSP. I don't see this as at all different from > the issue of the protection LSP itself. That is, it is of the nature of > LSP Rerouting as a protection mechanism that: > a. protection may fail because of lack of resources b. reversion may > fail because of lack of resources >=20 > *If* reversion is so important, I don't quite see why protection is not > important. If protection is important then you should be using a proper > protection mechanism and not waiting for post facto rerouting. > Furthermore, if you require that the LSP be retained for restoration, > why are you not using a protection mechanism? >=20 > But the general paradigm here is that you are willing to use the best > available LSP when it is set up in the first place, the best available > LSP when you re-route after failure, and the best available LSP when > you "revert". >=20 > Lastly, it *does* remain an _option_ to retain the failed LSP in order > to switch back. Nothing in the old text precludes that, although I > understand that there is an implication that it might be expected to be > torn down. >=20 > So I conclude that the proposed addition to section 12 is not what the > authors/WG intended. >=20 > We should discuss further. >=20 > Adrian >=20 > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: 31 July 2012 17:39 > > To: jplang@ieee.org; yakov@juniper.net; > dimitri.papadimitriou@alcatel- > > lucent.be; stbryant@cisco.com; adrian@olddog.co.uk; lberger@labn.net; > > dbrungard@att.com > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC4872 (3304) > > > > > > The following errata report has been submitted for RFC4872, "RSVP-TE > > Extensions in Support of End-to-End Generalized Multi-Protocol Label > > Switching (GMPLS) Recovery". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 > > > > -------------------------------------- > > Type: Technical > > Reported by: Lyndon Ong > > > > Section: 11 & 12 > > > > Original Text > > ------------- > > Section 11 says: > > > > > > (Full) LSP rerouting will be initiated by the head-end node that > has > > either detected the LSP failure or received a Notify message > and/or a > > PathErr message with the new error code/sub-code "Notify Error/LSP > > Locally Failed" for this LSP. The new LSP resources can be > > established using the make-before-break mechanism, where the new > LSP > > is set up before the old LSP is torn down. This is done by using > the > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > can share resources at common nodes. > > > > Section 12 says: > > > > [No text on reversion for (full) LSP Rerouting.] > > > > Corrected Text > > -------------- > > Section 11 should say: > > > > > > (Full) LSP rerouting will be initiated by the head-end node that > has > > either detected the LSP failure or received a Notify message > and/or a > > PathErr message with the new error code/sub-code "Notify Error/LSP > > Locally Failed" for this LSP. The new LSP resources can be > > established using the make-before-break mechanism, where the new > LSP > > is set up before the old LSP is torn down. This is done by using > the > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > can share resources at common nodes. The new LSP can be > established > > without tearing down the old LSP in case of reversion (see section > 12). > > > > Section 12 should say: > > > > For "(full) LSP Rerouting", reversion implies that the old LSP is > not > > torn down by the head-end node after the new LSP is established. > For > > reversion, the head-end node re-activates the old LSP after this > has > > recovered. > > > > > > > > Notes > > ----- > > Current text in RFC 4872 describes reversion in the cases of 1+1 > > bidirectional Protection, 1:N Protection with Extra Traffic and > > Rerouting Without Extra > Traffic, > > however it has no description of reversion with (Full) LSP Rerouting. > > For (full) LSP Rerouting, the description in Section 11 instead > > implies that > the old > > LSP is torn down. This has led to some confusion as to whether > > reversion with > > (full) LSP Rerouting is allowed or not allowed by the RFC. We believe > > this was > not > > intentional. The additions would make it clear that reversion can be > > supported with (Full) LSP Rerouting. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or rejected. > > When a decision is reached, the verifying party (IESG) can log in to > > change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > -------------------------------------- > > Title : RSVP-TE Extensions in Support of End-to-End > Generalized > Multi- > > Protocol Label Switching (GMPLS) Recovery > > Publication Date : May 2007 > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > Papadimitriou, Ed. > > Category : PROPOSED STANDARD > > Source : Common Control and Measurement Plane > > Area : Routing > > Stream : IETF > > Verifying Party : IESG >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From dimitri.papadimitriou@alcatel-lucent.com Wed Aug 1 08:08:24 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF94011E80DC for ; Wed, 1 Aug 2012 08:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.749 X-Spam-Level: X-Spam-Status: No, score=-6.749 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQndFreytNM5 for ; Wed, 1 Aug 2012 08:08:23 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6B811E80AD for ; Wed, 1 Aug 2012 08:08:23 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q71F82kN026662 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 1 Aug 2012 17:08:07 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 1 Aug 2012 17:07:58 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: "adrian@olddog.co.uk" , "ccamp@ietf.org" Date: Wed, 1 Aug 2012 17:07:57 +0200 Thread-Topic: [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQJG0ydQ2iZ1PPA/LaXiFWLC86ukfJZRWGeAgADq6XA= Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> In-Reply-To: <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "jplang@ieee.org" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 15:08:25 -0000 Hi,=20 I agree with the conclusion here below. Thanks, -dimitri.=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Wednesday, August 01, 2012 03:28 > To: ccamp@ietf.org > Cc: jplang@ieee.org; yakov@juniper.net; Papadimitriou,=20 > Dimitri (Dimitri); stbryant@cisco.com; lberger@labn.net;=20 > dbrungard@att.com; lyong@ciena.com > Subject: RE: [Technical Errata Reported] RFC4872 (3304) >=20 > Hi CCAMP, >=20 > I find that this erratum is raised against two sections one=20 > of which I supplied > text for. If this get contentious, I will call on Stewart to=20 > call consensus and > handle the Erratum in the system. >=20 > In my opinion, this proposal goes further than the intention=20 > of the authors/WG > in publishing 4872. >=20 > With regard to the proposed addition to section 11... > The use of mb4b is already in scope. The existing text says=20 > "The new LSP > resources can be established using the make-before-break=20 > mechanism," so there is > no need to re-state "The new LSP can be established without=20 > tearing down the old > LSP". >=20 > I think your concern here is whether the old LSP is ever torn=20 > down. I think that > you are worried that if the old LSP is torn down, it might be=20 > impossible to > perform reversion because, after repair, an attempt to revert=20 > (also using mb4b) > might find that key resources have been "stolen" by some=20 > other LSP. I don't see > this as at all different from the issue of the protection LSP=20 > itself. That is, > it is of the nature of LSP Rerouting as a protection mechanism that: > a. protection may fail because of lack of resources > b. reversion may fail because of lack of resources >=20 > *If* reversion is so important, I don't quite see why=20 > protection is not > important. If protection is important then you should be=20 > using a proper > protection mechanism and not waiting for post facto=20 > rerouting. Furthermore, if > you require that the LSP be retained for restoration, why are=20 > you not using a > protection mechanism?=20 >=20 > But the general paradigm here is that you are willing to use=20 > the best available > LSP when it is set up in the first place, the best available=20 > LSP when you > re-route after failure, and the best available LSP when you "revert". >=20 > Lastly, it *does* remain an _option_ to retain the failed LSP=20 > in order to switch > back. Nothing in the old text precludes that, although I=20 > understand that there > is an implication that it might be expected to be torn down. >=20 > So I conclude that the proposed addition to section 12 is not what the > authors/WG intended. >=20 > We should discuss further. >=20 > Adrian >=20 > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: 31 July 2012 17:39 > > To: jplang@ieee.org; yakov@juniper.net;=20 > dimitri.papadimitriou@alcatel- > > lucent.be; stbryant@cisco.com; adrian@olddog.co.uk;=20 > lberger@labn.net; > > dbrungard@att.com > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC4872 (3304) > >=20 > >=20 > > The following errata report has been submitted for RFC4872, > > "RSVP-TE Extensions in Support of End-to-End Generalized=20 > Multi-Protocol Label > > Switching (GMPLS) Recovery". > >=20 > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 > >=20 > > -------------------------------------- > > Type: Technical > > Reported by: Lyndon Ong > >=20 > > Section: 11 & 12 > >=20 > > Original Text > > ------------- > > Section 11 says: > >=20 > >=20 > > (Full) LSP rerouting will be initiated by the head-end=20 > node that has > > either detected the LSP failure or received a Notify=20 > message and/or a > > PathErr message with the new error code/sub-code "Notify=20 > Error/LSP > > Locally Failed" for this LSP. The new LSP resources can be > > established using the make-before-break mechanism, where=20 > the new LSP > > is set up before the old LSP is torn down. This is done=20 > by using the > > mechanisms of the SESSION_ATTRIBUTE object and the=20 > Shared-Explicit > > (SE) reservation style (see [RFC3209]). Both the new=20 > and old LSPs > > can share resources at common nodes. > >=20 > > Section 12 says: > >=20 > > [No text on reversion for (full) LSP Rerouting.] > >=20 > > Corrected Text > > -------------- > > Section 11 should say: > >=20 > >=20 > > (Full) LSP rerouting will be initiated by the head-end=20 > node that has > > either detected the LSP failure or received a Notify=20 > message and/or a > > PathErr message with the new error code/sub-code "Notify=20 > Error/LSP > > Locally Failed" for this LSP. The new LSP resources can be > > established using the make-before-break mechanism, where=20 > the new LSP > > is set up before the old LSP is torn down. This is done=20 > by using the > > mechanisms of the SESSION_ATTRIBUTE object and the=20 > Shared-Explicit > > (SE) reservation style (see [RFC3209]). Both the new=20 > and old LSPs > > can share resources at common nodes. The new LSP can be=20 > established > > without tearing down the old LSP in case of reversion=20 > (see section 12). > >=20 > > Section 12 should say: > >=20 > > For "(full) LSP Rerouting", reversion implies that the=20 > old LSP is not > > torn down by the head-end node after the new LSP is=20 > established. For > > reversion, the head-end node re-activates the old LSP=20 > after this has > > recovered. > >=20 > >=20 > >=20 > > Notes > > ----- > > Current text in RFC 4872 describes reversion in the cases=20 > of 1+1 bidirectional > > Protection, 1:N Protection with Extra Traffic and Rerouting=20 > Without Extra > Traffic, > > however it has no description of reversion with (Full) LSP=20 > Rerouting. > > For (full) LSP Rerouting, the description in Section 11=20 > instead implies that > the old > > LSP is torn down. This has led to some confusion as to=20 > whether reversion with > > (full) LSP Rerouting is allowed or not allowed by the RFC.=20 > We believe this was > not > > intentional. The additions would make it clear that=20 > reversion can be supported > > with (Full) LSP Rerouting. > >=20 > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > >=20 > > -------------------------------------- > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > -------------------------------------- > > Title : RSVP-TE Extensions in Support of=20 > End-to-End Generalized > Multi- > > Protocol Label Switching (GMPLS) Recovery > > Publication Date : May 2007 > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D.=20 > Papadimitriou, Ed. > > Category : PROPOSED STANDARD > > Source : Common Control and Measurement Plane > > Area : Routing > > Stream : IETF > > Verifying Party : IESG >=20 > = From giomarti@cisco.com Wed Aug 1 10:39:43 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D2E11E82A1 for ; Wed, 1 Aug 2012 10:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.917 X-Spam-Level: X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbmR07Me4Anx for ; Wed, 1 Aug 2012 10:39:40 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 80D5F11E8168 for ; Wed, 1 Aug 2012 10:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=giomarti@cisco.com; l=1906; q=dns/txt; s=iport; t=1343842779; x=1345052379; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=as0beHbJSfNhbBKnCtQ0ToiqS1lMxCe3krJAkp3GLA0=; b=VOyr7nInG6+JPkoQEjNsa33yq9J25VY0qSGHgb3iLC8rfHo4vE8Ap74i ib/6c9fFV2hAEqqsRkBtjEZH1TAC6AkuSnZHGEWfxDeahMmeXLpWH9h2W aok6scgW0SPd0ioafQbp9SBIrbAXdlaA3ArudTgM2QRZQ26Y1rr+9ewVV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKRpGVCtJV2Y/2dsb2JhbABFuRCBB4IgAQEBAwESASc0CwULAgEINhAyJQIEDieHZQYLnGOgT4tJAhiGD2ADlUeBFI0TgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,695,1336348800"; d="scan'208";a="107527350" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 01 Aug 2012 17:39:39 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q71HdcRq012375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 1 Aug 2012 17:39:39 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.5]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 12:39:38 -0500 From: "Giovanni Martinelli (giomarti)" To: "Giovanni Martinelli (giomarti)" Thread-Topic: Comment on draft-ietf-ccamp-general-constraint-encode-08: priority Thread-Index: AQHNbqOAwicEtWD5nEWGP6luAcXdUpdFj84A Date: Wed, 1 Aug 2012 17:39:37 +0000 Message-ID: <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> In-Reply-To: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.166.99] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.004 x-tm-as-result: No--40.157500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:39:43 -0000 Here my latest mail with comments on wavelength priority...=20 Here my memory on past discussion (please correct if wrong) - last short thread was during ieft83 (around 26/28 march), last mail was f= rom me and did not get answers. The content here below cover that mail as w= ell. - discussions about wl priority happens among authors not on ccamp mailing = list. On the mailing list you announce draft update around dec 2011. =20 Well, I'm not complaining about how discussion happen, simply I saw a not-= trivial addition to wg document, hence my comments. Cheers G On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: > Dear authors / ccamp, >=20 > here a few comments related to the priority field added to draft-ietf-cca= mp-general-constraint-encode: >=20 > A couple of editorial comments > 1) "wavelenght priority" appears in a draft that claim to be general. In= fact is available in "Available Labels Sub-TLV" and "Shared Backup Labels = Sub-TLV". So is a wavelength or label-like priority? > 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0 .= . 7]? >=20 >=20 > Then few other comments > 3) How the priority is used versus the A flag . Draft text report > " =20 > A (Availability bit) =3D 1 or 0 indicates that the labels listed in > the following label set field are available or not available, > respectively, for use at a given priority level as indicated by the > Priority Flags. >=20 > " > So does it means that there could be different "available labels sub-TLVs= " advertised?=20 >=20 > 4) Still unclear to me how this priority is different from the one report= ed in http://tools.ietf.org/html/draft-kattan-wson-property-01 and eventual= ly if this "priority" could fit the LSP priority already available (as one = of the comment we received at that time) >=20 > Cheers > G >=20 From adrian@olddog.co.uk Wed Aug 1 11:02:24 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547AA11E81CE for ; Wed, 1 Aug 2012 11:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id we0n1EfnLzLS for ; Wed, 1 Aug 2012 11:02:22 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 79B1511E8173 for ; Wed, 1 Aug 2012 11:02:21 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q71I1x3j023341; Wed, 1 Aug 2012 19:02:00 +0100 Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q71I1ouX023319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Aug 2012 19:01:54 +0100 From: "Adrian Farrel" To: "'Ong, Lyndon'" , References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> In-Reply-To: Date: Wed, 1 Aug 2012 19:01:49 +0100 Message-ID: <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJG0ydQ2iZ1PPA/LaXiFWLC86ukfAJY9gBGAZM7HFWWMxR7QA== Content-Language: en-gb Cc: dimitri.papadimitriou@alcatel-lucent.be, jplang@ieee.org, dbrungard@att.com Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:02:24 -0000 Hello again, > Thank you for the fast evaluation of the errata. It sounds like the correction that I > suggested has ended up overspecifying the method to do reversion with full > rerouting when it is very possible to support a form of reversion that doesn't > involve maintaining the old LSP. Right, I understand that you want to allow the option of retaining the old working LSP. Also that you have no intention to remove the option of removing the old working LSP. > From your response I believe that you do agree that it was not the intent of the > original specification text to imply that reversion with full rerouting is not allowed Definitely not the intent to imply that reversion with full rerouting is not allowed. Does the text say or even imply this? > (or to require that the old LSP always be torn down in full rerouting) Also no intention to *require* the old LSP to be torn down. My view is that the text is fully conformant with that. I understand that the text does not make an explicit statement of this. > so hopefully > with some more discussion we can determine if there is anything that could be > done to make that clearer. There is, of course, a lot that could be done to make it clearer. But is there really a need? We discussed the point. We agreed it is not prohibited in the RFC. Can we not just move on? Cheers, Adrian > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, July 31, 2012 6:28 PM > To: ccamp@ietf.org > Cc: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel- > lucent.be; stbryant@cisco.com; lberger@labn.net; dbrungard@att.com; Ong, > Lyndon > Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > Hi CCAMP, > > I find that this erratum is raised against two sections one of which I supplied text > for. If this get contentious, I will call on Stewart to call consensus and handle the > Erratum in the system. > > In my opinion, this proposal goes further than the intention of the authors/WG in > publishing 4872. > > With regard to the proposed addition to section 11... > The use of mb4b is already in scope. The existing text says "The new LSP > resources can be established using the make-before-break mechanism," so there > is no need to re-state "The new LSP can be established without tearing down the > old LSP". > > I think your concern here is whether the old LSP is ever torn down. I think that > you are worried that if the old LSP is torn down, it might be impossible to perform > reversion because, after repair, an attempt to revert (also using mb4b) might find > that key resources have been "stolen" by some other LSP. I don't see this as at all > different from the issue of the protection LSP itself. That is, it is of the nature of > LSP Rerouting as a protection mechanism that: > a. protection may fail because of lack of resources b. reversion may fail because > of lack of resources > > *If* reversion is so important, I don't quite see why protection is not important. > If protection is important then you should be using a proper protection > mechanism and not waiting for post facto rerouting. Furthermore, if you require > that the LSP be retained for restoration, why are you not using a protection > mechanism? > > But the general paradigm here is that you are willing to use the best available LSP > when it is set up in the first place, the best available LSP when you re-route after > failure, and the best available LSP when you "revert". > > Lastly, it *does* remain an _option_ to retain the failed LSP in order to switch > back. Nothing in the old text precludes that, although I understand that there is > an implication that it might be expected to be torn down. > > So I conclude that the proposed addition to section 12 is not what the > authors/WG intended. > > We should discuss further. > > Adrian > > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: 31 July 2012 17:39 > > To: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel- > > lucent.be; stbryant@cisco.com; adrian@olddog.co.uk; lberger@labn.net; > > dbrungard@att.com > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC4872 (3304) > > > > > > The following errata report has been submitted for RFC4872, "RSVP-TE > > Extensions in Support of End-to-End Generalized Multi-Protocol Label > > Switching (GMPLS) Recovery". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=4872&eid=3304 > > > > -------------------------------------- > > Type: Technical > > Reported by: Lyndon Ong > > > > Section: 11 & 12 > > > > Original Text > > ------------- > > Section 11 says: > > > > > > (Full) LSP rerouting will be initiated by the head-end node that has > > either detected the LSP failure or received a Notify message and/or a > > PathErr message with the new error code/sub-code "Notify Error/LSP > > Locally Failed" for this LSP. The new LSP resources can be > > established using the make-before-break mechanism, where the new LSP > > is set up before the old LSP is torn down. This is done by using the > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > can share resources at common nodes. > > > > Section 12 says: > > > > [No text on reversion for (full) LSP Rerouting.] > > > > Corrected Text > > -------------- > > Section 11 should say: > > > > > > (Full) LSP rerouting will be initiated by the head-end node that has > > either detected the LSP failure or received a Notify message and/or a > > PathErr message with the new error code/sub-code "Notify Error/LSP > > Locally Failed" for this LSP. The new LSP resources can be > > established using the make-before-break mechanism, where the new LSP > > is set up before the old LSP is torn down. This is done by using the > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > can share resources at common nodes. The new LSP can be established > > without tearing down the old LSP in case of reversion (see section 12). > > > > Section 12 should say: > > > > For "(full) LSP Rerouting", reversion implies that the old LSP is not > > torn down by the head-end node after the new LSP is established. For > > reversion, the head-end node re-activates the old LSP after this has > > recovered. > > > > > > > > Notes > > ----- > > Current text in RFC 4872 describes reversion in the cases of 1+1 > > bidirectional Protection, 1:N Protection with Extra Traffic and > > Rerouting Without Extra > Traffic, > > however it has no description of reversion with (Full) LSP Rerouting. > > For (full) LSP Rerouting, the description in Section 11 instead > > implies that > the old > > LSP is torn down. This has led to some confusion as to whether > > reversion with > > (full) LSP Rerouting is allowed or not allowed by the RFC. We believe > > this was > not > > intentional. The additions would make it clear that reversion can be > > supported with (Full) LSP Rerouting. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or rejected. > > When a decision is reached, the verifying party (IESG) can log in to > > change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > -------------------------------------- > > Title : RSVP-TE Extensions in Support of End-to-End Generalized > Multi- > > Protocol Label Switching (GMPLS) Recovery > > Publication Date : May 2007 > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed. > > Category : PROPOSED STANDARD > > Source : Common Control and Measurement Plane > > Area : Routing > > Stream : IETF > > Verifying Party : IESG From giomarti@cisco.com Wed Aug 1 11:28:53 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FA011E83D1 for ; Wed, 1 Aug 2012 11:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.002 X-Spam-Level: X-Spam-Status: No, score=-10.002 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhmmNACT8VZS for ; Wed, 1 Aug 2012 11:28:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D565711E83D0 for ; Wed, 1 Aug 2012 11:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=giomarti@cisco.com; l=1877; q=dns/txt; s=iport; t=1343845732; x=1345055332; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pJRR2e1dmE4wNXtQTusSqWaJ+0JiJmFUoio0BxWc9Jo=; b=Iu5hoJU9ueB6trSM02+ZxMWsZW65rWzkf5ikkkI9v0UeX+lHRjMdcM8F luKRlAnXiVBxT6gVi9qG4N7zFdcvYQEBCSE++ShdawpXdLw4cJsSpJgub yBNezOeJqv84Tjx5fQaR6spnvTalZ0OyMNy7eMFI+hl6WMvUJo7RLaYpk g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGV0GVCtJV2Y/2dsb2JhbABFuRCBB4IgAQEBAwESASc0CwULAgEINhAyJQIEDieHZQYLnF2gS4tJAhiGD2ADlUeBFI0TgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,695,1336348800"; d="scan'208";a="107562662" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 01 Aug 2012 18:28:52 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q71ISqZ1006896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 1 Aug 2012 18:28:52 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.5]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 13:28:52 -0500 From: "Giovanni Martinelli (giomarti)" To: "Giovanni Martinelli (giomarti)" Thread-Topic: Comment on draft-ietf-ccamp-general-constraint-encode-08: priority Thread-Index: AQHNbqOAwicEtWD5nEWGP6luAcXdUpdFnZCA Date: Wed, 1 Aug 2012 18:28:51 +0000 Message-ID: References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> In-Reply-To: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.166.99] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.000 x-tm-as-result: No--38.749700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <7C8710E2B19195449EC0A30B2AD1A3B9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:28:54 -0000 Here my latest mail with comments on wavelength priority...=20 Just to highlight background (please correct if wrong) - last short thread was during ieft83, last mail was from me and did not ge= t answers. The content here below cover that mail as well. - discussions about wl priority happens among authors not on ccamp mailing = list. On the mailing list you announce such update around dec 2011. =20 Well, I'm not complaining about how discussion happen, simply I saw a not-= trivial addition to wg document, hence my comments. Cheers G On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: > Dear authors / ccamp, >=20 > here a few comments related to the priority field added to draft-ietf-cca= mp-general-constraint-encode: >=20 > A couple of editorial comments > 1) "wavelenght priority" appears in a draft that claim to be general. In= fact is available in "Available Labels Sub-TLV" and "Shared Backup Labels = Sub-TLV". So is a wavelength or label-like priority? > 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0 .= . 7]? >=20 >=20 > Then few other comments > 3) How the priority is used versus the A flag . Draft text report > " =20 > A (Availability bit) =3D 1 or 0 indicates that the labels listed in > the following label set field are available or not available, > respectively, for use at a given priority level as indicated by the > Priority Flags. >=20 > " > So does it means that there could be different "available labels sub-TLVs= " advertised?=20 >=20 > 4) Still unclear to me how this priority is different from the one report= ed in http://tools.ietf.org/html/draft-kattan-wson-property-01 and eventual= ly if this "priority" could fit the LSP priority already available (as one = of the comment we received at that time) >=20 > Cheers > G >=20 From prvs=3560071543=lyong@ciena.com Wed Aug 1 14:47:07 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C8411E8193 for ; Wed, 1 Aug 2012 14:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.553 X-Spam-Level: X-Spam-Status: No, score=-100.553 tagged_above=-999 required=5 tests=[AWL=2.112, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAMAdGzxYiSD for ; Wed, 1 Aug 2012 14:47:05 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id CE23411E811A for ; Wed, 1 Aug 2012 14:47:05 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q71LjfFB020310; Wed, 1 Aug 2012 17:45:41 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 16fb1t09kv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 01 Aug 2012 17:45:41 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT01.ciena.com ([::1]) with mapi; Wed, 1 Aug 2012 17:45:41 -0400 From: "Ong, Lyndon" To: "adrian@olddog.co.uk" , "ccamp@ietf.org" Date: Wed, 1 Aug 2012 17:45:44 -0400 Thread-Topic: [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQJG0ydQ2iZ1PPA/LaXiFWLC86ukfAJY9gBGAZM7HFWWMxR7QIAAKsAA Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> In-Reply-To: <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-19078.001 x-tm-as-result: No--74.987300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-01_05:2012-08-01, 2012-08-01, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208010254 Cc: "dimitri.papadimitriou@alcatel-lucent.be" , "jplang@ieee.org" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:47:07 -0000 Hi Adrian, Sorry, not so fast! Let me make another proposal: Section 11:=20 Existing:=20 (Full) LSP rerouting will be initiated by the head-end node that has either detected the LSP failure or received a Notify message and/or a PathErr message with the new error code/sub-code "Notify Error/LSP Locally Failed" for this LSP. The new LSP resources can be established using the make-before-break mechanism, where the new LSP is set up before the old LSP is torn down. =20 New: (Full) LSP rerouting will be initiated by the head-end node that has either detected the LSP failure or received a Notify message and/or a PathErr message with the new error code/sub-code "Notify Error/LSP Locally Failed" for this LSP. The new LSP resources can be established using the make-before-break mechanism, where the new LSP is set up *while the old LSP is still in place*. =20 Reasoning: No longer implies that the old LSP would necessarily be torn dow= n. Note the text in Section 12 states Reversion refers to a recovery switching operation, where the normal traffic returns to (or remains on) the working LSP when it has recovered from the failure. *Reversion implies that resources remain allocated to the LSP that was originally routed over them even after a failure*. It is important to have mechanisms that allow reversion to be performed with minimal service disruption and reconfiguration. That could be interpreted to rule out Reversion with LSP Rerouting if you m= ust tear down the old LSP. Of course this could be fixed also (for example by deleting the statement). Thanks, Lyndon -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Wednesday, August 01, 2012 11:02 AM To: Ong, Lyndon; ccamp@ietf.org Cc: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel-lucen= t.be; stbryant@cisco.com; lberger@labn.net; dbrungard@att.com; Roch, Evelyn= e Subject: RE: [Technical Errata Reported] RFC4872 (3304) Hello again, > Thank you for the fast evaluation of the errata. It sounds like the correction that I > suggested has ended up overspecifying the method to do reversion with=20 > full rerouting when it is very possible to support a form of reversion=20 > that doesn't involve maintaining the old LSP. Right, I understand that you want to allow the option of retaining the old = working LSP. Also that you have no intention to remove the option of removi= ng the old working LSP. > From your response I believe that you do agree that it was not the=20 > intent of the > original specification text to imply that reversion with full=20 > rerouting is not allowed Definitely not the intent to imply that reversion with full rerouting is no= t allowed. Does the text say or even imply this? > (or to require that the old LSP always be torn down in full rerouting) Also no intention to *require* the old LSP to be torn down.=20 My view is that the text is fully conformant with that. I understand that the text does not make an explicit statement of this. > so hopefully > with some more discussion we can determine if there is anything that=20 > could be done to make that clearer. There is, of course, a lot that could be done to make it clearer. But is th= ere really a need? We discussed the point. We agreed it is not prohibited i= n the RFC. Can we not just move on? Cheers, Adrian > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, July 31, 2012 6:28 PM > To: ccamp@ietf.org > Cc: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel-=20 > lucent.be; stbryant@cisco.com; lberger@labn.net; dbrungard@att.com;=20 > Ong, Lyndon > Subject: RE: [Technical Errata Reported] RFC4872 (3304) >=20 > Hi CCAMP, >=20 > I find that this erratum is raised against two sections one of which I supplied text > for. If this get contentious, I will call on Stewart to call consensus=20 > and handle the > Erratum in the system. >=20 > In my opinion, this proposal goes further than the intention of the=20 > authors/WG in > publishing 4872. >=20 > With regard to the proposed addition to section 11... > The use of mb4b is already in scope. The existing text says "The new=20 > LSP resources can be established using the make-before-break=20 > mechanism," so there is no need to re-state "The new LSP can be=20 > established without tearing down the > old LSP". >=20 > I think your concern here is whether the old LSP is ever torn down. I=20 > think that > you are worried that if the old LSP is torn down, it might be=20 > impossible to perform > reversion because, after repair, an attempt to revert (also using=20 > mb4b) might find > that key resources have been "stolen" by some other LSP. I don't see=20 > this as at all > different from the issue of the protection LSP itself. That is, it is=20 > of the nature of > LSP Rerouting as a protection mechanism that: > a. protection may fail because of lack of resources b. reversion may=20 > fail because > of lack of resources >=20 > *If* reversion is so important, I don't quite see why protection is=20 > not important. > If protection is important then you should be using a proper=20 > protection mechanism and not waiting for post facto rerouting.=20 > Furthermore, if you require > that the LSP be retained for restoration, why are you not using a=20 > protection mechanism? >=20 > But the general paradigm here is that you are willing to use the best available LSP > when it is set up in the first place, the best available LSP when you=20 > re-route after > failure, and the best available LSP when you "revert". >=20 > Lastly, it *does* remain an _option_ to retain the failed LSP in order=20 > to switch > back. Nothing in the old text precludes that, although I understand=20 > that there is > an implication that it might be expected to be torn down. >=20 > So I conclude that the proposed addition to section 12 is not what the=20 > authors/WG intended. >=20 > We should discuss further. >=20 > Adrian >=20 > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: 31 July 2012 17:39 > > To: jplang@ieee.org; yakov@juniper.net;=20 > > dimitri.papadimitriou@alcatel- lucent.be; stbryant@cisco.com;=20 > > adrian@olddog.co.uk; lberger@labn.net; dbrungard@att.com > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC4872 (3304) > > > > > > The following errata report has been submitted for RFC4872, "RSVP-TE=20 > > Extensions in Support of End-to-End Generalized Multi-Protocol Label=20 > > Switching (GMPLS) Recovery". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 > > > > -------------------------------------- > > Type: Technical > > Reported by: Lyndon Ong > > > > Section: 11 & 12 > > > > Original Text > > ------------- > > Section 11 says: > > > > > > (Full) LSP rerouting will be initiated by the head-end node that has > > either detected the LSP failure or received a Notify message and/or = a > > PathErr message with the new error code/sub-code "Notify Error/LSP > > Locally Failed" for this LSP. The new LSP resources can be > > established using the make-before-break mechanism, where the new LSP > > is set up before the old LSP is torn down. This is done by using th= e > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > can share resources at common nodes. > > > > Section 12 says: > > > > [No text on reversion for (full) LSP Rerouting.] > > > > Corrected Text > > -------------- > > Section 11 should say: > > > > > > (Full) LSP rerouting will be initiated by the head-end node that has > > either detected the LSP failure or received a Notify message and/or = a > > PathErr message with the new error code/sub-code "Notify Error/LSP > > Locally Failed" for this LSP. The new LSP resources can be > > established using the make-before-break mechanism, where the new LSP > > is set up before the old LSP is torn down. This is done by using th= e > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > can share resources at common nodes. The new LSP can be established > > without tearing down the old LSP in case of reversion (see section 1= 2). > > > > Section 12 should say: > > > > For "(full) LSP Rerouting", reversion implies that the old LSP is no= t > > torn down by the head-end node after the new LSP is established. For > > reversion, the head-end node re-activates the old LSP after this has > > recovered. > > > > > > > > Notes > > ----- > > Current text in RFC 4872 describes reversion in the cases of 1+1=20 > > bidirectional Protection, 1:N Protection with Extra Traffic and=20 > > Rerouting Without Extra > Traffic, > > however it has no description of reversion with (Full) LSP Rerouting. > > For (full) LSP Rerouting, the description in Section 11 instead=20 > > implies that > the old > > LSP is torn down. This has led to some confusion as to whether=20 > > reversion with > > (full) LSP Rerouting is allowed or not allowed by the RFC. We=20 > > believe this was > not > > intentional. The additions would make it clear that reversion can be=20 > > supported with (Full) LSP Rerouting. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please=20 > > use "Reply All" to discuss whether it should be verified or rejected. > > When a decision is reached, the verifying party (IESG) can log in to=20 > > change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > -------------------------------------- > > Title : RSVP-TE Extensions in Support of End-to-End Generalized > Multi- > > Protocol Label Switching (GMPLS) Recovery > > Publication Date : May 2007 > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou= , Ed. > > Category : PROPOSED STANDARD > > Source : Common Control and Measurement Plane > > Area : Routing > > Stream : IETF > > Verifying Party : IESG From leeyoung@huawei.com Wed Aug 1 15:28:06 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758FA11E8399 for ; Wed, 1 Aug 2012 15:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQnH9F4-fTsH for ; Wed, 1 Aug 2012 15:28:05 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9E111E837F for ; Wed, 1 Aug 2012 15:28:05 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIP55507; Wed, 01 Aug 2012 14:28:05 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 15:25:34 -0700 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.49]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 15:25:37 -0700 From: Leeyoung To: "Giovanni Martinelli (giomarti)" Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority Thread-Index: AQHNcAyuJFh0KZM0PEuR5rvzvXz1+5dFha9g Date: Wed, 1 Aug 2012 22:25:36 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> In-Reply-To: <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:28:06 -0000 Hi Giovanni, The wavelength priority you propose seems different from the what we encode= d per Rao Rajan's suggestion. What we encoded in section 2.3 of gen encode = is not giving wavelength a priority level, among which I believe your wavel= ength property specifies. What we are proposing is what labels are available/not available for each p= riority level (similar to LSP reservation or holding priority) as the follo= wing encoding dictates:=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Reserved | Priority Flags| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where A (Availability bit) =3D 1 or 0 indicates that the labels listed in the following label set field are available or not available, respectively, for use at a given priority level as indicated by the Priority Flags. Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 corresponds to priority level 7. If a bit is set then the labels in the label set field are available or not available as indicated by the A bit for use at that particular priority level. Let's begin if we are in agreement with this point.=20 Thanks. Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G= iovanni Martinelli (giomarti) Sent: Wednesday, August 01, 2012 12:40 PM To: Giovanni Martinelli (giomarti) Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Here my latest mail with comments on wavelength priority...=20 Here my memory on past discussion (please correct if wrong) - last short thread was during ieft83 (around 26/28 march), last mail was f= rom me and did not get answers. The content here below cover that mail as w= ell. - discussions about wl priority happens among authors not on ccamp mailing = list. On the mailing list you announce draft update around dec 2011. =20 Well, I'm not complaining about how discussion happen, simply I saw a not-= trivial addition to wg document, hence my comments. Cheers G On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: > Dear authors / ccamp, >=20 > here a few comments related to the priority field added to draft-ietf-cca= mp-general-constraint-encode: >=20 > A couple of editorial comments > 1) "wavelenght priority" appears in a draft that claim to be general. In= fact is available in "Available Labels Sub-TLV" and "Shared Backup Labels = Sub-TLV". So is a wavelength or label-like priority? > 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0 .= . 7]? >=20 >=20 > Then few other comments > 3) How the priority is used versus the A flag . Draft text report > " =20 > A (Availability bit) =3D 1 or 0 indicates that the labels listed in > the following label set field are available or not available, > respectively, for use at a given priority level as indicated by the > Priority Flags. >=20 > " > So does it means that there could be different "available labels sub-TLVs= " advertised?=20 >=20 > 4) Still unclear to me how this priority is different from the one report= ed in http://tools.ietf.org/html/draft-kattan-wson-property-01 and eventual= ly if this "priority" could fit the LSP priority already available (as one = of the comment we received at that time) >=20 > Cheers > G >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From giomarti@cisco.com Wed Aug 1 15:42:18 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B331B11E811E for ; Wed, 1 Aug 2012 15:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.548 X-Spam-Level: X-Spam-Status: No, score=-9.548 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PP1Z6ut3ObB for ; Wed, 1 Aug 2012 15:42:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAF611E8117 for ; Wed, 1 Aug 2012 15:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=giomarti@cisco.com; l=4566; q=dns/txt; s=iport; t=1343860937; x=1345070537; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9M2wNZVjwhU6+9ycPjv/ZpsZpXgZ1Clxb4LfhVWA2Yo=; b=I5H7fH7Ef1P39+NwXYguqCKirz8ebRRr+B/UW0FFDV7s9+Zd3LFEPMgt +YT24Rc8leX1LmakCkAOYqNTZv7qRcvCXIz3f/dTaD6S62eIpIPnPurjm jpaYNe8S1tHh+CHqNKHzrzmhC1QVQ+shS4AjxzMuPLDQLDTtx5JbFjeCr w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPGvGVCtJV2d/2dsb2JhbABFuRKBB4IgAQEBAwEBAQEPASc0CwUHBAIBCBEEAQEBHgkHJwsUCQgCBA4FIodlBgudB6BCi0kCGIYPYAOVR4EUjROBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,696,1336348800"; d="scan'208";a="107637083" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 01 Aug 2012 22:42:17 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q71MgGRd010854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 22:42:17 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.5]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 17:42:16 -0500 From: "Giovanni Martinelli (giomarti)" To: Leeyoung Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority Thread-Index: AQHNbqOAwicEtWD5nEWGP6luAcXdUpdFj84AgABP4QCAAASpgA== Date: Wed, 1 Aug 2012 22:42:16 +0000 Message-ID: <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.92.5] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.004 x-tm-as-result: No--51.949300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:42:18 -0000 Hi Young, thx for the prompt reply On Aug 2, 2012, at 24:25 , Leeyoung wrote: > Hi Giovanni, >=20 > The wavelength priority you propose seems different from the what we enco= ded per Rao Rajan's suggestion. What we encoded in section 2.3 of gen encod= e is not giving wavelength a priority level, among which I believe your wav= elength property specifies. >=20 > What we are proposing is what labels are available/not available for each= priority level (similar to LSP reservation or holding priority) as the fol= lowing encoding dictates:=20 >=20 GM> So at the end is a "Label Priority" ? With the Label_Set granularity in= stead of the single Label? =20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A| Reserved | Priority Flags| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Label Set Field | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Where >=20 > A (Availability bit) =3D 1 or 0 indicates that the labels listed in > the following label set field are available or not available, > respectively, for use at a given priority level as indicated by the > Priority Flags. GM> The reading here suggest me that there could be multiple objects (I bet= up to 8) packed up somewere (e.g. something like sub-tlvs in the link adve= rtisement). Is my interpretation correct? Cheers G >=20 > Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 > corresponds to priority level 7. If a bit is set then the labels in > the label set field are available or not available as indicated by > the A bit for use at that particular priority level. >=20 > Let's begin if we are in agreement with this point.=20 >=20 > Thanks. > Young >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of= Giovanni Martinelli (giomarti) > Sent: Wednesday, August 01, 2012 12:40 PM > To: Giovanni Martinelli (giomarti) > Cc: CCAMP > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encod= e-08: priority >=20 > Here my latest mail with comments on wavelength priority...=20 >=20 > Here my memory on past discussion (please correct if wrong) > - last short thread was during ieft83 (around 26/28 march), last mail was= from me and did not get answers. The content here below cover that mail as= well. > - discussions about wl priority happens among authors not on ccamp mailin= g list. On the mailing list you announce draft update around dec 2011. =20 >=20 > Well, I'm not complaining about how discussion happen, simply I saw a no= t-trivial addition to wg document, hence my comments. >=20 > Cheers > G >=20 >=20 >=20 > On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: >=20 >> Dear authors / ccamp, >>=20 >> here a few comments related to the priority field added to draft-ietf-cc= amp-general-constraint-encode: >>=20 >> A couple of editorial comments >> 1) "wavelenght priority" appears in a draft that claim to be general. I= n fact is available in "Available Labels Sub-TLV" and "Shared Backup Labels= Sub-TLV". So is a wavelength or label-like priority? >> 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0 = .. 7]? >>=20 >>=20 >> Then few other comments >> 3) How the priority is used versus the A flag . Draft text report >> " =20 >> A (Availability bit) =3D 1 or 0 indicates that the labels listed in >> the following label set field are available or not available, >> respectively, for use at a given priority level as indicated by the >> Priority Flags. >>=20 >> " >> So does it means that there could be different "available labels sub-TLV= s" advertised?=20 >>=20 >> 4) Still unclear to me how this priority is different from the one repor= ted in http://tools.ietf.org/html/draft-kattan-wson-property-01 and eventua= lly if this "priority" could fit the LSP priority already available (as one= of the comment we received at that time) >>=20 >> Cheers >> G >>=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From adrian@olddog.co.uk Wed Aug 1 16:11:18 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422DE11E8288 for ; Wed, 1 Aug 2012 16:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxX+WShSO9hT for ; Wed, 1 Aug 2012 16:11:17 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEA411E81CC for ; Wed, 1 Aug 2012 16:11:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q71NB2jv015618; Thu, 2 Aug 2012 00:11:02 +0100 Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q71NAoPH015548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 00:10:56 +0100 From: "Adrian Farrel" To: "'Ong, Lyndon'" , References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> In-Reply-To: Date: Thu, 2 Aug 2012 00:10:49 +0100 Message-ID: <048101cd703a$ea2c5380$be84fa80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJG0ydQ2iZ1PPA/LaXiFWLC86ukfAJY9gBGAZM7HFUBWAcudgGj7AJ1lhuNFlA= Content-Language: en-gb Cc: dimitri.papadimitriou@alcatel-lucent.be, jplang@ieee.org, dbrungard@att.com Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:11:18 -0000 My personal opinion at this point is that you are proposing wordsmithing that would have been accepted during document development, but which is not necessary at this stage. Any misunderstanding in reading this document is due to an over-enthusiastic legalistic reading of the text and not an understanding of the technology. Adrian > -----Original Message----- > From: Ong, Lyndon [mailto:Lyong@ciena.com] > Sent: 01 August 2012 22:46 > To: adrian@olddog.co.uk; ccamp@ietf.org > Cc: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel- > lucent.be; stbryant@cisco.com; lberger@labn.net; dbrungard@att.com; Roch, > Evelyne > Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > Hi Adrian, > > Sorry, not so fast! Let me make another proposal: > > Section 11: > Existing: > (Full) LSP rerouting will be initiated by the head-end node that has > either detected the LSP failure or received a Notify message and/or a > PathErr message with the new error code/sub-code "Notify Error/LSP > Locally Failed" for this LSP. The new LSP resources can be > established using the make-before-break mechanism, where the new LSP > is set up before the old LSP is torn down. > > New: > (Full) LSP rerouting will be initiated by the head-end node that has > either detected the LSP failure or received a Notify message and/or a > PathErr message with the new error code/sub-code "Notify Error/LSP > Locally Failed" for this LSP. The new LSP resources can be > established using the make-before-break mechanism, where the new LSP > is set up *while the old LSP is still in place*. > > Reasoning: No longer implies that the old LSP would necessarily be torn down. > > Note the text in Section 12 states > Reversion refers to a recovery switching operation, where the normal > traffic returns to (or remains on) the working LSP when it has > recovered from the failure. *Reversion implies that resources remain > allocated to the LSP that was originally routed over them even after > a failure*. It is important to have mechanisms that allow reversion > to be performed with minimal service disruption and reconfiguration. > > That could be interpreted to rule out Reversion with LSP Rerouting if you must > tear down the old LSP. > Of course this could be fixed also (for example by deleting the statement). > > Thanks, > > Lyndon > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, August 01, 2012 11:02 AM > To: Ong, Lyndon; ccamp@ietf.org > Cc: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel- > lucent.be; stbryant@cisco.com; lberger@labn.net; dbrungard@att.com; Roch, > Evelyne > Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > Hello again, > > > Thank you for the fast evaluation of the errata. It sounds like the > correction that I > > suggested has ended up overspecifying the method to do reversion with > > full rerouting when it is very possible to support a form of reversion > > that doesn't involve maintaining the old LSP. > > Right, I understand that you want to allow the option of retaining the old working > LSP. Also that you have no intention to remove the option of removing the old > working LSP. > > > From your response I believe that you do agree that it was not the > > intent of > the > > original specification text to imply that reversion with full > > rerouting is not > allowed > > Definitely not the intent to imply that reversion with full rerouting is not allowed. > Does the text say or even imply this? > > > (or to require that the old LSP always be torn down in full rerouting) > > Also no intention to *require* the old LSP to be torn down. > My view is that the text is fully conformant with that. > I understand that the text does not make an explicit statement of this. > > > so hopefully > > with some more discussion we can determine if there is anything that > > could be done to make that clearer. > > There is, of course, a lot that could be done to make it clearer. But is there really a > need? We discussed the point. We agreed it is not prohibited in the RFC. Can we > not just move on? > > Cheers, > Adrian > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: Tuesday, July 31, 2012 6:28 PM > > To: ccamp@ietf.org > > Cc: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel- > > lucent.be; stbryant@cisco.com; lberger@labn.net; dbrungard@att.com; > > Ong, Lyndon > > Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > > > Hi CCAMP, > > > > I find that this erratum is raised against two sections one of which I > supplied text > > for. If this get contentious, I will call on Stewart to call consensus > > and > handle the > > Erratum in the system. > > > > In my opinion, this proposal goes further than the intention of the > > authors/WG > in > > publishing 4872. > > > > With regard to the proposed addition to section 11... > > The use of mb4b is already in scope. The existing text says "The new > > LSP resources can be established using the make-before-break > > mechanism," so there is no need to re-state "The new LSP can be > > established without tearing down > the > > old LSP". > > > > I think your concern here is whether the old LSP is ever torn down. I > > think > that > > you are worried that if the old LSP is torn down, it might be > > impossible to > perform > > reversion because, after repair, an attempt to revert (also using > > mb4b) might > find > > that key resources have been "stolen" by some other LSP. I don't see > > this as > at all > > different from the issue of the protection LSP itself. That is, it is > > of the > nature of > > LSP Rerouting as a protection mechanism that: > > a. protection may fail because of lack of resources b. reversion may > > fail > because > > of lack of resources > > > > *If* reversion is so important, I don't quite see why protection is > > not > important. > > If protection is important then you should be using a proper > > protection mechanism and not waiting for post facto rerouting. > > Furthermore, if you > require > > that the LSP be retained for restoration, why are you not using a > > protection mechanism? > > > > But the general paradigm here is that you are willing to use the best > available LSP > > when it is set up in the first place, the best available LSP when you > > re-route > after > > failure, and the best available LSP when you "revert". > > > > Lastly, it *does* remain an _option_ to retain the failed LSP in order > > to > switch > > back. Nothing in the old text precludes that, although I understand > > that there > is > > an implication that it might be expected to be torn down. > > > > So I conclude that the proposed addition to section 12 is not what the > > authors/WG intended. > > > > We should discuss further. > > > > Adrian > > > > > -----Original Message----- > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > Sent: 31 July 2012 17:39 > > > To: jplang@ieee.org; yakov@juniper.net; > > > dimitri.papadimitriou@alcatel- lucent.be; stbryant@cisco.com; > > > adrian@olddog.co.uk; lberger@labn.net; dbrungard@att.com > > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > > Subject: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > > The following errata report has been submitted for RFC4872, "RSVP-TE > > > Extensions in Support of End-to-End Generalized Multi-Protocol Label > > > Switching (GMPLS) Recovery". > > > > > > -------------------------------------- > > > You may review the report below and at: > > > http://www.rfc-editor.org/errata_search.php?rfc=4872&eid=3304 > > > > > > -------------------------------------- > > > Type: Technical > > > Reported by: Lyndon Ong > > > > > > Section: 11 & 12 > > > > > > Original Text > > > ------------- > > > Section 11 says: > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end node that has > > > either detected the LSP failure or received a Notify message and/or a > > > PathErr message with the new error code/sub-code "Notify Error/LSP > > > Locally Failed" for this LSP. The new LSP resources can be > > > established using the make-before-break mechanism, where the new LSP > > > is set up before the old LSP is torn down. This is done by using the > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > > can share resources at common nodes. > > > > > > Section 12 says: > > > > > > [No text on reversion for (full) LSP Rerouting.] > > > > > > Corrected Text > > > -------------- > > > Section 11 should say: > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end node that has > > > either detected the LSP failure or received a Notify message and/or a > > > PathErr message with the new error code/sub-code "Notify Error/LSP > > > Locally Failed" for this LSP. The new LSP resources can be > > > established using the make-before-break mechanism, where the new LSP > > > is set up before the old LSP is torn down. This is done by using the > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > > can share resources at common nodes. The new LSP can be established > > > without tearing down the old LSP in case of reversion (see section 12). > > > > > > Section 12 should say: > > > > > > For "(full) LSP Rerouting", reversion implies that the old LSP is not > > > torn down by the head-end node after the new LSP is established. For > > > reversion, the head-end node re-activates the old LSP after this has > > > recovered. > > > > > > > > > > > > Notes > > > ----- > > > Current text in RFC 4872 describes reversion in the cases of 1+1 > > > bidirectional Protection, 1:N Protection with Extra Traffic and > > > Rerouting Without Extra > > Traffic, > > > however it has no description of reversion with (Full) LSP Rerouting. > > > For (full) LSP Rerouting, the description in Section 11 instead > > > implies that > > the old > > > LSP is torn down. This has led to some confusion as to whether > > > reversion with > > > (full) LSP Rerouting is allowed or not allowed by the RFC. We > > > believe this was > > not > > > intentional. The additions would make it clear that reversion can be > > > supported with (Full) LSP Rerouting. > > > > > > Instructions: > > > ------------- > > > This errata is currently posted as "Reported". If necessary, please > > > use "Reply All" to discuss whether it should be verified or rejected. > > > When a decision is reached, the verifying party (IESG) can log in to > > > change the status and edit the report, if necessary. > > > > > > -------------------------------------- > > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > > -------------------------------------- > > > Title : RSVP-TE Extensions in Support of End-to-End > Generalized > > Multi- > > > Protocol Label Switching (GMPLS) Recovery > > > Publication Date : May 2007 > > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed. > > > Category : PROPOSED STANDARD > > > Source : Common Control and Measurement Plane > > > Area : Routing > > > Stream : IETF > > > Verifying Party : IESG From leeyoung@huawei.com Wed Aug 1 16:20:58 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA0311E83B3 for ; Wed, 1 Aug 2012 16:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e2B46XZkMiB for ; Wed, 1 Aug 2012 16:20:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D9C8E11E8391 for ; Wed, 1 Aug 2012 16:20:57 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIP58118; Wed, 01 Aug 2012 15:20:57 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 16:18:48 -0700 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.49]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 16:18:42 -0700 From: Leeyoung To: "Giovanni Martinelli (giomarti)" Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority Thread-Index: AQHNcAyuJFh0KZM0PEuR5rvzvXz1+5dFha9ggAB9XQD//4xN4A== Date: Wed, 1 Aug 2012 23:18:41 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172905ED70@dfweml511-mbs.china.huawei.com> References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> In-Reply-To: <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:20:59 -0000 Hi Giovanni, Thanks for your quick feedback.=20 Here's my response to your comments. Please see in-line. Thanks. Young -----Original Message----- From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com]=20 Sent: Wednesday, August 01, 2012 5:42 PM To: Leeyoung Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Young, thx for the prompt reply On Aug 2, 2012, at 24:25 , Leeyoung wrote: > Hi Giovanni, >=20 > The wavelength priority you propose seems different from the what we enco= ded per Rao Rajan's suggestion. What we encoded in section 2.3 of gen encod= e is not giving wavelength a priority level, among which I believe your wav= elength property specifies. >=20 > What we are proposing is what labels are available/not available for each= priority level (similar to LSP reservation or holding priority) as the fol= lowing encoding dictates:=20 >=20 GM> So at the end is a "Label Priority" ? With the Label_Set granularity in= stead of the single Label? =20 YOUNG>> No, this is not "label priority". Label is not "assigned" a priorit= y. Label is neutral. Say, you have five wavelengths available for grab and = you have two priorities you are aware of which is service level (e.g., LSP)= . For higher priority service, you may want to all your five wavelengths (w= 1-w5) available for grab while for lower priority, you may restrict to less= number of wavelengths, say three wavelengths only (e.g., w1-w3). Here you = can see individual wavelength is not assigned a priority. This is analogous= to how much BW availability for each priority in MPLS network, except that= we need to express in wavelength level. =20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A| Reserved | Priority Flags| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Label Set Field | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Where >=20 > A (Availability bit) =3D 1 or 0 indicates that the labels listed in > the following label set field are available or not available, > respectively, for use at a given priority level as indicated by the > Priority Flags. GM> The reading here suggest me that there could be multiple objects (I bet= up to 8) packed up somewere (e.g. something like sub-tlvs in the link adve= rtisement). Is my interpretation correct? YOUNG>> Yes.=20 Cheers G >=20 > Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 > corresponds to priority level 7. If a bit is set then the labels in > the label set field are available or not available as indicated by > the A bit for use at that particular priority level. >=20 > Let's begin if we are in agreement with this point.=20 >=20 > Thanks. > Young >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of= Giovanni Martinelli (giomarti) > Sent: Wednesday, August 01, 2012 12:40 PM > To: Giovanni Martinelli (giomarti) > Cc: CCAMP > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encod= e-08: priority >=20 > Here my latest mail with comments on wavelength priority...=20 >=20 > Here my memory on past discussion (please correct if wrong) > - last short thread was during ieft83 (around 26/28 march), last mail was= from me and did not get answers. The content here below cover that mail as= well. > - discussions about wl priority happens among authors not on ccamp mailin= g list. On the mailing list you announce draft update around dec 2011. =20 >=20 > Well, I'm not complaining about how discussion happen, simply I saw a no= t-trivial addition to wg document, hence my comments. >=20 > Cheers > G >=20 >=20 >=20 > On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: >=20 >> Dear authors / ccamp, >>=20 >> here a few comments related to the priority field added to draft-ietf-cc= amp-general-constraint-encode: >>=20 >> A couple of editorial comments >> 1) "wavelenght priority" appears in a draft that claim to be general. I= n fact is available in "Available Labels Sub-TLV" and "Shared Backup Labels= Sub-TLV". So is a wavelength or label-like priority? >> 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0 = .. 7]? >>=20 >>=20 >> Then few other comments >> 3) How the priority is used versus the A flag . Draft text report >> " =20 >> A (Availability bit) =3D 1 or 0 indicates that the labels listed in >> the following label set field are available or not available, >> respectively, for use at a given priority level as indicated by the >> Priority Flags. >>=20 >> " >> So does it means that there could be different "available labels sub-TLV= s" advertised?=20 >>=20 >> 4) Still unclear to me how this priority is different from the one repor= ted in http://tools.ietf.org/html/draft-kattan-wson-property-01 and eventua= lly if this "priority" could fit the LSP priority already available (as one= of the comment we received at that time) >>=20 >> Cheers >> G >>=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From kpithewan@infinera.com Wed Aug 1 16:41:21 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118A811E8279 for ; Wed, 1 Aug 2012 16:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[AWL=1.235, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkp3pWlNvf0Q for ; Wed, 1 Aug 2012 16:41:20 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id ECAE711E81DD for ; Wed, 1 Aug 2012 16:41:19 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0283.003; Wed, 1 Aug 2012 16:41:19 -0700 From: Khuzema Pithewan To: "CCAMP (ccamp@ietf.org)" Thread-Topic: New Version Notification for draft-rao-ccamp-otn-mlnmrn-ospfte-ext-00.txt Thread-Index: AQHNcD4a8Tq8x9cPWEC4esrGJoELS5dFnIFg Date: Wed, 1 Aug 2012 23:41:19 +0000 Message-ID: References: <20120801233334.6592.6622.idtracker@ietfa.amsl.com> In-Reply-To: <20120801233334.6592.6622.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CCAMP] FW: New Version Notification for draft-rao-ccamp-otn-mlnmrn-ospfte-ext-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:41:21 -0000 SGksDQoNCldlIGhhdmUgdXBsb2FkZWQgYSBkcmFmdCB0b2RheSBhZGRyZXNzaW5nIG1sbi9tcm4g ZXh0ZW5zaW9ucyBmb3IgT1ROIHJvdXRpbmcuIFBscyByZXZpZXcgYW5kIGxldCB1cyBrbm93IGNv bW1lbnRzDQoNCkF1dGhvcnMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10g DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAwMSwgMjAxMiA0OjM0IFBNDQpUbzogS2h1emVtYSBQ aXRoZXdhbg0KQ2M6IFJhamFuIFJhbw0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1yYW8tY2NhbXAtb3RuLW1sbm1ybi1vc3BmdGUtZXh0LTAwLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yYW8tY2NhbXAtb3RuLW1sbm1ybi1vc3BmdGUtZXh0 LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLaHV6ZW1hIFBpdGhl d2FuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFm dC1yYW8tY2NhbXAtb3RuLW1sbm1ybi1vc3BmdGUtZXh0DQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJ CSBPU1BGLVRFIGV4dGVuc2lvbnMgZm9yIE1MTk1STiBiYXNlZCBvbiBPVE4NCkNyZWF0aW9uIGRh dGU6CSAyMDEyLTA4LTAxDQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBv ZiBwYWdlczogNQ0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1yYW8tY2NhbXAtb3RuLW1sbm1ybi1vc3BmdGUtZXh0LTAwLnR4dA0KU3Rh dHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhby1j Y2FtcC1vdG4tbWxubXJuLW9zcGZ0ZS1leHQNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtcmFvLWNjYW1wLW90bi1tbG5tcm4tb3NwZnRlLWV4dC0wMA0K DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgT1NQRiBleHRlbnNpb25z IGZvciBtdWx0aS1sYXllci9tdWx0aS1yZWdpb24NCiAgIHdoZXJlIG9uZSBvZiB0aGUgcmVnaW9u cyBpcyBPVE4uDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0K From jdrake@juniper.net Wed Aug 1 16:50:37 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5DF21F889C for ; Wed, 1 Aug 2012 16:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.566 X-Spam-Level: X-Spam-Status: No, score=-4.566 tagged_above=-999 required=5 tests=[AWL=1.433, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNmNJpRUzfJM for ; Wed, 1 Aug 2012 16:50:35 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 9402D21F85D1 for ; Wed, 1 Aug 2012 16:50:30 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUBnAxPMk+rfxFo/iba4bdaz79tzmgcO1@postini.com; Wed, 01 Aug 2012 16:50:34 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 1 Aug 2012 16:49:11 -0700 From: John E Drake To: "adrian@olddog.co.uk" , "'Ong, Lyndon'" , "ccamp@ietf.org" Date: Wed, 1 Aug 2012 16:49:10 -0700 Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQJG0ydQ2iZ1PPA/LaXiFWLC86ukfAJY9gBGAZM7HFWWMxR7QIAAY78g Message-ID: <5E893DB832F57341992548CDBB333163A5A8E93302@EMBX01-HQ.jnpr.net> References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> In-Reply-To: <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jplang@ieee.org" , "dimitri.papadimitriou@alcatel-lucent.be" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:50:37 -0000 Is it not the case that the old LSP is broken? In which case it needs to b= e cleaned up and re-signaled. Sent from my iPhone > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Adrian Farrel > Sent: Wednesday, August 01, 2012 11:02 AM > To: 'Ong, Lyndon'; ccamp@ietf.org > Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org; > dbrungard@att.com > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >=20 > Hello again, >=20 > > Thank you for the fast evaluation of the errata. It sounds like the > correction that I > > suggested has ended up overspecifying the method to do reversion with > > full rerouting when it is very possible to support a form of > reversion > > that doesn't involve maintaining the old LSP. >=20 > Right, I understand that you want to allow the option of retaining the > old working LSP. Also that you have no intention to remove the option > of removing the old working LSP. >=20 > > From your response I believe that you do agree that it was not the > > intent of > the > > original specification text to imply that reversion with full > > rerouting is not > allowed >=20 > Definitely not the intent to imply that reversion with full rerouting > is not allowed. > Does the text say or even imply this? >=20 > > (or to require that the old LSP always be torn down in full > rerouting) >=20 > Also no intention to *require* the old LSP to be torn down. > My view is that the text is fully conformant with that. > I understand that the text does not make an explicit statement of this. >=20 > > so hopefully > > with some more discussion we can determine if there is anything that > > could be done to make that clearer. >=20 > There is, of course, a lot that could be done to make it clearer. But > is there really a need? We discussed the point. We agreed it is not > prohibited in the RFC. Can we not just move on? >=20 > Cheers, > Adrian > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: Tuesday, July 31, 2012 6:28 PM > > To: ccamp@ietf.org > > Cc: jplang@ieee.org; yakov@juniper.net; > dimitri.papadimitriou@alcatel- > > lucent.be; stbryant@cisco.com; lberger@labn.net; dbrungard@att.com; > > Ong, Lyndon > > Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > > > Hi CCAMP, > > > > I find that this erratum is raised against two sections one of which > I > supplied text > > for. If this get contentious, I will call on Stewart to call > consensus > > and > handle the > > Erratum in the system. > > > > In my opinion, this proposal goes further than the intention of the > > authors/WG > in > > publishing 4872. > > > > With regard to the proposed addition to section 11... > > The use of mb4b is already in scope. The existing text says "The new > > LSP resources can be established using the make-before-break > > mechanism," so there is no need to re-state "The new LSP can be > > established without tearing down > the > > old LSP". > > > > I think your concern here is whether the old LSP is ever torn down. I > > think > that > > you are worried that if the old LSP is torn down, it might be > > impossible to > perform > > reversion because, after repair, an attempt to revert (also using > > mb4b) might > find > > that key resources have been "stolen" by some other LSP. I don't see > > this as > at all > > different from the issue of the protection LSP itself. That is, it is > > of the > nature of > > LSP Rerouting as a protection mechanism that: > > a. protection may fail because of lack of resources b. reversion may > > fail > because > > of lack of resources > > > > *If* reversion is so important, I don't quite see why protection is > > not > important. > > If protection is important then you should be using a proper > > protection mechanism and not waiting for post facto rerouting. > > Furthermore, if you > require > > that the LSP be retained for restoration, why are you not using a > > protection mechanism? > > > > But the general paradigm here is that you are willing to use the best > available LSP > > when it is set up in the first place, the best available LSP when you > > re-route > after > > failure, and the best available LSP when you "revert". > > > > Lastly, it *does* remain an _option_ to retain the failed LSP in > order > > to > switch > > back. Nothing in the old text precludes that, although I understand > > that there > is > > an implication that it might be expected to be torn down. > > > > So I conclude that the proposed addition to section 12 is not what > the > > authors/WG intended. > > > > We should discuss further. > > > > Adrian > > > > > -----Original Message----- > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > Sent: 31 July 2012 17:39 > > > To: jplang@ieee.org; yakov@juniper.net; > > > dimitri.papadimitriou@alcatel- lucent.be; stbryant@cisco.com; > > > adrian@olddog.co.uk; lberger@labn.net; dbrungard@att.com > > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > > Subject: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > > The following errata report has been submitted for RFC4872, "RSVP- > TE > > > Extensions in Support of End-to-End Generalized Multi-Protocol > Label > > > Switching (GMPLS) Recovery". > > > > > > -------------------------------------- > > > You may review the report below and at: > > > http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 > > > > > > -------------------------------------- > > > Type: Technical > > > Reported by: Lyndon Ong > > > > > > Section: 11 & 12 > > > > > > Original Text > > > ------------- > > > Section 11 says: > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end node that > has > > > either detected the LSP failure or received a Notify message > and/or a > > > PathErr message with the new error code/sub-code "Notify > Error/LSP > > > Locally Failed" for this LSP. The new LSP resources can be > > > established using the make-before-break mechanism, where the new > LSP > > > is set up before the old LSP is torn down. This is done by > using the > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared- > Explicit > > > (SE) reservation style (see [RFC3209]). Both the new and old > LSPs > > > can share resources at common nodes. > > > > > > Section 12 says: > > > > > > [No text on reversion for (full) LSP Rerouting.] > > > > > > Corrected Text > > > -------------- > > > Section 11 should say: > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end node that > has > > > either detected the LSP failure or received a Notify message > and/or a > > > PathErr message with the new error code/sub-code "Notify > Error/LSP > > > Locally Failed" for this LSP. The new LSP resources can be > > > established using the make-before-break mechanism, where the new > LSP > > > is set up before the old LSP is torn down. This is done by > using the > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared- > Explicit > > > (SE) reservation style (see [RFC3209]). Both the new and old > LSPs > > > can share resources at common nodes. The new LSP can be > established > > > without tearing down the old LSP in case of reversion (see > section 12). > > > > > > Section 12 should say: > > > > > > For "(full) LSP Rerouting", reversion implies that the old LSP > is not > > > torn down by the head-end node after the new LSP is established. > For > > > reversion, the head-end node re-activates the old LSP after this > has > > > recovered. > > > > > > > > > > > > Notes > > > ----- > > > Current text in RFC 4872 describes reversion in the cases of 1+1 > > > bidirectional Protection, 1:N Protection with Extra Traffic and > > > Rerouting Without Extra > > Traffic, > > > however it has no description of reversion with (Full) LSP > Rerouting. > > > For (full) LSP Rerouting, the description in Section 11 instead > > > implies that > > the old > > > LSP is torn down. This has led to some confusion as to whether > > > reversion with > > > (full) LSP Rerouting is allowed or not allowed by the RFC. We > > > believe this was > > not > > > intentional. The additions would make it clear that reversion can > be > > > supported with (Full) LSP Rerouting. > > > > > > Instructions: > > > ------------- > > > This errata is currently posted as "Reported". If necessary, please > > > use "Reply All" to discuss whether it should be verified or > rejected. > > > When a decision is reached, the verifying party (IESG) can log in > to > > > change the status and edit the report, if necessary. > > > > > > -------------------------------------- > > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > > -------------------------------------- > > > Title : RSVP-TE Extensions in Support of End-to-End > Generalized > > Multi- > > > Protocol Label Switching (GMPLS) Recovery > > > Publication Date : May 2007 > > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > Papadimitriou, Ed. > > > Category : PROPOSED STANDARD > > > Source : Common Control and Measurement Plane > > > Area : Routing > > > Stream : IETF > > > Verifying Party : IESG >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From acee.lindem@ericsson.com Wed Aug 1 17:26:00 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC5611E80EC; Wed, 1 Aug 2012 17:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKp21jr2GioE; Wed, 1 Aug 2012 17:25:58 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id CE81411E80BA; Wed, 1 Aug 2012 17:25:57 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q720PqoE022473; Wed, 1 Aug 2012 19:25:53 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.190]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 1 Aug 2012 20:25:46 -0400 From: Acee Lindem To: "iesg-secretary@ietf.org" Date: Wed, 1 Aug 2012 20:25:45 -0400 Thread-Topic: Last Call: (ASON Routing for OSPFv2 Protocols) to Proposed Standard Thread-Index: Ac1wRVt1dEOeYFePQ1qlx24ZFc+WlQ== Message-ID: <76B81EC9-E7C5-45E3-9245-B07F013F8324@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-23-487725107"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: CCAMP , Andy Malis Subject: Re: [CCAMP] Last Call: (ASON Routing for OSPFv2 Protocols) to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:26:00 -0000 --Apple-Mail-23-487725107 Content-Type: multipart/alternative; boundary=Apple-Mail-22-487725093 --Apple-Mail-22-487725093 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, The authors have received comments from Stephen Shew regarding our = references to ASON name spaces and would like to=20 change the text to clarify these references. The proposed changes are = included below. Unless anyone=20 has any serious objections, we intend to make these changes as part of = the IETF last call process.=20 Any further discussion will take place on the CCAMP list. Thanks, Acee Lindem dhcp-421c:Desktop ealflin$ diff -c = draft-ietf-ccamp-rfc5787bis-05.txt.orig = draft-ietf-ccamp-rfc5787bis-05.txt *** draft-ietf-ccamp-rfc5787bis-05.txt.orig 2012-07-24 = 20:51:22.000000000 -0400 --- draft-ietf-ccamp-rfc5787bis-05.txt 2012-07-31 21:26:18.000000000 = -0400 *************** *** 354,366 **** and corresponding identifiers defined for GMPLS routing, and how these support the physical (or logical) separation of transport = plane entities and control plane components. GMPLS supports this ! separation of identifiers and planes. =20 In the context of OSPF Traffic Engineering (TE), an ASON transport node corresponds to a unique OSPF TE node. An OSPF TE node is uniquely identified by the TE Router Address TLV [RFC3630]. In this document, this TE Router Address is referred to as the TE Router = ID, ! which is in the ASON SCN name space. The TE Router ID should not = be confused with the OSPF Router ID which uniquely identifies an OSPF router within an OSPF routing domain [RFC2328] and is in a name = space for control plane components. --- 354,387 ---- and corresponding identifiers defined for GMPLS routing, and how these support the physical (or logical) separation of transport = plane entities and control plane components. GMPLS supports this ! separation of identifiers and planes.=20 !=20 ! ASON refers to transport plane identifiers as SubNetwork Points or=20= ! (SNPs). An SNP is an abstraction that represents an actual or=20 ! potential underlying connection point (CP) (or connection = termination ! point (CTP)) or an actual or potential termination connection point ! (TCP) or trail termination point (TTP). Several SNPs (in different=20= ! subnetwork partitions) may represent the same TCP or CP [G.8080].=20= ! A collection of SNPs used for ASON routing is referred to as the ! SubNetork Point Pool (SNPP) and its identifiers are from the SNPP ! name space. In this context, an SNPP would refer to Optical=20 ! Transport Network (OTN) switch and an SNP would be an identifier ! for an optical channel.=20 !=20 ! Conversely, the Signaling Control Network (SCN) consists of the=20 ! communication paths over which ASON Protocol Controller (PC)=20 ! adjacencies are established, and the control plane consists of the ! ASON PC instances and their corresponding adjacencies. Given=20 ! that OSPF is always transpored over IP, the SCN and control plane ! will normally coincide. However, a given ASON PC instance may=20 ! establish adjacencies over multiple SCNs and multiple ASON PC=20 ! instances can use the same SCN. =20 In the context of OSPF Traffic Engineering (TE), an ASON transport node corresponds to a unique OSPF TE node. An OSPF TE node is uniquely identified by the TE Router Address TLV [RFC3630]. In this document, this TE Router Address is referred to as the TE Router = ID, ! which is in the ASON SNPP name space. The TE Router ID should not = be confused with the OSPF Router ID which uniquely identifies an OSPF router within an OSPF routing domain [RFC2328] and is in a name = space for control plane components. *************** *** 370,376 **** OSPF TE node IP address, i.e., the IP address is always reachable when there is IP connectivity to the associated OSPF TE node. However, in the context of the OSPF ASON operation, the TE Router = ID ! is an identifier within the ASON SCN.=20 =20 ASON defines a Routing Controller (RC) as an entity that handles (abstract) information needed for routing and the routing = information --- 391,397 ---- OSPF TE node IP address, i.e., the IP address is always reachable when there is IP connectivity to the associated OSPF TE node. However, in the context of the OSPF ASON operation, the TE Router = ID ! is an identifier within the ASON SNPP name space.=20 =20 ASON defines a Routing Controller (RC) as an entity that handles (abstract) information needed for routing and the routing = information *************** *** 398,404 **** =20 In ASON, reachability refers to the set of endpoints reachable in = the transport plane by an associated ASON transport node. Reachable ! entities are identified in the ASON SCN name space.=20 =20 In order to advertise blocks of reachable address prefixes, a summarization mechanism is introduced that is based on the = techniques --- 419,426 ---- =20 In ASON, reachability refers to the set of endpoints reachable in = the transport plane by an associated ASON transport node. Reachable ! entities are identified in the ASON SNPP name space, and the = transport ! topology is identified from that name space.=20 =20 In order to advertise blocks of reachable address prefixes, a summarization mechanism is introduced that is based on the = techniques *************** *** 636,642 **** of ASON information as described herein. If it is not included in a Node Attribute TLV or a value of 0 is specified for the Local TE Router Identifier, the Note Attribute TLV will not be used for ! determining ASON SCN reachability. Additionally, the condition SHOULD be logged for possible action by the network operator.=20 =20 7. Routing Information Dissemination --- 658,664 ---- of ASON information as described herein. If it is not included in a Node Attribute TLV or a value of 0 is specified for the Local TE Router Identifier, the Note Attribute TLV will not be used for ! determining ASON SNPP reachability. Additionally, the condition SHOULD be logged for possible action by the network operator.=20 =20 7. Routing Information Dissemination > The IESG has received a request from the Common Control and = Measurement > Plane WG (ccamp) to consider the following document: > - 'ASON Routing for OSPFv2 Protocols' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf at ietf.org mailing lists by 2012-08-17. Exceptionally, comments = may be > sent to iesg at ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. This is a = four- > week last call period because it spans the IETF-84 meeting. >=20 > Abstract >=20 > The ITU-T has defined an architecture and requirements for = operating > an Automatically Switched Optical Network (ASON). >=20 > The Generalized Multiprotocol Label Switching (GMPLS) protocol = suite > is designed to provide a control plane for a range of network > technologies including optical networks such as time division > multiplexing (TDM) networks including SONET/SDH and Optical = Transport > Networks (OTNs), and lambda switching optical networks. >=20 > The requirements for GMPLS routing to satisfy the requirements of > ASON routing, and an evaluation of existing GMPLS routing protocols > are provided in other documents. This document defines extensions = to > the OSPFv2 Link State Routing Protocol to meet the requirements for > routing in an ASON. >=20 > Note that this work is scoped to the requirements and evaluation > expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations > current when those documents were written. Future extensions of > revisions of this work may be necessary if the ITU-T = Recommendations > are revised or if new requirements are introduced into a revision = of > RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/ballot/ >=20 > No IPR declarations have been submitted directly on this I-D. --Apple-Mail-22-487725093 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

dhcp-421c:Deskto= p ealflin$ diff -c draft-ietf-ccamp-rfc5787bis-05.txt.orig = draft-ietf-ccamp-rfc5787bis-05.txt
*** = draft-ietf-ccamp-rfc5787bis-05.txt.orig 2012-07-24 20:51:22.000000000 = -0400
--- draft-ietf-ccamp-rfc5787bis-05.txt = 2012-07-31 21:26:18.000000000 = -0400
***************
*** 354,366 = ****
     and corresponding identifiers defined = for GMPLS routing, and how
     these support = the physical (or logical) separation of transport plane
  =    entities and control plane components.  GMPLS supports = this
!    separation of identifiers and = planes.
  
     In the = context of OSPF Traffic Engineering (TE), an ASON = transport
     node corresponds to a unique = OSPF TE node.  An OSPF TE node is
    =  uniquely identified by the TE Router Address TLV [RFC3630]. In = this
     document, this TE Router Address is = referred to as the TE Router ID,
!    which is in = the ASON SCN name space.  The TE Router ID should not = be
     confused with the OSPF Router ID which = uniquely identifies an OSPF
     router within = an OSPF routing domain [RFC2328] and is in a name space
  =    for control plane components.
--- 354,387 = ----
     and corresponding identifiers defined = for GMPLS routing, and how
     these support = the physical (or logical) separation of transport plane
  =    entities and control plane components.  GMPLS supports = this
!    separation of identifiers and = planes. 
! 
!    ASON refers to = transport plane identifiers as SubNetwork Points or 
! =    (SNPs). An SNP is an abstraction that represents an actual = or 
!    potential underlying connection point = (CP) (or connection termination
!    point (CTP)) or = an actual or potential termination connection point
!   =  (TCP) or trail termination point (TTP). Several SNPs (in = different 
!    subnetwork partitions) may = represent the same TCP or CP [G.8080]. 
!    A = collection of SNPs used for ASON routing is referred to as = the
!    SubNetork Point Pool (SNPP) and its = identifiers are from the SNPP
!    name space. In = this context, an SNPP would refer to Optical 
!   =  Transport Network (OTN) switch and an SNP would be an = identifier
!    for an optical = channel. 
! 
!    Conversely, = the Signaling Control Network (SCN) consists of the 
! =    communication paths over which ASON Protocol Controller = (PC) 
!    adjacencies are established, and the = control plane consists of the
!    ASON PC instances = and their corresponding adjacencies.  Given 
! =    that OSPF is always transpored over IP, the SCN and control = plane
!    will normally coincide. However, a given = ASON PC instance may 
!    establish = adjacencies over multiple SCNs and multiple ASON PC 
! =    instances can use the same = SCN.
  
     In the context = of OSPF Traffic Engineering (TE), an ASON transport
  =    node corresponds to a unique OSPF TE node.  An OSPF TE = node is
     uniquely identified by the TE = Router Address TLV [RFC3630]. In this
    =  document, this TE Router Address is referred to as the TE Router = ID,
!    which is in the ASON SNPP name space. =  The TE Router ID should not be
    =  confused with the OSPF Router ID which uniquely identifies an = OSPF
     router within an OSPF routing domain = [RFC2328] and is in a name space
     for = control plane components.
***************
*** = 370,376 ****
     OSPF TE node IP address, = i.e., the IP address is always reachable
    =  when there is IP connectivity to the associated OSPF TE = node.
     However, in the context of the OSPF = ASON operation, the TE Router ID
!    is an = identifier within the ASON = SCN. 
  
     ASON = defines a Routing Controller (RC) as an entity that = handles
     (abstract) information needed for = routing and the routing information
--- 391,397 = ----
     OSPF TE node IP address, i.e., the IP = address is always reachable
     when there is = IP connectivity to the associated OSPF TE node.
    =  However, in the context of the OSPF ASON operation, the TE Router = ID
!    is an identifier within the ASON SNPP name = space. 
  
     ASON = defines a Routing Controller (RC) as an entity that = handles
     (abstract) information needed for = routing and the routing = information
***************
*** 398,404 = ****
  
     In ASON, = reachability refers to the set of endpoints reachable in = the
     transport plane by an associated ASON = transport node. Reachable
!    entities are = identified in the ASON SCN name = space. 
  
     In = order to advertise blocks of reachable address prefixes, = a
     summarization mechanism is introduced = that is based on the techniques
--- 419,426 = ----
  
     In ASON, = reachability refers to the set of endpoints reachable in = the
     transport plane by an associated ASON = transport node. Reachable
!    entities are = identified in the ASON SNPP name space, and the transport
! =    topology is identified from that name = space. 
  
     In = order to advertise blocks of reachable address prefixes, = a
     summarization mechanism is introduced = that is based on the techniques
***************
*** = 636,642 ****
     of ASON information as = described herein. If it is not included in a
    =  Node Attribute TLV or a value of 0 is specified for the Local = TE
     Router Identifier, the Note Attribute = TLV will not be used for
!    determining ASON SCN = reachability.  Additionally, the condition
    =  SHOULD be logged for possible action by the network = operator. 
  
  7.  Routing = Information Dissemination
--- 658,664 ----
  =    of ASON information as described herein. If it is not = included in a
     Node Attribute TLV or a = value of 0 is specified for the Local TE
    =  Router Identifier, the Note Attribute TLV will not be used = for
!    determining ASON SNPP reachability. =  Additionally, the condition
     SHOULD = be logged for possible action by the network = operator. 
  
  7.  Routing = Information Dissemination

The IESG has received a request from the Common =
Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'ASON Routing for OSPFv2 Protocols'
  <draft-ietf-ccamp-rfc5787bis-05.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf at ietf.org mailing lists by =
2012-08-17. Exceptionally, comments may be
sent to iesg at ietf.org instead. In =
either case, please retain the
beginning of the Subject line to allow automated sorting. This is a =
four-
week last call period because it spans the IETF-84 meeting.

Abstract

   The ITU-T has defined an architecture and requirements for operating
   an Automatically Switched Optical Network (ASON).

   The Generalized Multiprotocol Label Switching (GMPLS) protocol suite
   is designed to provide a control plane for a range of network
   technologies including optical networks such as time division
   multiplexing (TDM) networks including SONET/SDH and Optical Transport
   Networks (OTNs), and lambda switching optical networks.

   The requirements for GMPLS routing to satisfy the requirements of
   ASON routing, and an evaluation of existing GMPLS routing protocols
   are provided in other documents.  This document defines extensions to
   the OSPFv2 Link State Routing Protocol to meet the requirements for
   routing in an ASON.

   Note that this work is scoped to the requirements and evaluation
   expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations
   current when those documents were written.  Future extensions of
   revisions of this work may be necessary if the ITU-T Recommendations
   are revised or if new requirements are introduced into a revision of
   RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786.



The file can be obtained via
http=
://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/ballot/=


No IPR declarations have been submitted directly on this =
I-D.

= --Apple-Mail-22-487725093-- --Apple-Mail-23-487725107 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgwMjAwMjU0NVowIwYJKoZI hvcNAQkEMRYEFCXwa7TVdTOK70tGeBlGPjq+GFkVMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgB+VBFio1kn2lMBmH5PDDbmRVxz3HNXoUSJpuSxiWTyJiTNMrpGyRFFNkz07hRgw Y2ae+ewZP6r0laXchBPVJ1RanLQylOi+HLos3aRkKeNDaXwm3ZWMAwhZmF7vj33N5Xgl3qDilg4B YlU4OxAAekDdjZ4y6BCaeF1cPB0tGESNAAAAAAAA --Apple-Mail-23-487725107-- From zali@cisco.com Wed Aug 1 17:40:12 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA7811E81DD for ; Wed, 1 Aug 2012 17:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VXvpyWXOtag for ; Wed, 1 Aug 2012 17:40:11 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B72E911E819B for ; Wed, 1 Aug 2012 17:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zali@cisco.com; l=8730; q=dns/txt; s=iport; t=1343868010; x=1345077610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=H+f2LC0ScZBddz0lpemeQP/BkoM/NoBsgbh1+gSywpQ=; b=E0J8nXqMWTfh5RdMEpeh0H+aIs4ZgCywA1dVCv+0+UXvh5N7bBmm/8C0 N8rp4b51tskDiovh9CGjnw1vBaY4D7onSKu6w/yBUNQCt4KQO2JLwifJ0 a5ha5aDo72c0XczoiuWojjw3Guzd+osxUw5fI0HK6VWtUpbTT3mWdARV/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFnLGVCtJXHB/2dsb2JhbAArGrkUgQeCIAEBAQMBAQEBDwEnNAsFBwQCAQgRBAEBCxQJBycLFAkIAgQBDQUIGodlBgspnGCgSYtJhilgA6NugWaCX28 X-IronPort-AV: E=Sophos;i="4.77,697,1336348800"; d="scan'208";a="107646514" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 02 Aug 2012 00:40:10 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q720e9LW031133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 00:40:09 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.5]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 19:40:09 -0500 From: "Zafar Ali (zali)" To: "adrian@olddog.co.uk" , "ccamp@ietf.org" Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNbzsfFZzh5ZC7+kKOIa930++KWJdEfyWAgAEr+aA= Date: Thu, 2 Aug 2012 00:40:08 +0000 Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> In-Reply-To: <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.38] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.004 x-tm-as-result: No--73.443700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jplang@ieee.org" , "dimitri.papadimitriou@alcatel-lucent.be" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:40:12 -0000 Hi Adrian-=20 Please see comments in-line.=20 Thanks Regards ... Zafar=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Adrian Farrel > Sent: Tuesday, July 31, 2012 9:28 PM > To: ccamp@ietf.org > Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org; > dbrungard@att.com > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >=20 > Hi CCAMP, >=20 > I find that this erratum is raised against two sections one of which I > supplied > text for. If this get contentious, I will call on Stewart to call > consensus and > handle the Erratum in the system. >=20 > In my opinion, this proposal goes further than the intention of the > authors/WG > in publishing 4872. >=20 > With regard to the proposed addition to section 11... > The use of mb4b is already in scope. The existing text says "The new LSP > resources can be established using the make-before-break mechanism," so > there is > no need to re-state "The new LSP can be established without tearing down > the old > LSP". >=20 > I think your concern here is whether the old LSP is ever torn down. I > think that > you are worried that if the old LSP is torn down, it might be impossible > to > perform reversion because, after repair, an attempt to revert (also > using mb4b) > might find that key resources have been "stolen" by some other LSP. I > don't see > this as at all different from the issue of the protection LSP itself. > That is, > it is of the nature of LSP Rerouting as a protection mechanism that: > a. protection may fail because of lack of resources > b. reversion may fail because of lack of resources >=20 Not if the states for old (working) LSP is kept around during failure.=20 > *If* reversion is so important, I don't quite see why protection is not > important.=20 Reversion and Protection are orthogonal to each other. A network may have a= requirement for "reversion" for unprotected LSP. These requirements, as yo= u know, come from the Transport world. Typically working LSP follows nomina= l path (e.g., least latency path) and SPs would like the LSP to go back to = nominal LSP path once a failure is repair. During failure time, either prot= ection or restoration kicks in to minimize impact on the service. Reversion= requirements equally apply to protection as well as restoration. =20 > If protection is important then you should be using a proper > protection mechanism and not waiting for post facto rerouting. Again, for some circuit SP may decide that on-the-fly restoration suffices = (may be based on monitory cost for the circuit). But they still like the LS= P to go back to the nominal path (original working path).=20 > Furthermore, if > you require that the LSP be retained for restoration, why are you not > using a > protection mechanism? >=20 Again, the option to retain original (working) LSP should not depends on wh= ether circuit is protected or restored on-the-fly. =20 > But the general paradigm here is that you are willing to use the best > available > LSP when it is set up in the first place, the best available LSP when > you > re-route after failure, and the best available LSP when you "revert". >=20 The original paths in the network may be explicit (with mix of dynamic for = other services). In this case, service of a LSP may not come back to the or= iginal explicit paths if some other (dynamic) LSP "stole" the resources for= the failed working LSP (if resources are released during a failure) - as y= ou noted above.=20 > Lastly, it *does* remain an _option_ to retain the failed LSP in order > to switch > back. Nothing in the old text precludes that, although I understand that > there > is an implication that it might be expected to be torn down. >=20 > So I conclude that the proposed addition to section 12 is not what the > authors/WG intended. >=20 > We should discuss further. >=20 > Adrian >=20 > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: 31 July 2012 17:39 > > To: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel- > > lucent.be; stbryant@cisco.com; adrian@olddog.co.uk; lberger@labn.net; > > dbrungard@att.com > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC4872 (3304) > > > > > > The following errata report has been submitted for RFC4872, > > "RSVP-TE Extensions in Support of End-to-End Generalized Multi- > Protocol Label > > Switching (GMPLS) Recovery". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 > > > > -------------------------------------- > > Type: Technical > > Reported by: Lyndon Ong > > > > Section: 11 & 12 > > > > Original Text > > ------------- > > Section 11 says: > > > > > > (Full) LSP rerouting will be initiated by the head-end node that > has > > either detected the LSP failure or received a Notify message and/or > a > > PathErr message with the new error code/sub-code "Notify Error/LSP > > Locally Failed" for this LSP. The new LSP resources can be > > established using the make-before-break mechanism, where the new > LSP > > is set up before the old LSP is torn down. This is done by using > the > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > can share resources at common nodes. > > > > Section 12 says: > > > > [No text on reversion for (full) LSP Rerouting.] > > > > Corrected Text > > -------------- > > Section 11 should say: > > > > > > (Full) LSP rerouting will be initiated by the head-end node that > has > > either detected the LSP failure or received a Notify message and/or > a > > PathErr message with the new error code/sub-code "Notify Error/LSP > > Locally Failed" for this LSP. The new LSP resources can be > > established using the make-before-break mechanism, where the new > LSP > > is set up before the old LSP is torn down. This is done by using > the > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > can share resources at common nodes. The new LSP can be > established > > without tearing down the old LSP in case of reversion (see section > 12). > > > > Section 12 should say: > > > > For "(full) LSP Rerouting", reversion implies that the old LSP is > not > > torn down by the head-end node after the new LSP is established. > For > > reversion, the head-end node re-activates the old LSP after this > has > > recovered. > > > > > > > > Notes > > ----- > > Current text in RFC 4872 describes reversion in the cases of 1+1 > bidirectional > > Protection, 1:N Protection with Extra Traffic and Rerouting Without > Extra > Traffic, > > however it has no description of reversion with (Full) LSP Rerouting. > > For (full) LSP Rerouting, the description in Section 11 instead > implies that > the old > > LSP is torn down. This has led to some confusion as to whether > reversion with > > (full) LSP Rerouting is allowed or not allowed by the RFC. We believe > this was > not > > intentional. The additions would make it clear that reversion can be > supported > > with (Full) LSP Rerouting. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > -------------------------------------- > > Title : RSVP-TE Extensions in Support of End-to-End > Generalized > Multi- > > Protocol Label Switching (GMPLS) Recovery > > Publication Date : May 2007 > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > Papadimitriou, Ed. > > Category : PROPOSED STANDARD > > Source : Common Control and Measurement Plane > > Area : Routing > > Stream : IETF > > Verifying Party : IESG >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From zali@cisco.com Wed Aug 1 17:48:17 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26B011E81DD for ; Wed, 1 Aug 2012 17:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvULC8+TqhLU for ; Wed, 1 Aug 2012 17:48:14 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0909111E80E1 for ; Wed, 1 Aug 2012 17:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11022; q=dns/txt; s=iport; t=1343868494; x=1345078094; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HiXBStDCZsh8vaAW5z7MqmRq9cUUIOiP2IYyBN7YElA=; b=LrZav30E45KbyEJ5SiARfai8PEEbyrFt//7abTaiQuRfu2cWh1PRgPZ7 /jT6Tm80lGmmSKIR6qdgSWGoDU7dhNY0pVtuu6GhV6W4VGhcuQ8Fe79Vv 66asRQRJzxY/h8ZLT2kI6fb0JONRbDwFpY+dFo7Yj194dWoIWy8BsmTp5 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAATNGVCtJV2Z/2dsb2JhbAArGrkUgQeCIAEBAQQBAQEPASc0CwwEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCBqHawspnFWgR4tJhilgA6NugWaCX29w X-IronPort-AV: E=Sophos;i="4.77,697,1336348800"; d="scan'208";a="104675665" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 02 Aug 2012 00:48:11 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q720mBAZ008206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 00:48:11 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.5]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 19:48:11 -0500 From: "Zafar Ali (zali)" To: John E Drake , "adrian@olddog.co.uk" , "'Ong, Lyndon'" , "ccamp@ietf.org" Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNb+xUnlXr8OcXskWk6mpWOJqAZZdFk2qAgABhDAD//7xuQA== Date: Thu, 2 Aug 2012 00:48:10 +0000 Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A5A8E93302@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A5A8E93302@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.38] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.004 x-tm-as-result: No--85.340700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jplang@ieee.org" , "dimitri.papadimitriou@alcatel-lucent.be" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:48:18 -0000 Hi John-=20 Please see my response to Adrian's email for the use case for keeping the o= riginal LSP around during failure.=20 Thanks Regards ... Zafar=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of John E Drake > Sent: Wednesday, August 01, 2012 7:49 PM > To: adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > dbrungard@att.com > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >=20 > Is it not the case that the old LSP is broken? In which case it needs > to be cleaned up and re-signaled. >=20 > Sent from my iPhone >=20 >=20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > > Of Adrian Farrel > > Sent: Wednesday, August 01, 2012 11:02 AM > > To: 'Ong, Lyndon'; ccamp@ietf.org > > Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org; > > dbrungard@att.com > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > Hello again, > > > > > Thank you for the fast evaluation of the errata. It sounds like the > > correction that I > > > suggested has ended up overspecifying the method to do reversion > with > > > full rerouting when it is very possible to support a form of > > reversion > > > that doesn't involve maintaining the old LSP. > > > > Right, I understand that you want to allow the option of retaining the > > old working LSP. Also that you have no intention to remove the option > > of removing the old working LSP. > > > > > From your response I believe that you do agree that it was not the > > > intent of > > the > > > original specification text to imply that reversion with full > > > rerouting is not > > allowed > > > > Definitely not the intent to imply that reversion with full rerouting > > is not allowed. > > Does the text say or even imply this? > > > > > (or to require that the old LSP always be torn down in full > > rerouting) > > > > Also no intention to *require* the old LSP to be torn down. > > My view is that the text is fully conformant with that. > > I understand that the text does not make an explicit statement of > this. > > > > > so hopefully > > > with some more discussion we can determine if there is anything that > > > could be done to make that clearer. > > > > There is, of course, a lot that could be done to make it clearer. But > > is there really a need? We discussed the point. We agreed it is not > > prohibited in the RFC. Can we not just move on? > > > > Cheers, > > Adrian > > > -----Original Message----- > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > Sent: Tuesday, July 31, 2012 6:28 PM > > > To: ccamp@ietf.org > > > Cc: jplang@ieee.org; yakov@juniper.net; > > dimitri.papadimitriou@alcatel- > > > lucent.be; stbryant@cisco.com; lberger@labn.net; dbrungard@att.com; > > > Ong, Lyndon > > > Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > > > > > Hi CCAMP, > > > > > > I find that this erratum is raised against two sections one of which > > I > > supplied text > > > for. If this get contentious, I will call on Stewart to call > > consensus > > > and > > handle the > > > Erratum in the system. > > > > > > In my opinion, this proposal goes further than the intention of the > > > authors/WG > > in > > > publishing 4872. > > > > > > With regard to the proposed addition to section 11... > > > The use of mb4b is already in scope. The existing text says "The new > > > LSP resources can be established using the make-before-break > > > mechanism," so there is no need to re-state "The new LSP can be > > > established without tearing down > > the > > > old LSP". > > > > > > I think your concern here is whether the old LSP is ever torn down. > I > > > think > > that > > > you are worried that if the old LSP is torn down, it might be > > > impossible to > > perform > > > reversion because, after repair, an attempt to revert (also using > > > mb4b) might > > find > > > that key resources have been "stolen" by some other LSP. I don't see > > > this as > > at all > > > different from the issue of the protection LSP itself. That is, it > is > > > of the > > nature of > > > LSP Rerouting as a protection mechanism that: > > > a. protection may fail because of lack of resources b. reversion may > > > fail > > because > > > of lack of resources > > > > > > *If* reversion is so important, I don't quite see why protection is > > > not > > important. > > > If protection is important then you should be using a proper > > > protection mechanism and not waiting for post facto rerouting. > > > Furthermore, if you > > require > > > that the LSP be retained for restoration, why are you not using a > > > protection mechanism? > > > > > > But the general paradigm here is that you are willing to use the > best > > available LSP > > > when it is set up in the first place, the best available LSP when > you > > > re-route > > after > > > failure, and the best available LSP when you "revert". > > > > > > Lastly, it *does* remain an _option_ to retain the failed LSP in > > order > > > to > > switch > > > back. Nothing in the old text precludes that, although I understand > > > that there > > is > > > an implication that it might be expected to be torn down. > > > > > > So I conclude that the proposed addition to section 12 is not what > > the > > > authors/WG intended. > > > > > > We should discuss further. > > > > > > Adrian > > > > > > > -----Original Message----- > > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > > Sent: 31 July 2012 17:39 > > > > To: jplang@ieee.org; yakov@juniper.net; > > > > dimitri.papadimitriou@alcatel- lucent.be; stbryant@cisco.com; > > > > adrian@olddog.co.uk; lberger@labn.net; dbrungard@att.com > > > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > > > Subject: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > > > > > The following errata report has been submitted for RFC4872, "RSVP- > > TE > > > > Extensions in Support of End-to-End Generalized Multi-Protocol > > Label > > > > Switching (GMPLS) Recovery". > > > > > > > > -------------------------------------- > > > > You may review the report below and at: > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 > > > > > > > > -------------------------------------- > > > > Type: Technical > > > > Reported by: Lyndon Ong > > > > > > > > Section: 11 & 12 > > > > > > > > Original Text > > > > ------------- > > > > Section 11 says: > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end node > that > > has > > > > either detected the LSP failure or received a Notify message > > and/or a > > > > PathErr message with the new error code/sub-code "Notify > > Error/LSP > > > > Locally Failed" for this LSP. The new LSP resources can be > > > > established using the make-before-break mechanism, where the > new > > LSP > > > > is set up before the old LSP is torn down. This is done by > > using the > > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared- > > Explicit > > > > (SE) reservation style (see [RFC3209]). Both the new and old > > LSPs > > > > can share resources at common nodes. > > > > > > > > Section 12 says: > > > > > > > > [No text on reversion for (full) LSP Rerouting.] > > > > > > > > Corrected Text > > > > -------------- > > > > Section 11 should say: > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end node > that > > has > > > > either detected the LSP failure or received a Notify message > > and/or a > > > > PathErr message with the new error code/sub-code "Notify > > Error/LSP > > > > Locally Failed" for this LSP. The new LSP resources can be > > > > established using the make-before-break mechanism, where the > new > > LSP > > > > is set up before the old LSP is torn down. This is done by > > using the > > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared- > > Explicit > > > > (SE) reservation style (see [RFC3209]). Both the new and old > > LSPs > > > > can share resources at common nodes. The new LSP can be > > established > > > > without tearing down the old LSP in case of reversion (see > > section 12). > > > > > > > > Section 12 should say: > > > > > > > > For "(full) LSP Rerouting", reversion implies that the old LSP > > is not > > > > torn down by the head-end node after the new LSP is > established. > > For > > > > reversion, the head-end node re-activates the old LSP after > this > > has > > > > recovered. > > > > > > > > > > > > > > > > Notes > > > > ----- > > > > Current text in RFC 4872 describes reversion in the cases of 1+1 > > > > bidirectional Protection, 1:N Protection with Extra Traffic and > > > > Rerouting Without Extra > > > Traffic, > > > > however it has no description of reversion with (Full) LSP > > Rerouting. > > > > For (full) LSP Rerouting, the description in Section 11 instead > > > > implies that > > > the old > > > > LSP is torn down. This has led to some confusion as to whether > > > > reversion with > > > > (full) LSP Rerouting is allowed or not allowed by the RFC. We > > > > believe this was > > > not > > > > intentional. The additions would make it clear that reversion can > > be > > > > supported with (Full) LSP Rerouting. > > > > > > > > Instructions: > > > > ------------- > > > > This errata is currently posted as "Reported". If necessary, > please > > > > use "Reply All" to discuss whether it should be verified or > > rejected. > > > > When a decision is reached, the verifying party (IESG) can log in > > to > > > > change the status and edit the report, if necessary. > > > > > > > > -------------------------------------- > > > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > > > -------------------------------------- > > > > Title : RSVP-TE Extensions in Support of End-to-End > > Generalized > > > Multi- > > > > Protocol Label Switching (GMPLS) Recovery > > > > Publication Date : May 2007 > > > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > > Papadimitriou, Ed. > > > > Category : PROPOSED STANDARD > > > > Source : Common Control and Measurement Plane > > > > Area : Routing > > > > Stream : IETF > > > > Verifying Party : IESG > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Wed Aug 1 17:54:34 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64E911E81F6 for ; Wed, 1 Aug 2012 17:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.609 X-Spam-Level: X-Spam-Status: No, score=-4.609 tagged_above=-999 required=5 tests=[AWL=1.390, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-pK7PHydN+O for ; Wed, 1 Aug 2012 17:54:33 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id D77DB11E8250 for ; Wed, 1 Aug 2012 17:54:27 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUBnPwNJXkA8T9DWswahlmnA5rmLSJBtI@postini.com; Wed, 01 Aug 2012 17:54:33 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 1 Aug 2012 17:54:08 -0700 From: John E Drake To: "Zafar Ali (zali)" , "adrian@olddog.co.uk" , "'Ong, Lyndon'" , "ccamp@ietf.org" Date: Wed, 1 Aug 2012 17:54:06 -0700 Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNb+xUnlXr8OcXskWk6mpWOJqAZZdFk2qAgABhDAD//7xuQIAAAP9A Message-ID: <5E893DB832F57341992548CDBB333163A5A8E9337E@EMBX01-HQ.jnpr.net> References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A5A8E93302@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jplang@ieee.org" , "dimitri.papadimitriou@alcatel-lucent.be" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:54:35 -0000 You can't keep the original, broken LSP around because it no longer has e2e= committed resources. The best you can do is clean it up and try to re-ins= tantiate it on its original path.=20 Sent from my iPhone > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Wednesday, August 01, 2012 5:48 PM > To: John E Drake; adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > dbrungard@att.com > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >=20 > Hi John- >=20 > Please see my response to Adrian's email for the use case for keeping > the original LSP around during failure. >=20 > Thanks >=20 > Regards ... Zafar >=20 >=20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of John E Drake > > Sent: Wednesday, August 01, 2012 7:49 PM > > To: adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org > > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > > dbrungard@att.com > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > Is it not the case that the old LSP is broken? In which case it > needs > > to be cleaned up and re-signaled. > > > > Sent from my iPhone > > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > Behalf Of Adrian Farrel > > > Sent: Wednesday, August 01, 2012 11:02 AM > > > To: 'Ong, Lyndon'; ccamp@ietf.org > > > Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org; > > > dbrungard@att.com > > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > > > Hello again, > > > > > > > Thank you for the fast evaluation of the errata. It sounds like > > > > the > > > correction that I > > > > suggested has ended up overspecifying the method to do reversion > > with > > > > full rerouting when it is very possible to support a form of > > > reversion > > > > that doesn't involve maintaining the old LSP. > > > > > > Right, I understand that you want to allow the option of retaining > > > the old working LSP. Also that you have no intention to remove the > > > option of removing the old working LSP. > > > > > > > From your response I believe that you do agree that it was not > the > > > > intent of > > > the > > > > original specification text to imply that reversion with full > > > > rerouting is not > > > allowed > > > > > > Definitely not the intent to imply that reversion with full > > > rerouting is not allowed. > > > Does the text say or even imply this? > > > > > > > (or to require that the old LSP always be torn down in full > > > rerouting) > > > > > > Also no intention to *require* the old LSP to be torn down. > > > My view is that the text is fully conformant with that. > > > I understand that the text does not make an explicit statement of > > this. > > > > > > > so hopefully > > > > with some more discussion we can determine if there is anything > > > > that could be done to make that clearer. > > > > > > There is, of course, a lot that could be done to make it clearer. > > > But is there really a need? We discussed the point. We agreed it is > > > not prohibited in the RFC. Can we not just move on? > > > > > > Cheers, > > > Adrian > > > > -----Original Message----- > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > Sent: Tuesday, July 31, 2012 6:28 PM > > > > To: ccamp@ietf.org > > > > Cc: jplang@ieee.org; yakov@juniper.net; > > > dimitri.papadimitriou@alcatel- > > > > lucent.be; stbryant@cisco.com; lberger@labn.net; > > > > dbrungard@att.com; Ong, Lyndon > > > > Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > Hi CCAMP, > > > > > > > > I find that this erratum is raised against two sections one of > > > > which > > > I > > > supplied text > > > > for. If this get contentious, I will call on Stewart to call > > > consensus > > > > and > > > handle the > > > > Erratum in the system. > > > > > > > > In my opinion, this proposal goes further than the intention of > > > > the authors/WG > > > in > > > > publishing 4872. > > > > > > > > With regard to the proposed addition to section 11... > > > > The use of mb4b is already in scope. The existing text says "The > > > > new LSP resources can be established using the make-before-break > > > > mechanism," so there is no need to re-state "The new LSP can be > > > > established without tearing down > > > the > > > > old LSP". > > > > > > > > I think your concern here is whether the old LSP is ever torn > down. > > I > > > > think > > > that > > > > you are worried that if the old LSP is torn down, it might be > > > > impossible to > > > perform > > > > reversion because, after repair, an attempt to revert (also using > > > > mb4b) might > > > find > > > > that key resources have been "stolen" by some other LSP. I don't > > > > see this as > > > at all > > > > different from the issue of the protection LSP itself. That is, > it > > is > > > > of the > > > nature of > > > > LSP Rerouting as a protection mechanism that: > > > > a. protection may fail because of lack of resources b. reversion > > > > may fail > > > because > > > > of lack of resources > > > > > > > > *If* reversion is so important, I don't quite see why protection > > > > is not > > > important. > > > > If protection is important then you should be using a proper > > > > protection mechanism and not waiting for post facto rerouting. > > > > Furthermore, if you > > > require > > > > that the LSP be retained for restoration, why are you not using a > > > > protection mechanism? > > > > > > > > But the general paradigm here is that you are willing to use the > > best > > > available LSP > > > > when it is set up in the first place, the best available LSP when > > you > > > > re-route > > > after > > > > failure, and the best available LSP when you "revert". > > > > > > > > Lastly, it *does* remain an _option_ to retain the failed LSP in > > > order > > > > to > > > switch > > > > back. Nothing in the old text precludes that, although I > > > > understand that there > > > is > > > > an implication that it might be expected to be torn down. > > > > > > > > So I conclude that the proposed addition to section 12 is not > what > > > the > > > > authors/WG intended. > > > > > > > > We should discuss further. > > > > > > > > Adrian > > > > > > > > > -----Original Message----- > > > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > > > Sent: 31 July 2012 17:39 > > > > > To: jplang@ieee.org; yakov@juniper.net; > > > > > dimitri.papadimitriou@alcatel- lucent.be; stbryant@cisco.com; > > > > > adrian@olddog.co.uk; lberger@labn.net; dbrungard@att.com > > > > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > > > > Subject: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > > > > > > > > The following errata report has been submitted for RFC4872, > > > > > "RSVP- > > > TE > > > > > Extensions in Support of End-to-End Generalized Multi-Protocol > > > Label > > > > > Switching (GMPLS) Recovery". > > > > > > > > > > -------------------------------------- > > > > > You may review the report below and at: > > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 > > > > > > > > > > -------------------------------------- > > > > > Type: Technical > > > > > Reported by: Lyndon Ong > > > > > > > > > > Section: 11 & 12 > > > > > > > > > > Original Text > > > > > ------------- > > > > > Section 11 says: > > > > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end node > > that > > > has > > > > > either detected the LSP failure or received a Notify message > > > and/or a > > > > > PathErr message with the new error code/sub-code "Notify > > > Error/LSP > > > > > Locally Failed" for this LSP. The new LSP resources can be > > > > > established using the make-before-break mechanism, where the > > new > > > LSP > > > > > is set up before the old LSP is torn down. This is done by > > > using the > > > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared- > > > Explicit > > > > > (SE) reservation style (see [RFC3209]). Both the new and > old > > > LSPs > > > > > can share resources at common nodes. > > > > > > > > > > Section 12 says: > > > > > > > > > > [No text on reversion for (full) LSP Rerouting.] > > > > > > > > > > Corrected Text > > > > > -------------- > > > > > Section 11 should say: > > > > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end node > > that > > > has > > > > > either detected the LSP failure or received a Notify message > > > and/or a > > > > > PathErr message with the new error code/sub-code "Notify > > > Error/LSP > > > > > Locally Failed" for this LSP. The new LSP resources can be > > > > > established using the make-before-break mechanism, where the > > new > > > LSP > > > > > is set up before the old LSP is torn down. This is done by > > > using the > > > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared- > > > Explicit > > > > > (SE) reservation style (see [RFC3209]). Both the new and > old > > > LSPs > > > > > can share resources at common nodes. The new LSP can be > > > established > > > > > without tearing down the old LSP in case of reversion (see > > > section 12). > > > > > > > > > > Section 12 should say: > > > > > > > > > > For "(full) LSP Rerouting", reversion implies that the old > > > > > LSP > > > is not > > > > > torn down by the head-end node after the new LSP is > > established. > > > For > > > > > reversion, the head-end node re-activates the old LSP after > > this > > > has > > > > > recovered. > > > > > > > > > > > > > > > > > > > > Notes > > > > > ----- > > > > > Current text in RFC 4872 describes reversion in the cases of > 1+1 > > > > > bidirectional Protection, 1:N Protection with Extra Traffic and > > > > > Rerouting Without Extra > > > > Traffic, > > > > > however it has no description of reversion with (Full) LSP > > > Rerouting. > > > > > For (full) LSP Rerouting, the description in Section 11 instead > > > > > implies that > > > > the old > > > > > LSP is torn down. This has led to some confusion as to whether > > > > > reversion with > > > > > (full) LSP Rerouting is allowed or not allowed by the RFC. We > > > > > believe this was > > > > not > > > > > intentional. The additions would make it clear that reversion > > > > > can > > > be > > > > > supported with (Full) LSP Rerouting. > > > > > > > > > > Instructions: > > > > > ------------- > > > > > This errata is currently posted as "Reported". If necessary, > > please > > > > > use "Reply All" to discuss whether it should be verified or > > > rejected. > > > > > When a decision is reached, the verifying party (IESG) can log > > > > > in > > > to > > > > > change the status and edit the report, if necessary. > > > > > > > > > > -------------------------------------- > > > > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > > > > -------------------------------------- > > > > > Title : RSVP-TE Extensions in Support of End-to- > End > > > Generalized > > > > Multi- > > > > > Protocol Label Switching (GMPLS) Recovery > > > > > Publication Date : May 2007 > > > > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > > > Papadimitriou, Ed. > > > > > Category : PROPOSED STANDARD > > > > > Source : Common Control and Measurement Plane > > > > > Area : Routing > > > > > Stream : IETF > > > > > Verifying Party : IESG > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Wed Aug 1 18:13:35 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B67C11E810B for ; Wed, 1 Aug 2012 18:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.388 X-Spam-Level: X-Spam-Status: No, score=-97.388 tagged_above=-999 required=5 tests=[AWL=2.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Xhurc3VC7yL for ; Wed, 1 Aug 2012 18:13:34 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id CC06211E80FD for ; Wed, 1 Aug 2012 18:13:33 -0700 (PDT) Received: (qmail 28815 invoked by uid 0); 2 Aug 2012 01:13:32 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 2 Aug 2012 01:13:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=mqXlORoCtPL+eF/kF2XcAn06yYOdChTR8DWoyfXMuNo=; b=uQEYD8s6LNio8ted7OwSdi2fxlPAYnMOj1fLn9RoksiI6g8LWuGZYhWwIWReOb+aReIIzKqvhBiCZuOp50fklV0TTEscZMyq7kBU3rPGWKXd8uHtbnczJvVegKLIy/JV; Received: from box313.bluehost.com ([69.89.31.113]:37057 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1SwjyP-0004LQ-O5; Wed, 01 Aug 2012 19:13:10 -0600 Message-ID: <5019D420.1030500@labn.net> Date: Wed, 01 Aug 2012 18:13:04 -0700 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: adrian@olddog.co.uk, "'Ong, Lyndon'" References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> In-Reply-To: <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: dimitri.papadimitriou@alcatel-lucent.be, ccamp@ietf.org, jplang@ieee.org, dbrungard@att.com Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) [resend] X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:13:35 -0000 > There is, of course, a lot that could be done to make it clearer. But is there > really a need? We discussed the point. We agreed it is not prohibited in the > RFC. Can we not just move on? So it sounds like there's agreement that there's no technical errata here. Perhaps an alternate way to proceed is to replace this errata with an editorial errata that states that a future revision of the RFC should explicitly discuss how this scenario is covered? Comments/thoughts? Lou On 8/1/2012 11:01 AM, Adrian Farrel wrote: > Hello again, > >> Thank you for the fast evaluation of the errata. It sounds like the > correction that I >> suggested has ended up overspecifying the method to do reversion with full >> rerouting when it is very possible to support a form of reversion that doesn't >> involve maintaining the old LSP. > > Right, I understand that you want to allow the option of retaining the old > working LSP. Also that you have no intention to remove the option of removing > the old working LSP. > >> From your response I believe that you do agree that it was not the intent of > the >> original specification text to imply that reversion with full rerouting is not > allowed > > Definitely not the intent to imply that reversion with full rerouting is not > allowed. > Does the text say or even imply this? > >> (or to require that the old LSP always be torn down in full rerouting) > > Also no intention to *require* the old LSP to be torn down. > My view is that the text is fully conformant with that. > I understand that the text does not make an explicit statement of this. > >> so hopefully >> with some more discussion we can determine if there is anything that could be >> done to make that clearer. > > There is, of course, a lot that could be done to make it clearer. But is there > really a need? We discussed the point. We agreed it is not prohibited in the > RFC. Can we not just move on? > > Cheers, > Adrian >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Tuesday, July 31, 2012 6:28 PM >> To: ccamp@ietf.org >> Cc: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel- >> lucent.be; stbryant@cisco.com; lberger@labn.net; dbrungard@att.com; Ong, >> Lyndon >> Subject: RE: [Technical Errata Reported] RFC4872 (3304) >> >> Hi CCAMP, >> >> I find that this erratum is raised against two sections one of which I > supplied text >> for. If this get contentious, I will call on Stewart to call consensus and > handle the >> Erratum in the system. >> >> In my opinion, this proposal goes further than the intention of the authors/WG > in >> publishing 4872. >> >> With regard to the proposed addition to section 11... >> The use of mb4b is already in scope. The existing text says "The new LSP >> resources can be established using the make-before-break mechanism," so there >> is no need to re-state "The new LSP can be established without tearing down > the >> old LSP". >> >> I think your concern here is whether the old LSP is ever torn down. I think > that >> you are worried that if the old LSP is torn down, it might be impossible to > perform >> reversion because, after repair, an attempt to revert (also using mb4b) might > find >> that key resources have been "stolen" by some other LSP. I don't see this as > at all >> different from the issue of the protection LSP itself. That is, it is of the > nature of >> LSP Rerouting as a protection mechanism that: >> a. protection may fail because of lack of resources b. reversion may fail > because >> of lack of resources >> >> *If* reversion is so important, I don't quite see why protection is not > important. >> If protection is important then you should be using a proper protection >> mechanism and not waiting for post facto rerouting. Furthermore, if you > require >> that the LSP be retained for restoration, why are you not using a protection >> mechanism? >> >> But the general paradigm here is that you are willing to use the best > available LSP >> when it is set up in the first place, the best available LSP when you re-route > after >> failure, and the best available LSP when you "revert". >> >> Lastly, it *does* remain an _option_ to retain the failed LSP in order to > switch >> back. Nothing in the old text precludes that, although I understand that there > is >> an implication that it might be expected to be torn down. >> >> So I conclude that the proposed addition to section 12 is not what the >> authors/WG intended. >> >> We should discuss further. >> >> Adrian >> >>> -----Original Message----- >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>> Sent: 31 July 2012 17:39 >>> To: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel- >>> lucent.be; stbryant@cisco.com; adrian@olddog.co.uk; lberger@labn.net; >>> dbrungard@att.com >>> Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org >>> Subject: [Technical Errata Reported] RFC4872 (3304) >>> >>> >>> The following errata report has been submitted for RFC4872, "RSVP-TE >>> Extensions in Support of End-to-End Generalized Multi-Protocol Label >>> Switching (GMPLS) Recovery". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=4872&eid=3304 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Lyndon Ong >>> >>> Section: 11 & 12 >>> >>> Original Text >>> ------------- >>> Section 11 says: >>> >>> >>> (Full) LSP rerouting will be initiated by the head-end node that has >>> either detected the LSP failure or received a Notify message and/or a >>> PathErr message with the new error code/sub-code "Notify Error/LSP >>> Locally Failed" for this LSP. The new LSP resources can be >>> established using the make-before-break mechanism, where the new LSP >>> is set up before the old LSP is torn down. This is done by using the >>> mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit >>> (SE) reservation style (see [RFC3209]). Both the new and old LSPs >>> can share resources at common nodes. >>> >>> Section 12 says: >>> >>> [No text on reversion for (full) LSP Rerouting.] >>> >>> Corrected Text >>> -------------- >>> Section 11 should say: >>> >>> >>> (Full) LSP rerouting will be initiated by the head-end node that has >>> either detected the LSP failure or received a Notify message and/or a >>> PathErr message with the new error code/sub-code "Notify Error/LSP >>> Locally Failed" for this LSP. The new LSP resources can be >>> established using the make-before-break mechanism, where the new LSP >>> is set up before the old LSP is torn down. This is done by using the >>> mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit >>> (SE) reservation style (see [RFC3209]). Both the new and old LSPs >>> can share resources at common nodes. The new LSP can be established >>> without tearing down the old LSP in case of reversion (see section 12). >>> >>> Section 12 should say: >>> >>> For "(full) LSP Rerouting", reversion implies that the old LSP is not >>> torn down by the head-end node after the new LSP is established. For >>> reversion, the head-end node re-activates the old LSP after this has >>> recovered. >>> >>> >>> >>> Notes >>> ----- >>> Current text in RFC 4872 describes reversion in the cases of 1+1 >>> bidirectional Protection, 1:N Protection with Extra Traffic and >>> Rerouting Without Extra >> Traffic, >>> however it has no description of reversion with (Full) LSP Rerouting. >>> For (full) LSP Rerouting, the description in Section 11 instead >>> implies that >> the old >>> LSP is torn down. This has led to some confusion as to whether >>> reversion with >>> (full) LSP Rerouting is allowed or not allowed by the RFC. We believe >>> this was >> not >>> intentional. The additions would make it clear that reversion can be >>> supported with (Full) LSP Rerouting. >>> >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or rejected. >>> When a decision is reached, the verifying party (IESG) can log in to >>> change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) >>> -------------------------------------- >>> Title : RSVP-TE Extensions in Support of End-to-End > Generalized >> Multi- >>> Protocol Label Switching (GMPLS) Recovery >>> Publication Date : May 2007 >>> Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed. >>> Category : PROPOSED STANDARD >>> Source : Common Control and Measurement Plane >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG > > > > > From lberger@labn.net Wed Aug 1 18:20:58 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA9821F8AED for ; Wed, 1 Aug 2012 18:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.388 X-Spam-Level: X-Spam-Status: No, score=-97.388 tagged_above=-999 required=5 tests=[AWL=2.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQNkR+NS98D6 for ; Wed, 1 Aug 2012 18:20:58 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 8873321F8AEB for ; Wed, 1 Aug 2012 18:20:58 -0700 (PDT) Received: (qmail 17341 invoked by uid 0); 1 Aug 2012 21:45:03 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 1 Aug 2012 21:45:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=mqXlORoCtPL+eF/kF2XcAn06yYOdChTR8DWoyfXMuNo=; b=vBXVEJUWwRF9H3lVApl7c42XDDj0jzl6cVEVgCv0fI4bDBriH5Yfj6YVURasginlKUbwy9U2TDO3wRng1pvo6MLJwoRik9HiZmTGhR1jW4BlWx7GmUqfXlKL4mklQ50U; Received: from box313.bluehost.com ([69.89.31.113]:44585 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Swgj0-0007UU-3S; Wed, 01 Aug 2012 15:45:02 -0600 Message-ID: <5019A35A.7090906@labn.net> Date: Wed, 01 Aug 2012 14:44:58 -0700 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: adrian@olddog.co.uk, "'Ong, Lyndon'" References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> In-Reply-To: <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: dimitri.papadimitriou@alcatel-lucent.be, ccamp@ietf.org, jplang@ieee.org, dbrungard@att.com Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:20:59 -0000 > There is, of course, a lot that could be done to make it clearer. But is there > really a need? We discussed the point. We agreed it is not prohibited in the > RFC. Can we not just move on? So it sounds like there's agreement that there's no technical errata here. Perhaps an alternate way to proceed is to replace this errata with an editorial errata that states that a future revision of the RFC should explicitly discuss how this scenario is covered? Comments/thoughts? Lou On 8/1/2012 11:01 AM, Adrian Farrel wrote: > Hello again, > >> Thank you for the fast evaluation of the errata. It sounds like the > correction that I >> suggested has ended up overspecifying the method to do reversion with full >> rerouting when it is very possible to support a form of reversion that doesn't >> involve maintaining the old LSP. > > Right, I understand that you want to allow the option of retaining the old > working LSP. Also that you have no intention to remove the option of removing > the old working LSP. > >> From your response I believe that you do agree that it was not the intent of > the >> original specification text to imply that reversion with full rerouting is not > allowed > > Definitely not the intent to imply that reversion with full rerouting is not > allowed. > Does the text say or even imply this? > >> (or to require that the old LSP always be torn down in full rerouting) > > Also no intention to *require* the old LSP to be torn down. > My view is that the text is fully conformant with that. > I understand that the text does not make an explicit statement of this. > >> so hopefully >> with some more discussion we can determine if there is anything that could be >> done to make that clearer. > > There is, of course, a lot that could be done to make it clearer. But is there > really a need? We discussed the point. We agreed it is not prohibited in the > RFC. Can we not just move on? > > Cheers, > Adrian >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Tuesday, July 31, 2012 6:28 PM >> To: ccamp@ietf.org >> Cc: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel- >> lucent.be; stbryant@cisco.com; lberger@labn.net; dbrungard@att.com; Ong, >> Lyndon >> Subject: RE: [Technical Errata Reported] RFC4872 (3304) >> >> Hi CCAMP, >> >> I find that this erratum is raised against two sections one of which I > supplied text >> for. If this get contentious, I will call on Stewart to call consensus and > handle the >> Erratum in the system. >> >> In my opinion, this proposal goes further than the intention of the authors/WG > in >> publishing 4872. >> >> With regard to the proposed addition to section 11... >> The use of mb4b is already in scope. The existing text says "The new LSP >> resources can be established using the make-before-break mechanism," so there >> is no need to re-state "The new LSP can be established without tearing down > the >> old LSP". >> >> I think your concern here is whether the old LSP is ever torn down. I think > that >> you are worried that if the old LSP is torn down, it might be impossible to > perform >> reversion because, after repair, an attempt to revert (also using mb4b) might > find >> that key resources have been "stolen" by some other LSP. I don't see this as > at all >> different from the issue of the protection LSP itself. That is, it is of the > nature of >> LSP Rerouting as a protection mechanism that: >> a. protection may fail because of lack of resources b. reversion may fail > because >> of lack of resources >> >> *If* reversion is so important, I don't quite see why protection is not > important. >> If protection is important then you should be using a proper protection >> mechanism and not waiting for post facto rerouting. Furthermore, if you > require >> that the LSP be retained for restoration, why are you not using a protection >> mechanism? >> >> But the general paradigm here is that you are willing to use the best > available LSP >> when it is set up in the first place, the best available LSP when you re-route > after >> failure, and the best available LSP when you "revert". >> >> Lastly, it *does* remain an _option_ to retain the failed LSP in order to > switch >> back. Nothing in the old text precludes that, although I understand that there > is >> an implication that it might be expected to be torn down. >> >> So I conclude that the proposed addition to section 12 is not what the >> authors/WG intended. >> >> We should discuss further. >> >> Adrian >> >>> -----Original Message----- >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>> Sent: 31 July 2012 17:39 >>> To: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel- >>> lucent.be; stbryant@cisco.com; adrian@olddog.co.uk; lberger@labn.net; >>> dbrungard@att.com >>> Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org >>> Subject: [Technical Errata Reported] RFC4872 (3304) >>> >>> >>> The following errata report has been submitted for RFC4872, "RSVP-TE >>> Extensions in Support of End-to-End Generalized Multi-Protocol Label >>> Switching (GMPLS) Recovery". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=4872&eid=3304 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Lyndon Ong >>> >>> Section: 11 & 12 >>> >>> Original Text >>> ------------- >>> Section 11 says: >>> >>> >>> (Full) LSP rerouting will be initiated by the head-end node that has >>> either detected the LSP failure or received a Notify message and/or a >>> PathErr message with the new error code/sub-code "Notify Error/LSP >>> Locally Failed" for this LSP. The new LSP resources can be >>> established using the make-before-break mechanism, where the new LSP >>> is set up before the old LSP is torn down. This is done by using the >>> mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit >>> (SE) reservation style (see [RFC3209]). Both the new and old LSPs >>> can share resources at common nodes. >>> >>> Section 12 says: >>> >>> [No text on reversion for (full) LSP Rerouting.] >>> >>> Corrected Text >>> -------------- >>> Section 11 should say: >>> >>> >>> (Full) LSP rerouting will be initiated by the head-end node that has >>> either detected the LSP failure or received a Notify message and/or a >>> PathErr message with the new error code/sub-code "Notify Error/LSP >>> Locally Failed" for this LSP. The new LSP resources can be >>> established using the make-before-break mechanism, where the new LSP >>> is set up before the old LSP is torn down. This is done by using the >>> mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit >>> (SE) reservation style (see [RFC3209]). Both the new and old LSPs >>> can share resources at common nodes. The new LSP can be established >>> without tearing down the old LSP in case of reversion (see section 12). >>> >>> Section 12 should say: >>> >>> For "(full) LSP Rerouting", reversion implies that the old LSP is not >>> torn down by the head-end node after the new LSP is established. For >>> reversion, the head-end node re-activates the old LSP after this has >>> recovered. >>> >>> >>> >>> Notes >>> ----- >>> Current text in RFC 4872 describes reversion in the cases of 1+1 >>> bidirectional Protection, 1:N Protection with Extra Traffic and >>> Rerouting Without Extra >> Traffic, >>> however it has no description of reversion with (Full) LSP Rerouting. >>> For (full) LSP Rerouting, the description in Section 11 instead >>> implies that >> the old >>> LSP is torn down. This has led to some confusion as to whether >>> reversion with >>> (full) LSP Rerouting is allowed or not allowed by the RFC. We believe >>> this was >> not >>> intentional. The additions would make it clear that reversion can be >>> supported with (Full) LSP Rerouting. >>> >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or rejected. >>> When a decision is reached, the verifying party (IESG) can log in to >>> change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) >>> -------------------------------------- >>> Title : RSVP-TE Extensions in Support of End-to-End > Generalized >> Multi- >>> Protocol Label Switching (GMPLS) Recovery >>> Publication Date : May 2007 >>> Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed. >>> Category : PROPOSED STANDARD >>> Source : Common Control and Measurement Plane >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG > > > > > From prvs=3561bf1d5b=lyong@ciena.com Wed Aug 1 18:28:39 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC1D11E8156 for ; Wed, 1 Aug 2012 18:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.257 X-Spam-Level: X-Spam-Status: No, score=-101.257 tagged_above=-999 required=5 tests=[AWL=1.408, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCXJw+QdDPQD for ; Wed, 1 Aug 2012 18:28:38 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7A38B11E810C for ; Wed, 1 Aug 2012 18:28:38 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q721QkrT000406; Wed, 1 Aug 2012 21:28:30 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 16ff03r2s6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 01 Aug 2012 21:28:30 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 1 Aug 2012 21:28:31 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Wed, 1 Aug 2012 21:28:31 -0400 From: "Ong, Lyndon" To: Lou Berger , "adrian@olddog.co.uk" Date: Wed, 1 Aug 2012 21:28:29 -0400 Thread-Topic: [Technical Errata Reported] RFC4872 (3304) Thread-Index: Ac1wTRS0M3usl6SSR6+VyD4+SOtyvAAAI9QA Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5019A35A.7090906@labn.net> In-Reply-To: <5019A35A.7090906@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-19076.004 x-tm-as-result: No--65.841300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-01_06:2012-08-01, 2012-08-01, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208010324 Cc: "dimitri.papadimitriou@alcatel-lucent.be" , "ccamp@ietf.org" , "jplang@ieee.org" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:28:40 -0000 That sounds like it might be a good direction to me. Cheers, Lyndon -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Wednesday, August 01, 2012 2:45 PM To: adrian@olddog.co.uk; Ong, Lyndon Cc: ccamp@ietf.org; jplang@ieee.org; yakov@juniper.net; dimitri.papadimitri= ou@alcatel-lucent.be; stbryant@cisco.com; dbrungard@att.com; Roch, Evelyne Subject: Re: [Technical Errata Reported] RFC4872 (3304) > There is, of course, a lot that could be done to make it clearer. But is there > really a need? We discussed the point. We agreed it is not prohibited in the > RFC. Can we not just move on? So it sounds like there's agreement that there's no technical errata here. Perhaps an alternate way to proceed is to replace this errata with an edito= rial errata that states that a future revision of the RFC should explicitly= discuss how this scenario is covered? Comments/thoughts? Lou On 8/1/2012 11:01 AM, Adrian Farrel wrote: > Hello again, >=20 >> Thank you for the fast evaluation of the errata. It sounds like the > correction that I >> suggested has ended up overspecifying the method to do reversion with=20 >> full rerouting when it is very possible to support a form of=20 >> reversion that doesn't involve maintaining the old LSP. >=20 > Right, I understand that you want to allow the option of retaining the=20 > old working LSP. Also that you have no intention to remove the option=20 > of removing the old working LSP. >=20 >> From your response I believe that you do agree that it was not the=20 >> intent of > the >> original specification text to imply that reversion with full=20 >> rerouting is not > allowed >=20 > Definitely not the intent to imply that reversion with full rerouting=20 > is not allowed. > Does the text say or even imply this? >=20 >> (or to require that the old LSP always be torn down in full=20 >> rerouting) >=20 > Also no intention to *require* the old LSP to be torn down.=20 > My view is that the text is fully conformant with that. > I understand that the text does not make an explicit statement of this. >=20 >> so hopefully >> with some more discussion we can determine if there is anything that=20 >> could be done to make that clearer. >=20 > There is, of course, a lot that could be done to make it clearer. But=20 > is there really a need? We discussed the point. We agreed it is not=20 > prohibited in the RFC. Can we not just move on? >=20 > Cheers, > Adrian >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Tuesday, July 31, 2012 6:28 PM >> To: ccamp@ietf.org >> Cc: jplang@ieee.org; yakov@juniper.net;=20 >> dimitri.papadimitriou@alcatel- lucent.be; stbryant@cisco.com;=20 >> lberger@labn.net; dbrungard@att.com; Ong, Lyndon >> Subject: RE: [Technical Errata Reported] RFC4872 (3304) >> >> Hi CCAMP, >> >> I find that this erratum is raised against two sections one of which=20 >> I > supplied text >> for. If this get contentious, I will call on Stewart to call=20 >> consensus and > handle the >> Erratum in the system. >> >> In my opinion, this proposal goes further than the intention of the=20 >> authors/WG > in >> publishing 4872. >> >> With regard to the proposed addition to section 11... >> The use of mb4b is already in scope. The existing text says "The new=20 >> LSP resources can be established using the make-before-break=20 >> mechanism," so there is no need to re-state "The new LSP can be=20 >> established without tearing down > the >> old LSP". >> >> I think your concern here is whether the old LSP is ever torn down. I=20 >> think > that >> you are worried that if the old LSP is torn down, it might be=20 >> impossible to > perform >> reversion because, after repair, an attempt to revert (also using=20 >> mb4b) might > find >> that key resources have been "stolen" by some other LSP. I don't see=20 >> this as > at all >> different from the issue of the protection LSP itself. That is, it is=20 >> of the > nature of >> LSP Rerouting as a protection mechanism that: >> a. protection may fail because of lack of resources b. reversion may=20 >> fail > because >> of lack of resources >> >> *If* reversion is so important, I don't quite see why protection is=20 >> not > important. >> If protection is important then you should be using a proper=20 >> protection mechanism and not waiting for post facto rerouting.=20 >> Furthermore, if you > require >> that the LSP be retained for restoration, why are you not using a=20 >> protection mechanism? >> >> But the general paradigm here is that you are willing to use the best > available LSP >> when it is set up in the first place, the best available LSP when you=20 >> re-route > after >> failure, and the best available LSP when you "revert". >> >> Lastly, it *does* remain an _option_ to retain the failed LSP in=20 >> order to > switch >> back. Nothing in the old text precludes that, although I understand=20 >> that there > is >> an implication that it might be expected to be torn down. >> >> So I conclude that the proposed addition to section 12 is not what=20 >> the authors/WG intended. >> >> We should discuss further. >> >> Adrian >> >>> -----Original Message----- >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>> Sent: 31 July 2012 17:39 >>> To: jplang@ieee.org; yakov@juniper.net;=20 >>> dimitri.papadimitriou@alcatel- lucent.be; stbryant@cisco.com;=20 >>> adrian@olddog.co.uk; lberger@labn.net; dbrungard@att.com >>> Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org >>> Subject: [Technical Errata Reported] RFC4872 (3304) >>> >>> >>> The following errata report has been submitted for RFC4872, "RSVP-TE=20 >>> Extensions in Support of End-to-End Generalized Multi-Protocol Label=20 >>> Switching (GMPLS) Recovery". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Lyndon Ong >>> >>> Section: 11 & 12 >>> >>> Original Text >>> ------------- >>> Section 11 says: >>> >>> >>> (Full) LSP rerouting will be initiated by the head-end node that has >>> either detected the LSP failure or received a Notify message and/or = a >>> PathErr message with the new error code/sub-code "Notify Error/LSP >>> Locally Failed" for this LSP. The new LSP resources can be >>> established using the make-before-break mechanism, where the new LSP >>> is set up before the old LSP is torn down. This is done by using th= e >>> mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit >>> (SE) reservation style (see [RFC3209]). Both the new and old LSPs >>> can share resources at common nodes. >>> >>> Section 12 says: >>> >>> [No text on reversion for (full) LSP Rerouting.] >>> >>> Corrected Text >>> -------------- >>> Section 11 should say: >>> >>> >>> (Full) LSP rerouting will be initiated by the head-end node that has >>> either detected the LSP failure or received a Notify message and/or = a >>> PathErr message with the new error code/sub-code "Notify Error/LSP >>> Locally Failed" for this LSP. The new LSP resources can be >>> established using the make-before-break mechanism, where the new LSP >>> is set up before the old LSP is torn down. This is done by using th= e >>> mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit >>> (SE) reservation style (see [RFC3209]). Both the new and old LSPs >>> can share resources at common nodes. The new LSP can be established >>> without tearing down the old LSP in case of reversion (see section 1= 2). >>> >>> Section 12 should say: >>> >>> For "(full) LSP Rerouting", reversion implies that the old LSP is no= t >>> torn down by the head-end node after the new LSP is established. For >>> reversion, the head-end node re-activates the old LSP after this has >>> recovered. >>> >>> >>> >>> Notes >>> ----- >>> Current text in RFC 4872 describes reversion in the cases of 1+1=20 >>> bidirectional Protection, 1:N Protection with Extra Traffic and=20 >>> Rerouting Without Extra >> Traffic, >>> however it has no description of reversion with (Full) LSP Rerouting. >>> For (full) LSP Rerouting, the description in Section 11 instead=20 >>> implies that >> the old >>> LSP is torn down. This has led to some confusion as to whether=20 >>> reversion with >>> (full) LSP Rerouting is allowed or not allowed by the RFC. We=20 >>> believe this was >> not >>> intentional. The additions would make it clear that reversion can be=20 >>> supported with (Full) LSP Rerouting. >>> >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please=20 >>> use "Reply All" to discuss whether it should be verified or rejected. >>> When a decision is reached, the verifying party (IESG) can log in to=20 >>> change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) >>> -------------------------------------- >>> Title : RSVP-TE Extensions in Support of End-to-End > Generalized >> Multi- >>> Protocol Label Switching (GMPLS) Recovery >>> Publication Date : May 2007 >>> Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou= , Ed. >>> Category : PROPOSED STANDARD >>> Source : Common Control and Measurement Plane >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG >=20 >=20 >=20 >=20 >=20 From Sidd.Aanand@ecitele.com Wed Aug 1 21:06:32 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C23F11E80E1 for ; Wed, 1 Aug 2012 21:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.902 X-Spam-Level: X-Spam-Status: No, score=-4.902 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtBHZ2qKqVeQ for ; Wed, 1 Aug 2012 21:06:31 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id D681D11E812C for ; Wed, 1 Aug 2012 21:06:30 -0700 (PDT) Received: from [85.158.143.99:38850] by server-2.bemta-4.messagelabs.com id C5/CA-17938-4CCF9105; Thu, 02 Aug 2012 04:06:28 +0000 X-Env-Sender: Sidd.Aanand@ecitele.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1343880388!28954786!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 16030 invoked from network); 2 Aug 2012 04:06:28 -0000 Received: from unknown (HELO FRIDLPPSB002.ECITELE.COM) (168.87.1.157) by server-13.tower-216.messagelabs.com with SMTP; 2 Aug 2012 04:06:28 -0000 X-AuditID: a8571402-b7f1a6d000000fb4-a3-5019f7c4c56d Received: from FRIDWPPCH002.ecitele.com (Unknown_Domain [10.1.16.53]) by FRIDLPPSB002.ECITELE.COM (Symantec Messaging Gateway) with SMTP id 6D.A1.04020.4C7F9105; Thu, 2 Aug 2012 05:45:08 +0200 (CEST) Received: from FRIDWPPMB002.ecitele.com ([169.254.4.204]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Thu, 2 Aug 2012 06:06:25 +0200 From: Sidd Aanand To: John E Drake , "adrian@olddog.co.uk" , "ccamp@ietf.org" Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNbzsdA+RIyRgyLkqpuMdSJDEPKJdECcyAgADUMYCAAQvH4A== Date: Thu, 2 Aug 2012 04:06:24 +0000 Message-ID: <65D64BED7222584D930F9A9FAD51FFA9271C091A@FRIDWPPMB002.ecitele.com> References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A5A8E92CB0@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A5A8E92CB0@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.132.197] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA1VTfUwTZxzee3eUA7nl+JC+bZZ4XsYfGyKtIrkltjKBWRRDRZIt04hn77U9 bK/nXQW6mQU3/1jIFDZjoqSJMCspQtaFZVHi4gdKVPzAPxRRI9EIDkrijETAkaB3njL23/P+ nuf5Pe/H7yXxjH9NVlKUQkiReD9rSiVSwQfWvEvTFret4e9cbuanIZwbiQwR3KmeKME96JtJ 4iIPi7lrJyexIpMr3voad403RYBrtPkC5opGX2Guu9/fSXbF/ugAbtPXDWA1L0nBEB9CjIBU j4N1K2It7wmzjCg4WDvLyH7egwJICjlYXpaRJLDO1NVaUZQYJHmCgih5HWzZ5oo8jlv1WZ6d dVb5RJVBeQFe9DMBpKq8FzFaRT+CJCCB2RlUmJAPMQryiLKIth/Afc87H+Bywln/S+QA3gAG 7Y0ghYR0ATz48AZm4Gx4azhuagSpZAbdD+Ds5G1gLKIAzl2ME42AJE10Lvy9r1A3ZNF18Nzk BKFrcLoTwCP9L4FOZNJr4M2eUcwQFcHBg23JBl4Lm54N4Tom6I9h99Emk44pugJOvd6XbIR1 ABjpmnoblkKXw7FEvq4B2u6m+7ve9sRpM7w/cuzdrmkY/WsAN/BiOP5kLkm3QpqF1886Dfky 2HrmhcnAubC9bQI3YtPh1aMjhGG1wAuxIaIZmFsWJLQssLcssLcssLcC4iSAX1SWlZS73ZvX 2mwrlpcWl1WVlpcuL67Y2A20aYp9mYWdBj/cs/cCmgRsGjUjW9wZSXytGg70AguJsYupR7Na 6cMdQSHs41VftbLHj9ReAEmczaI+b9Q4SuDD3yAl+J7itDv8Gbcu8gT1Rw9Vr7TZ/rdgzdS2 SmdFBu3V5m4XQjJS3ls/IkkWUk/1xHQFeVH9TtEf+o/GyBQ9OU1LntE1lCrzAVX0Gnw/sFjN 1BOdoHXCt0ea9yaAWTtfJnVdZ9O0aZx3JbSGmNawqihbb6j9hXnK2gDEwZJfd307Hfsuvqb7 RvzxQIEjsiHWVfNVYK6+cN9wzaYs32/Coi0dJ05lz10pWeff317Xtn5qPDCWU3r2WeamMX/t ebB1SWFf3eUc+c/0H4/PPm471DNczS29bCv459Fz6T5989XeRNHGQ/bdn4wKE6fzDz/Nv/Yi Z+9AeMWga7y5pp0lVB9v/xRXVP4NnBYjWQ0EAAA= Cc: "jplang@ieee.org" , "dimitri.papadimitriou@alcatel-lucent.be" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 04:06:32 -0000 FWIW, I agree too -- I don't see any issues with the current text. Thanks, Sidd -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Jo= hn E Drake Sent: Wednesday, August 01, 2012 7:38 PM To: adrian@olddog.co.uk; ccamp@ietf.org Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; dbrungard@att.= com Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) I don't see any problem with the existing text. Sent from my iPhone > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Adrian Farrel > Sent: Tuesday, July 31, 2012 6:28 PM > To: ccamp@ietf.org > Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org; > dbrungard@att.com > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > Hi CCAMP, > > I find that this erratum is raised against two sections one of which I > supplied text for. If this get contentious, I will call on Stewart to > call consensus and handle the Erratum in the system. > > In my opinion, this proposal goes further than the intention of the > authors/WG in publishing 4872. > > With regard to the proposed addition to section 11... > The use of mb4b is already in scope. The existing text says "The new > LSP resources can be established using the make-before-break > mechanism," so there is no need to re-state "The new LSP can be > established without tearing down the old LSP". > > I think your concern here is whether the old LSP is ever torn down. I > think that you are worried that if the old LSP is torn down, it might > be impossible to perform reversion because, after repair, an attempt > to revert (also using mb4b) might find that key resources have been > "stolen" by some other LSP. I don't see this as at all different from > the issue of the protection LSP itself. That is, it is of the nature > of LSP Rerouting as a protection mechanism that: > a. protection may fail because of lack of resources b. reversion may > fail because of lack of resources > > *If* reversion is so important, I don't quite see why protection is > not important. If protection is important then you should be using a > proper protection mechanism and not waiting for post facto rerouting. > Furthermore, if you require that the LSP be retained for restoration, > why are you not using a protection mechanism? > > But the general paradigm here is that you are willing to use the best > available LSP when it is set up in the first place, the best available > LSP when you re-route after failure, and the best available LSP when > you "revert". > > Lastly, it *does* remain an _option_ to retain the failed LSP in order > to switch back. Nothing in the old text precludes that, although I > understand that there is an implication that it might be expected to > be torn down. > > So I conclude that the proposed addition to section 12 is not what the > authors/WG intended. > > We should discuss further. > > Adrian > > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: 31 July 2012 17:39 > > To: jplang@ieee.org; yakov@juniper.net; > dimitri.papadimitriou@alcatel- > > lucent.be; stbryant@cisco.com; adrian@olddog.co.uk; > > lberger@labn.net; dbrungard@att.com > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC4872 (3304) > > > > > > The following errata report has been submitted for RFC4872, "RSVP-TE > > Extensions in Support of End-to-End Generalized Multi-Protocol Label > > Switching (GMPLS) Recovery". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 > > > > -------------------------------------- > > Type: Technical > > Reported by: Lyndon Ong > > > > Section: 11 & 12 > > > > Original Text > > ------------- > > Section 11 says: > > > > > > (Full) LSP rerouting will be initiated by the head-end node that > has > > either detected the LSP failure or received a Notify message > and/or a > > PathErr message with the new error code/sub-code "Notify Error/LSP > > Locally Failed" for this LSP. The new LSP resources can be > > established using the make-before-break mechanism, where the new > LSP > > is set up before the old LSP is torn down. This is done by using > the > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > can share resources at common nodes. > > > > Section 12 says: > > > > [No text on reversion for (full) LSP Rerouting.] > > > > Corrected Text > > -------------- > > Section 11 should say: > > > > > > (Full) LSP rerouting will be initiated by the head-end node that > has > > either detected the LSP failure or received a Notify message > and/or a > > PathErr message with the new error code/sub-code "Notify Error/LSP > > Locally Failed" for this LSP. The new LSP resources can be > > established using the make-before-break mechanism, where the new > LSP > > is set up before the old LSP is torn down. This is done by using > the > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > can share resources at common nodes. The new LSP can be > established > > without tearing down the old LSP in case of reversion (see > > section > 12). > > > > Section 12 should say: > > > > For "(full) LSP Rerouting", reversion implies that the old LSP is > not > > torn down by the head-end node after the new LSP is established. > For > > reversion, the head-end node re-activates the old LSP after this > has > > recovered. > > > > > > > > Notes > > ----- > > Current text in RFC 4872 describes reversion in the cases of 1+1 > > bidirectional Protection, 1:N Protection with Extra Traffic and > > Rerouting Without Extra > Traffic, > > however it has no description of reversion with (Full) LSP Rerouting. > > For (full) LSP Rerouting, the description in Section 11 instead > > implies that > the old > > LSP is torn down. This has led to some confusion as to whether > > reversion with > > (full) LSP Rerouting is allowed or not allowed by the RFC. We > > believe this was > not > > intentional. The additions would make it clear that reversion can be > > supported with (Full) LSP Rerouting. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or rejected. > > When a decision is reached, the verifying party (IESG) can log in to > > change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > -------------------------------------- > > Title : RSVP-TE Extensions in Support of End-to-End > Generalized > Multi- > > Protocol Label Switching (GMPLS) Recovery > > Publication Date : May 2007 > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > Papadimitriou, Ed. > > Category : PROPOSED STANDARD > > Source : Common Control and Measurement Plane > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From zali@cisco.com Thu Aug 2 02:11:30 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8121821F8E47 for ; Thu, 2 Aug 2012 02:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQtzW02hqPtE for ; Thu, 2 Aug 2012 02:11:28 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7E00B21F8E45 for ; Thu, 2 Aug 2012 02:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zali@cisco.com; l=14075; q=dns/txt; s=iport; t=1343898687; x=1345108287; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yuCix2fZW2tJXQdX/wak82zKnjOP+lH9vTD7Ph9zGK8=; b=EUaDD+LpLC4fME6Al3S15USYN1RIVEDTqmMDhTJaP7vmx4Myj6z4woFb ZBGRzqdweF5TcEV+7MnFeNJYmk97eY/z5uNlNeflVwjnHXeRCgnY/YZOj 5h2mRsVRYhU+8gWA5iqD0HeJvfdX7tY8tbJhtoVkce8WJ55o7FxW3/kiK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJBDGlCtJXG//2dsb2JhbAArGrkNgQeCIAEBAQMBAQEBDwEnNAsFBwQCAQgRBAEBCxQJBycLFAkIAgQBDQUIGodlBgspnQKgO4tJhiRgA5ZbjROBZoJfb3A X-IronPort-AV: E=Sophos;i="4.77,699,1336348800"; d="scan'208";a="107784863" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 02 Aug 2012 09:11:24 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q729BNNc008309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 09:11:23 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.5]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Thu, 2 Aug 2012 04:11:23 -0500 From: "Zafar Ali (zali)" To: John E Drake , "adrian@olddog.co.uk" , "'Ong, Lyndon'" , "ccamp@ietf.org" Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNb+xUnlXr8OcXskWk6mpWOJqAZZdFk2qAgABhDAD//7xuQIAAAP9AgACJhkA= Date: Thu, 2 Aug 2012 09:11:22 +0000 Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A5A8E93302@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A5A8E9337E@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A5A8E9337E@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.201] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.006 x-tm-as-result: No--76.498700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jplang@ieee.org" , "dimitri.papadimitriou@alcatel-lucent.be" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 09:11:30 -0000 Hi John/ Adrian, et al-=20 Please see in-line.=20 Thanks Regards ... Zafar=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Wednesday, August 01, 2012 8:54 PM > To: Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > dbrungard@att.com > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >=20 > You can't keep the original, broken LSP around because it no longer has > e2e committed resources. The best you can do is clean it up and try to > re-instantiate it on its original path. >=20 "Section 12. Reversion" of http://tools.ietf.org/html/rfc4872.=20 " Reversion implies that resources remain allocated to the LSP that was originally routed over them even after a failure."=20 So in this case it is required that the original LSP does not release the a= lready committed resource during failure.=20 If the node detecting the failure send a Path Error "without" PSR flag and = the ingress node does NOT tear LSPs that require the above mentioned behavi= or, the path and resv states for the original (working) LSP along the nomin= al path are kept around.=20 > Sent from my iPhone >=20 > > -----Original Message----- > > From: Zafar Ali (zali) [mailto:zali@cisco.com] > > Sent: Wednesday, August 01, 2012 5:48 PM > > To: John E Drake; adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org > > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > > dbrungard@att.com > > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > Hi John- > > > > Please see my response to Adrian's email for the use case for keeping > > the original LSP around during failure. > > > > Thanks > > > > Regards ... Zafar > > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of John E Drake > > > Sent: Wednesday, August 01, 2012 7:49 PM > > > To: adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org > > > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > > > dbrungard@att.com > > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > > > Is it not the case that the old LSP is broken? In which case it > > needs > > > to be cleaned up and re-signaled. > > > > > > Sent from my iPhone > > > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf Of Adrian Farrel > > > > Sent: Wednesday, August 01, 2012 11:02 AM > > > > To: 'Ong, Lyndon'; ccamp@ietf.org > > > > Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org; > > > > dbrungard@att.com > > > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > > > > > Hello again, > > > > > > > > > Thank you for the fast evaluation of the errata. It sounds like > > > > > the > > > > correction that I > > > > > suggested has ended up overspecifying the method to do reversion > > > with > > > > > full rerouting when it is very possible to support a form of > > > > reversion > > > > > that doesn't involve maintaining the old LSP. > > > > > > > > Right, I understand that you want to allow the option of retaining > > > > the old working LSP. Also that you have no intention to remove the > > > > option of removing the old working LSP. > > > > > > > > > From your response I believe that you do agree that it was not > > the > > > > > intent of > > > > the > > > > > original specification text to imply that reversion with full > > > > > rerouting is not > > > > allowed > > > > > > > > Definitely not the intent to imply that reversion with full > > > > rerouting is not allowed. > > > > Does the text say or even imply this? > > > > > > > > > (or to require that the old LSP always be torn down in full > > > > rerouting) > > > > > > > > Also no intention to *require* the old LSP to be torn down. > > > > My view is that the text is fully conformant with that. > > > > I understand that the text does not make an explicit statement of > > > this. > > > > > > > > > so hopefully > > > > > with some more discussion we can determine if there is anything > > > > > that could be done to make that clearer. > > > > > > > > There is, of course, a lot that could be done to make it clearer. > > > > But is there really a need? We discussed the point. We agreed it > is > > > > not prohibited in the RFC. Can we not just move on? > > > > > > > > Cheers, > > > > Adrian > > > > > -----Original Message----- > > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > > Sent: Tuesday, July 31, 2012 6:28 PM > > > > > To: ccamp@ietf.org > > > > > Cc: jplang@ieee.org; yakov@juniper.net; > > > > dimitri.papadimitriou@alcatel- > > > > > lucent.be; stbryant@cisco.com; lberger@labn.net; > > > > > dbrungard@att.com; Ong, Lyndon > > > > > Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > > > Hi CCAMP, > > > > > > > > > > I find that this erratum is raised against two sections one of > > > > > which > > > > I > > > > supplied text > > > > > for. If this get contentious, I will call on Stewart to call > > > > consensus > > > > > and > > > > handle the > > > > > Erratum in the system. > > > > > > > > > > In my opinion, this proposal goes further than the intention of > > > > > the authors/WG > > > > in > > > > > publishing 4872. > > > > > > > > > > With regard to the proposed addition to section 11... > > > > > The use of mb4b is already in scope. The existing text says "The > > > > > new LSP resources can be established using the make-before-break > > > > > mechanism," so there is no need to re-state "The new LSP can be > > > > > established without tearing down > > > > the > > > > > old LSP". > > > > > > > > > > I think your concern here is whether the old LSP is ever torn > > down. > > > I > > > > > think > > > > that > > > > > you are worried that if the old LSP is torn down, it might be > > > > > impossible to > > > > perform > > > > > reversion because, after repair, an attempt to revert (also > using > > > > > mb4b) might > > > > find > > > > > that key resources have been "stolen" by some other LSP. I don't > > > > > see this as > > > > at all > > > > > different from the issue of the protection LSP itself. That is, > > it > > > is > > > > > of the > > > > nature of > > > > > LSP Rerouting as a protection mechanism that: > > > > > a. protection may fail because of lack of resources b. reversion > > > > > may fail > > > > because > > > > > of lack of resources > > > > > > > > > > *If* reversion is so important, I don't quite see why protection > > > > > is not > > > > important. > > > > > If protection is important then you should be using a proper > > > > > protection mechanism and not waiting for post facto rerouting. > > > > > Furthermore, if you > > > > require > > > > > that the LSP be retained for restoration, why are you not using > a > > > > > protection mechanism? > > > > > > > > > > But the general paradigm here is that you are willing to use the > > > best > > > > available LSP > > > > > when it is set up in the first place, the best available LSP > when > > > you > > > > > re-route > > > > after > > > > > failure, and the best available LSP when you "revert". > > > > > > > > > > Lastly, it *does* remain an _option_ to retain the failed LSP in > > > > order > > > > > to > > > > switch > > > > > back. Nothing in the old text precludes that, although I > > > > > understand that there > > > > is > > > > > an implication that it might be expected to be torn down. > > > > > > > > > > So I conclude that the proposed addition to section 12 is not > > what > > > > the > > > > > authors/WG intended. > > > > > > > > > > We should discuss further. > > > > > > > > > > Adrian > > > > > > > > > > > -----Original Message----- > > > > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > > > > Sent: 31 July 2012 17:39 > > > > > > To: jplang@ieee.org; yakov@juniper.net; > > > > > > dimitri.papadimitriou@alcatel- lucent.be; stbryant@cisco.com; > > > > > > adrian@olddog.co.uk; lberger@labn.net; dbrungard@att.com > > > > > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > > > > > Subject: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > > > > > > > > > > > The following errata report has been submitted for RFC4872, > > > > > > "RSVP- > > > > TE > > > > > > Extensions in Support of End-to-End Generalized Multi-Protocol > > > > Label > > > > > > Switching (GMPLS) Recovery". > > > > > > > > > > > > -------------------------------------- > > > > > > You may review the report below and at: > > > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D33= 04 > > > > > > > > > > > > -------------------------------------- > > > > > > Type: Technical > > > > > > Reported by: Lyndon Ong > > > > > > > > > > > > Section: 11 & 12 > > > > > > > > > > > > Original Text > > > > > > ------------- > > > > > > Section 11 says: > > > > > > > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end node > > > that > > > > has > > > > > > either detected the LSP failure or received a Notify > message > > > > and/or a > > > > > > PathErr message with the new error code/sub-code "Notify > > > > Error/LSP > > > > > > Locally Failed" for this LSP. The new LSP resources can be > > > > > > established using the make-before-break mechanism, where > the > > > new > > > > LSP > > > > > > is set up before the old LSP is torn down. This is done by > > > > using the > > > > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared- > > > > Explicit > > > > > > (SE) reservation style (see [RFC3209]). Both the new and > > old > > > > LSPs > > > > > > can share resources at common nodes. > > > > > > > > > > > > Section 12 says: > > > > > > > > > > > > [No text on reversion for (full) LSP Rerouting.] > > > > > > > > > > > > Corrected Text > > > > > > -------------- > > > > > > Section 11 should say: > > > > > > > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end node > > > that > > > > has > > > > > > either detected the LSP failure or received a Notify > message > > > > and/or a > > > > > > PathErr message with the new error code/sub-code "Notify > > > > Error/LSP > > > > > > Locally Failed" for this LSP. The new LSP resources can be > > > > > > established using the make-before-break mechanism, where > the > > > new > > > > LSP > > > > > > is set up before the old LSP is torn down. This is done by > > > > using the > > > > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared- > > > > Explicit > > > > > > (SE) reservation style (see [RFC3209]). Both the new and > > old > > > > LSPs > > > > > > can share resources at common nodes. The new LSP can be > > > > established > > > > > > without tearing down the old LSP in case of reversion (see > > > > section 12). > > > > > > > > > > > > Section 12 should say: > > > > > > > > > > > > For "(full) LSP Rerouting", reversion implies that the old > > > > > > LSP > > > > is not > > > > > > torn down by the head-end node after the new LSP is > > > established. > > > > For > > > > > > reversion, the head-end node re-activates the old LSP after > > > this > > > > has > > > > > > recovered. > > > > > > > > > > > > > > > > > > > > > > > > Notes > > > > > > ----- > > > > > > Current text in RFC 4872 describes reversion in the cases of > > 1+1 > > > > > > bidirectional Protection, 1:N Protection with Extra Traffic > and > > > > > > Rerouting Without Extra > > > > > Traffic, > > > > > > however it has no description of reversion with (Full) LSP > > > > Rerouting. > > > > > > For (full) LSP Rerouting, the description in Section 11 > instead > > > > > > implies that > > > > > the old > > > > > > LSP is torn down. This has led to some confusion as to whether > > > > > > reversion with > > > > > > (full) LSP Rerouting is allowed or not allowed by the RFC. We > > > > > > believe this was > > > > > not > > > > > > intentional. The additions would make it clear that reversion > > > > > > can > > > > be > > > > > > supported with (Full) LSP Rerouting. > > > > > > > > > > > > Instructions: > > > > > > ------------- > > > > > > This errata is currently posted as "Reported". If necessary, > > > please > > > > > > use "Reply All" to discuss whether it should be verified or > > > > rejected. > > > > > > When a decision is reached, the verifying party (IESG) can log > > > > > > in > > > > to > > > > > > change the status and edit the report, if necessary. > > > > > > > > > > > > -------------------------------------- > > > > > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > > > > > -------------------------------------- > > > > > > Title : RSVP-TE Extensions in Support of End-to- > > End > > > > Generalized > > > > > Multi- > > > > > > Protocol Label Switching (GMPLS) Recovery > > > > > > Publication Date : May 2007 > > > > > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > > > > Papadimitriou, Ed. > > > > > > Category : PROPOSED STANDARD > > > > > > Source : Common Control and Measurement Plane > > > > > > Area : Routing > > > > > > Stream : IETF > > > > > > Verifying Party : IESG > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp From prvs=3561bf1d5b=lyong@ciena.com Thu Aug 2 07:45:29 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8223711E8072 for ; Thu, 2 Aug 2012 07:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.609 X-Spam-Level: X-Spam-Status: No, score=-101.609 tagged_above=-999 required=5 tests=[AWL=1.056, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoefTTTCwbGV for ; Thu, 2 Aug 2012 07:45:28 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 47BBA11E80A6 for ; Thu, 2 Aug 2012 07:45:28 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q72Eir4H013192; Thu, 2 Aug 2012 10:45:18 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 16fu6283af-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 02 Aug 2012 10:45:18 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT01.ciena.com (10.4.140.138) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 2 Aug 2012 10:45:18 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Thu, 2 Aug 2012 10:45:18 -0400 From: "Ong, Lyndon" To: "Zafar Ali (zali)" , John E Drake , "adrian@olddog.co.uk" , "ccamp@ietf.org" Date: Thu, 2 Aug 2012 10:45:18 -0400 Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNb+xUnlXr8OcXskWk6mpWOJqAZZdFk2qAgABhDAD//7xuQIAAAP9AgACJhkCAAF9scA== Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A5A8E93302@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A5A8E9337E@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-19078.007 X-TM-AS-Result: No--57.678700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-01_06:2012-08-01, 2012-08-01, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208020131 Cc: "jplang@ieee.org" , "dimitri.papadimitriou@alcatel-lucent.be" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:45:29 -0000 Hi Zafar, I noted that section of the text as well. Cheers, Lyndon -----Original Message----- From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Thursday, August 02, 2012 2:11 AM To: John E Drake; adrian@olddog.co.uk; Ong, Lyndon; ccamp@ietf.org Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; dbrungard@att= .com Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Hi John/ Adrian, et al- Please see in-line. Thanks Regards ... Zafar > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Wednesday, August 01, 2012 8:54 PM > To: Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, Lyndon'; > ccamp@ietf.org > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > dbrungard@att.com > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > You can't keep the original, broken LSP around because it no longer > has e2e committed resources. The best you can do is clean it up and > try to re-instantiate it on its original path. > "Section 12. Reversion" of http://tools.ietf.org/html/rfc4872. " Reversion implies that resources remain allocated to the LSP that was originally routed over them even after a failure." So in this case it is required that the original LSP does not release the a= lready committed resource during failure. If the node detecting the failure send a Path Error "without" PSR flag and = the ingress node does NOT tear LSPs that require the above mentioned behavi= or, the path and resv states for the original (working) LSP along the nomin= al path are kept around. > Sent from my iPhone > > > -----Original Message----- > > From: Zafar Ali (zali) [mailto:zali@cisco.com] > > Sent: Wednesday, August 01, 2012 5:48 PM > > To: John E Drake; adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org > > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > > dbrungard@att.com > > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > Hi John- > > > > Please see my response to Adrian's email for the use case for > > keeping the original LSP around during failure. > > > > Thanks > > > > Regards ... Zafar > > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of John E Drake > > > Sent: Wednesday, August 01, 2012 7:49 PM > > > To: adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org > > > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > > > dbrungard@att.com > > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > > > Is it not the case that the old LSP is broken? In which case it > > needs > > > to be cleaned up and re-signaled. > > > > > > Sent from my iPhone > > > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf Of Adrian Farrel > > > > Sent: Wednesday, August 01, 2012 11:02 AM > > > > To: 'Ong, Lyndon'; ccamp@ietf.org > > > > Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org; > > > > dbrungard@att.com > > > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > > > > > Hello again, > > > > > > > > > Thank you for the fast evaluation of the errata. It sounds > > > > > like the > > > > correction that I > > > > > suggested has ended up overspecifying the method to do > > > > > reversion > > > with > > > > > full rerouting when it is very possible to support a form of > > > > reversion > > > > > that doesn't involve maintaining the old LSP. > > > > > > > > Right, I understand that you want to allow the option of > > > > retaining the old working LSP. Also that you have no intention > > > > to remove the option of removing the old working LSP. > > > > > > > > > From your response I believe that you do agree that it was not > > the > > > > > intent of > > > > the > > > > > original specification text to imply that reversion with full > > > > > rerouting is not > > > > allowed > > > > > > > > Definitely not the intent to imply that reversion with full > > > > rerouting is not allowed. > > > > Does the text say or even imply this? > > > > > > > > > (or to require that the old LSP always be torn down in full > > > > rerouting) > > > > > > > > Also no intention to *require* the old LSP to be torn down. > > > > My view is that the text is fully conformant with that. > > > > I understand that the text does not make an explicit statement > > > > of > > > this. > > > > > > > > > so hopefully > > > > > with some more discussion we can determine if there is > > > > > anything that could be done to make that clearer. > > > > > > > > There is, of course, a lot that could be done to make it clearer. > > > > But is there really a need? We discussed the point. We agreed it > is > > > > not prohibited in the RFC. Can we not just move on? > > > > > > > > Cheers, > > > > Adrian > > > > > -----Original Message----- > > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > > Sent: Tuesday, July 31, 2012 6:28 PM > > > > > To: ccamp@ietf.org > > > > > Cc: jplang@ieee.org; yakov@juniper.net; > > > > dimitri.papadimitriou@alcatel- > > > > > lucent.be; stbryant@cisco.com; lberger@labn.net; > > > > > dbrungard@att.com; Ong, Lyndon > > > > > Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > > > Hi CCAMP, > > > > > > > > > > I find that this erratum is raised against two sections one of > > > > > which > > > > I > > > > supplied text > > > > > for. If this get contentious, I will call on Stewart to call > > > > consensus > > > > > and > > > > handle the > > > > > Erratum in the system. > > > > > > > > > > In my opinion, this proposal goes further than the intention > > > > > of the authors/WG > > > > in > > > > > publishing 4872. > > > > > > > > > > With regard to the proposed addition to section 11... > > > > > The use of mb4b is already in scope. The existing text says > > > > > "The new LSP resources can be established using the > > > > > make-before-break mechanism," so there is no need to re-state > > > > > "The new LSP can be established without tearing down > > > > the > > > > > old LSP". > > > > > > > > > > I think your concern here is whether the old LSP is ever torn > > down. > > > I > > > > > think > > > > that > > > > > you are worried that if the old LSP is torn down, it might be > > > > > impossible to > > > > perform > > > > > reversion because, after repair, an attempt to revert (also > using > > > > > mb4b) might > > > > find > > > > > that key resources have been "stolen" by some other LSP. I > > > > > don't see this as > > > > at all > > > > > different from the issue of the protection LSP itself. That > > > > > is, > > it > > > is > > > > > of the > > > > nature of > > > > > LSP Rerouting as a protection mechanism that: > > > > > a. protection may fail because of lack of resources b. > > > > > reversion may fail > > > > because > > > > > of lack of resources > > > > > > > > > > *If* reversion is so important, I don't quite see why > > > > > protection is not > > > > important. > > > > > If protection is important then you should be using a proper > > > > > protection mechanism and not waiting for post facto rerouting. > > > > > Furthermore, if you > > > > require > > > > > that the LSP be retained for restoration, why are you not > > > > > using > a > > > > > protection mechanism? > > > > > > > > > > But the general paradigm here is that you are willing to use > > > > > the > > > best > > > > available LSP > > > > > when it is set up in the first place, the best available LSP > when > > > you > > > > > re-route > > > > after > > > > > failure, and the best available LSP when you "revert". > > > > > > > > > > Lastly, it *does* remain an _option_ to retain the failed LSP > > > > > in > > > > order > > > > > to > > > > switch > > > > > back. Nothing in the old text precludes that, although I > > > > > understand that there > > > > is > > > > > an implication that it might be expected to be torn down. > > > > > > > > > > So I conclude that the proposed addition to section 12 is not > > what > > > > the > > > > > authors/WG intended. > > > > > > > > > > We should discuss further. > > > > > > > > > > Adrian > > > > > > > > > > > -----Original Message----- > > > > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > > > > Sent: 31 July 2012 17:39 > > > > > > To: jplang@ieee.org; yakov@juniper.net; > > > > > > dimitri.papadimitriou@alcatel- lucent.be; > > > > > > stbryant@cisco.com; adrian@olddog.co.uk; lberger@labn.net; > > > > > > dbrungard@att.com > > > > > > Cc: lyong@ciena.com; ccamp@ietf.org; > > > > > > rfc-editor@rfc-editor.org > > > > > > Subject: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > > > > > > > > > > > The following errata report has been submitted for RFC4872, > > > > > > "RSVP- > > > > TE > > > > > > Extensions in Support of End-to-End Generalized > > > > > > Multi-Protocol > > > > Label > > > > > > Switching (GMPLS) Recovery". > > > > > > > > > > > > -------------------------------------- > > > > > > You may review the report below and at: > > > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D33= 0 > > > > > > 4 > > > > > > > > > > > > -------------------------------------- > > > > > > Type: Technical > > > > > > Reported by: Lyndon Ong > > > > > > > > > > > > Section: 11 & 12 > > > > > > > > > > > > Original Text > > > > > > ------------- > > > > > > Section 11 says: > > > > > > > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end > > > > > > node > > > that > > > > has > > > > > > either detected the LSP failure or received a Notify > message > > > > and/or a > > > > > > PathErr message with the new error code/sub-code "Notify > > > > Error/LSP > > > > > > Locally Failed" for this LSP. The new LSP resources can be > > > > > > established using the make-before-break mechanism, where > the > > > new > > > > LSP > > > > > > is set up before the old LSP is torn down. This is done > > > > > > by > > > > using the > > > > > > mechanisms of the SESSION_ATTRIBUTE object and the > > > > > > Shared- > > > > Explicit > > > > > > (SE) reservation style (see [RFC3209]). Both the new and > > old > > > > LSPs > > > > > > can share resources at common nodes. > > > > > > > > > > > > Section 12 says: > > > > > > > > > > > > [No text on reversion for (full) LSP Rerouting.] > > > > > > > > > > > > Corrected Text > > > > > > -------------- > > > > > > Section 11 should say: > > > > > > > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end > > > > > > node > > > that > > > > has > > > > > > either detected the LSP failure or received a Notify > message > > > > and/or a > > > > > > PathErr message with the new error code/sub-code "Notify > > > > Error/LSP > > > > > > Locally Failed" for this LSP. The new LSP resources can be > > > > > > established using the make-before-break mechanism, where > the > > > new > > > > LSP > > > > > > is set up before the old LSP is torn down. This is done > > > > > > by > > > > using the > > > > > > mechanisms of the SESSION_ATTRIBUTE object and the > > > > > > Shared- > > > > Explicit > > > > > > (SE) reservation style (see [RFC3209]). Both the new and > > old > > > > LSPs > > > > > > can share resources at common nodes. The new LSP can be > > > > established > > > > > > without tearing down the old LSP in case of reversion > > > > > > (see > > > > section 12). > > > > > > > > > > > > Section 12 should say: > > > > > > > > > > > > For "(full) LSP Rerouting", reversion implies that the > > > > > > old LSP > > > > is not > > > > > > torn down by the head-end node after the new LSP is > > > established. > > > > For > > > > > > reversion, the head-end node re-activates the old LSP > > > > > > after > > > this > > > > has > > > > > > recovered. > > > > > > > > > > > > > > > > > > > > > > > > Notes > > > > > > ----- > > > > > > Current text in RFC 4872 describes reversion in the cases of > > 1+1 > > > > > > bidirectional Protection, 1:N Protection with Extra Traffic > and > > > > > > Rerouting Without Extra > > > > > Traffic, > > > > > > however it has no description of reversion with (Full) LSP > > > > Rerouting. > > > > > > For (full) LSP Rerouting, the description in Section 11 > instead > > > > > > implies that > > > > > the old > > > > > > LSP is torn down. This has led to some confusion as to > > > > > > whether reversion with > > > > > > (full) LSP Rerouting is allowed or not allowed by the RFC. > > > > > > We believe this was > > > > > not > > > > > > intentional. The additions would make it clear that > > > > > > reversion can > > > > be > > > > > > supported with (Full) LSP Rerouting. > > > > > > > > > > > > Instructions: > > > > > > ------------- > > > > > > This errata is currently posted as "Reported". If necessary, > > > please > > > > > > use "Reply All" to discuss whether it should be verified or > > > > rejected. > > > > > > When a decision is reached, the verifying party (IESG) can > > > > > > log in > > > > to > > > > > > change the status and edit the report, if necessary. > > > > > > > > > > > > -------------------------------------- > > > > > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > > > > > -------------------------------------- > > > > > > Title : RSVP-TE Extensions in Support of End-to- > > End > > > > Generalized > > > > > Multi- > > > > > > Protocol Label Switching (GMPLS) Recovery > > > > > > Publication Date : May 2007 > > > > > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > > > > Papadimitriou, Ed. > > > > > > Category : PROPOSED STANDARD > > > > > > Source : Common Control and Measurement Plane > > > > > > Area : Routing > > > > > > Stream : IETF > > > > > > Verifying Party : IESG > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp From dimitri.papadimitriou@alcatel-lucent.com Thu Aug 2 08:24:28 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF2E21E8034 for ; Thu, 2 Aug 2012 08:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.383 X-Spam-Level: X-Spam-Status: No, score=-8.383 tagged_above=-999 required=5 tests=[AWL=1.267, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7R8lKAbq-tL for ; Thu, 2 Aug 2012 08:24:26 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC0711E8087 for ; Thu, 2 Aug 2012 08:24:25 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q72FNpPX007594 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 2 Aug 2012 17:24:13 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 2 Aug 2012 17:24:04 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: Lou Berger , "adrian@olddog.co.uk" , "'Ong, Lyndon'" Date: Thu, 2 Aug 2012 17:24:01 +0200 Thread-Topic: [Technical Errata Reported] RFC4872 (3304) Thread-Index: Ac1wTRfqxAtgBDpoTmW5aPGeI7exFwALOvlw Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5019A35A.7090906@labn.net> In-Reply-To: <5019A35A.7090906@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "ccamp@ietf.org" , "jplang@ieee.org" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 15:24:28 -0000 Lou,=20 there is by definition no notion of "reversion" in full LSP re-routing. thi= s is why there is no such description: it is less faster than e.g. protecti= on but less resource-consuming (direct release of resources after establish= ment of the new LSP using make-before-break/RFC 3209) and more robust. see = also RFC 4428 for more details.=20 -> so I am not sure to which revision placeholder of RFC 4872 you are talki= ng as I miss the rationales for a "scenario" that increases recovery time *= and* resource consumption. Thanks, -dimitri. > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: Wednesday, August 01, 2012 23:45 > To: adrian@olddog.co.uk; 'Ong, Lyndon' > Cc: ccamp@ietf.org; jplang@ieee.org; yakov@juniper.net;=20 > Papadimitriou, Dimitri (Dimitri); stbryant@cisco.com;=20 > dbrungard@att.com; 'Roch, Evelyne' > Subject: Re: [Technical Errata Reported] RFC4872 (3304) >=20 > > There is, of course, a lot that could be done to make it=20 > clearer. But > is there > > really a need? We discussed the point. We agreed it is not=20 > prohibited > in the > > RFC. Can we not just move on? >=20 > So it sounds like there's agreement that there's no technical=20 > errata here. >=20 > Perhaps an alternate way to proceed is to replace this errata with an > editorial errata that states that a future revision of the RFC should > explicitly discuss how this scenario is covered? >=20 > Comments/thoughts? >=20 > Lou >=20 > On 8/1/2012 11:01 AM, Adrian Farrel wrote: > > Hello again, > >=20 > >> Thank you for the fast evaluation of the errata. It=20 > sounds like the > > correction that I > >> suggested has ended up overspecifying the method to do=20 > reversion with full > >> rerouting when it is very possible to support a form of=20 > reversion that doesn't > >> involve maintaining the old LSP. > >=20 > > Right, I understand that you want to allow the option of=20 > retaining the old > > working LSP. Also that you have no intention to remove the=20 > option of removing > > the old working LSP. > >=20 > >> From your response I believe that you do agree that it was=20 > not the intent of > > the > >> original specification text to imply that reversion with=20 > full rerouting is not > > allowed > >=20 > > Definitely not the intent to imply that reversion with full=20 > rerouting is not > > allowed. > > Does the text say or even imply this? > >=20 > >> (or to require that the old LSP always be torn down in=20 > full rerouting) > >=20 > > Also no intention to *require* the old LSP to be torn down.=20 > > My view is that the text is fully conformant with that. > > I understand that the text does not make an explicit=20 > statement of this. > >=20 > >> so hopefully > >> with some more discussion we can determine if there is=20 > anything that could be > >> done to make that clearer. > >=20 > > There is, of course, a lot that could be done to make it=20 > clearer. But is there > > really a need? We discussed the point. We agreed it is not=20 > prohibited in the > > RFC. Can we not just move on? > >=20 > > Cheers, > > Adrian > >> -----Original Message----- > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> Sent: Tuesday, July 31, 2012 6:28 PM > >> To: ccamp@ietf.org > >> Cc: jplang@ieee.org; yakov@juniper.net;=20 > dimitri.papadimitriou@alcatel- > >> lucent.be; stbryant@cisco.com; lberger@labn.net;=20 > dbrungard@att.com; Ong, > >> Lyndon > >> Subject: RE: [Technical Errata Reported] RFC4872 (3304) > >> > >> Hi CCAMP, > >> > >> I find that this erratum is raised against two sections=20 > one of which I > > supplied text > >> for. If this get contentious, I will call on Stewart to=20 > call consensus and > > handle the > >> Erratum in the system. > >> > >> In my opinion, this proposal goes further than the=20 > intention of the authors/WG > > in > >> publishing 4872. > >> > >> With regard to the proposed addition to section 11... > >> The use of mb4b is already in scope. The existing text=20 > says "The new LSP > >> resources can be established using the make-before-break=20 > mechanism," so there > >> is no need to re-state "The new LSP can be established=20 > without tearing down > > the > >> old LSP". > >> > >> I think your concern here is whether the old LSP is ever=20 > torn down. I think > > that > >> you are worried that if the old LSP is torn down, it might=20 > be impossible to > > perform > >> reversion because, after repair, an attempt to revert=20 > (also using mb4b) might > > find > >> that key resources have been "stolen" by some other LSP. I=20 > don't see this as > > at all > >> different from the issue of the protection LSP itself.=20 > That is, it is of the > > nature of > >> LSP Rerouting as a protection mechanism that: > >> a. protection may fail because of lack of resources b.=20 > reversion may fail > > because > >> of lack of resources > >> > >> *If* reversion is so important, I don't quite see why=20 > protection is not > > important. > >> If protection is important then you should be using a=20 > proper protection > >> mechanism and not waiting for post facto rerouting.=20 > Furthermore, if you > > require > >> that the LSP be retained for restoration, why are you not=20 > using a protection > >> mechanism? > >> > >> But the general paradigm here is that you are willing to=20 > use the best > > available LSP > >> when it is set up in the first place, the best available=20 > LSP when you re-route > > after > >> failure, and the best available LSP when you "revert". > >> > >> Lastly, it *does* remain an _option_ to retain the failed=20 > LSP in order to > > switch > >> back. Nothing in the old text precludes that, although I=20 > understand that there > > is > >> an implication that it might be expected to be torn down. > >> > >> So I conclude that the proposed addition to section 12 is=20 > not what the > >> authors/WG intended. > >> > >> We should discuss further. > >> > >> Adrian > >> > >>> -----Original Message----- > >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >>> Sent: 31 July 2012 17:39 > >>> To: jplang@ieee.org; yakov@juniper.net;=20 > dimitri.papadimitriou@alcatel- > >>> lucent.be; stbryant@cisco.com; adrian@olddog.co.uk;=20 > lberger@labn.net; > >>> dbrungard@att.com > >>> Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > >>> Subject: [Technical Errata Reported] RFC4872 (3304) > >>> > >>> > >>> The following errata report has been submitted for=20 > RFC4872, "RSVP-TE > >>> Extensions in Support of End-to-End Generalized=20 > Multi-Protocol Label > >>> Switching (GMPLS) Recovery". > >>> > >>> -------------------------------------- > >>> You may review the report below and at: > >>> http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 > >>> > >>> -------------------------------------- > >>> Type: Technical > >>> Reported by: Lyndon Ong > >>> > >>> Section: 11 & 12 > >>> > >>> Original Text > >>> ------------- > >>> Section 11 says: > >>> > >>> > >>> (Full) LSP rerouting will be initiated by the head-end=20 > node that has > >>> either detected the LSP failure or received a Notify=20 > message and/or a > >>> PathErr message with the new error code/sub-code=20 > "Notify Error/LSP > >>> Locally Failed" for this LSP. The new LSP resources can be > >>> established using the make-before-break mechanism,=20 > where the new LSP > >>> is set up before the old LSP is torn down. This is=20 > done by using the > >>> mechanisms of the SESSION_ATTRIBUTE object and the=20 > Shared-Explicit > >>> (SE) reservation style (see [RFC3209]). Both the new=20 > and old LSPs > >>> can share resources at common nodes. > >>> > >>> Section 12 says: > >>> > >>> [No text on reversion for (full) LSP Rerouting.] > >>> > >>> Corrected Text > >>> -------------- > >>> Section 11 should say: > >>> > >>> > >>> (Full) LSP rerouting will be initiated by the head-end=20 > node that has > >>> either detected the LSP failure or received a Notify=20 > message and/or a > >>> PathErr message with the new error code/sub-code=20 > "Notify Error/LSP > >>> Locally Failed" for this LSP. The new LSP resources can be > >>> established using the make-before-break mechanism,=20 > where the new LSP > >>> is set up before the old LSP is torn down. This is=20 > done by using the > >>> mechanisms of the SESSION_ATTRIBUTE object and the=20 > Shared-Explicit > >>> (SE) reservation style (see [RFC3209]). Both the new=20 > and old LSPs > >>> can share resources at common nodes. The new LSP can=20 > be established > >>> without tearing down the old LSP in case of reversion=20 > (see section 12). > >>> > >>> Section 12 should say: > >>> > >>> For "(full) LSP Rerouting", reversion implies that the=20 > old LSP is not > >>> torn down by the head-end node after the new LSP is=20 > established. For > >>> reversion, the head-end node re-activates the old LSP=20 > after this has > >>> recovered. > >>> > >>> > >>> > >>> Notes > >>> ----- > >>> Current text in RFC 4872 describes reversion in the cases of 1+1 > >>> bidirectional Protection, 1:N Protection with Extra Traffic and > >>> Rerouting Without Extra > >> Traffic, > >>> however it has no description of reversion with (Full)=20 > LSP Rerouting. > >>> For (full) LSP Rerouting, the description in Section 11 instead > >>> implies that > >> the old > >>> LSP is torn down. This has led to some confusion as to whether > >>> reversion with > >>> (full) LSP Rerouting is allowed or not allowed by the=20 > RFC. We believe > >>> this was > >> not > >>> intentional. The additions would make it clear that=20 > reversion can be > >>> supported with (Full) LSP Rerouting. > >>> > >>> Instructions: > >>> ------------- > >>> This errata is currently posted as "Reported". If=20 > necessary, please > >>> use "Reply All" to discuss whether it should be verified=20 > or rejected. > >>> When a decision is reached, the verifying party (IESG)=20 > can log in to > >>> change the status and edit the report, if necessary. > >>> > >>> -------------------------------------- > >>> RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > >>> -------------------------------------- > >>> Title : RSVP-TE Extensions in Support of End-to-End > > Generalized > >> Multi- > >>> Protocol Label Switching (GMPLS) Recovery > >>> Publication Date : May 2007 > >>> Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D.=20 > Papadimitriou, Ed. > >>> Category : PROPOSED STANDARD > >>> Source : Common Control and Measurement Plane > >>> Area : Routing > >>> Stream : IETF > >>> Verifying Party : IESG > >=20 > >=20 > >=20 > >=20 > >=20 > = From zali@cisco.com Thu Aug 2 08:47:09 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9117E21F8622 for ; Thu, 2 Aug 2012 08:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59+ZsFBkxj0z for ; Thu, 2 Aug 2012 08:47:08 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1394D21F8620 for ; Thu, 2 Aug 2012 08:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zali@cisco.com; l=12838; q=dns/txt; s=iport; t=1343922428; x=1345132028; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HD9hPYvlDzIUA9ccAr4tvzMLmDAhLSEDeEld8hT0paA=; b=NZyo8S1EVxUcVwzJvR9SWRF6HHHTU8pE9ROQFsJ2xZTYloY0iieo9S1h NihDVqU7k1QVGjCmmQvZ5Ycd+DYWkFa/PCqvS1EC0hBoyYhreXog7dWF6 abqIzmKwD1GlD+lu6FNBF7nx5uxizCuOJ8SnpgwIBVu54Z5Z52GbXWqpD w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPSfGlCtJXG9/2dsb2JhbAArGrkMgQeCIAEBAQMBAQEBDwEUEzQLBQcEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQgah2UGCymcPqBMi0mGJGADo26BZoJfbw X-IronPort-AV: E=Sophos;i="4.77,701,1336348800"; d="scan'208";a="107882494" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 02 Aug 2012 15:47:07 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q72Fl7UI005862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 15:47:07 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.69]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 10:47:07 -0500 From: "Zafar Ali (zali)" To: "Papadimitriou, Dimitri (Dimitri)" , Lou Berger , "adrian@olddog.co.uk" , "'Ong, Lyndon'" Thread-Topic: [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNcMLyahN3GskcHE2KgpRsg0CwJpdGqVrA Date: Thu, 2 Aug 2012 15:47:05 +0000 Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5019A35A.7090906@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.201] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.006 x-tm-as-result: No--72.721400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jplang@ieee.org" , "ccamp@ietf.org" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 15:47:09 -0000 Dimitri-=20 Please see in-line.=20 Thanks Regards ... Zafar=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Papadimitriou, Dimitri (Dimitri) > Sent: Thursday, August 02, 2012 11:24 AM > To: Lou Berger; adrian@olddog.co.uk; 'Ong, Lyndon' > Cc: ccamp@ietf.org; jplang@ieee.org; dbrungard@att.com > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >=20 > Lou, >=20 > there is by definition no notion of "reversion" in full LSP re-routing. > this is why there is no such description: it is less faster than e.g. > protection but less resource-consuming (direct release of resources > after establishment of the new LSP using make-before-break/RFC 3209) and > more robust. see also RFC 4428 for more details. >=20 > -> so I am not sure to which revision placeholder of RFC 4872 you are > talking as I miss the rationales for a "scenario" that increases > recovery time *and* resource consumption. >=20 Reversion requirement has nothing to do with the "recovery time" or "protec= tion" vs. "restoration". Reversion requirement has to do with ability for t= he LSP to come back up on the original path *after* the failure is recovere= d. Typically working LSP follows nominal path (e.g., least latency path) an= d SPs would like the LSP to go back to nominal LSP path once a failure is r= epair. During failure time, either protection or restoration kicks in to mi= nimize impact on the service. Reversion requirements equally apply to prote= ction as well as restoration. =20 For some circuit SP may decide that on-the-fly restoration suffices (may be= based on monitory cost for the circuit). But they still like the LSP to go= back to the nominal path (original working path).=20 > Thanks, > -dimitri. > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, August 01, 2012 23:45 > > To: adrian@olddog.co.uk; 'Ong, Lyndon' > > Cc: ccamp@ietf.org; jplang@ieee.org; yakov@juniper.net; > > Papadimitriou, Dimitri (Dimitri); stbryant@cisco.com; > > dbrungard@att.com; 'Roch, Evelyne' > > Subject: Re: [Technical Errata Reported] RFC4872 (3304) > > > > > There is, of course, a lot that could be done to make it > > clearer. But > > is there > > > really a need? We discussed the point. We agreed it is not > > prohibited > > in the > > > RFC. Can we not just move on? > > > > So it sounds like there's agreement that there's no technical > > errata here. > > > > Perhaps an alternate way to proceed is to replace this errata with an > > editorial errata that states that a future revision of the RFC should > > explicitly discuss how this scenario is covered? > > > > Comments/thoughts? > > > > Lou > > > > On 8/1/2012 11:01 AM, Adrian Farrel wrote: > > > Hello again, > > > > > >> Thank you for the fast evaluation of the errata. It > > sounds like the > > > correction that I > > >> suggested has ended up overspecifying the method to do > > reversion with full > > >> rerouting when it is very possible to support a form of > > reversion that doesn't > > >> involve maintaining the old LSP. > > > > > > Right, I understand that you want to allow the option of > > retaining the old > > > working LSP. Also that you have no intention to remove the > > option of removing > > > the old working LSP. > > > > > >> From your response I believe that you do agree that it was > > not the intent of > > > the > > >> original specification text to imply that reversion with > > full rerouting is not > > > allowed > > > > > > Definitely not the intent to imply that reversion with full > > rerouting is not > > > allowed. > > > Does the text say or even imply this? > > > > > >> (or to require that the old LSP always be torn down in > > full rerouting) > > > > > > Also no intention to *require* the old LSP to be torn down. > > > My view is that the text is fully conformant with that. > > > I understand that the text does not make an explicit > > statement of this. > > > > > >> so hopefully > > >> with some more discussion we can determine if there is > > anything that could be > > >> done to make that clearer. > > > > > > There is, of course, a lot that could be done to make it > > clearer. But is there > > > really a need? We discussed the point. We agreed it is not > > prohibited in the > > > RFC. Can we not just move on? > > > > > > Cheers, > > > Adrian > > >> -----Original Message----- > > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > >> Sent: Tuesday, July 31, 2012 6:28 PM > > >> To: ccamp@ietf.org > > >> Cc: jplang@ieee.org; yakov@juniper.net; > > dimitri.papadimitriou@alcatel- > > >> lucent.be; stbryant@cisco.com; lberger@labn.net; > > dbrungard@att.com; Ong, > > >> Lyndon > > >> Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > >> > > >> Hi CCAMP, > > >> > > >> I find that this erratum is raised against two sections > > one of which I > > > supplied text > > >> for. If this get contentious, I will call on Stewart to > > call consensus and > > > handle the > > >> Erratum in the system. > > >> > > >> In my opinion, this proposal goes further than the > > intention of the authors/WG > > > in > > >> publishing 4872. > > >> > > >> With regard to the proposed addition to section 11... > > >> The use of mb4b is already in scope. The existing text > > says "The new LSP > > >> resources can be established using the make-before-break > > mechanism," so there > > >> is no need to re-state "The new LSP can be established > > without tearing down > > > the > > >> old LSP". > > >> > > >> I think your concern here is whether the old LSP is ever > > torn down. I think > > > that > > >> you are worried that if the old LSP is torn down, it might > > be impossible to > > > perform > > >> reversion because, after repair, an attempt to revert > > (also using mb4b) might > > > find > > >> that key resources have been "stolen" by some other LSP. I > > don't see this as > > > at all > > >> different from the issue of the protection LSP itself. > > That is, it is of the > > > nature of > > >> LSP Rerouting as a protection mechanism that: > > >> a. protection may fail because of lack of resources b. > > reversion may fail > > > because > > >> of lack of resources > > >> > > >> *If* reversion is so important, I don't quite see why > > protection is not > > > important. > > >> If protection is important then you should be using a > > proper protection > > >> mechanism and not waiting for post facto rerouting. > > Furthermore, if you > > > require > > >> that the LSP be retained for restoration, why are you not > > using a protection > > >> mechanism? > > >> > > >> But the general paradigm here is that you are willing to > > use the best > > > available LSP > > >> when it is set up in the first place, the best available > > LSP when you re-route > > > after > > >> failure, and the best available LSP when you "revert". > > >> > > >> Lastly, it *does* remain an _option_ to retain the failed > > LSP in order to > > > switch > > >> back. Nothing in the old text precludes that, although I > > understand that there > > > is > > >> an implication that it might be expected to be torn down. > > >> > > >> So I conclude that the proposed addition to section 12 is > > not what the > > >> authors/WG intended. > > >> > > >> We should discuss further. > > >> > > >> Adrian > > >> > > >>> -----Original Message----- > > >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > >>> Sent: 31 July 2012 17:39 > > >>> To: jplang@ieee.org; yakov@juniper.net; > > dimitri.papadimitriou@alcatel- > > >>> lucent.be; stbryant@cisco.com; adrian@olddog.co.uk; > > lberger@labn.net; > > >>> dbrungard@att.com > > >>> Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > >>> Subject: [Technical Errata Reported] RFC4872 (3304) > > >>> > > >>> > > >>> The following errata report has been submitted for > > RFC4872, "RSVP-TE > > >>> Extensions in Support of End-to-End Generalized > > Multi-Protocol Label > > >>> Switching (GMPLS) Recovery". > > >>> > > >>> -------------------------------------- > > >>> You may review the report below and at: > > >>> http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 > > >>> > > >>> -------------------------------------- > > >>> Type: Technical > > >>> Reported by: Lyndon Ong > > >>> > > >>> Section: 11 & 12 > > >>> > > >>> Original Text > > >>> ------------- > > >>> Section 11 says: > > >>> > > >>> > > >>> (Full) LSP rerouting will be initiated by the head-end > > node that has > > >>> either detected the LSP failure or received a Notify > > message and/or a > > >>> PathErr message with the new error code/sub-code > > "Notify Error/LSP > > >>> Locally Failed" for this LSP. The new LSP resources can be > > >>> established using the make-before-break mechanism, > > where the new LSP > > >>> is set up before the old LSP is torn down. This is > > done by using the > > >>> mechanisms of the SESSION_ATTRIBUTE object and the > > Shared-Explicit > > >>> (SE) reservation style (see [RFC3209]). Both the new > > and old LSPs > > >>> can share resources at common nodes. > > >>> > > >>> Section 12 says: > > >>> > > >>> [No text on reversion for (full) LSP Rerouting.] > > >>> > > >>> Corrected Text > > >>> -------------- > > >>> Section 11 should say: > > >>> > > >>> > > >>> (Full) LSP rerouting will be initiated by the head-end > > node that has > > >>> either detected the LSP failure or received a Notify > > message and/or a > > >>> PathErr message with the new error code/sub-code > > "Notify Error/LSP > > >>> Locally Failed" for this LSP. The new LSP resources can be > > >>> established using the make-before-break mechanism, > > where the new LSP > > >>> is set up before the old LSP is torn down. This is > > done by using the > > >>> mechanisms of the SESSION_ATTRIBUTE object and the > > Shared-Explicit > > >>> (SE) reservation style (see [RFC3209]). Both the new > > and old LSPs > > >>> can share resources at common nodes. The new LSP can > > be established > > >>> without tearing down the old LSP in case of reversion > > (see section 12). > > >>> > > >>> Section 12 should say: > > >>> > > >>> For "(full) LSP Rerouting", reversion implies that the > > old LSP is not > > >>> torn down by the head-end node after the new LSP is > > established. For > > >>> reversion, the head-end node re-activates the old LSP > > after this has > > >>> recovered. > > >>> > > >>> > > >>> > > >>> Notes > > >>> ----- > > >>> Current text in RFC 4872 describes reversion in the cases of 1+1 > > >>> bidirectional Protection, 1:N Protection with Extra Traffic and > > >>> Rerouting Without Extra > > >> Traffic, > > >>> however it has no description of reversion with (Full) > > LSP Rerouting. > > >>> For (full) LSP Rerouting, the description in Section 11 instead > > >>> implies that > > >> the old > > >>> LSP is torn down. This has led to some confusion as to whether > > >>> reversion with > > >>> (full) LSP Rerouting is allowed or not allowed by the > > RFC. We believe > > >>> this was > > >> not > > >>> intentional. The additions would make it clear that > > reversion can be > > >>> supported with (Full) LSP Rerouting. > > >>> > > >>> Instructions: > > >>> ------------- > > >>> This errata is currently posted as "Reported". If > > necessary, please > > >>> use "Reply All" to discuss whether it should be verified > > or rejected. > > >>> When a decision is reached, the verifying party (IESG) > > can log in to > > >>> change the status and edit the report, if necessary. > > >>> > > >>> -------------------------------------- > > >>> RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > >>> -------------------------------------- > > >>> Title : RSVP-TE Extensions in Support of End-to-End > > > Generalized > > >> Multi- > > >>> Protocol Label Switching (GMPLS) Recovery > > >>> Publication Date : May 2007 > > >>> Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > > Papadimitriou, Ed. > > >>> Category : PROPOSED STANDARD > > >>> Source : Common Control and Measurement Plane > > >>> Area : Routing > > >>> Stream : IETF > > >>> Verifying Party : IESG > > > > > > > > > > > > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From giomarti@cisco.com Thu Aug 2 09:15:39 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FA521F8510 for ; Thu, 2 Aug 2012 09:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.068 X-Spam-Level: X-Spam-Status: No, score=-10.068 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ecm7EM38nNhg for ; Thu, 2 Aug 2012 09:15:38 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BA61A21F84AF for ; Thu, 2 Aug 2012 09:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=giomarti@cisco.com; l=6625; q=dns/txt; s=iport; t=1343924138; x=1345133738; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XS17ofDK5iakD+TxwexzQXctnGGpB72i2l/O+Lagx4A=; b=TPpQ6+4J2xAmGJUyJe5drugiU5KJ+xP4Cdn0CoTJLCczIOy7ugQgifnn HgvDHjmJMvaDTO1p5xfcLUKPHStDHZ8szunjJ09rTG5B4PSK4EdBbmHNd FttcJwV5aaFQfBQTs291Nq2WNlp8WdnLPmJA30JKU1gubsOHyMjkxyI6Q o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB6nGlCtJV2Z/2dsb2JhbABFuQyBB4IgAQEBAwEBAQEPASc0CwUHBAIBCBEEAQEBHgkHJwsUCQgCBA4FIodlBgucXqBRi0kCGIYKYAOVR4EUjROBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="107882940" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 02 Aug 2012 16:15:38 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q72GFcA1027175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 16:15:38 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.69]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 11:15:37 -0500 From: "Giovanni Martinelli (giomarti)" To: Leeyoung Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority Thread-Index: AQHNbqOAwicEtWD5nEWGP6luAcXdUpdFj84AgABP4QCAAASpgIAACiyAgAEcMgA= Date: Thu, 2 Aug 2012 16:15:37 +0000 Message-ID: <48F63A76-53E9-4C38-A266-8B8BAB9F7838@cisco.com> References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED70@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172905ED70@dfweml511-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.166.99] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.006 x-tm-as-result: No--59.598300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <27871CC5ECC1374498E825831189CA58@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:15:40 -0000 Hi Young, btw first just a naming issue (I guess a question for the wg in general) th= e object label_set here has the same name name as the label_set form rfc347= 1 but it has actually a different encoding, so just asking if worth figurin= g out a little different name. If no one complain I'm fine too. please see inline On Aug 2, 2012, at 1:18 , Leeyoung wrote: > > On Aug 2, 2012, at 24:25 , Leeyoung wrote: >=20 >> Hi Giovanni, >>=20 >> The wavelength priority you propose seems different from the what we enc= oded per Rao Rajan's suggestion. What we encoded in section 2.3 of gen enco= de is not giving wavelength a priority level, among which I believe your wa= velength property specifies. >>=20 >> What we are proposing is what labels are available/not available for eac= h priority level (similar to LSP reservation or holding priority) as the fo= llowing encoding dictates:=20 >>=20 >=20 >=20 > GM> So at the end is a "Label Priority" ? With the Label_Set granularity = instead of the single Label? =20 >=20 > YOUNG>> No, this is not "label priority". Label is not "assigned" a prior= ity. Label is neutral. Say, you have five wavelengths available for grab an= d you have two priorities you are aware of which is service level (e.g., LS= P). For higher priority service, you may want to all your five wavelengths = (w1-w5) available for grab while for lower priority, you may restrict to le= ss number of wavelengths, say three wavelengths only (e.g., w1-w3). GM> Well I'm not sure I'm following you, you say that labels are not assign= ed to a priority but then there is a priority associated to a label set. Fo= r sure label is neutral but "someone" decide if it goes in a label set with= a certain priority, or in another (or in both label_set ). So, to me this = means associate (is this term better than assign?) a priority to a label. > Here you can see individual wavelength is not assigned a priority. GM> the granularity is the label_set so you can easily see that's equivalen= t to individual label, anyway single label or label-set its not a substanti= al difference to me. > This is analogous to how much BW availability for each priority in MPLS n= etwork, except that we need to express in wavelength level. =20 >=20 >=20 >=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |A| Reserved | Priority Flags| Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Label Set Field | >> : : >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Where >>=20 >> A (Availability bit) =3D 1 or 0 indicates that the labels listed in >> the following label set field are available or not available, >> respectively, for use at a given priority level as indicated by the >> Priority Flags. >=20 >=20 > GM> The reading here suggest me that there could be multiple objects (I b= et up to 8) packed up somewere (e.g. something like sub-tlvs in the link ad= vertisement). Is my interpretation correct? >=20 > YOUNG>> Yes.=20 >=20 GM> two encoding question here: GM> 1/ why using flags instead of classical three bits?=20 GM> 2/ What the usage of A? I mean you have an Available_label object and t= hen you set A=3D0 which means that labels are not available... could you pl= ease clarify better? =20 Cheers G > Cheers > G >=20 >=20 >>=20 >> Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 >> corresponds to priority level 7. If a bit is set then the labels in >> the label set field are available or not available as indicated by >> the A bit for use at that particular priority level. >>=20 >> Let's begin if we are in agreement with this point.=20 >>=20 >> Thanks. >> Young >>=20 >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf O= f Giovanni Martinelli (giomarti) >> Sent: Wednesday, August 01, 2012 12:40 PM >> To: Giovanni Martinelli (giomarti) >> Cc: CCAMP >> Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-enco= de-08: priority >>=20 >> Here my latest mail with comments on wavelength priority...=20 >>=20 >> Here my memory on past discussion (please correct if wrong) >> - last short thread was during ieft83 (around 26/28 march), last mail wa= s from me and did not get answers. The content here below cover that mail a= s well. >> - discussions about wl priority happens among authors not on ccamp maili= ng list. On the mailing list you announce draft update around dec 2011. =20 >>=20 >> Well, I'm not complaining about how discussion happen, simply I saw a n= ot-trivial addition to wg document, hence my comments. >>=20 >> Cheers >> G >>=20 >>=20 >>=20 >> On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: >>=20 >>> Dear authors / ccamp, >>>=20 >>> here a few comments related to the priority field added to draft-ietf-c= camp-general-constraint-encode: >>>=20 >>> A couple of editorial comments >>> 1) "wavelenght priority" appears in a draft that claim to be general. = In fact is available in "Available Labels Sub-TLV" and "Shared Backup Label= s Sub-TLV". So is a wavelength or label-like priority? >>> 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0= .. 7]? >>>=20 >>>=20 >>> Then few other comments >>> 3) How the priority is used versus the A flag . Draft text report >>> " =20 >>> A (Availability bit) =3D 1 or 0 indicates that the labels listed in >>> the following label set field are available or not available, >>> respectively, for use at a given priority level as indicated by the >>> Priority Flags. >>>=20 >>> " >>> So does it means that there could be different "available labels sub-TL= Vs" advertised?=20 >>>=20 >>> 4) Still unclear to me how this priority is different from the one repo= rted in http://tools.ietf.org/html/draft-kattan-wson-property-01 and eventu= ally if this "priority" could fit the LSP priority already available (as on= e of the comment we received at that time) >>>=20 >>> Cheers >>> G >>>=20 >>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >=20 From rrao@infinera.com Thu Aug 2 09:20:57 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A504E11E80CC for ; Thu, 2 Aug 2012 09:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twFpizIu423L for ; Thu, 2 Aug 2012 09:20:56 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 21D3811E80EA for ; Thu, 2 Aug 2012 09:20:56 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0283.003; Thu, 2 Aug 2012 09:20:55 -0700 From: Rajan Rao To: John E Drake , "Zafar Ali (zali)" , "adrian@olddog.co.uk" , "'Ong, Lyndon'" , "ccamp@ietf.org" Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNb+xRzb87U2dmuEW4nUyID8ipJZdFtPGAgABhDQCAABB8AIAAAagAgACMARA= Date: Thu, 2 Aug 2012 16:20:54 +0000 Message-ID: <650AA355E323C34D9D4AAEED952E053D347EE404@SV-EXDB-PROD2.infinera.com> References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A5A8E93302@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A5A8E9337E@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A5A8E9337E@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jplang@ieee.org" , "dimitri.papadimitriou@alcatel-lucent.be" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:20:57 -0000 John, Revertive restoration requires keeping original path because continuous mo= nitoring of failed path is necessary for revertive operation upon recovery. Thanks Rajan -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of J= ohn E Drake Sent: Wednesday, August 01, 2012 5:54 PM To: Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; dbrungard@att= .com Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) You can't keep the original, broken LSP around because it no longer has e2e= committed resources. The best you can do is clean it up and try to re-ins= tantiate it on its original path.=20 Sent from my iPhone > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Wednesday, August 01, 2012 5:48 PM > To: John E Drake; adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > dbrungard@att.com > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >=20 > Hi John- >=20 > Please see my response to Adrian's email for the use case for keeping=20 > the original LSP around during failure. >=20 > Thanks >=20 > Regards ... Zafar >=20 >=20 > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of John E Drake > > Sent: Wednesday, August 01, 2012 7:49 PM > > To: adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org > > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > > dbrungard@att.com > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > Is it not the case that the old LSP is broken? In which case it > needs > > to be cleaned up and re-signaled. > > > > Sent from my iPhone > > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 > > > Behalf Of Adrian Farrel > > > Sent: Wednesday, August 01, 2012 11:02 AM > > > To: 'Ong, Lyndon'; ccamp@ietf.org > > > Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org;=20 > > > dbrungard@att.com > > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > > > Hello again, > > > > > > > Thank you for the fast evaluation of the errata. It sounds like=20 > > > > the > > > correction that I > > > > suggested has ended up overspecifying the method to do reversion > > with > > > > full rerouting when it is very possible to support a form of > > > reversion > > > > that doesn't involve maintaining the old LSP. > > > > > > Right, I understand that you want to allow the option of retaining=20 > > > the old working LSP. Also that you have no intention to remove the=20 > > > option of removing the old working LSP. > > > > > > > From your response I believe that you do agree that it was not > the > > > > intent of > > > the > > > > original specification text to imply that reversion with full=20 > > > > rerouting is not > > > allowed > > > > > > Definitely not the intent to imply that reversion with full=20 > > > rerouting is not allowed. > > > Does the text say or even imply this? > > > > > > > (or to require that the old LSP always be torn down in full > > > rerouting) > > > > > > Also no intention to *require* the old LSP to be torn down. > > > My view is that the text is fully conformant with that. > > > I understand that the text does not make an explicit statement of > > this. > > > > > > > so hopefully > > > > with some more discussion we can determine if there is anything=20 > > > > that could be done to make that clearer. > > > > > > There is, of course, a lot that could be done to make it clearer. > > > But is there really a need? We discussed the point. We agreed it=20 > > > is not prohibited in the RFC. Can we not just move on? > > > > > > Cheers, > > > Adrian > > > > -----Original Message----- > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > Sent: Tuesday, July 31, 2012 6:28 PM > > > > To: ccamp@ietf.org > > > > Cc: jplang@ieee.org; yakov@juniper.net; > > > dimitri.papadimitriou@alcatel- > > > > lucent.be; stbryant@cisco.com; lberger@labn.net;=20 > > > > dbrungard@att.com; Ong, Lyndon > > > > Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > Hi CCAMP, > > > > > > > > I find that this erratum is raised against two sections one of=20 > > > > which > > > I > > > supplied text > > > > for. If this get contentious, I will call on Stewart to call > > > consensus > > > > and > > > handle the > > > > Erratum in the system. > > > > > > > > In my opinion, this proposal goes further than the intention of=20 > > > > the authors/WG > > > in > > > > publishing 4872. > > > > > > > > With regard to the proposed addition to section 11... > > > > The use of mb4b is already in scope. The existing text says "The=20 > > > > new LSP resources can be established using the make-before-break=20 > > > > mechanism," so there is no need to re-state "The new LSP can be=20 > > > > established without tearing down > > > the > > > > old LSP". > > > > > > > > I think your concern here is whether the old LSP is ever torn > down. > > I > > > > think > > > that > > > > you are worried that if the old LSP is torn down, it might be=20 > > > > impossible to > > > perform > > > > reversion because, after repair, an attempt to revert (also=20 > > > > using > > > > mb4b) might > > > find > > > > that key resources have been "stolen" by some other LSP. I don't=20 > > > > see this as > > > at all > > > > different from the issue of the protection LSP itself. That is, > it > > is > > > > of the > > > nature of > > > > LSP Rerouting as a protection mechanism that: > > > > a. protection may fail because of lack of resources b. reversion=20 > > > > may fail > > > because > > > > of lack of resources > > > > > > > > *If* reversion is so important, I don't quite see why protection=20 > > > > is not > > > important. > > > > If protection is important then you should be using a proper=20 > > > > protection mechanism and not waiting for post facto rerouting. > > > > Furthermore, if you > > > require > > > > that the LSP be retained for restoration, why are you not using=20 > > > > a protection mechanism? > > > > > > > > But the general paradigm here is that you are willing to use the > > best > > > available LSP > > > > when it is set up in the first place, the best available LSP=20 > > > > when > > you > > > > re-route > > > after > > > > failure, and the best available LSP when you "revert". > > > > > > > > Lastly, it *does* remain an _option_ to retain the failed LSP in > > > order > > > > to > > > switch > > > > back. Nothing in the old text precludes that, although I=20 > > > > understand that there > > > is > > > > an implication that it might be expected to be torn down. > > > > > > > > So I conclude that the proposed addition to section 12 is not > what > > > the > > > > authors/WG intended. > > > > > > > > We should discuss further. > > > > > > > > Adrian > > > > > > > > > -----Original Message----- > > > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > > > Sent: 31 July 2012 17:39 > > > > > To: jplang@ieee.org; yakov@juniper.net; > > > > > dimitri.papadimitriou@alcatel- lucent.be; stbryant@cisco.com;=20 > > > > > adrian@olddog.co.uk; lberger@labn.net; dbrungard@att.com > > > > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > > > > Subject: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > > > > > > > > The following errata report has been submitted for RFC4872, > > > > > "RSVP- > > > TE > > > > > Extensions in Support of End-to-End Generalized Multi-Protocol > > > Label > > > > > Switching (GMPLS) Recovery". > > > > > > > > > > -------------------------------------- > > > > > You may review the report below and at: > > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 > > > > > > > > > > -------------------------------------- > > > > > Type: Technical > > > > > Reported by: Lyndon Ong > > > > > > > > > > Section: 11 & 12 > > > > > > > > > > Original Text > > > > > ------------- > > > > > Section 11 says: > > > > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end node > > that > > > has > > > > > either detected the LSP failure or received a Notify=20 > > > > > message > > > and/or a > > > > > PathErr message with the new error code/sub-code "Notify > > > Error/LSP > > > > > Locally Failed" for this LSP. The new LSP resources can be > > > > > established using the make-before-break mechanism, where=20 > > > > > the > > new > > > LSP > > > > > is set up before the old LSP is torn down. This is done by > > > using the > > > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared- > > > Explicit > > > > > (SE) reservation style (see [RFC3209]). Both the new and > old > > > LSPs > > > > > can share resources at common nodes. > > > > > > > > > > Section 12 says: > > > > > > > > > > [No text on reversion for (full) LSP Rerouting.] > > > > > > > > > > Corrected Text > > > > > -------------- > > > > > Section 11 should say: > > > > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end node > > that > > > has > > > > > either detected the LSP failure or received a Notify=20 > > > > > message > > > and/or a > > > > > PathErr message with the new error code/sub-code "Notify > > > Error/LSP > > > > > Locally Failed" for this LSP. The new LSP resources can be > > > > > established using the make-before-break mechanism, where=20 > > > > > the > > new > > > LSP > > > > > is set up before the old LSP is torn down. This is done by > > > using the > > > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared- > > > Explicit > > > > > (SE) reservation style (see [RFC3209]). Both the new and > old > > > LSPs > > > > > can share resources at common nodes. The new LSP can be > > > established > > > > > without tearing down the old LSP in case of reversion (see > > > section 12). > > > > > > > > > > Section 12 should say: > > > > > > > > > > For "(full) LSP Rerouting", reversion implies that the old=20 > > > > > LSP > > > is not > > > > > torn down by the head-end node after the new LSP is > > established. > > > For > > > > > reversion, the head-end node re-activates the old LSP after > > this > > > has > > > > > recovered. > > > > > > > > > > > > > > > > > > > > Notes > > > > > ----- > > > > > Current text in RFC 4872 describes reversion in the cases of > 1+1 > > > > > bidirectional Protection, 1:N Protection with Extra Traffic=20 > > > > > and Rerouting Without Extra > > > > Traffic, > > > > > however it has no description of reversion with (Full) LSP > > > Rerouting. > > > > > For (full) LSP Rerouting, the description in Section 11=20 > > > > > instead implies that > > > > the old > > > > > LSP is torn down. This has led to some confusion as to whether=20 > > > > > reversion with > > > > > (full) LSP Rerouting is allowed or not allowed by the RFC. We=20 > > > > > believe this was > > > > not > > > > > intentional. The additions would make it clear that reversion=20 > > > > > can > > > be > > > > > supported with (Full) LSP Rerouting. > > > > > > > > > > Instructions: > > > > > ------------- > > > > > This errata is currently posted as "Reported". If necessary, > > please > > > > > use "Reply All" to discuss whether it should be verified or > > > rejected. > > > > > When a decision is reached, the verifying party (IESG) can log=20 > > > > > in > > > to > > > > > change the status and edit the report, if necessary. > > > > > > > > > > -------------------------------------- > > > > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > > > > -------------------------------------- > > > > > Title : RSVP-TE Extensions in Support of End-to- > End > > > Generalized > > > > Multi- > > > > > Protocol Label Switching (GMPLS) Recovery > > > > > Publication Date : May 2007 > > > > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > > > Papadimitriou, Ed. > > > > > Category : PROPOSED STANDARD > > > > > Source : Common Control and Measurement Plane > > > > > Area : Routing > > > > > Stream : IETF > > > > > Verifying Party : IESG > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From bjabbari@isocore.com Thu Aug 2 09:21:09 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7722C11E80E5 for ; Thu, 2 Aug 2012 09:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTSlwrrm5NXN for ; Thu, 2 Aug 2012 09:21:07 -0700 (PDT) Received: from ns1.cpanel.btnaccess.com (unknown [205.177.121.254]) by ietfa.amsl.com (Postfix) with ESMTP id 91F8011E80EC for ; Thu, 2 Aug 2012 09:21:06 -0700 (PDT) Received: from [98.218.0.206] (port=43871 helo=[10.0.1.64]) by ns1.cpanel.btnaccess.com with esmtpa (Exim 4.77) (envelope-from ) id 1Swy91-0000gz-1l; Thu, 02 Aug 2012 12:21:03 -0400 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Thu, 02 Aug 2012 12:20:58 -0400 From: Bijan Jabbari To: "Zafar Ali (zali)" , "Papadimitriou, Dimitri (Dimitri)" , Lou Berger , "adrian@olddog.co.uk" , "'Ong, Lyndon'" Message-ID: Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com Cc: "jplang@ieee.org" , "ccamp@ietf.org" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:21:09 -0000 Furthermore, the mechanism to restore to the original LSP should be a primary option or mode of operation for an operator to exercise. And, it should not be done via a work-around solution. There are other protocols in use today which refer to this as "change-back after failure" and this mode is widely deployed. I am not sure how widely this RFC is practiced! I doubt it is significantly deployed, if any at this time. However, this may be used widely in the future. So why not fix it now properly. Best, - Bijan On 8/2/12 11:47 AM, "Zafar Ali (zali)" wrote: >Dimitri- > >Please see in-line. > >Thanks > >Regards ... Zafar > > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Papadimitriou, Dimitri (Dimitri) >> Sent: Thursday, August 02, 2012 11:24 AM >> To: Lou Berger; adrian@olddog.co.uk; 'Ong, Lyndon' >> Cc: ccamp@ietf.org; jplang@ieee.org; dbrungard@att.com >> Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >> >> Lou, >> >> there is by definition no notion of "reversion" in full LSP re-routing. >> this is why there is no such description: it is less faster than e.g. >> protection but less resource-consuming (direct release of resources >> after establishment of the new LSP using make-before-break/RFC 3209) and >> more robust. see also RFC 4428 for more details. >> >> -> so I am not sure to which revision placeholder of RFC 4872 you are >> talking as I miss the rationales for a "scenario" that increases >> recovery time *and* resource consumption. >> > >Reversion requirement has nothing to do with the "recovery time" or >"protection" vs. "restoration". Reversion requirement has to do with >ability for the LSP to come back up on the original path *after* the >failure is recovered. Typically working LSP follows nominal path (e.g., >least latency path) and SPs would like the LSP to go back to nominal LSP >path once a failure is repair. During failure time, either protection or >restoration kicks in to minimize impact on the service. Reversion >requirements equally apply to protection as well as restoration. > >For some circuit SP may decide that on-the-fly restoration suffices (may >be based on monitory cost for the circuit). But they still like the LSP >to go back to the nominal path (original working path). > >> Thanks, >> -dimitri. >> > -----Original Message----- >> > From: Lou Berger [mailto:lberger@labn.net] >> > Sent: Wednesday, August 01, 2012 23:45 >> > To: adrian@olddog.co.uk; 'Ong, Lyndon' >> > Cc: ccamp@ietf.org; jplang@ieee.org; yakov@juniper.net; >> > Papadimitriou, Dimitri (Dimitri); stbryant@cisco.com; >> > dbrungard@att.com; 'Roch, Evelyne' >> > Subject: Re: [Technical Errata Reported] RFC4872 (3304) >> > >> > > There is, of course, a lot that could be done to make it >> > clearer. But >> > is there >> > > really a need? We discussed the point. We agreed it is not >> > prohibited >> > in the >> > > RFC. Can we not just move on? >> > >> > So it sounds like there's agreement that there's no technical >> > errata here. >> > >> > Perhaps an alternate way to proceed is to replace this errata with an >> > editorial errata that states that a future revision of the RFC should >> > explicitly discuss how this scenario is covered? >> > >> > Comments/thoughts? >> > >> > Lou >> > >> > On 8/1/2012 11:01 AM, Adrian Farrel wrote: >> > > Hello again, >> > > >> > >> Thank you for the fast evaluation of the errata. It >> > sounds like the >> > > correction that I >> > >> suggested has ended up overspecifying the method to do >> > reversion with full >> > >> rerouting when it is very possible to support a form of >> > reversion that doesn't >> > >> involve maintaining the old LSP. >> > > >> > > Right, I understand that you want to allow the option of >> > retaining the old >> > > working LSP. Also that you have no intention to remove the >> > option of removing >> > > the old working LSP. >> > > >> > >> From your response I believe that you do agree that it was >> > not the intent of >> > > the >> > >> original specification text to imply that reversion with >> > full rerouting is not >> > > allowed >> > > >> > > Definitely not the intent to imply that reversion with full >> > rerouting is not >> > > allowed. >> > > Does the text say or even imply this? >> > > >> > >> (or to require that the old LSP always be torn down in >> > full rerouting) >> > > >> > > Also no intention to *require* the old LSP to be torn down. >> > > My view is that the text is fully conformant with that. >> > > I understand that the text does not make an explicit >> > statement of this. >> > > >> > >> so hopefully >> > >> with some more discussion we can determine if there is >> > anything that could be >> > >> done to make that clearer. >> > > >> > > There is, of course, a lot that could be done to make it >> > clearer. But is there >> > > really a need? We discussed the point. We agreed it is not >> > prohibited in the >> > > RFC. Can we not just move on? >> > > >> > > Cheers, >> > > Adrian >> > >> -----Original Message----- >> > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> > >> Sent: Tuesday, July 31, 2012 6:28 PM >> > >> To: ccamp@ietf.org >> > >> Cc: jplang@ieee.org; yakov@juniper.net; >> > dimitri.papadimitriou@alcatel- >> > >> lucent.be; stbryant@cisco.com; lberger@labn.net; >> > dbrungard@att.com; Ong, >> > >> Lyndon >> > >> Subject: RE: [Technical Errata Reported] RFC4872 (3304) >> > >> >> > >> Hi CCAMP, >> > >> >> > >> I find that this erratum is raised against two sections >> > one of which I >> > > supplied text >> > >> for. If this get contentious, I will call on Stewart to >> > call consensus and >> > > handle the >> > >> Erratum in the system. >> > >> >> > >> In my opinion, this proposal goes further than the >> > intention of the authors/WG >> > > in >> > >> publishing 4872. >> > >> >> > >> With regard to the proposed addition to section 11... >> > >> The use of mb4b is already in scope. The existing text >> > says "The new LSP >> > >> resources can be established using the make-before-break >> > mechanism," so there >> > >> is no need to re-state "The new LSP can be established >> > without tearing down >> > > the >> > >> old LSP". >> > >> >> > >> I think your concern here is whether the old LSP is ever >> > torn down. I think >> > > that >> > >> you are worried that if the old LSP is torn down, it might >> > be impossible to >> > > perform >> > >> reversion because, after repair, an attempt to revert >> > (also using mb4b) might >> > > find >> > >> that key resources have been "stolen" by some other LSP. I >> > don't see this as >> > > at all >> > >> different from the issue of the protection LSP itself. >> > That is, it is of the >> > > nature of >> > >> LSP Rerouting as a protection mechanism that: >> > >> a. protection may fail because of lack of resources b. >> > reversion may fail >> > > because >> > >> of lack of resources >> > >> >> > >> *If* reversion is so important, I don't quite see why >> > protection is not >> > > important. >> > >> If protection is important then you should be using a >> > proper protection >> > >> mechanism and not waiting for post facto rerouting. >> > Furthermore, if you >> > > require >> > >> that the LSP be retained for restoration, why are you not >> > using a protection >> > >> mechanism? >> > >> >> > >> But the general paradigm here is that you are willing to >> > use the best >> > > available LSP >> > >> when it is set up in the first place, the best available >> > LSP when you re-route >> > > after >> > >> failure, and the best available LSP when you "revert". >> > >> >> > >> Lastly, it *does* remain an _option_ to retain the failed >> > LSP in order to >> > > switch >> > >> back. Nothing in the old text precludes that, although I >> > understand that there >> > > is >> > >> an implication that it might be expected to be torn down. >> > >> >> > >> So I conclude that the proposed addition to section 12 is >> > not what the >> > >> authors/WG intended. >> > >> >> > >> We should discuss further. >> > >> >> > >> Adrian >> > >> >> > >>> -----Original Message----- >> > >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> > >>> Sent: 31 July 2012 17:39 >> > >>> To: jplang@ieee.org; yakov@juniper.net; >> > dimitri.papadimitriou@alcatel- >> > >>> lucent.be; stbryant@cisco.com; adrian@olddog.co.uk; >> > lberger@labn.net; >> > >>> dbrungard@att.com >> > >>> Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org >> > >>> Subject: [Technical Errata Reported] RFC4872 (3304) >> > >>> >> > >>> >> > >>> The following errata report has been submitted for >> > RFC4872, "RSVP-TE >> > >>> Extensions in Support of End-to-End Generalized >> > Multi-Protocol Label >> > >>> Switching (GMPLS) Recovery". >> > >>> >> > >>> -------------------------------------- >> > >>> You may review the report below and at: >> > >>> http://www.rfc-editor.org/errata_search.php?rfc=4872&eid=3304 >> > >>> >> > >>> -------------------------------------- >> > >>> Type: Technical >> > >>> Reported by: Lyndon Ong >> > >>> >> > >>> Section: 11 & 12 >> > >>> >> > >>> Original Text >> > >>> ------------- >> > >>> Section 11 says: >> > >>> >> > >>> >> > >>> (Full) LSP rerouting will be initiated by the head-end >> > node that has >> > >>> either detected the LSP failure or received a Notify >> > message and/or a >> > >>> PathErr message with the new error code/sub-code >> > "Notify Error/LSP >> > >>> Locally Failed" for this LSP. The new LSP resources can be >> > >>> established using the make-before-break mechanism, >> > where the new LSP >> > >>> is set up before the old LSP is torn down. This is >> > done by using the >> > >>> mechanisms of the SESSION_ATTRIBUTE object and the >> > Shared-Explicit >> > >>> (SE) reservation style (see [RFC3209]). Both the new >> > and old LSPs >> > >>> can share resources at common nodes. >> > >>> >> > >>> Section 12 says: >> > >>> >> > >>> [No text on reversion for (full) LSP Rerouting.] >> > >>> >> > >>> Corrected Text >> > >>> -------------- >> > >>> Section 11 should say: >> > >>> >> > >>> >> > >>> (Full) LSP rerouting will be initiated by the head-end >> > node that has >> > >>> either detected the LSP failure or received a Notify >> > message and/or a >> > >>> PathErr message with the new error code/sub-code >> > "Notify Error/LSP >> > >>> Locally Failed" for this LSP. The new LSP resources can be >> > >>> established using the make-before-break mechanism, >> > where the new LSP >> > >>> is set up before the old LSP is torn down. This is >> > done by using the >> > >>> mechanisms of the SESSION_ATTRIBUTE object and the >> > Shared-Explicit >> > >>> (SE) reservation style (see [RFC3209]). Both the new >> > and old LSPs >> > >>> can share resources at common nodes. The new LSP can >> > be established >> > >>> without tearing down the old LSP in case of reversion >> > (see section 12). >> > >>> >> > >>> Section 12 should say: >> > >>> >> > >>> For "(full) LSP Rerouting", reversion implies that the >> > old LSP is not >> > >>> torn down by the head-end node after the new LSP is >> > established. For >> > >>> reversion, the head-end node re-activates the old LSP >> > after this has >> > >>> recovered. >> > >>> >> > >>> >> > >>> >> > >>> Notes >> > >>> ----- >> > >>> Current text in RFC 4872 describes reversion in the cases of 1+1 >> > >>> bidirectional Protection, 1:N Protection with Extra Traffic and >> > >>> Rerouting Without Extra >> > >> Traffic, >> > >>> however it has no description of reversion with (Full) >> > LSP Rerouting. >> > >>> For (full) LSP Rerouting, the description in Section 11 instead >> > >>> implies that >> > >> the old >> > >>> LSP is torn down. This has led to some confusion as to whether >> > >>> reversion with >> > >>> (full) LSP Rerouting is allowed or not allowed by the >> > RFC. We believe >> > >>> this was >> > >> not >> > >>> intentional. The additions would make it clear that >> > reversion can be >> > >>> supported with (Full) LSP Rerouting. >> > >>> >> > >>> Instructions: >> > >>> ------------- >> > >>> This errata is currently posted as "Reported". If >> > necessary, please >> > >>> use "Reply All" to discuss whether it should be verified >> > or rejected. >> > >>> When a decision is reached, the verifying party (IESG) >> > can log in to >> > >>> change the status and edit the report, if necessary. >> > >>> >> > >>> -------------------------------------- >> > >>> RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) >> > >>> -------------------------------------- >> > >>> Title : RSVP-TE Extensions in Support of End-to-End >> > > Generalized >> > >> Multi- >> > >>> Protocol Label Switching (GMPLS) Recovery >> > >>> Publication Date : May 2007 >> > >>> Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. >> > Papadimitriou, Ed. >> > >>> Category : PROPOSED STANDARD >> > >>> Source : Common Control and Measurement Plane >> > >>> Area : Routing >> > >>> Stream : IETF >> > >>> Verifying Party : IESG >> > > >> > > >> > > >> > > >> > > >> > >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp From prvs=3561bf1d5b=lyong@ciena.com Thu Aug 2 09:27:17 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D9921F8618 for ; Thu, 2 Aug 2012 09:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.82 X-Spam-Level: X-Spam-Status: No, score=-101.82 tagged_above=-999 required=5 tests=[AWL=0.845, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uaeVzCEugDr for ; Thu, 2 Aug 2012 09:27:15 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id CA7BD21F861F for ; Thu, 2 Aug 2012 09:27:15 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q72GPenP014525; Thu, 2 Aug 2012 12:27:03 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 16fu628dy5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 02 Aug 2012 12:27:03 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Thu, 2 Aug 2012 12:27:03 -0400 From: "Ong, Lyndon" To: "Zafar Ali (zali)" , "Papadimitriou, Dimitri (Dimitri)" , Lou Berger , "adrian@olddog.co.uk" Date: Thu, 2 Aug 2012 12:26:59 -0400 Thread-Topic: [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNcMLyahN3GskcHE2KgpRsg0CwJpdGqVrAgAALjkA= Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5019A35A.7090906@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-02_06:2012-08-01, 2012-08-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208020161 Cc: "jplang@ieee.org" , "ccamp@ietf.org" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:27:17 -0000 I agree with Zafar, I believe that the interest in reversion is due to carr= ier's operational concerns. Cheers, Lyndon -----Original Message----- From: Zafar Ali (zali) [mailto:zali@cisco.com]=20 Sent: Thursday, August 02, 2012 8:47 AM To: Papadimitriou, Dimitri (Dimitri); Lou Berger; adrian@olddog.co.uk; Ong,= Lyndon Cc: ccamp@ietf.org; jplang@ieee.org; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC4872 (3304) Dimitri-=20 Please see in-line.=20 Thanks Regards ... Zafar=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=20 > Of Papadimitriou, Dimitri (Dimitri) > Sent: Thursday, August 02, 2012 11:24 AM > To: Lou Berger; adrian@olddog.co.uk; 'Ong, Lyndon' > Cc: ccamp@ietf.org; jplang@ieee.org; dbrungard@att.com > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >=20 > Lou, >=20 > there is by definition no notion of "reversion" in full LSP re-routing. > this is why there is no such description: it is less faster than e.g. > protection but less resource-consuming (direct release of resources=20 > after establishment of the new LSP using make-before-break/RFC 3209)=20 > and more robust. see also RFC 4428 for more details. >=20 > -> so I am not sure to which revision placeholder of RFC 4872 you are > talking as I miss the rationales for a "scenario" that increases=20 > recovery time *and* resource consumption. >=20 Reversion requirement has nothing to do with the "recovery time" or "protec= tion" vs. "restoration". Reversion requirement has to do with ability for t= he LSP to come back up on the original path *after* the failure is recovere= d. Typically working LSP follows nominal path (e.g., least latency path) an= d SPs would like the LSP to go back to nominal LSP path once a failure is r= epair. During failure time, either protection or restoration kicks in to mi= nimize impact on the service. Reversion requirements equally apply to prote= ction as well as restoration. =20 For some circuit SP may decide that on-the-fly restoration suffices (may be= based on monitory cost for the circuit). But they still like the LSP to go= back to the nominal path (original working path).=20 > Thanks, > -dimitri. > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, August 01, 2012 23:45 > > To: adrian@olddog.co.uk; 'Ong, Lyndon' > > Cc: ccamp@ietf.org; jplang@ieee.org; yakov@juniper.net;=20 > > Papadimitriou, Dimitri (Dimitri); stbryant@cisco.com;=20 > > dbrungard@att.com; 'Roch, Evelyne' > > Subject: Re: [Technical Errata Reported] RFC4872 (3304) > > > > > There is, of course, a lot that could be done to make it > > clearer. But > > is there > > > really a need? We discussed the point. We agreed it is not > > prohibited > > in the > > > RFC. Can we not just move on? > > > > So it sounds like there's agreement that there's no technical errata=20 > > here. > > > > Perhaps an alternate way to proceed is to replace this errata with=20 > > an editorial errata that states that a future revision of the RFC=20 > > should explicitly discuss how this scenario is covered? > > > > Comments/thoughts? > > > > Lou > > > > On 8/1/2012 11:01 AM, Adrian Farrel wrote: > > > Hello again, > > > > > >> Thank you for the fast evaluation of the errata. It > > sounds like the > > > correction that I > > >> suggested has ended up overspecifying the method to do > > reversion with full > > >> rerouting when it is very possible to support a form of > > reversion that doesn't > > >> involve maintaining the old LSP. > > > > > > Right, I understand that you want to allow the option of > > retaining the old > > > working LSP. Also that you have no intention to remove the > > option of removing > > > the old working LSP. > > > > > >> From your response I believe that you do agree that it was > > not the intent of > > > the > > >> original specification text to imply that reversion with > > full rerouting is not > > > allowed > > > > > > Definitely not the intent to imply that reversion with full > > rerouting is not > > > allowed. > > > Does the text say or even imply this? > > > > > >> (or to require that the old LSP always be torn down in > > full rerouting) > > > > > > Also no intention to *require* the old LSP to be torn down. > > > My view is that the text is fully conformant with that. > > > I understand that the text does not make an explicit > > statement of this. > > > > > >> so hopefully > > >> with some more discussion we can determine if there is > > anything that could be > > >> done to make that clearer. > > > > > > There is, of course, a lot that could be done to make it > > clearer. But is there > > > really a need? We discussed the point. We agreed it is not > > prohibited in the > > > RFC. Can we not just move on? > > > > > > Cheers, > > > Adrian > > >> -----Original Message----- > > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > >> Sent: Tuesday, July 31, 2012 6:28 PM > > >> To: ccamp@ietf.org > > >> Cc: jplang@ieee.org; yakov@juniper.net; > > dimitri.papadimitriou@alcatel- > > >> lucent.be; stbryant@cisco.com; lberger@labn.net; > > dbrungard@att.com; Ong, > > >> Lyndon > > >> Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > >> > > >> Hi CCAMP, > > >> > > >> I find that this erratum is raised against two sections > > one of which I > > > supplied text > > >> for. If this get contentious, I will call on Stewart to > > call consensus and > > > handle the > > >> Erratum in the system. > > >> > > >> In my opinion, this proposal goes further than the > > intention of the authors/WG > > > in > > >> publishing 4872. > > >> > > >> With regard to the proposed addition to section 11... > > >> The use of mb4b is already in scope. The existing text > > says "The new LSP > > >> resources can be established using the make-before-break > > mechanism," so there > > >> is no need to re-state "The new LSP can be established > > without tearing down > > > the > > >> old LSP". > > >> > > >> I think your concern here is whether the old LSP is ever > > torn down. I think > > > that > > >> you are worried that if the old LSP is torn down, it might > > be impossible to > > > perform > > >> reversion because, after repair, an attempt to revert > > (also using mb4b) might > > > find > > >> that key resources have been "stolen" by some other LSP. I > > don't see this as > > > at all > > >> different from the issue of the protection LSP itself. > > That is, it is of the > > > nature of > > >> LSP Rerouting as a protection mechanism that: > > >> a. protection may fail because of lack of resources b. > > reversion may fail > > > because > > >> of lack of resources > > >> > > >> *If* reversion is so important, I don't quite see why > > protection is not > > > important. > > >> If protection is important then you should be using a > > proper protection > > >> mechanism and not waiting for post facto rerouting. > > Furthermore, if you > > > require > > >> that the LSP be retained for restoration, why are you not > > using a protection > > >> mechanism? > > >> > > >> But the general paradigm here is that you are willing to > > use the best > > > available LSP > > >> when it is set up in the first place, the best available > > LSP when you re-route > > > after > > >> failure, and the best available LSP when you "revert". > > >> > > >> Lastly, it *does* remain an _option_ to retain the failed > > LSP in order to > > > switch > > >> back. Nothing in the old text precludes that, although I > > understand that there > > > is > > >> an implication that it might be expected to be torn down. > > >> > > >> So I conclude that the proposed addition to section 12 is > > not what the > > >> authors/WG intended. > > >> > > >> We should discuss further. > > >> > > >> Adrian > > >> > > >>> -----Original Message----- > > >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > >>> Sent: 31 July 2012 17:39 > > >>> To: jplang@ieee.org; yakov@juniper.net; > > dimitri.papadimitriou@alcatel- > > >>> lucent.be; stbryant@cisco.com; adrian@olddog.co.uk; > > lberger@labn.net; > > >>> dbrungard@att.com > > >>> Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > >>> Subject: [Technical Errata Reported] RFC4872 (3304) > > >>> > > >>> > > >>> The following errata report has been submitted for > > RFC4872, "RSVP-TE > > >>> Extensions in Support of End-to-End Generalized > > Multi-Protocol Label > > >>> Switching (GMPLS) Recovery". > > >>> > > >>> -------------------------------------- > > >>> You may review the report below and at: > > >>> http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 > > >>> > > >>> -------------------------------------- > > >>> Type: Technical > > >>> Reported by: Lyndon Ong > > >>> > > >>> Section: 11 & 12 > > >>> > > >>> Original Text > > >>> ------------- > > >>> Section 11 says: > > >>> > > >>> > > >>> (Full) LSP rerouting will be initiated by the head-end > > node that has > > >>> either detected the LSP failure or received a Notify > > message and/or a > > >>> PathErr message with the new error code/sub-code > > "Notify Error/LSP > > >>> Locally Failed" for this LSP. The new LSP resources can be > > >>> established using the make-before-break mechanism, > > where the new LSP > > >>> is set up before the old LSP is torn down. This is > > done by using the > > >>> mechanisms of the SESSION_ATTRIBUTE object and the > > Shared-Explicit > > >>> (SE) reservation style (see [RFC3209]). Both the new > > and old LSPs > > >>> can share resources at common nodes. > > >>> > > >>> Section 12 says: > > >>> > > >>> [No text on reversion for (full) LSP Rerouting.] > > >>> > > >>> Corrected Text > > >>> -------------- > > >>> Section 11 should say: > > >>> > > >>> > > >>> (Full) LSP rerouting will be initiated by the head-end > > node that has > > >>> either detected the LSP failure or received a Notify > > message and/or a > > >>> PathErr message with the new error code/sub-code > > "Notify Error/LSP > > >>> Locally Failed" for this LSP. The new LSP resources can be > > >>> established using the make-before-break mechanism, > > where the new LSP > > >>> is set up before the old LSP is torn down. This is > > done by using the > > >>> mechanisms of the SESSION_ATTRIBUTE object and the > > Shared-Explicit > > >>> (SE) reservation style (see [RFC3209]). Both the new > > and old LSPs > > >>> can share resources at common nodes. The new LSP can > > be established > > >>> without tearing down the old LSP in case of reversion > > (see section 12). > > >>> > > >>> Section 12 should say: > > >>> > > >>> For "(full) LSP Rerouting", reversion implies that the > > old LSP is not > > >>> torn down by the head-end node after the new LSP is > > established. For > > >>> reversion, the head-end node re-activates the old LSP > > after this has > > >>> recovered. > > >>> > > >>> > > >>> > > >>> Notes > > >>> ----- > > >>> Current text in RFC 4872 describes reversion in the cases of 1+1=20 > > >>> bidirectional Protection, 1:N Protection with Extra Traffic and=20 > > >>> Rerouting Without Extra > > >> Traffic, > > >>> however it has no description of reversion with (Full) > > LSP Rerouting. > > >>> For (full) LSP Rerouting, the description in Section 11 instead=20 > > >>> implies that > > >> the old > > >>> LSP is torn down. This has led to some confusion as to whether=20 > > >>> reversion with > > >>> (full) LSP Rerouting is allowed or not allowed by the > > RFC. We believe > > >>> this was > > >> not > > >>> intentional. The additions would make it clear that > > reversion can be > > >>> supported with (Full) LSP Rerouting. > > >>> > > >>> Instructions: > > >>> ------------- > > >>> This errata is currently posted as "Reported". If > > necessary, please > > >>> use "Reply All" to discuss whether it should be verified > > or rejected. > > >>> When a decision is reached, the verifying party (IESG) > > can log in to > > >>> change the status and edit the report, if necessary. > > >>> > > >>> -------------------------------------- > > >>> RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > >>> -------------------------------------- > > >>> Title : RSVP-TE Extensions in Support of End-to-End > > > Generalized > > >> Multi- > > >>> Protocol Label Switching (GMPLS) Recovery > > >>> Publication Date : May 2007 > > >>> Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > > Papadimitriou, Ed. > > >>> Category : PROPOSED STANDARD > > >>> Source : Common Control and Measurement Plane > > >>> Area : Routing > > >>> Stream : IETF > > >>> Verifying Party : IESG > > > > > > > > > > > > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Thu Aug 2 09:52:44 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2AC21E80B4 for ; Thu, 2 Aug 2012 09:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.65 X-Spam-Level: X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[AWL=1.349, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB1bSBKjvlxJ for ; Thu, 2 Aug 2012 09:52:42 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 238F911E80E7 for ; Thu, 2 Aug 2012 09:52:38 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUBqwUvqEDHdtUOiG2SAlkXnsP1PbHnmm@postini.com; Thu, 02 Aug 2012 09:52:42 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 2 Aug 2012 09:51:48 -0700 From: John E Drake To: Rajan Rao , "Zafar Ali (zali)" , "adrian@olddog.co.uk" , "'Ong, Lyndon'" , "ccamp@ietf.org" Date: Thu, 2 Aug 2012 09:51:47 -0700 Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNb+xRzb87U2dmuEW4nUyID8ipJZdFtPGAgABhDQCAABB8AIAAAagAgACMARCAAAd3wA== Message-ID: <5E893DB832F57341992548CDBB333163A5A8E93642@EMBX01-HQ.jnpr.net> References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A5A8E93302@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A5A8E9337E@EMBX01-HQ.jnpr.net> <650AA355E323C34D9D4AAEED952E053D347EE404@SV-EXDB-PROD2.infinera.com> In-Reply-To: <650AA355E323C34D9D4AAEED952E053D347EE404@SV-EXDB-PROD2.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jplang@ieee.org" , "dimitri.papadimitriou@alcatel-lucent.be" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:52:45 -0000 Rajan, Due to link and/or node failure the resources of a failed LSP may not be ma= intained. Further, at any time a higher priority LSP may be established th= at pre-empts the resources of a failed LSP. This is sort of basic. Also, because of this, I am not sure what the phrase 'continuous monitoring= of failed path is necessary' means or how you intend to accomplish this ot= her than by attempting to re-establish the failed LSP along its original pa= th. Finally, and most importantly, as I indicated yesterday, I don't see anythi= ng wrong with the existing text. Thanks, John Sent from my iPhone > -----Original Message----- > From: Rajan Rao [mailto:rrao@infinera.com] > Sent: Thursday, August 02, 2012 9:21 AM > To: John E Drake; Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, Lyndon'; > ccamp@ietf.org > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > dbrungard@att.com > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > John, > > Revertive restoration requires keeping original path because > continuous monitoring of failed path is necessary for revertive > operation upon recovery. > > Thanks > Rajan > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of John E Drake > Sent: Wednesday, August 01, 2012 5:54 PM > To: Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, Lyndon'; > ccamp@ietf.org > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > dbrungard@att.com > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > You can't keep the original, broken LSP around because it no longer has > e2e committed resources. The best you can do is clean it up and try to > re-instantiate it on its original path. > > Sent from my iPhone > > > -----Original Message----- > > From: Zafar Ali (zali) [mailto:zali@cisco.com] > > Sent: Wednesday, August 01, 2012 5:48 PM > > To: John E Drake; adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org > > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > > dbrungard@att.com > > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > Hi John- > > > > Please see my response to Adrian's email for the use case for keeping > > the original LSP around during failure. > > > > Thanks > > > > Regards ... Zafar > > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of John E Drake > > > Sent: Wednesday, August 01, 2012 7:49 PM > > > To: adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org > > > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > > > dbrungard@att.com > > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > > > Is it not the case that the old LSP is broken? In which case it > > needs > > > to be cleaned up and re-signaled. > > > > > > Sent from my iPhone > > > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > > > Behalf Of Adrian Farrel > > > > Sent: Wednesday, August 01, 2012 11:02 AM > > > > To: 'Ong, Lyndon'; ccamp@ietf.org > > > > Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org; > > > > dbrungard@att.com > > > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > > > > > Hello again, > > > > > > > > > Thank you for the fast evaluation of the errata. It sounds > like > > > > > the > > > > correction that I > > > > > suggested has ended up overspecifying the method to do > reversion > > > with > > > > > full rerouting when it is very possible to support a form of > > > > reversion > > > > > that doesn't involve maintaining the old LSP. > > > > > > > > Right, I understand that you want to allow the option of > retaining > > > > the old working LSP. Also that you have no intention to remove > the > > > > option of removing the old working LSP. > > > > > > > > > From your response I believe that you do agree that it was not > > the > > > > > intent of > > > > the > > > > > original specification text to imply that reversion with full > > > > > rerouting is not > > > > allowed > > > > > > > > Definitely not the intent to imply that reversion with full > > > > rerouting is not allowed. > > > > Does the text say or even imply this? > > > > > > > > > (or to require that the old LSP always be torn down in full > > > > rerouting) > > > > > > > > Also no intention to *require* the old LSP to be torn down. > > > > My view is that the text is fully conformant with that. > > > > I understand that the text does not make an explicit statement of > > > this. > > > > > > > > > so hopefully > > > > > with some more discussion we can determine if there is anything > > > > > that could be done to make that clearer. > > > > > > > > There is, of course, a lot that could be done to make it clearer. > > > > But is there really a need? We discussed the point. We agreed it > > > > is not prohibited in the RFC. Can we not just move on? > > > > > > > > Cheers, > > > > Adrian > > > > > -----Original Message----- > > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > > Sent: Tuesday, July 31, 2012 6:28 PM > > > > > To: ccamp@ietf.org > > > > > Cc: jplang@ieee.org; yakov@juniper.net; > > > > dimitri.papadimitriou@alcatel- > > > > > lucent.be; stbryant@cisco.com; lberger@labn.net; > > > > > dbrungard@att.com; Ong, Lyndon > > > > > Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > > > Hi CCAMP, > > > > > > > > > > I find that this erratum is raised against two sections one of > > > > > which > > > > I > > > > supplied text > > > > > for. If this get contentious, I will call on Stewart to call > > > > consensus > > > > > and > > > > handle the > > > > > Erratum in the system. > > > > > > > > > > In my opinion, this proposal goes further than the intention of > > > > > the authors/WG > > > > in > > > > > publishing 4872. > > > > > > > > > > With regard to the proposed addition to section 11... > > > > > The use of mb4b is already in scope. The existing text says > "The > > > > > new LSP resources can be established using the make-before- > break > > > > > mechanism," so there is no need to re-state "The new LSP can be > > > > > established without tearing down > > > > the > > > > > old LSP". > > > > > > > > > > I think your concern here is whether the old LSP is ever torn > > down. > > > I > > > > > think > > > > that > > > > > you are worried that if the old LSP is torn down, it might be > > > > > impossible to > > > > perform > > > > > reversion because, after repair, an attempt to revert (also > > > > > using > > > > > mb4b) might > > > > find > > > > > that key resources have been "stolen" by some other LSP. I > don't > > > > > see this as > > > > at all > > > > > different from the issue of the protection LSP itself. That is, > > it > > > is > > > > > of the > > > > nature of > > > > > LSP Rerouting as a protection mechanism that: > > > > > a. protection may fail because of lack of resources b. > reversion > > > > > may fail > > > > because > > > > > of lack of resources > > > > > > > > > > *If* reversion is so important, I don't quite see why > protection > > > > > is not > > > > important. > > > > > If protection is important then you should be using a proper > > > > > protection mechanism and not waiting for post facto rerouting. > > > > > Furthermore, if you > > > > require > > > > > that the LSP be retained for restoration, why are you not using > > > > > a protection mechanism? > > > > > > > > > > But the general paradigm here is that you are willing to use > the > > > best > > > > available LSP > > > > > when it is set up in the first place, the best available LSP > > > > > when > > > you > > > > > re-route > > > > after > > > > > failure, and the best available LSP when you "revert". > > > > > > > > > > Lastly, it *does* remain an _option_ to retain the failed LSP > in > > > > order > > > > > to > > > > switch > > > > > back. Nothing in the old text precludes that, although I > > > > > understand that there > > > > is > > > > > an implication that it might be expected to be torn down. > > > > > > > > > > So I conclude that the proposed addition to section 12 is not > > what > > > > the > > > > > authors/WG intended. > > > > > > > > > > We should discuss further. > > > > > > > > > > Adrian > > > > > > > > > > > -----Original Message----- > > > > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > > > > Sent: 31 July 2012 17:39 > > > > > > To: jplang@ieee.org; yakov@juniper.net; > > > > > > dimitri.papadimitriou@alcatel- lucent.be; stbryant@cisco.com; > > > > > > adrian@olddog.co.uk; lberger@labn.net; dbrungard@att.com > > > > > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc- > editor.org > > > > > > Subject: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > > > > > > > > > > > The following errata report has been submitted for RFC4872, > > > > > > "RSVP- > > > > TE > > > > > > Extensions in Support of End-to-End Generalized Multi- > Protocol > > > > Label > > > > > > Switching (GMPLS) Recovery". > > > > > > > > > > > > -------------------------------------- > > > > > > You may review the report below and at: > > > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D33= 04 > > > > > > > > > > > > -------------------------------------- > > > > > > Type: Technical > > > > > > Reported by: Lyndon Ong > > > > > > > > > > > > Section: 11 & 12 > > > > > > > > > > > > Original Text > > > > > > ------------- > > > > > > Section 11 says: > > > > > > > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end > node > > > that > > > > has > > > > > > either detected the LSP failure or received a Notify > > > > > > message > > > > and/or a > > > > > > PathErr message with the new error code/sub-code "Notify > > > > Error/LSP > > > > > > Locally Failed" for this LSP. The new LSP resources can > be > > > > > > established using the make-before-break mechanism, where > > > > > > the > > > new > > > > LSP > > > > > > is set up before the old LSP is torn down. This is done > by > > > > using the > > > > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared- > > > > Explicit > > > > > > (SE) reservation style (see [RFC3209]). Both the new and > > old > > > > LSPs > > > > > > can share resources at common nodes. > > > > > > > > > > > > Section 12 says: > > > > > > > > > > > > [No text on reversion for (full) LSP Rerouting.] > > > > > > > > > > > > Corrected Text > > > > > > -------------- > > > > > > Section 11 should say: > > > > > > > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end > node > > > that > > > > has > > > > > > either detected the LSP failure or received a Notify > > > > > > message > > > > and/or a > > > > > > PathErr message with the new error code/sub-code "Notify > > > > Error/LSP > > > > > > Locally Failed" for this LSP. The new LSP resources can > be > > > > > > established using the make-before-break mechanism, where > > > > > > the > > > new > > > > LSP > > > > > > is set up before the old LSP is torn down. This is done > by > > > > using the > > > > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared- > > > > Explicit > > > > > > (SE) reservation style (see [RFC3209]). Both the new and > > old > > > > LSPs > > > > > > can share resources at common nodes. The new LSP can be > > > > established > > > > > > without tearing down the old LSP in case of reversion (see > > > > section 12). > > > > > > > > > > > > Section 12 should say: > > > > > > > > > > > > For "(full) LSP Rerouting", reversion implies that the old > > > > > > LSP > > > > is not > > > > > > torn down by the head-end node after the new LSP is > > > established. > > > > For > > > > > > reversion, the head-end node re-activates the old LSP > after > > > this > > > > has > > > > > > recovered. > > > > > > > > > > > > > > > > > > > > > > > > Notes > > > > > > ----- > > > > > > Current text in RFC 4872 describes reversion in the cases of > > 1+1 > > > > > > bidirectional Protection, 1:N Protection with Extra Traffic > > > > > > and Rerouting Without Extra > > > > > Traffic, > > > > > > however it has no description of reversion with (Full) LSP > > > > Rerouting. > > > > > > For (full) LSP Rerouting, the description in Section 11 > > > > > > instead implies that > > > > > the old > > > > > > LSP is torn down. This has led to some confusion as to > whether > > > > > > reversion with > > > > > > (full) LSP Rerouting is allowed or not allowed by the RFC. We > > > > > > believe this was > > > > > not > > > > > > intentional. The additions would make it clear that reversion > > > > > > can > > > > be > > > > > > supported with (Full) LSP Rerouting. > > > > > > > > > > > > Instructions: > > > > > > ------------- > > > > > > This errata is currently posted as "Reported". If necessary, > > > please > > > > > > use "Reply All" to discuss whether it should be verified or > > > > rejected. > > > > > > When a decision is reached, the verifying party (IESG) can > log > > > > > > in > > > > to > > > > > > change the status and edit the report, if necessary. > > > > > > > > > > > > -------------------------------------- > > > > > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > > > > > -------------------------------------- > > > > > > Title : RSVP-TE Extensions in Support of End- > to- > > End > > > > Generalized > > > > > Multi- > > > > > > Protocol Label Switching (GMPLS) Recovery > > > > > > Publication Date : May 2007 > > > > > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > > > > Papadimitriou, Ed. > > > > > > Category : PROPOSED STANDARD > > > > > > Source : Common Control and Measurement Plane > > > > > > Area : Routing > > > > > > Stream : IETF > > > > > > Verifying Party : IESG > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Thu Aug 2 09:57:32 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC08221E80B0 for ; Thu, 2 Aug 2012 09:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.689 X-Spam-Level: X-Spam-Status: No, score=-4.689 tagged_above=-999 required=5 tests=[AWL=1.310, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNfGQ08+-kSw for ; Thu, 2 Aug 2012 09:57:30 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id AE27A21E80AC for ; Thu, 2 Aug 2012 09:57:29 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUBqxURkeAKM6/LcomACaHD+2YltBtoXY@postini.com; Thu, 02 Aug 2012 09:57:30 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 2 Aug 2012 09:54:29 -0700 From: John E Drake To: "Ong, Lyndon" , "Zafar Ali (zali)" , "Papadimitriou, Dimitri (Dimitri)" , Lou Berger , "adrian@olddog.co.uk" Date: Thu, 2 Aug 2012 09:54:28 -0700 Thread-Topic: [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNcMLyahN3GskcHE2KgpRsg0CwJpdGqVrAgAALjkCAAAf4wA== Message-ID: <5E893DB832F57341992548CDBB333163A5A8E9364D@EMBX01-HQ.jnpr.net> References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5019A35A.7090906@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jplang@ieee.org" , "ccamp@ietf.org" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:57:32 -0000 Lyndon, As I am sure you remember, that is why graceful restart was invented. Thanks, John Sent from my iPhone > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Ong, Lyndon > Sent: Thursday, August 02, 2012 9:27 AM > To: Zafar Ali (zali); Papadimitriou, Dimitri (Dimitri); Lou Berger; > adrian@olddog.co.uk > Cc: jplang@ieee.org; ccamp@ietf.org; dbrungard@att.com > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > I agree with Zafar, I believe that the interest in reversion is due to > carrier's operational concerns. > > Cheers, > > Lyndon > > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Thursday, August 02, 2012 8:47 AM > To: Papadimitriou, Dimitri (Dimitri); Lou Berger; adrian@olddog.co.uk; > Ong, Lyndon > Cc: ccamp@ietf.org; jplang@ieee.org; dbrungard@att.com > Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > Dimitri- > > Please see in-line. > > Thanks > > Regards ... Zafar > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Papadimitriou, Dimitri (Dimitri) > > Sent: Thursday, August 02, 2012 11:24 AM > > To: Lou Berger; adrian@olddog.co.uk; 'Ong, Lyndon' > > Cc: ccamp@ietf.org; jplang@ieee.org; dbrungard@att.com > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > Lou, > > > > there is by definition no notion of "reversion" in full LSP re- > routing. > > this is why there is no such description: it is less faster than e.g. > > protection but less resource-consuming (direct release of resources > > after establishment of the new LSP using make-before-break/RFC 3209) > > and more robust. see also RFC 4428 for more details. > > > > -> so I am not sure to which revision placeholder of RFC 4872 you are > > talking as I miss the rationales for a "scenario" that increases > > recovery time *and* resource consumption. > > > > Reversion requirement has nothing to do with the "recovery time" or > "protection" vs. "restoration". Reversion requirement has to do with > ability for the LSP to come back up on the original path *after* the > failure is recovered. Typically working LSP follows nominal path (e.g., > least latency path) and SPs would like the LSP to go back to nominal > LSP path once a failure is repair. During failure time, either > protection or restoration kicks in to minimize impact on the service. > Reversion requirements equally apply to protection as well as > restoration. > > For some circuit SP may decide that on-the-fly restoration suffices > (may be based on monitory cost for the circuit). But they still like > the LSP to go back to the nominal path (original working path). > > > Thanks, > > -dimitri. > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, August 01, 2012 23:45 > > > To: adrian@olddog.co.uk; 'Ong, Lyndon' > > > Cc: ccamp@ietf.org; jplang@ieee.org; yakov@juniper.net; > > > Papadimitriou, Dimitri (Dimitri); stbryant@cisco.com; > > > dbrungard@att.com; 'Roch, Evelyne' > > > Subject: Re: [Technical Errata Reported] RFC4872 (3304) > > > > > > > There is, of course, a lot that could be done to make it > > > clearer. But > > > is there > > > > really a need? We discussed the point. We agreed it is not > > > prohibited > > > in the > > > > RFC. Can we not just move on? > > > > > > So it sounds like there's agreement that there's no technical > errata > > > here. > > > > > > Perhaps an alternate way to proceed is to replace this errata with > > > an editorial errata that states that a future revision of the RFC > > > should explicitly discuss how this scenario is covered? > > > > > > Comments/thoughts? > > > > > > Lou > > > > > > On 8/1/2012 11:01 AM, Adrian Farrel wrote: > > > > Hello again, > > > > > > > >> Thank you for the fast evaluation of the errata. It > > > sounds like the > > > > correction that I > > > >> suggested has ended up overspecifying the method to do > > > reversion with full > > > >> rerouting when it is very possible to support a form of > > > reversion that doesn't > > > >> involve maintaining the old LSP. > > > > > > > > Right, I understand that you want to allow the option of > > > retaining the old > > > > working LSP. Also that you have no intention to remove the > > > option of removing > > > > the old working LSP. > > > > > > > >> From your response I believe that you do agree that it was > > > not the intent of > > > > the > > > >> original specification text to imply that reversion with > > > full rerouting is not > > > > allowed > > > > > > > > Definitely not the intent to imply that reversion with full > > > rerouting is not > > > > allowed. > > > > Does the text say or even imply this? > > > > > > > >> (or to require that the old LSP always be torn down in > > > full rerouting) > > > > > > > > Also no intention to *require* the old LSP to be torn down. > > > > My view is that the text is fully conformant with that. > > > > I understand that the text does not make an explicit > > > statement of this. > > > > > > > >> so hopefully > > > >> with some more discussion we can determine if there is > > > anything that could be > > > >> done to make that clearer. > > > > > > > > There is, of course, a lot that could be done to make it > > > clearer. But is there > > > > really a need? We discussed the point. We agreed it is not > > > prohibited in the > > > > RFC. Can we not just move on? > > > > > > > > Cheers, > > > > Adrian > > > >> -----Original Message----- > > > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > >> Sent: Tuesday, July 31, 2012 6:28 PM > > > >> To: ccamp@ietf.org > > > >> Cc: jplang@ieee.org; yakov@juniper.net; > > > dimitri.papadimitriou@alcatel- > > > >> lucent.be; stbryant@cisco.com; lberger@labn.net; > > > dbrungard@att.com; Ong, > > > >> Lyndon > > > >> Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > > >> > > > >> Hi CCAMP, > > > >> > > > >> I find that this erratum is raised against two sections > > > one of which I > > > > supplied text > > > >> for. If this get contentious, I will call on Stewart to > > > call consensus and > > > > handle the > > > >> Erratum in the system. > > > >> > > > >> In my opinion, this proposal goes further than the > > > intention of the authors/WG > > > > in > > > >> publishing 4872. > > > >> > > > >> With regard to the proposed addition to section 11... > > > >> The use of mb4b is already in scope. The existing text > > > says "The new LSP > > > >> resources can be established using the make-before-break > > > mechanism," so there > > > >> is no need to re-state "The new LSP can be established > > > without tearing down > > > > the > > > >> old LSP". > > > >> > > > >> I think your concern here is whether the old LSP is ever > > > torn down. I think > > > > that > > > >> you are worried that if the old LSP is torn down, it might > > > be impossible to > > > > perform > > > >> reversion because, after repair, an attempt to revert > > > (also using mb4b) might > > > > find > > > >> that key resources have been "stolen" by some other LSP. I > > > don't see this as > > > > at all > > > >> different from the issue of the protection LSP itself. > > > That is, it is of the > > > > nature of > > > >> LSP Rerouting as a protection mechanism that: > > > >> a. protection may fail because of lack of resources b. > > > reversion may fail > > > > because > > > >> of lack of resources > > > >> > > > >> *If* reversion is so important, I don't quite see why > > > protection is not > > > > important. > > > >> If protection is important then you should be using a > > > proper protection > > > >> mechanism and not waiting for post facto rerouting. > > > Furthermore, if you > > > > require > > > >> that the LSP be retained for restoration, why are you not > > > using a protection > > > >> mechanism? > > > >> > > > >> But the general paradigm here is that you are willing to > > > use the best > > > > available LSP > > > >> when it is set up in the first place, the best available > > > LSP when you re-route > > > > after > > > >> failure, and the best available LSP when you "revert". > > > >> > > > >> Lastly, it *does* remain an _option_ to retain the failed > > > LSP in order to > > > > switch > > > >> back. Nothing in the old text precludes that, although I > > > understand that there > > > > is > > > >> an implication that it might be expected to be torn down. > > > >> > > > >> So I conclude that the proposed addition to section 12 is > > > not what the > > > >> authors/WG intended. > > > >> > > > >> We should discuss further. > > > >> > > > >> Adrian > > > >> > > > >>> -----Original Message----- > > > >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > >>> Sent: 31 July 2012 17:39 > > > >>> To: jplang@ieee.org; yakov@juniper.net; > > > dimitri.papadimitriou@alcatel- > > > >>> lucent.be; stbryant@cisco.com; adrian@olddog.co.uk; > > > lberger@labn.net; > > > >>> dbrungard@att.com > > > >>> Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > > >>> Subject: [Technical Errata Reported] RFC4872 (3304) > > > >>> > > > >>> > > > >>> The following errata report has been submitted for > > > RFC4872, "RSVP-TE > > > >>> Extensions in Support of End-to-End Generalized > > > Multi-Protocol Label > > > >>> Switching (GMPLS) Recovery". > > > >>> > > > >>> -------------------------------------- > > > >>> You may review the report below and at: > > > >>> http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 > > > >>> > > > >>> -------------------------------------- > > > >>> Type: Technical > > > >>> Reported by: Lyndon Ong > > > >>> > > > >>> Section: 11 & 12 > > > >>> > > > >>> Original Text > > > >>> ------------- > > > >>> Section 11 says: > > > >>> > > > >>> > > > >>> (Full) LSP rerouting will be initiated by the head-end > > > node that has > > > >>> either detected the LSP failure or received a Notify > > > message and/or a > > > >>> PathErr message with the new error code/sub-code > > > "Notify Error/LSP > > > >>> Locally Failed" for this LSP. The new LSP resources can be > > > >>> established using the make-before-break mechanism, > > > where the new LSP > > > >>> is set up before the old LSP is torn down. This is > > > done by using the > > > >>> mechanisms of the SESSION_ATTRIBUTE object and the > > > Shared-Explicit > > > >>> (SE) reservation style (see [RFC3209]). Both the new > > > and old LSPs > > > >>> can share resources at common nodes. > > > >>> > > > >>> Section 12 says: > > > >>> > > > >>> [No text on reversion for (full) LSP Rerouting.] > > > >>> > > > >>> Corrected Text > > > >>> -------------- > > > >>> Section 11 should say: > > > >>> > > > >>> > > > >>> (Full) LSP rerouting will be initiated by the head-end > > > node that has > > > >>> either detected the LSP failure or received a Notify > > > message and/or a > > > >>> PathErr message with the new error code/sub-code > > > "Notify Error/LSP > > > >>> Locally Failed" for this LSP. The new LSP resources can be > > > >>> established using the make-before-break mechanism, > > > where the new LSP > > > >>> is set up before the old LSP is torn down. This is > > > done by using the > > > >>> mechanisms of the SESSION_ATTRIBUTE object and the > > > Shared-Explicit > > > >>> (SE) reservation style (see [RFC3209]). Both the new > > > and old LSPs > > > >>> can share resources at common nodes. The new LSP can > > > be established > > > >>> without tearing down the old LSP in case of reversion > > > (see section 12). > > > >>> > > > >>> Section 12 should say: > > > >>> > > > >>> For "(full) LSP Rerouting", reversion implies that the > > > old LSP is not > > > >>> torn down by the head-end node after the new LSP is > > > established. For > > > >>> reversion, the head-end node re-activates the old LSP > > > after this has > > > >>> recovered. > > > >>> > > > >>> > > > >>> > > > >>> Notes > > > >>> ----- > > > >>> Current text in RFC 4872 describes reversion in the cases of > 1+1 > > > >>> bidirectional Protection, 1:N Protection with Extra Traffic and > > > >>> Rerouting Without Extra > > > >> Traffic, > > > >>> however it has no description of reversion with (Full) > > > LSP Rerouting. > > > >>> For (full) LSP Rerouting, the description in Section 11 instead > > > >>> implies that > > > >> the old > > > >>> LSP is torn down. This has led to some confusion as to whether > > > >>> reversion with > > > >>> (full) LSP Rerouting is allowed or not allowed by the > > > RFC. We believe > > > >>> this was > > > >> not > > > >>> intentional. The additions would make it clear that > > > reversion can be > > > >>> supported with (Full) LSP Rerouting. > > > >>> > > > >>> Instructions: > > > >>> ------------- > > > >>> This errata is currently posted as "Reported". If > > > necessary, please > > > >>> use "Reply All" to discuss whether it should be verified > > > or rejected. > > > >>> When a decision is reached, the verifying party (IESG) > > > can log in to > > > >>> change the status and edit the report, if necessary. > > > >>> > > > >>> -------------------------------------- > > > >>> RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > > >>> -------------------------------------- > > > >>> Title : RSVP-TE Extensions in Support of End-to- > End > > > > Generalized > > > >> Multi- > > > >>> Protocol Label Switching (GMPLS) Recovery > > > >>> Publication Date : May 2007 > > > >>> Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > > > Papadimitriou, Ed. > > > >>> Category : PROPOSED STANDARD > > > >>> Source : Common Control and Measurement Plane > > > >>> Area : Routing > > > >>> Stream : IETF > > > >>> Verifying Party : IESG > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From leeyoung@huawei.com Thu Aug 2 09:58:10 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1E121E80C1 for ; Thu, 2 Aug 2012 09:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFcaIz+uA8Bh for ; Thu, 2 Aug 2012 09:58:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3B78921E80B0 for ; Thu, 2 Aug 2012 09:58:09 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIJ20507; Thu, 02 Aug 2012 08:58:09 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 09:56:30 -0700 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.49]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 09:56:35 -0700 From: Leeyoung To: "Giovanni Martinelli (giomarti)" Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority Thread-Index: AQHNcAyuJFh0KZM0PEuR5rvzvXz1+5dFha9ggAB9XQD//4xN4IABmgCA//+RYuA= Date: Thu, 2 Aug 2012 16:56:34 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172905EEC1@dfweml511-mbs.china.huawei.com> References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED70@dfweml511-mbs.china.huawei.com> <48F63A76-53E9-4C38-A266-8B8BAB9F7838@cisco.com> In-Reply-To: <48F63A76-53E9-4C38-A266-8B8BAB9F7838@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:58:10 -0000 Hi Giovanni, Please see in-line for my responses. Thanks.=20 -----Original Message----- From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com]=20 Sent: Thursday, August 02, 2012 11:16 AM To: Leeyoung Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Young, btw first just a naming issue (I guess a question for the wg in general) th= e object label_set here has the same name name as the label_set form rfc347= 1 but it has actually a different encoding, so just asking if worth figurin= g out a little different name. If no one complain I'm fine too. YOUNG>> We are expanding the label set concept from 3471. I am not sure if = there is a new name needed here. I defer this to WG chairs.=20 please see inline On Aug 2, 2012, at 1:18 , Leeyoung wrote: > > On Aug 2, 2012, at 24:25 , Leeyoung wrote: >=20 >> Hi Giovanni, >>=20 >> The wavelength priority you propose seems different from the what we enc= oded per Rao Rajan's suggestion. What we encoded in section 2.3 of gen enco= de is not giving wavelength a priority level, among which I believe your wa= velength property specifies. >>=20 >> What we are proposing is what labels are available/not available for eac= h priority level (similar to LSP reservation or holding priority) as the fo= llowing encoding dictates:=20 >>=20 >=20 >=20 > GM> So at the end is a "Label Priority" ? With the Label_Set granularity = instead of the single Label? =20 >=20 > YOUNG>> No, this is not "label priority". Label is not "assigned" a prior= ity. Label is neutral. Say, you have five wavelengths available for grab an= d you have two priorities you are aware of which is service level (e.g., LS= P). For higher priority service, you may want to all your five wavelengths = (w1-w5) available for grab while for lower priority, you may restrict to le= ss number of wavelengths, say three wavelengths only (e.g., w1-w3). GM> Well I'm not sure I'm following you, you say that labels are not assign= ed to a priority but then there is a priority associated to a label set. Fo= r sure label is neutral but "someone" decide if it goes in a label set with= a certain priority, or in another (or in both label_set ). So, to me this = means associate (is this term better than assign?) a priority to a label. YOUNG>> I think I explained enough what the current encoding is. This is ab= out what labels are available for LSP priority. Some labels may be availabl= e for more than one LSP priority. There is no 1:1 "association" between lab= el and priority per se.=20 > Here you can see individual wavelength is not assigned a priority. GM> the granularity is the label_set so you can easily see that's equivalen= t to individual label, anyway single label or label-set its not a substanti= al difference to me. > This is analogous to how much BW availability for each priority in MPLS n= etwork, except that we need to express in wavelength level. =20 >=20 >=20 >=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |A| Reserved | Priority Flags| Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Label Set Field | >> : : >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Where >>=20 >> A (Availability bit) =3D 1 or 0 indicates that the labels listed in >> the following label set field are available or not available, >> respectively, for use at a given priority level as indicated by the >> Priority Flags. >=20 >=20 > GM> The reading here suggest me that there could be multiple objects (I b= et up to 8) packed up somewere (e.g. something like sub-tlvs in the link ad= vertisement). Is my interpretation correct? >=20 > YOUNG>> Yes.=20 >=20 GM> two encoding question here: GM> 1/ why using flags instead of classical three bits?=20 GM> 2/ What the usage of A? I mean you have an Available_label object and t= hen you set A=3D0 which means that labels are not available... could you pl= ease clarify better? =20 YOUNG>> Yes, three bits can do that. We put A=3D0 (not available) --just to= give more flexibility. That's all. If you want to restrict some ranges of = labels to lower LSP, using A bit (A=3D0) would be more efficient to express= such need.=20 Cheers G > Cheers > G >=20 >=20 >>=20 >> Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 >> corresponds to priority level 7. If a bit is set then the labels in >> the label set field are available or not available as indicated by >> the A bit for use at that particular priority level. >>=20 >> Let's begin if we are in agreement with this point.=20 >>=20 >> Thanks. >> Young >>=20 >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf O= f Giovanni Martinelli (giomarti) >> Sent: Wednesday, August 01, 2012 12:40 PM >> To: Giovanni Martinelli (giomarti) >> Cc: CCAMP >> Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-enco= de-08: priority >>=20 >> Here my latest mail with comments on wavelength priority...=20 >>=20 >> Here my memory on past discussion (please correct if wrong) >> - last short thread was during ieft83 (around 26/28 march), last mail wa= s from me and did not get answers. The content here below cover that mail a= s well. >> - discussions about wl priority happens among authors not on ccamp maili= ng list. On the mailing list you announce draft update around dec 2011. =20 >>=20 >> Well, I'm not complaining about how discussion happen, simply I saw a n= ot-trivial addition to wg document, hence my comments. >>=20 >> Cheers >> G >>=20 >>=20 >>=20 >> On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: >>=20 >>> Dear authors / ccamp, >>>=20 >>> here a few comments related to the priority field added to draft-ietf-c= camp-general-constraint-encode: >>>=20 >>> A couple of editorial comments >>> 1) "wavelenght priority" appears in a draft that claim to be general. = In fact is available in "Available Labels Sub-TLV" and "Shared Backup Label= s Sub-TLV". So is a wavelength or label-like priority? >>> 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0= .. 7]? >>>=20 >>>=20 >>> Then few other comments >>> 3) How the priority is used versus the A flag . Draft text report >>> " =20 >>> A (Availability bit) =3D 1 or 0 indicates that the labels listed in >>> the following label set field are available or not available, >>> respectively, for use at a given priority level as indicated by the >>> Priority Flags. >>>=20 >>> " >>> So does it means that there could be different "available labels sub-TL= Vs" advertised?=20 >>>=20 >>> 4) Still unclear to me how this priority is different from the one repo= rted in http://tools.ietf.org/html/draft-kattan-wson-property-01 and eventu= ally if this "priority" could fit the LSP priority already available (as on= e of the comment we received at that time) >>>=20 >>> Cheers >>> G >>>=20 >>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >=20 From rrao@infinera.com Thu Aug 2 10:18:50 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF5D11E8174 for ; Thu, 2 Aug 2012 10:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbDNJG+boLdq for ; Thu, 2 Aug 2012 10:18:48 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 886BA11E8170 for ; Thu, 2 Aug 2012 10:18:47 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0283.003; Thu, 2 Aug 2012 10:18:46 -0700 From: Rajan Rao To: John E Drake , "Zafar Ali (zali)" , "adrian@olddog.co.uk" , "'Ong, Lyndon'" , "ccamp@ietf.org" Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNb+xRzb87U2dmuEW4nUyID8ipJZdFtPGAgABhDQCAABB8AIAAAagAgACMARCAAAd3wIAAB6hw Date: Thu, 2 Aug 2012 17:18:45 +0000 Message-ID: <650AA355E323C34D9D4AAEED952E053D347EE4F1@SV-EXDB-PROD2.infinera.com> References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A5A8E93302@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A5A8E9337E@EMBX01-HQ.jnpr.net> <650AA355E323C34D9D4AAEED952E053D347EE404@SV-EXDB-PROD2.infinera.com> <5E893DB832F57341992548CDBB333163A5A8E93642@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A5A8E93642@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jplang@ieee.org" , "dimitri.papadimitriou@alcatel-lucent.be" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:18:50 -0000 John, I too agree that existing text from Section-12 (see below) is sufficient as= pointed by Zafar. The text below should also clarify your questions. =20 " For "Rerouting without Extra-traffic" (including the shared recovery case), reversion implies that the formerly working LSP has not been torn down by the head-end node upon PathErr message reception, i.e., the head-end node kept refreshing the working LSP under failure condition. This ensures that the exact same resources are retrieved after reversion switching (except if the working LSP required re- signaling). " Thanks Rajan -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, August 02, 2012 9:52 AM To: Rajan Rao; Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@= ietf.org Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; dbrungard@att= .com Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Rajan, Due to link and/or node failure the resources of a failed LSP may not be ma= intained. Further, at any time a higher priority LSP may be established th= at pre-empts the resources of a failed LSP. This is sort of basic. Also, because of this, I am not sure what the phrase 'continuous monitoring= of failed path is necessary' means or how you intend to accomplish this ot= her than by attempting to re-establish the failed LSP along its original pa= th. Finally, and most importantly, as I indicated yesterday, I don't see anythi= ng wrong with the existing text. Thanks, John Sent from my iPhone > -----Original Message----- > From: Rajan Rao [mailto:rrao@infinera.com] > Sent: Thursday, August 02, 2012 9:21 AM > To: John E Drake; Zafar Ali (zali); adrian@olddog.co.uk; 'Ong,=20 > Lyndon'; ccamp@ietf.org > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > dbrungard@att.com > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > John, > > Revertive restoration requires keeping original path because=20 > continuous monitoring of failed path is necessary for revertive=20 > operation upon recovery. > > Thanks > Rajan > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=20 > Of John E Drake > Sent: Wednesday, August 01, 2012 5:54 PM > To: Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, Lyndon';=20 > ccamp@ietf.org > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > dbrungard@att.com > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > You can't keep the original, broken LSP around because it no longer=20 > has e2e committed resources. The best you can do is clean it up and=20 > try to re-instantiate it on its original path. > > Sent from my iPhone > > > -----Original Message----- > > From: Zafar Ali (zali) [mailto:zali@cisco.com] > > Sent: Wednesday, August 01, 2012 5:48 PM > > To: John E Drake; adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org > > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > > dbrungard@att.com > > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > Hi John- > > > > Please see my response to Adrian's email for the use case for=20 > > keeping the original LSP around during failure. > > > > Thanks > > > > Regards ... Zafar > > > > > > > -----Original Message----- > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > > Behalf > > > Of John E Drake > > > Sent: Wednesday, August 01, 2012 7:49 PM > > > To: adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org > > > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > > > dbrungard@att.com > > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > > > Is it not the case that the old LSP is broken? In which case it > > needs > > > to be cleaned up and re-signaled. > > > > > > Sent from my iPhone > > > > > > > > > > -----Original Message----- > > > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 > > > > Behalf Of Adrian Farrel > > > > Sent: Wednesday, August 01, 2012 11:02 AM > > > > To: 'Ong, Lyndon'; ccamp@ietf.org > > > > Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org;=20 > > > > dbrungard@att.com > > > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > > > > > Hello again, > > > > > > > > > Thank you for the fast evaluation of the errata. It sounds > like > > > > > the > > > > correction that I > > > > > suggested has ended up overspecifying the method to do > reversion > > > with > > > > > full rerouting when it is very possible to support a form of > > > > reversion > > > > > that doesn't involve maintaining the old LSP. > > > > > > > > Right, I understand that you want to allow the option of > retaining > > > > the old working LSP. Also that you have no intention to remove > the > > > > option of removing the old working LSP. > > > > > > > > > From your response I believe that you do agree that it was not > > the > > > > > intent of > > > > the > > > > > original specification text to imply that reversion with full=20 > > > > > rerouting is not > > > > allowed > > > > > > > > Definitely not the intent to imply that reversion with full=20 > > > > rerouting is not allowed. > > > > Does the text say or even imply this? > > > > > > > > > (or to require that the old LSP always be torn down in full > > > > rerouting) > > > > > > > > Also no intention to *require* the old LSP to be torn down. > > > > My view is that the text is fully conformant with that. > > > > I understand that the text does not make an explicit statement=20 > > > > of > > > this. > > > > > > > > > so hopefully > > > > > with some more discussion we can determine if there is=20 > > > > > anything that could be done to make that clearer. > > > > > > > > There is, of course, a lot that could be done to make it clearer. > > > > But is there really a need? We discussed the point. We agreed it=20 > > > > is not prohibited in the RFC. Can we not just move on? > > > > > > > > Cheers, > > > > Adrian > > > > > -----Original Message----- > > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > > Sent: Tuesday, July 31, 2012 6:28 PM > > > > > To: ccamp@ietf.org > > > > > Cc: jplang@ieee.org; yakov@juniper.net; > > > > dimitri.papadimitriou@alcatel- > > > > > lucent.be; stbryant@cisco.com; lberger@labn.net;=20 > > > > > dbrungard@att.com; Ong, Lyndon > > > > > Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > > > Hi CCAMP, > > > > > > > > > > I find that this erratum is raised against two sections one of=20 > > > > > which > > > > I > > > > supplied text > > > > > for. If this get contentious, I will call on Stewart to call > > > > consensus > > > > > and > > > > handle the > > > > > Erratum in the system. > > > > > > > > > > In my opinion, this proposal goes further than the intention=20 > > > > > of the authors/WG > > > > in > > > > > publishing 4872. > > > > > > > > > > With regard to the proposed addition to section 11... > > > > > The use of mb4b is already in scope. The existing text says > "The > > > > > new LSP resources can be established using the make-before- > break > > > > > mechanism," so there is no need to re-state "The new LSP can=20 > > > > > be established without tearing down > > > > the > > > > > old LSP". > > > > > > > > > > I think your concern here is whether the old LSP is ever torn > > down. > > > I > > > > > think > > > > that > > > > > you are worried that if the old LSP is torn down, it might be=20 > > > > > impossible to > > > > perform > > > > > reversion because, after repair, an attempt to revert (also=20 > > > > > using > > > > > mb4b) might > > > > find > > > > > that key resources have been "stolen" by some other LSP. I > don't > > > > > see this as > > > > at all > > > > > different from the issue of the protection LSP itself. That=20 > > > > > is, > > it > > > is > > > > > of the > > > > nature of > > > > > LSP Rerouting as a protection mechanism that: > > > > > a. protection may fail because of lack of resources b. > reversion > > > > > may fail > > > > because > > > > > of lack of resources > > > > > > > > > > *If* reversion is so important, I don't quite see why > protection > > > > > is not > > > > important. > > > > > If protection is important then you should be using a proper=20 > > > > > protection mechanism and not waiting for post facto rerouting. > > > > > Furthermore, if you > > > > require > > > > > that the LSP be retained for restoration, why are you not=20 > > > > > using a protection mechanism? > > > > > > > > > > But the general paradigm here is that you are willing to use > the > > > best > > > > available LSP > > > > > when it is set up in the first place, the best available LSP=20 > > > > > when > > > you > > > > > re-route > > > > after > > > > > failure, and the best available LSP when you "revert". > > > > > > > > > > Lastly, it *does* remain an _option_ to retain the failed LSP > in > > > > order > > > > > to > > > > switch > > > > > back. Nothing in the old text precludes that, although I=20 > > > > > understand that there > > > > is > > > > > an implication that it might be expected to be torn down. > > > > > > > > > > So I conclude that the proposed addition to section 12 is not > > what > > > > the > > > > > authors/WG intended. > > > > > > > > > > We should discuss further. > > > > > > > > > > Adrian > > > > > > > > > > > -----Original Message----- > > > > > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > > > > Sent: 31 July 2012 17:39 > > > > > > To: jplang@ieee.org; yakov@juniper.net; > > > > > > dimitri.papadimitriou@alcatel- lucent.be;=20 > > > > > > stbryant@cisco.com; adrian@olddog.co.uk; lberger@labn.net;=20 > > > > > > dbrungard@att.com > > > > > > Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc- > editor.org > > > > > > Subject: [Technical Errata Reported] RFC4872 (3304) > > > > > > > > > > > > > > > > > > The following errata report has been submitted for RFC4872, > > > > > > "RSVP- > > > > TE > > > > > > Extensions in Support of End-to-End Generalized Multi- > Protocol > > > > Label > > > > > > Switching (GMPLS) Recovery". > > > > > > > > > > > > -------------------------------------- > > > > > > You may review the report below and at: > > > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D33= 0 > > > > > > 4 > > > > > > > > > > > > -------------------------------------- > > > > > > Type: Technical > > > > > > Reported by: Lyndon Ong > > > > > > > > > > > > Section: 11 & 12 > > > > > > > > > > > > Original Text > > > > > > ------------- > > > > > > Section 11 says: > > > > > > > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end > node > > > that > > > > has > > > > > > either detected the LSP failure or received a Notify=20 > > > > > > message > > > > and/or a > > > > > > PathErr message with the new error code/sub-code "Notify > > > > Error/LSP > > > > > > Locally Failed" for this LSP. The new LSP resources can > be > > > > > > established using the make-before-break mechanism, where=20 > > > > > > the > > > new > > > > LSP > > > > > > is set up before the old LSP is torn down. This is done > by > > > > using the > > > > > > mechanisms of the SESSION_ATTRIBUTE object and the=20 > > > > > > Shared- > > > > Explicit > > > > > > (SE) reservation style (see [RFC3209]). Both the new and > > old > > > > LSPs > > > > > > can share resources at common nodes. > > > > > > > > > > > > Section 12 says: > > > > > > > > > > > > [No text on reversion for (full) LSP Rerouting.] > > > > > > > > > > > > Corrected Text > > > > > > -------------- > > > > > > Section 11 should say: > > > > > > > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end > node > > > that > > > > has > > > > > > either detected the LSP failure or received a Notify=20 > > > > > > message > > > > and/or a > > > > > > PathErr message with the new error code/sub-code "Notify > > > > Error/LSP > > > > > > Locally Failed" for this LSP. The new LSP resources can > be > > > > > > established using the make-before-break mechanism, where=20 > > > > > > the > > > new > > > > LSP > > > > > > is set up before the old LSP is torn down. This is done > by > > > > using the > > > > > > mechanisms of the SESSION_ATTRIBUTE object and the=20 > > > > > > Shared- > > > > Explicit > > > > > > (SE) reservation style (see [RFC3209]). Both the new and > > old > > > > LSPs > > > > > > can share resources at common nodes. The new LSP can be > > > > established > > > > > > without tearing down the old LSP in case of reversion=20 > > > > > > (see > > > > section 12). > > > > > > > > > > > > Section 12 should say: > > > > > > > > > > > > For "(full) LSP Rerouting", reversion implies that the=20 > > > > > > old LSP > > > > is not > > > > > > torn down by the head-end node after the new LSP is > > > established. > > > > For > > > > > > reversion, the head-end node re-activates the old LSP > after > > > this > > > > has > > > > > > recovered. > > > > > > > > > > > > > > > > > > > > > > > > Notes > > > > > > ----- > > > > > > Current text in RFC 4872 describes reversion in the cases of > > 1+1 > > > > > > bidirectional Protection, 1:N Protection with Extra Traffic=20 > > > > > > and Rerouting Without Extra > > > > > Traffic, > > > > > > however it has no description of reversion with (Full) LSP > > > > Rerouting. > > > > > > For (full) LSP Rerouting, the description in Section 11=20 > > > > > > instead implies that > > > > > the old > > > > > > LSP is torn down. This has led to some confusion as to > whether > > > > > > reversion with > > > > > > (full) LSP Rerouting is allowed or not allowed by the RFC.=20 > > > > > > We believe this was > > > > > not > > > > > > intentional. The additions would make it clear that=20 > > > > > > reversion can > > > > be > > > > > > supported with (Full) LSP Rerouting. > > > > > > > > > > > > Instructions: > > > > > > ------------- > > > > > > This errata is currently posted as "Reported". If necessary, > > > please > > > > > > use "Reply All" to discuss whether it should be verified or > > > > rejected. > > > > > > When a decision is reached, the verifying party (IESG) can > log > > > > > > in > > > > to > > > > > > change the status and edit the report, if necessary. > > > > > > > > > > > > -------------------------------------- > > > > > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > > > > > -------------------------------------- > > > > > > Title : RSVP-TE Extensions in Support of End- > to- > > End > > > > Generalized > > > > > Multi- > > > > > > Protocol Label Switching (GMPLS) Recovery > > > > > > Publication Date : May 2007 > > > > > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > > > > Papadimitriou, Ed. > > > > > > Category : PROPOSED STANDARD > > > > > > Source : Common Control and Measurement Plane > > > > > > Area : Routing > > > > > > Stream : IETF > > > > > > Verifying Party : IESG > > > > > > > > _______________________________________________ > > > > CCAMP mailing list > > > > CCAMP@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From prvs=3561bf1d5b=lyong@ciena.com Thu Aug 2 10:27:45 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2F811E817F for ; Thu, 2 Aug 2012 10:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.961 X-Spam-Level: X-Spam-Status: No, score=-101.961 tagged_above=-999 required=5 tests=[AWL=0.704, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACrFQ1DD1Uxi for ; Thu, 2 Aug 2012 10:27:44 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 1F76111E80D1 for ; Thu, 2 Aug 2012 10:27:44 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q72HPLOA001245; Thu, 2 Aug 2012 13:27:37 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 16fwqqr1jb-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 02 Aug 2012 13:27:37 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 2 Aug 2012 13:27:37 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Thu, 2 Aug 2012 13:27:37 -0400 From: "Ong, Lyndon" To: John E Drake , "Zafar Ali (zali)" , "Papadimitriou, Dimitri (Dimitri)" , Lou Berger , "adrian@olddog.co.uk" Date: Thu, 2 Aug 2012 13:27:36 -0400 Thread-Topic: [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNcMLyahN3GskcHE2KgpRsg0CwJpdGqVrAgAALjkCAAAf4wIAACPHA Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5019A35A.7090906@labn.net> <5E893DB832F57341992548CDBB333163A5A8E9364D@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A5A8E9364D@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-19078.004 x-tm-as-result: No--23.967800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-02_06:2012-08-01, 2012-08-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208020181 Cc: "jplang@ieee.org" , "ccamp@ietf.org" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:27:46 -0000 Hi John, We may be talking about different things, I was thinking of carriers' manag= ement systems for transport networks. Anyway it's a side point. Cheers, Lyndon -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: Thursday, August 02, 2012 9:54 AM To: Ong, Lyndon; Zafar Ali (zali); Papadimitriou, Dimitri (Dimitri); Lou Be= rger; adrian@olddog.co.uk Cc: jplang@ieee.org; ccamp@ietf.org; dbrungard@att.com Subject: RE: [Technical Errata Reported] RFC4872 (3304) Lyndon, As I am sure you remember, that is why graceful restart was invented. Thanks, John Sent from my iPhone > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Ong, Lyndon > Sent: Thursday, August 02, 2012 9:27 AM > To: Zafar Ali (zali); Papadimitriou, Dimitri (Dimitri); Lou Berger; > adrian@olddog.co.uk > Cc: jplang@ieee.org; ccamp@ietf.org; dbrungard@att.com > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > I agree with Zafar, I believe that the interest in reversion is due to > carrier's operational concerns. > > Cheers, > > Lyndon > > -----Original Message----- > From: Zafar Ali (zali) [mailto:zali@cisco.com] > Sent: Thursday, August 02, 2012 8:47 AM > To: Papadimitriou, Dimitri (Dimitri); Lou Berger; adrian@olddog.co.uk; > Ong, Lyndon > Cc: ccamp@ietf.org; jplang@ieee.org; dbrungard@att.com > Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > Dimitri- > > Please see in-line. > > Thanks > > Regards ... Zafar > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > Of Papadimitriou, Dimitri (Dimitri) > > Sent: Thursday, August 02, 2012 11:24 AM > > To: Lou Berger; adrian@olddog.co.uk; 'Ong, Lyndon' > > Cc: ccamp@ietf.org; jplang@ieee.org; dbrungard@att.com > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > > > Lou, > > > > there is by definition no notion of "reversion" in full LSP re- > routing. > > this is why there is no such description: it is less faster than e.g. > > protection but less resource-consuming (direct release of resources > > after establishment of the new LSP using make-before-break/RFC 3209) > > and more robust. see also RFC 4428 for more details. > > > > -> so I am not sure to which revision placeholder of RFC 4872 you > > -> are > > talking as I miss the rationales for a "scenario" that increases > > recovery time *and* resource consumption. > > > > Reversion requirement has nothing to do with the "recovery time" or > "protection" vs. "restoration". Reversion requirement has to do with > ability for the LSP to come back up on the original path *after* the > failure is recovered. Typically working LSP follows nominal path > (e.g., least latency path) and SPs would like the LSP to go back to > nominal LSP path once a failure is repair. During failure time, either > protection or restoration kicks in to minimize impact on the service. > Reversion requirements equally apply to protection as well as > restoration. > > For some circuit SP may decide that on-the-fly restoration suffices > (may be based on monitory cost for the circuit). But they still like > the LSP to go back to the nominal path (original working path). > > > Thanks, > > -dimitri. > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, August 01, 2012 23:45 > > > To: adrian@olddog.co.uk; 'Ong, Lyndon' > > > Cc: ccamp@ietf.org; jplang@ieee.org; yakov@juniper.net; > > > Papadimitriou, Dimitri (Dimitri); stbryant@cisco.com; > > > dbrungard@att.com; 'Roch, Evelyne' > > > Subject: Re: [Technical Errata Reported] RFC4872 (3304) > > > > > > > There is, of course, a lot that could be done to make it > > > clearer. But > > > is there > > > > really a need? We discussed the point. We agreed it is not > > > prohibited > > > in the > > > > RFC. Can we not just move on? > > > > > > So it sounds like there's agreement that there's no technical > errata > > > here. > > > > > > Perhaps an alternate way to proceed is to replace this errata with > > > an editorial errata that states that a future revision of the RFC > > > should explicitly discuss how this scenario is covered? > > > > > > Comments/thoughts? > > > > > > Lou > > > > > > On 8/1/2012 11:01 AM, Adrian Farrel wrote: > > > > Hello again, > > > > > > > >> Thank you for the fast evaluation of the errata. It > > > sounds like the > > > > correction that I > > > >> suggested has ended up overspecifying the method to do > > > reversion with full > > > >> rerouting when it is very possible to support a form of > > > reversion that doesn't > > > >> involve maintaining the old LSP. > > > > > > > > Right, I understand that you want to allow the option of > > > retaining the old > > > > working LSP. Also that you have no intention to remove the > > > option of removing > > > > the old working LSP. > > > > > > > >> From your response I believe that you do agree that it was > > > not the intent of > > > > the > > > >> original specification text to imply that reversion with > > > full rerouting is not > > > > allowed > > > > > > > > Definitely not the intent to imply that reversion with full > > > rerouting is not > > > > allowed. > > > > Does the text say or even imply this? > > > > > > > >> (or to require that the old LSP always be torn down in > > > full rerouting) > > > > > > > > Also no intention to *require* the old LSP to be torn down. > > > > My view is that the text is fully conformant with that. > > > > I understand that the text does not make an explicit > > > statement of this. > > > > > > > >> so hopefully > > > >> with some more discussion we can determine if there is > > > anything that could be > > > >> done to make that clearer. > > > > > > > > There is, of course, a lot that could be done to make it > > > clearer. But is there > > > > really a need? We discussed the point. We agreed it is not > > > prohibited in the > > > > RFC. Can we not just move on? > > > > > > > > Cheers, > > > > Adrian > > > >> -----Original Message----- > > > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > >> Sent: Tuesday, July 31, 2012 6:28 PM > > > >> To: ccamp@ietf.org > > > >> Cc: jplang@ieee.org; yakov@juniper.net; > > > dimitri.papadimitriou@alcatel- > > > >> lucent.be; stbryant@cisco.com; lberger@labn.net; > > > dbrungard@att.com; Ong, > > > >> Lyndon > > > >> Subject: RE: [Technical Errata Reported] RFC4872 (3304) > > > >> > > > >> Hi CCAMP, > > > >> > > > >> I find that this erratum is raised against two sections > > > one of which I > > > > supplied text > > > >> for. If this get contentious, I will call on Stewart to > > > call consensus and > > > > handle the > > > >> Erratum in the system. > > > >> > > > >> In my opinion, this proposal goes further than the > > > intention of the authors/WG > > > > in > > > >> publishing 4872. > > > >> > > > >> With regard to the proposed addition to section 11... > > > >> The use of mb4b is already in scope. The existing text > > > says "The new LSP > > > >> resources can be established using the make-before-break > > > mechanism," so there > > > >> is no need to re-state "The new LSP can be established > > > without tearing down > > > > the > > > >> old LSP". > > > >> > > > >> I think your concern here is whether the old LSP is ever > > > torn down. I think > > > > that > > > >> you are worried that if the old LSP is torn down, it might > > > be impossible to > > > > perform > > > >> reversion because, after repair, an attempt to revert > > > (also using mb4b) might > > > > find > > > >> that key resources have been "stolen" by some other LSP. I > > > don't see this as > > > > at all > > > >> different from the issue of the protection LSP itself. > > > That is, it is of the > > > > nature of > > > >> LSP Rerouting as a protection mechanism that: > > > >> a. protection may fail because of lack of resources b. > > > reversion may fail > > > > because > > > >> of lack of resources > > > >> > > > >> *If* reversion is so important, I don't quite see why > > > protection is not > > > > important. > > > >> If protection is important then you should be using a > > > proper protection > > > >> mechanism and not waiting for post facto rerouting. > > > Furthermore, if you > > > > require > > > >> that the LSP be retained for restoration, why are you not > > > using a protection > > > >> mechanism? > > > >> > > > >> But the general paradigm here is that you are willing to > > > use the best > > > > available LSP > > > >> when it is set up in the first place, the best available > > > LSP when you re-route > > > > after > > > >> failure, and the best available LSP when you "revert". > > > >> > > > >> Lastly, it *does* remain an _option_ to retain the failed > > > LSP in order to > > > > switch > > > >> back. Nothing in the old text precludes that, although I > > > understand that there > > > > is > > > >> an implication that it might be expected to be torn down. > > > >> > > > >> So I conclude that the proposed addition to section 12 is > > > not what the > > > >> authors/WG intended. > > > >> > > > >> We should discuss further. > > > >> > > > >> Adrian > > > >> > > > >>> -----Original Message----- > > > >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > > >>> Sent: 31 July 2012 17:39 > > > >>> To: jplang@ieee.org; yakov@juniper.net; > > > dimitri.papadimitriou@alcatel- > > > >>> lucent.be; stbryant@cisco.com; adrian@olddog.co.uk; > > > lberger@labn.net; > > > >>> dbrungard@att.com > > > >>> Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org > > > >>> Subject: [Technical Errata Reported] RFC4872 (3304) > > > >>> > > > >>> > > > >>> The following errata report has been submitted for > > > RFC4872, "RSVP-TE > > > >>> Extensions in Support of End-to-End Generalized > > > Multi-Protocol Label > > > >>> Switching (GMPLS) Recovery". > > > >>> > > > >>> -------------------------------------- > > > >>> You may review the report below and at: > > > >>> http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D3304 > > > >>> > > > >>> -------------------------------------- > > > >>> Type: Technical > > > >>> Reported by: Lyndon Ong > > > >>> > > > >>> Section: 11 & 12 > > > >>> > > > >>> Original Text > > > >>> ------------- > > > >>> Section 11 says: > > > >>> > > > >>> > > > >>> (Full) LSP rerouting will be initiated by the head-end > > > node that has > > > >>> either detected the LSP failure or received a Notify > > > message and/or a > > > >>> PathErr message with the new error code/sub-code > > > "Notify Error/LSP > > > >>> Locally Failed" for this LSP. The new LSP resources can be > > > >>> established using the make-before-break mechanism, > > > where the new LSP > > > >>> is set up before the old LSP is torn down. This is > > > done by using the > > > >>> mechanisms of the SESSION_ATTRIBUTE object and the > > > Shared-Explicit > > > >>> (SE) reservation style (see [RFC3209]). Both the new > > > and old LSPs > > > >>> can share resources at common nodes. > > > >>> > > > >>> Section 12 says: > > > >>> > > > >>> [No text on reversion for (full) LSP Rerouting.] > > > >>> > > > >>> Corrected Text > > > >>> -------------- > > > >>> Section 11 should say: > > > >>> > > > >>> > > > >>> (Full) LSP rerouting will be initiated by the head-end > > > node that has > > > >>> either detected the LSP failure or received a Notify > > > message and/or a > > > >>> PathErr message with the new error code/sub-code > > > "Notify Error/LSP > > > >>> Locally Failed" for this LSP. The new LSP resources can be > > > >>> established using the make-before-break mechanism, > > > where the new LSP > > > >>> is set up before the old LSP is torn down. This is > > > done by using the > > > >>> mechanisms of the SESSION_ATTRIBUTE object and the > > > Shared-Explicit > > > >>> (SE) reservation style (see [RFC3209]). Both the new > > > and old LSPs > > > >>> can share resources at common nodes. The new LSP can > > > be established > > > >>> without tearing down the old LSP in case of reversion > > > (see section 12). > > > >>> > > > >>> Section 12 should say: > > > >>> > > > >>> For "(full) LSP Rerouting", reversion implies that the > > > old LSP is not > > > >>> torn down by the head-end node after the new LSP is > > > established. For > > > >>> reversion, the head-end node re-activates the old LSP > > > after this has > > > >>> recovered. > > > >>> > > > >>> > > > >>> > > > >>> Notes > > > >>> ----- > > > >>> Current text in RFC 4872 describes reversion in the cases of > 1+1 > > > >>> bidirectional Protection, 1:N Protection with Extra Traffic > > > >>> and Rerouting Without Extra > > > >> Traffic, > > > >>> however it has no description of reversion with (Full) > > > LSP Rerouting. > > > >>> For (full) LSP Rerouting, the description in Section 11 > > > >>> instead implies that > > > >> the old > > > >>> LSP is torn down. This has led to some confusion as to whether > > > >>> reversion with > > > >>> (full) LSP Rerouting is allowed or not allowed by the > > > RFC. We believe > > > >>> this was > > > >> not > > > >>> intentional. The additions would make it clear that > > > reversion can be > > > >>> supported with (Full) LSP Rerouting. > > > >>> > > > >>> Instructions: > > > >>> ------------- > > > >>> This errata is currently posted as "Reported". If > > > necessary, please > > > >>> use "Reply All" to discuss whether it should be verified > > > or rejected. > > > >>> When a decision is reached, the verifying party (IESG) > > > can log in to > > > >>> change the status and edit the report, if necessary. > > > >>> > > > >>> -------------------------------------- > > > >>> RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > > >>> -------------------------------------- > > > >>> Title : RSVP-TE Extensions in Support of End-to- > End > > > > Generalized > > > >> Multi- > > > >>> Protocol Label Switching (GMPLS) Recovery > > > >>> Publication Date : May 2007 > > > >>> Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. > > > Papadimitriou, Ed. > > > >>> Category : PROPOSED STANDARD > > > >>> Source : Common Control and Measurement Plane > > > >>> Area : Routing > > > >>> Stream : IETF > > > >>> Verifying Party : IESG > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From rrao@infinera.com Thu Aug 2 10:39:37 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F213E21E810E for ; Thu, 2 Aug 2012 10:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRXT2TYngLhs for ; Thu, 2 Aug 2012 10:39:36 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0785A21E810F for ; Thu, 2 Aug 2012 10:39:35 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0283.003; Thu, 2 Aug 2012 10:39:35 -0700 From: Rajan Rao To: Leeyoung , "Giovanni Martinelli (giomarti)" Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority Thread-Index: AQHNcAy0UkTqZeG4LEua7hBAeom47ZdF/mQAgAAEqACAAAosgIABHCGAgAALcQD//5T7sA== Date: Thu, 2 Aug 2012 17:39:35 +0000 Message-ID: <650AA355E323C34D9D4AAEED952E053D347EE54E@SV-EXDB-PROD2.infinera.com> References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED70@dfweml511-mbs.china.huawei.com> <48F63A76-53E9-4C38-A266-8B8BAB9F7838@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905EEC1@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172905EEC1@dfweml511-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:39:37 -0000 Giovanni, My comment few months ago was to cover bandwidth advertisement at all 8 pr= iority levels as in PSC, TDM & TDM-OTN switching cases. The priority bas= ed advertisement in WSON/LSC is no different from other cases. What might be useful is to add couple of examples to show how this is used = along with other flags. Hope this helps. Thanks Rajan -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= eeyoung Sent: Thursday, August 02, 2012 9:57 AM To: Giovanni Martinelli (giomarti) Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Giovanni, Please see in-line for my responses. Thanks.=20 -----Original Message----- From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] Sent: Thursday, August 02, 2012 11:16 AM To: Leeyoung Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Young, btw first just a naming issue (I guess a question for the wg in general) th= e object label_set here has the same name name as the label_set form rfc347= 1 but it has actually a different encoding, so just asking if worth figurin= g out a little different name. If no one complain I'm fine too. YOUNG>> We are expanding the label set concept from 3471. I am not sure if = there is a new name needed here. I defer this to WG chairs.=20 please see inline On Aug 2, 2012, at 1:18 , Leeyoung wrote: > > On Aug 2, 2012, at 24:25 , Leeyoung wrote: >=20 >> Hi Giovanni, >>=20 >> The wavelength priority you propose seems different from the what we enc= oded per Rao Rajan's suggestion. What we encoded in section 2.3 of gen enco= de is not giving wavelength a priority level, among which I believe your wa= velength property specifies. >>=20 >> What we are proposing is what labels are available/not available for eac= h priority level (similar to LSP reservation or holding priority) as the fo= llowing encoding dictates:=20 >>=20 >=20 >=20 > GM> So at the end is a "Label Priority" ? With the Label_Set granularity = instead of the single Label? =20 >=20 > YOUNG>> No, this is not "label priority". Label is not "assigned" a prior= ity. Label is neutral. Say, you have five wavelengths available for grab an= d you have two priorities you are aware of which is service level (e.g., LS= P). For higher priority service, you may want to all your five wavelengths = (w1-w5) available for grab while for lower priority, you may restrict to le= ss number of wavelengths, say three wavelengths only (e.g., w1-w3). GM> Well I'm not sure I'm following you, you say that labels are not assign= ed to a priority but then there is a priority associated to a label set. Fo= r sure label is neutral but "someone" decide if it goes in a label set with= a certain priority, or in another (or in both label_set ). So, to me this = means associate (is this term better than assign?) a priority to a label. YOUNG>> I think I explained enough what the current encoding is. This is ab= out what labels are available for LSP priority. Some labels may be availabl= e for more than one LSP priority. There is no 1:1 "association" between lab= el and priority per se.=20 > Here you can see individual wavelength is not assigned a priority. GM> the granularity is the label_set so you can easily see that's equivalen= t to individual label, anyway single label or label-set its not a substanti= al difference to me. > This is analogous to how much BW availability for each priority in MPLS n= etwork, except that we need to express in wavelength level. =20 >=20 >=20 >=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |A| Reserved | Priority Flags| Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Label Set Field | >> : : >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Where >>=20 >> A (Availability bit) =3D 1 or 0 indicates that the labels listed in =20 >> the following label set field are available or not available, =20 >> respectively, for use at a given priority level as indicated by the =20 >> Priority Flags. >=20 >=20 > GM> The reading here suggest me that there could be multiple objects (I b= et up to 8) packed up somewere (e.g. something like sub-tlvs in the link ad= vertisement). Is my interpretation correct? >=20 > YOUNG>> Yes.=20 >=20 GM> two encoding question here: GM> 1/ why using flags instead of classical three bits?=20 GM> 2/ What the usage of A? I mean you have an Available_label object and t= hen you set A=3D0 which means that labels are not available... could you pl= ease clarify better? =20 YOUNG>> Yes, three bits can do that. We put A=3D0 (not available) --just to= give more flexibility. That's all. If you want to restrict some ranges of = labels to lower LSP, using A bit (A=3D0) would be more efficient to express= such need.=20 Cheers G > Cheers > G >=20 >=20 >>=20 >> Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 =20 >> corresponds to priority level 7. If a bit is set then the labels in =20 >> the label set field are available or not available as indicated by =20 >> the A bit for use at that particular priority level. >>=20 >> Let's begin if we are in agreement with this point.=20 >>=20 >> Thanks. >> Young >>=20 >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >> Behalf Of Giovanni Martinelli (giomarti) >> Sent: Wednesday, August 01, 2012 12:40 PM >> To: Giovanni Martinelli (giomarti) >> Cc: CCAMP >> Subject: Re: [CCAMP] Comment on=20 >> draft-ietf-ccamp-general-constraint-encode-08: priority >>=20 >> Here my latest mail with comments on wavelength priority...=20 >>=20 >> Here my memory on past discussion (please correct if wrong) >> - last short thread was during ieft83 (around 26/28 march), last mail wa= s from me and did not get answers. The content here below cover that mail a= s well. >> - discussions about wl priority happens among authors not on ccamp maili= ng list. On the mailing list you announce draft update around dec 2011. =20 >>=20 >> Well, I'm not complaining about how discussion happen, simply I saw a n= ot-trivial addition to wg document, hence my comments. >>=20 >> Cheers >> G >>=20 >>=20 >>=20 >> On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: >>=20 >>> Dear authors / ccamp, >>>=20 >>> here a few comments related to the priority field added to draft-ietf-c= camp-general-constraint-encode: >>>=20 >>> A couple of editorial comments >>> 1) "wavelenght priority" appears in a draft that claim to be general. = In fact is available in "Available Labels Sub-TLV" and "Shared Backup Label= s Sub-TLV". So is a wavelength or label-like priority? >>> 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0= .. 7]? >>>=20 >>>=20 >>> Then few other comments >>> 3) How the priority is used versus the A flag . Draft text report " >>> A (Availability bit) =3D 1 or 0 indicates that the labels listed in=20 >>> the following label set field are available or not available,=20 >>> respectively, for use at a given priority level as indicated by the=20 >>> Priority Flags. >>>=20 >>> " >>> So does it means that there could be different "available labels sub-TL= Vs" advertised?=20 >>>=20 >>> 4) Still unclear to me how this priority is different from the one=20 >>> reported in http://tools.ietf.org/html/draft-kattan-wson-property-01=20 >>> and eventually if this "priority" could fit the LSP priority already=20 >>> available (as one of the comment we received at that time) >>>=20 >>> Cheers >>> G >>>=20 >>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Thu Aug 2 10:40:38 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B570611E8087 for ; Thu, 2 Aug 2012 10:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.463 X-Spam-Level: X-Spam-Status: No, score=-97.463 tagged_above=-999 required=5 tests=[AWL=2.098, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+PtXbW0Vih0 for ; Thu, 2 Aug 2012 10:40:37 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 4965021F85BB for ; Thu, 2 Aug 2012 10:40:37 -0700 (PDT) Received: (qmail 7001 invoked by uid 0); 2 Aug 2012 16:34:30 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 2 Aug 2012 16:34:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=s73DvJPmI7NhbO7yLyhEnM8U3xutpFD4b7A9f+2UJGQ=; b=aBZkgS4fp1ffOlIf+qJl4TynVtDrxnM0Qc5tLoot8Hs33KCTUeoXsBeF/Qij279s2n8SuOFFeDqyhKG6N+aUVBlkNHruaV/1M2JYi/PDwG7W9cdhc8Zdn6fGSD59K/FA; Received: from box313.bluehost.com ([69.89.31.113]:36082 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1SwyM1-0003QP-GJ; Thu, 02 Aug 2012 10:34:30 -0600 Message-ID: <501AAC11.50807@labn.net> Date: Thu, 02 Aug 2012 09:34:25 -0700 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Papadimitriou, Dimitri (Dimitri)" References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5019A35A.7090906@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" , "jplang@ieee.org" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:40:38 -0000 Dimitri, (hat off) while it is not explicit, there is nothing in the draft that precludes it and some of us certainly reviewed the document at the time with this in mind to ensure it wasn't. Furthermore, as we heard in Paris, there is at least one deployed implementation that implements reversion with full LSP rerouting. Based on the level of discussion, I suspect an info doc may be a better way to go on this topic... Lou On 8/2/2012 8:24 AM, Papadimitriou, Dimitri (Dimitri) wrote: > Lou, > > there is by definition no notion of "reversion" in full LSP > re-routing. this is why there is no such description: it is less > faster than e.g. protection but less resource-consuming (direct > release of resources after establishment of the new LSP using > make-before-break/RFC 3209) and more robust. see also RFC 4428 for > more details. > > -> so I am not sure to which revision placeholder of RFC 4872 you are > talking as I miss the rationales for a "scenario" that increases > recovery time *and* resource consumption. > > Thanks, > -dimitri. >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, August 01, 2012 23:45 >> To: adrian@olddog.co.uk; 'Ong, Lyndon' >> Cc: ccamp@ietf.org; jplang@ieee.org; yakov@juniper.net; >> Papadimitriou, Dimitri (Dimitri); stbryant@cisco.com; >> dbrungard@att.com; 'Roch, Evelyne' >> Subject: Re: [Technical Errata Reported] RFC4872 (3304) >> >>> There is, of course, a lot that could be done to make it >> clearer. But >> is there >>> really a need? We discussed the point. We agreed it is not >> prohibited >> in the >>> RFC. Can we not just move on? >> >> So it sounds like there's agreement that there's no technical >> errata here. >> >> Perhaps an alternate way to proceed is to replace this errata with an >> editorial errata that states that a future revision of the RFC should >> explicitly discuss how this scenario is covered? >> >> Comments/thoughts? >> >> Lou >> >> On 8/1/2012 11:01 AM, Adrian Farrel wrote: >>> Hello again, >>> >>>> Thank you for the fast evaluation of the errata. It >> sounds like the >>> correction that I >>>> suggested has ended up overspecifying the method to do >> reversion with full >>>> rerouting when it is very possible to support a form of >> reversion that doesn't >>>> involve maintaining the old LSP. >>> >>> Right, I understand that you want to allow the option of >> retaining the old >>> working LSP. Also that you have no intention to remove the >> option of removing >>> the old working LSP. >>> >>>> From your response I believe that you do agree that it was >> not the intent of >>> the >>>> original specification text to imply that reversion with >> full rerouting is not >>> allowed >>> >>> Definitely not the intent to imply that reversion with full >> rerouting is not >>> allowed. >>> Does the text say or even imply this? >>> >>>> (or to require that the old LSP always be torn down in >> full rerouting) >>> >>> Also no intention to *require* the old LSP to be torn down. >>> My view is that the text is fully conformant with that. >>> I understand that the text does not make an explicit >> statement of this. >>> >>>> so hopefully >>>> with some more discussion we can determine if there is >> anything that could be >>>> done to make that clearer. >>> >>> There is, of course, a lot that could be done to make it >> clearer. But is there >>> really a need? We discussed the point. We agreed it is not >> prohibited in the >>> RFC. Can we not just move on? >>> >>> Cheers, >>> Adrian >>>> -----Original Message----- >>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>> Sent: Tuesday, July 31, 2012 6:28 PM >>>> To: ccamp@ietf.org >>>> Cc: jplang@ieee.org; yakov@juniper.net; >> dimitri.papadimitriou@alcatel- >>>> lucent.be; stbryant@cisco.com; lberger@labn.net; >> dbrungard@att.com; Ong, >>>> Lyndon >>>> Subject: RE: [Technical Errata Reported] RFC4872 (3304) >>>> >>>> Hi CCAMP, >>>> >>>> I find that this erratum is raised against two sections >> one of which I >>> supplied text >>>> for. If this get contentious, I will call on Stewart to >> call consensus and >>> handle the >>>> Erratum in the system. >>>> >>>> In my opinion, this proposal goes further than the >> intention of the authors/WG >>> in >>>> publishing 4872. >>>> >>>> With regard to the proposed addition to section 11... >>>> The use of mb4b is already in scope. The existing text >> says "The new LSP >>>> resources can be established using the make-before-break >> mechanism," so there >>>> is no need to re-state "The new LSP can be established >> without tearing down >>> the >>>> old LSP". >>>> >>>> I think your concern here is whether the old LSP is ever >> torn down. I think >>> that >>>> you are worried that if the old LSP is torn down, it might >> be impossible to >>> perform >>>> reversion because, after repair, an attempt to revert >> (also using mb4b) might >>> find >>>> that key resources have been "stolen" by some other LSP. I >> don't see this as >>> at all >>>> different from the issue of the protection LSP itself. >> That is, it is of the >>> nature of >>>> LSP Rerouting as a protection mechanism that: >>>> a. protection may fail because of lack of resources b. >> reversion may fail >>> because >>>> of lack of resources >>>> >>>> *If* reversion is so important, I don't quite see why >> protection is not >>> important. >>>> If protection is important then you should be using a >> proper protection >>>> mechanism and not waiting for post facto rerouting. >> Furthermore, if you >>> require >>>> that the LSP be retained for restoration, why are you not >> using a protection >>>> mechanism? >>>> >>>> But the general paradigm here is that you are willing to >> use the best >>> available LSP >>>> when it is set up in the first place, the best available >> LSP when you re-route >>> after >>>> failure, and the best available LSP when you "revert". >>>> >>>> Lastly, it *does* remain an _option_ to retain the failed >> LSP in order to >>> switch >>>> back. Nothing in the old text precludes that, although I >> understand that there >>> is >>>> an implication that it might be expected to be torn down. >>>> >>>> So I conclude that the proposed addition to section 12 is >> not what the >>>> authors/WG intended. >>>> >>>> We should discuss further. >>>> >>>> Adrian >>>> >>>>> -----Original Message----- >>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>> Sent: 31 July 2012 17:39 >>>>> To: jplang@ieee.org; yakov@juniper.net; >> dimitri.papadimitriou@alcatel- >>>>> lucent.be; stbryant@cisco.com; adrian@olddog.co.uk; >> lberger@labn.net; >>>>> dbrungard@att.com >>>>> Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc-editor.org >>>>> Subject: [Technical Errata Reported] RFC4872 (3304) >>>>> >>>>> >>>>> The following errata report has been submitted for >> RFC4872, "RSVP-TE >>>>> Extensions in Support of End-to-End Generalized >> Multi-Protocol Label >>>>> Switching (GMPLS) Recovery". >>>>> >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata_search.php?rfc=4872&eid=3304 >>>>> >>>>> -------------------------------------- >>>>> Type: Technical >>>>> Reported by: Lyndon Ong >>>>> >>>>> Section: 11 & 12 >>>>> >>>>> Original Text >>>>> ------------- >>>>> Section 11 says: >>>>> >>>>> >>>>> (Full) LSP rerouting will be initiated by the head-end >> node that has >>>>> either detected the LSP failure or received a Notify >> message and/or a >>>>> PathErr message with the new error code/sub-code >> "Notify Error/LSP >>>>> Locally Failed" for this LSP. The new LSP resources can be >>>>> established using the make-before-break mechanism, >> where the new LSP >>>>> is set up before the old LSP is torn down. This is >> done by using the >>>>> mechanisms of the SESSION_ATTRIBUTE object and the >> Shared-Explicit >>>>> (SE) reservation style (see [RFC3209]). Both the new >> and old LSPs >>>>> can share resources at common nodes. >>>>> >>>>> Section 12 says: >>>>> >>>>> [No text on reversion for (full) LSP Rerouting.] >>>>> >>>>> Corrected Text >>>>> -------------- >>>>> Section 11 should say: >>>>> >>>>> >>>>> (Full) LSP rerouting will be initiated by the head-end >> node that has >>>>> either detected the LSP failure or received a Notify >> message and/or a >>>>> PathErr message with the new error code/sub-code >> "Notify Error/LSP >>>>> Locally Failed" for this LSP. The new LSP resources can be >>>>> established using the make-before-break mechanism, >> where the new LSP >>>>> is set up before the old LSP is torn down. This is >> done by using the >>>>> mechanisms of the SESSION_ATTRIBUTE object and the >> Shared-Explicit >>>>> (SE) reservation style (see [RFC3209]). Both the new >> and old LSPs >>>>> can share resources at common nodes. The new LSP can >> be established >>>>> without tearing down the old LSP in case of reversion >> (see section 12). >>>>> >>>>> Section 12 should say: >>>>> >>>>> For "(full) LSP Rerouting", reversion implies that the >> old LSP is not >>>>> torn down by the head-end node after the new LSP is >> established. For >>>>> reversion, the head-end node re-activates the old LSP >> after this has >>>>> recovered. >>>>> >>>>> >>>>> >>>>> Notes >>>>> ----- >>>>> Current text in RFC 4872 describes reversion in the cases of 1+1 >>>>> bidirectional Protection, 1:N Protection with Extra Traffic and >>>>> Rerouting Without Extra >>>> Traffic, >>>>> however it has no description of reversion with (Full) >> LSP Rerouting. >>>>> For (full) LSP Rerouting, the description in Section 11 instead >>>>> implies that >>>> the old >>>>> LSP is torn down. This has led to some confusion as to whether >>>>> reversion with >>>>> (full) LSP Rerouting is allowed or not allowed by the >> RFC. We believe >>>>> this was >>>> not >>>>> intentional. The additions would make it clear that >> reversion can be >>>>> supported with (Full) LSP Rerouting. >>>>> >>>>> Instructions: >>>>> ------------- >>>>> This errata is currently posted as "Reported". If >> necessary, please >>>>> use "Reply All" to discuss whether it should be verified >> or rejected. >>>>> When a decision is reached, the verifying party (IESG) >> can log in to >>>>> change the status and edit the report, if necessary. >>>>> >>>>> -------------------------------------- >>>>> RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) >>>>> -------------------------------------- >>>>> Title : RSVP-TE Extensions in Support of End-to-End >>> Generalized >>>> Multi- >>>>> Protocol Label Switching (GMPLS) Recovery >>>>> Publication Date : May 2007 >>>>> Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. >> Papadimitriou, Ed. >>>>> Category : PROPOSED STANDARD >>>>> Source : Common Control and Measurement Plane >>>>> Area : Routing >>>>> Stream : IETF >>>>> Verifying Party : IESG >>> >>> >>> >>> >>> >> > > > From giomarti@cisco.com Thu Aug 2 10:48:46 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED2B11E81B2 for ; Thu, 2 Aug 2012 10:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.121 X-Spam-Level: X-Spam-Status: No, score=-10.121 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6piH8HQuPiuJ for ; Thu, 2 Aug 2012 10:48:45 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 12DCC11E80D3 for ; Thu, 2 Aug 2012 10:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=giomarti@cisco.com; l=8886; q=dns/txt; s=iport; t=1343929725; x=1345139325; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=u0sAbpBohdDvN5wgS8zXEna/AtfvmeFH22LhqE/xxSU=; b=OE98Mtsp4KrWnxBsTb/o+NKsyjgsAXZ+S5BIzgUe01FXFlZljqlDGW9k cpiXheAnH8DSdH5nFIURGsCc6gA6zurIw89ozi/j4hAGbzHcL5XqQxOYo v9aoRO7AX/r8olwN9WT3czdxzXuvAlNzgyFiK4DzhDw62J5OwL950OH5V I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHK8GlCtJXHA/2dsb2JhbABFuRmBB4IgAQEBAwEBAQEPASc0CwUHBAIBCA4DBAEBAR4JBycLFAkIAgQOBSKHZQYLnGOgVItKAhiGCmADlUeBFI0TgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="107944565" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 02 Aug 2012 17:48:44 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q72Hmi1U016323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 17:48:44 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.69]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 12:48:44 -0500 From: "Giovanni Martinelli (giomarti)" To: Rajan Rao Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority Thread-Index: AQHNbqOAwicEtWD5nEWGP6luAcXdUpdFj84AgABP4QCAAASpgIAACiyAgAEcMgCAAAtfAIAADAWAgAACo4A= Date: Thu, 2 Aug 2012 17:48:43 +0000 Message-ID: References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED70@dfweml511-mbs.china.huawei.com> <48F63A76-53E9-4C38-A266-8B8BAB9F7838@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905EEC1@dfweml511-mbs.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D347EE54E@SV-EXDB-PROD2.infinera.com> In-Reply-To: <650AA355E323C34D9D4AAEED952E053D347EE54E@SV-EXDB-PROD2.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.166.99] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.004 x-tm-as-result: No--67.279600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <03EBF9E3BECF9541AD30BD23A890C984@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:48:47 -0000 Hi Rajan, On Aug 2, 2012, at 19:39 , Rajan Rao wrote: > Giovanni, >=20 > My comment few months ago was to cover bandwidth advertisement at all 8 = priority levels as in PSC, TDM & TDM-OTN switching cases. The priority b= ased advertisement in WSON/LSC is no different from other cases. >=20 > What might be useful is to add couple of examples to show how this is use= d along with other flags. >=20 that would be very helpful (so we can reach common understanding) thx G > Hope this helps. > Thanks > Rajan >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of= Leeyoung > Sent: Thursday, August 02, 2012 9:57 AM > To: Giovanni Martinelli (giomarti) > Cc: CCAMP > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encod= e-08: priority >=20 > Hi Giovanni, >=20 > Please see in-line for my responses. >=20 > Thanks.=20 >=20 > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: Thursday, August 02, 2012 11:16 AM > To: Leeyoung > Cc: CCAMP > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encod= e-08: priority >=20 > Hi Young, >=20 > btw first just a naming issue (I guess a question for the wg in general) = the object label_set here has the same name name as the label_set form rfc3= 471 but it has actually a different encoding, so just asking if worth figur= ing out a little different name. If no one complain I'm fine too. >=20 > YOUNG>> We are expanding the label set concept from 3471. I am not sure i= f there is a new name needed here. I defer this to WG chairs.=20 >=20 > please see inline >=20 > On Aug 2, 2012, at 1:18 , Leeyoung wrote: >=20 >> >> On Aug 2, 2012, at 24:25 , Leeyoung wrote: >>=20 >>> Hi Giovanni, >>>=20 >>> The wavelength priority you propose seems different from the what we en= coded per Rao Rajan's suggestion. What we encoded in section 2.3 of gen enc= ode is not giving wavelength a priority level, among which I believe your w= avelength property specifies. >>>=20 >>> What we are proposing is what labels are available/not available for ea= ch priority level (similar to LSP reservation or holding priority) as the f= ollowing encoding dictates:=20 >>>=20 >>=20 >>=20 >> GM> So at the end is a "Label Priority" ? With the Label_Set granularity= instead of the single Label? =20 >>=20 >> YOUNG>> No, this is not "label priority". Label is not "assigned" a prio= rity. Label is neutral. Say, you have five wavelengths available for grab a= nd you have two priorities you are aware of which is service level (e.g., L= SP). For higher priority service, you may want to all your five wavelengths= (w1-w5) available for grab while for lower priority, you may restrict to l= ess number of wavelengths, say three wavelengths only (e.g., w1-w3). >=20 >=20 > GM> Well I'm not sure I'm following you, you say that labels are not assi= gned to a priority but then there is a priority associated to a label set. = For sure label is neutral but "someone" decide if it goes in a label set wi= th a certain priority, or in another (or in both label_set ). So, to me thi= s means associate (is this term better than assign?) a priority to a label. >=20 > YOUNG>> I think I explained enough what the current encoding is. This is = about what labels are available for LSP priority. Some labels may be availa= ble for more than one LSP priority. There is no 1:1 "association" between l= abel and priority per se.=20 >=20 >> Here you can see individual wavelength is not assigned a priority. >=20 >=20 > GM> the granularity is the label_set so you can easily see that's equival= ent to individual label, anyway single label or label-set its not a substan= tial difference to me. >=20 >=20 >=20 >> This is analogous to how much BW availability for each priority in MPLS = network, except that we need to express in wavelength level. =20 >>=20 >>=20 >>=20 >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |A| Reserved | Priority Flags| Reserved | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Label Set Field | >>> : : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Where >>>=20 >>> A (Availability bit) =3D 1 or 0 indicates that the labels listed in =20 >>> the following label set field are available or not available, =20 >>> respectively, for use at a given priority level as indicated by the =20 >>> Priority Flags. >>=20 >>=20 >> GM> The reading here suggest me that there could be multiple objects (I = bet up to 8) packed up somewere (e.g. something like sub-tlvs in the link a= dvertisement). Is my interpretation correct? >>=20 >> YOUNG>> Yes.=20 >>=20 >=20 > GM> two encoding question here: > GM> 1/ why using flags instead of classical three bits?=20 > GM> 2/ What the usage of A? I mean you have an Available_label object and= then you set A=3D0 which means that labels are not available... could you = please clarify better? >=20 > YOUNG>> Yes, three bits can do that. We put A=3D0 (not available) --just = to give more flexibility. That's all. If you want to restrict some ranges o= f labels to lower LSP, using A bit (A=3D0) would be more efficient to expre= ss such need.=20 >=20 > Cheers > G >=20 >=20 >=20 >> Cheers >> G >>=20 >>=20 >>>=20 >>> Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 =20 >>> corresponds to priority level 7. If a bit is set then the labels in =20 >>> the label set field are available or not available as indicated by =20 >>> the A bit for use at that particular priority level. >>>=20 >>> Let's begin if we are in agreement with this point.=20 >>>=20 >>> Thanks. >>> Young >>>=20 >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>> Behalf Of Giovanni Martinelli (giomarti) >>> Sent: Wednesday, August 01, 2012 12:40 PM >>> To: Giovanni Martinelli (giomarti) >>> Cc: CCAMP >>> Subject: Re: [CCAMP] Comment on=20 >>> draft-ietf-ccamp-general-constraint-encode-08: priority >>>=20 >>> Here my latest mail with comments on wavelength priority...=20 >>>=20 >>> Here my memory on past discussion (please correct if wrong) >>> - last short thread was during ieft83 (around 26/28 march), last mail w= as from me and did not get answers. The content here below cover that mail = as well. >>> - discussions about wl priority happens among authors not on ccamp mail= ing list. On the mailing list you announce draft update around dec 2011. =20 >>>=20 >>> Well, I'm not complaining about how discussion happen, simply I saw a = not-trivial addition to wg document, hence my comments. >>>=20 >>> Cheers >>> G >>>=20 >>>=20 >>>=20 >>> On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: >>>=20 >>>> Dear authors / ccamp, >>>>=20 >>>> here a few comments related to the priority field added to draft-ietf-= ccamp-general-constraint-encode: >>>>=20 >>>> A couple of editorial comments >>>> 1) "wavelenght priority" appears in a draft that claim to be general.= In fact is available in "Available Labels Sub-TLV" and "Shared Backup Labe= ls Sub-TLV". So is a wavelength or label-like priority? >>>> 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [= 0 .. 7]? >>>>=20 >>>>=20 >>>> Then few other comments >>>> 3) How the priority is used versus the A flag . Draft text report " >>>> A (Availability bit) =3D 1 or 0 indicates that the labels listed in=20 >>>> the following label set field are available or not available,=20 >>>> respectively, for use at a given priority level as indicated by the=20 >>>> Priority Flags. >>>>=20 >>>> " >>>> So does it means that there could be different "available labels sub-T= LVs" advertised?=20 >>>>=20 >>>> 4) Still unclear to me how this priority is different from the one=20 >>>> reported in http://tools.ietf.org/html/draft-kattan-wson-property-01=20 >>>> and eventually if this "priority" could fit the LSP priority already=20 >>>> available (as one of the comment we received at that time) >>>>=20 >>>> Cheers >>>> G >>>>=20 >>>=20 >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Thu Aug 2 10:52:37 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5034C11E81D0 for ; Thu, 2 Aug 2012 10:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[AWL=1.274, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQhpkuMYsi7a for ; Thu, 2 Aug 2012 10:52:35 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id D8DC011E81CF for ; Thu, 2 Aug 2012 10:52:31 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUBq+OUsevYz4MmWhm4Yb02JbC4kyyCU8@postini.com; Thu, 02 Aug 2012 10:52:35 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 2 Aug 2012 10:48:44 -0700 From: John E Drake To: Rajan Rao Date: Thu, 2 Aug 2012 10:48:43 -0700 Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: Ac1w1w9rIQNCuH9/QOW8zcDPLjM2tw== Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A5A8E93302@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A5A8E9337E@EMBX01-HQ.jnpr.net> <650AA355E323C34D9D4AAEED952E053D347EE404@SV-EXDB-PROD2.infinera.com> <5E893DB832F57341992548CDBB333163A5A8E93642@EMBX01-HQ.jnpr.net> <650AA355E323C34D9D4AAEED952E053D347EE4F1@SV-EXDB-PROD2.infinera.com> In-Reply-To: <650AA355E323C34D9D4AAEED952E053D347EE4F1@SV-EXDB-PROD2.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dimitri.papadimitriou@alcatel-lucent.be" , "ccamp@ietf.org" , "jplang@ieee.org" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:52:37 -0000 If I were so inclined, I would file an erratum against the text you cited. Sent from my iPhone On Aug 2, 2012, at 10:18 AM, "Rajan Rao" wrote: > John, > > I too agree that existing text from Section-12 (see below) is sufficient = as pointed by Zafar. The text below should also clarify your questions. > " > For "Rerouting without Extra-traffic" (including the shared recovery > case), reversion implies that the formerly working LSP has not been > torn down by the head-end node upon PathErr message reception, i.e., > the head-end node kept refreshing the working LSP under failure > condition. This ensures that the exact same resources are retrieved > after reversion switching (except if the working LSP required re- > signaling). > " > > Thanks > Rajan > > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, August 02, 2012 9:52 AM > To: Rajan Rao; Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, Lyndon'; ccam= p@ietf.org > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; dbrungard@a= tt.com > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > Rajan, > > Due to link and/or node failure the resources of a failed LSP may not be = maintained. Further, at any time a higher priority LSP may be established = that pre-empts the resources of a failed LSP. This is sort of basic. > > Also, because of this, I am not sure what the phrase 'continuous monitori= ng of failed path is necessary' means or how you intend to accomplish this = other than by attempting to re-establish the failed LSP along its original = path. > > Finally, and most importantly, as I indicated yesterday, I don't see anyt= hing wrong with the existing text. > > Thanks, > > John > > Sent from my iPhone > >> -----Original Message----- >> From: Rajan Rao [mailto:rrao@infinera.com] >> Sent: Thursday, August 02, 2012 9:21 AM >> To: John E Drake; Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, >> Lyndon'; ccamp@ietf.org >> Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; >> dbrungard@att.com >> Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >> >> John, >> >> Revertive restoration requires keeping original path because >> continuous monitoring of failed path is necessary for revertive >> operation upon recovery. >> >> Thanks >> Rajan >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of John E Drake >> Sent: Wednesday, August 01, 2012 5:54 PM >> To: Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, Lyndon'; >> ccamp@ietf.org >> Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; >> dbrungard@att.com >> Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >> >> You can't keep the original, broken LSP around because it no longer >> has e2e committed resources. The best you can do is clean it up and >> try to re-instantiate it on its original path. >> >> Sent from my iPhone >> >>> -----Original Message----- >>> From: Zafar Ali (zali) [mailto:zali@cisco.com] >>> Sent: Wednesday, August 01, 2012 5:48 PM >>> To: John E Drake; adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org >>> Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; >>> dbrungard@att.com >>> Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >>> >>> Hi John- >>> >>> Please see my response to Adrian's email for the use case for >>> keeping the original LSP around during failure. >>> >>> Thanks >>> >>> Regards ... Zafar >>> >>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>> Behalf >>>> Of John E Drake >>>> Sent: Wednesday, August 01, 2012 7:49 PM >>>> To: adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org >>>> Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; >>>> dbrungard@att.com >>>> Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >>>> >>>> Is it not the case that the old LSP is broken? In which case it >>> needs >>>> to be cleaned up and re-signaled. >>>> >>>> Sent from my iPhone >>>> >>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf Of Adrian Farrel >>>>> Sent: Wednesday, August 01, 2012 11:02 AM >>>>> To: 'Ong, Lyndon'; ccamp@ietf.org >>>>> Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org; >>>>> dbrungard@att.com >>>>> Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >>>>> >>>>> Hello again, >>>>> >>>>>> Thank you for the fast evaluation of the errata. It sounds >> like >>>>>> the >>>>> correction that I >>>>>> suggested has ended up overspecifying the method to do >> reversion >>>> with >>>>>> full rerouting when it is very possible to support a form of >>>>> reversion >>>>>> that doesn't involve maintaining the old LSP. >>>>> >>>>> Right, I understand that you want to allow the option of >> retaining >>>>> the old working LSP. Also that you have no intention to remove >> the >>>>> option of removing the old working LSP. >>>>> >>>>>> From your response I believe that you do agree that it was not >>> the >>>>>> intent of >>>>> the >>>>>> original specification text to imply that reversion with full >>>>>> rerouting is not >>>>> allowed >>>>> >>>>> Definitely not the intent to imply that reversion with full >>>>> rerouting is not allowed. >>>>> Does the text say or even imply this? >>>>> >>>>>> (or to require that the old LSP always be torn down in full >>>>> rerouting) >>>>> >>>>> Also no intention to *require* the old LSP to be torn down. >>>>> My view is that the text is fully conformant with that. >>>>> I understand that the text does not make an explicit statement >>>>> of >>>> this. >>>>> >>>>>> so hopefully >>>>>> with some more discussion we can determine if there is >>>>>> anything that could be done to make that clearer. >>>>> >>>>> There is, of course, a lot that could be done to make it clearer. >>>>> But is there really a need? We discussed the point. We agreed it >>>>> is not prohibited in the RFC. Can we not just move on? >>>>> >>>>> Cheers, >>>>> Adrian >>>>>> -----Original Message----- >>>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>>>> Sent: Tuesday, July 31, 2012 6:28 PM >>>>>> To: ccamp@ietf.org >>>>>> Cc: jplang@ieee.org; yakov@juniper.net; >>>>> dimitri.papadimitriou@alcatel- >>>>>> lucent.be; stbryant@cisco.com; lberger@labn.net; >>>>>> dbrungard@att.com; Ong, Lyndon >>>>>> Subject: RE: [Technical Errata Reported] RFC4872 (3304) >>>>>> >>>>>> Hi CCAMP, >>>>>> >>>>>> I find that this erratum is raised against two sections one of >>>>>> which >>>>> I >>>>> supplied text >>>>>> for. If this get contentious, I will call on Stewart to call >>>>> consensus >>>>>> and >>>>> handle the >>>>>> Erratum in the system. >>>>>> >>>>>> In my opinion, this proposal goes further than the intention >>>>>> of the authors/WG >>>>> in >>>>>> publishing 4872. >>>>>> >>>>>> With regard to the proposed addition to section 11... >>>>>> The use of mb4b is already in scope. The existing text says >> "The >>>>>> new LSP resources can be established using the make-before- >> break >>>>>> mechanism," so there is no need to re-state "The new LSP can >>>>>> be established without tearing down >>>>> the >>>>>> old LSP". >>>>>> >>>>>> I think your concern here is whether the old LSP is ever torn >>> down. >>>> I >>>>>> think >>>>> that >>>>>> you are worried that if the old LSP is torn down, it might be >>>>>> impossible to >>>>> perform >>>>>> reversion because, after repair, an attempt to revert (also >>>>>> using >>>>>> mb4b) might >>>>> find >>>>>> that key resources have been "stolen" by some other LSP. I >> don't >>>>>> see this as >>>>> at all >>>>>> different from the issue of the protection LSP itself. That >>>>>> is, >>> it >>>> is >>>>>> of the >>>>> nature of >>>>>> LSP Rerouting as a protection mechanism that: >>>>>> a. protection may fail because of lack of resources b. >> reversion >>>>>> may fail >>>>> because >>>>>> of lack of resources >>>>>> >>>>>> *If* reversion is so important, I don't quite see why >> protection >>>>>> is not >>>>> important. >>>>>> If protection is important then you should be using a proper >>>>>> protection mechanism and not waiting for post facto rerouting. >>>>>> Furthermore, if you >>>>> require >>>>>> that the LSP be retained for restoration, why are you not >>>>>> using a protection mechanism? >>>>>> >>>>>> But the general paradigm here is that you are willing to use >> the >>>> best >>>>> available LSP >>>>>> when it is set up in the first place, the best available LSP >>>>>> when >>>> you >>>>>> re-route >>>>> after >>>>>> failure, and the best available LSP when you "revert". >>>>>> >>>>>> Lastly, it *does* remain an _option_ to retain the failed LSP >> in >>>>> order >>>>>> to >>>>> switch >>>>>> back. Nothing in the old text precludes that, although I >>>>>> understand that there >>>>> is >>>>>> an implication that it might be expected to be torn down. >>>>>> >>>>>> So I conclude that the proposed addition to section 12 is not >>> what >>>>> the >>>>>> authors/WG intended. >>>>>> >>>>>> We should discuss further. >>>>>> >>>>>> Adrian >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>>>> Sent: 31 July 2012 17:39 >>>>>>> To: jplang@ieee.org; yakov@juniper.net; >>>>>>> dimitri.papadimitriou@alcatel- lucent.be; >>>>>>> stbryant@cisco.com; adrian@olddog.co.uk; lberger@labn.net; >>>>>>> dbrungard@att.com >>>>>>> Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc- >> editor.org >>>>>>> Subject: [Technical Errata Reported] RFC4872 (3304) >>>>>>> >>>>>>> >>>>>>> The following errata report has been submitted for RFC4872, >>>>>>> "RSVP- >>>>> TE >>>>>>> Extensions in Support of End-to-End Generalized Multi- >> Protocol >>>>> Label >>>>>>> Switching (GMPLS) Recovery". >>>>>>> >>>>>>> -------------------------------------- >>>>>>> You may review the report below and at: >>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D330 >>>>>>> 4 >>>>>>> >>>>>>> -------------------------------------- >>>>>>> Type: Technical >>>>>>> Reported by: Lyndon Ong >>>>>>> >>>>>>> Section: 11 & 12 >>>>>>> >>>>>>> Original Text >>>>>>> ------------- >>>>>>> Section 11 says: >>>>>>> >>>>>>> >>>>>>> (Full) LSP rerouting will be initiated by the head-end >> node >>>> that >>>>> has >>>>>>> either detected the LSP failure or received a Notify >>>>>>> message >>>>> and/or a >>>>>>> PathErr message with the new error code/sub-code "Notify >>>>> Error/LSP >>>>>>> Locally Failed" for this LSP. The new LSP resources can >> be >>>>>>> established using the make-before-break mechanism, where >>>>>>> the >>>> new >>>>> LSP >>>>>>> is set up before the old LSP is torn down. This is done >> by >>>>> using the >>>>>>> mechanisms of the SESSION_ATTRIBUTE object and the >>>>>>> Shared- >>>>> Explicit >>>>>>> (SE) reservation style (see [RFC3209]). Both the new and >>> old >>>>> LSPs >>>>>>> can share resources at common nodes. >>>>>>> >>>>>>> Section 12 says: >>>>>>> >>>>>>> [No text on reversion for (full) LSP Rerouting.] >>>>>>> >>>>>>> Corrected Text >>>>>>> -------------- >>>>>>> Section 11 should say: >>>>>>> >>>>>>> >>>>>>> (Full) LSP rerouting will be initiated by the head-end >> node >>>> that >>>>> has >>>>>>> either detected the LSP failure or received a Notify >>>>>>> message >>>>> and/or a >>>>>>> PathErr message with the new error code/sub-code "Notify >>>>> Error/LSP >>>>>>> Locally Failed" for this LSP. The new LSP resources can >> be >>>>>>> established using the make-before-break mechanism, where >>>>>>> the >>>> new >>>>> LSP >>>>>>> is set up before the old LSP is torn down. This is done >> by >>>>> using the >>>>>>> mechanisms of the SESSION_ATTRIBUTE object and the >>>>>>> Shared- >>>>> Explicit >>>>>>> (SE) reservation style (see [RFC3209]). Both the new and >>> old >>>>> LSPs >>>>>>> can share resources at common nodes. The new LSP can be >>>>> established >>>>>>> without tearing down the old LSP in case of reversion >>>>>>> (see >>>>> section 12). >>>>>>> >>>>>>> Section 12 should say: >>>>>>> >>>>>>> For "(full) LSP Rerouting", reversion implies that the >>>>>>> old LSP >>>>> is not >>>>>>> torn down by the head-end node after the new LSP is >>>> established. >>>>> For >>>>>>> reversion, the head-end node re-activates the old LSP >> after >>>> this >>>>> has >>>>>>> recovered. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Notes >>>>>>> ----- >>>>>>> Current text in RFC 4872 describes reversion in the cases of >>> 1+1 >>>>>>> bidirectional Protection, 1:N Protection with Extra Traffic >>>>>>> and Rerouting Without Extra >>>>>> Traffic, >>>>>>> however it has no description of reversion with (Full) LSP >>>>> Rerouting. >>>>>>> For (full) LSP Rerouting, the description in Section 11 >>>>>>> instead implies that >>>>>> the old >>>>>>> LSP is torn down. This has led to some confusion as to >> whether >>>>>>> reversion with >>>>>>> (full) LSP Rerouting is allowed or not allowed by the RFC. >>>>>>> We believe this was >>>>>> not >>>>>>> intentional. The additions would make it clear that >>>>>>> reversion can >>>>> be >>>>>>> supported with (Full) LSP Rerouting. >>>>>>> >>>>>>> Instructions: >>>>>>> ------------- >>>>>>> This errata is currently posted as "Reported". If necessary, >>>> please >>>>>>> use "Reply All" to discuss whether it should be verified or >>>>> rejected. >>>>>>> When a decision is reached, the verifying party (IESG) can >> log >>>>>>> in >>>>> to >>>>>>> change the status and edit the report, if necessary. >>>>>>> >>>>>>> -------------------------------------- >>>>>>> RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) >>>>>>> -------------------------------------- >>>>>>> Title : RSVP-TE Extensions in Support of End- >> to- >>> End >>>>> Generalized >>>>>> Multi- >>>>>>> Protocol Label Switching (GMPLS) Recovery >>>>>>> Publication Date : May 2007 >>>>>>> Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. >>>>> Papadimitriou, Ed. >>>>>>> Category : PROPOSED STANDARD >>>>>>> Source : Common Control and Measurement Plane >>>>>>> Area : Routing >>>>>>> Stream : IETF >>>>>>> Verifying Party : IESG >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Thu Aug 2 11:03:03 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3091B11E818C for ; Thu, 2 Aug 2012 11:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.759 X-Spam-Level: X-Spam-Status: No, score=-4.759 tagged_above=-999 required=5 tests=[AWL=1.240, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhbLUmtNM7mR for ; Thu, 2 Aug 2012 11:03:01 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 210C411E80F5 for ; Thu, 2 Aug 2012 11:02:49 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUBrAxcGfUaFcm6JPo+TA8UScu9hdDGRt@postini.com; Thu, 02 Aug 2012 11:02:58 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 2 Aug 2012 11:01:15 -0700 From: John E Drake To: Rajan Rao Date: Thu, 2 Aug 2012 11:01:12 -0700 Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: Ac1w2M6uc4BWtT2CTVKt0wMjSCQvVQ== Message-ID: <45500ED4-5474-409A-AA03-5AF442808AA9@juniper.net> References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A5A8E93302@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A5A8E9337E@EMBX01-HQ.jnpr.net> <650AA355E323C34D9D4AAEED952E053D347EE404@SV-EXDB-PROD2.infinera.com> <5E893DB832F57341992548CDBB333163A5A8E93642@EMBX01-HQ.jnpr.net> <650AA355E323C34D9D4AAEED952E053D347EE4F1@SV-EXDB-PROD2.infinera.com> In-Reply-To: <650AA355E323C34D9D4AAEED952E053D347EE4F1@SV-EXDB-PROD2.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dimitri.papadimitriou@alcatel-lucent.be" , "ccamp@ietf.org" , "jplang@ieee.org" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:03:03 -0000 It also occurs to me that the text you cited, although problematic, clearly= addresses Lyndon's initial erratum. Sent from my iPhone On Aug 2, 2012, at 10:18 AM, "Rajan Rao" wrote: > John, > > I too agree that existing text from Section-12 (see below) is sufficient = as pointed by Zafar. The text below should also clarify your questions. > " > For "Rerouting without Extra-traffic" (including the shared recovery > case), reversion implies that the formerly working LSP has not been > torn down by the head-end node upon PathErr message reception, i.e., > the head-end node kept refreshing the working LSP under failure > condition. This ensures that the exact same resources are retrieved > after reversion switching (except if the working LSP required re- > signaling). > " > > Thanks > Rajan > > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, August 02, 2012 9:52 AM > To: Rajan Rao; Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, Lyndon'; ccam= p@ietf.org > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; dbrungard@a= tt.com > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > Rajan, > > Due to link and/or node failure the resources of a failed LSP may not be = maintained. Further, at any time a higher priority LSP may be established = that pre-empts the resources of a failed LSP. This is sort of basic. > > Also, because of this, I am not sure what the phrase 'continuous monitori= ng of failed path is necessary' means or how you intend to accomplish this = other than by attempting to re-establish the failed LSP along its original = path. > > Finally, and most importantly, as I indicated yesterday, I don't see anyt= hing wrong with the existing text. > > Thanks, > > John > > Sent from my iPhone > >> -----Original Message----- >> From: Rajan Rao [mailto:rrao@infinera.com] >> Sent: Thursday, August 02, 2012 9:21 AM >> To: John E Drake; Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, >> Lyndon'; ccamp@ietf.org >> Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; >> dbrungard@att.com >> Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >> >> John, >> >> Revertive restoration requires keeping original path because >> continuous monitoring of failed path is necessary for revertive >> operation upon recovery. >> >> Thanks >> Rajan >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of John E Drake >> Sent: Wednesday, August 01, 2012 5:54 PM >> To: Zafar Ali (zali); adrian@olddog.co.uk; 'Ong, Lyndon'; >> ccamp@ietf.org >> Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; >> dbrungard@att.com >> Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >> >> You can't keep the original, broken LSP around because it no longer >> has e2e committed resources. The best you can do is clean it up and >> try to re-instantiate it on its original path. >> >> Sent from my iPhone >> >>> -----Original Message----- >>> From: Zafar Ali (zali) [mailto:zali@cisco.com] >>> Sent: Wednesday, August 01, 2012 5:48 PM >>> To: John E Drake; adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org >>> Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; >>> dbrungard@att.com >>> Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >>> >>> Hi John- >>> >>> Please see my response to Adrian's email for the use case for >>> keeping the original LSP around during failure. >>> >>> Thanks >>> >>> Regards ... Zafar >>> >>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>> Behalf >>>> Of John E Drake >>>> Sent: Wednesday, August 01, 2012 7:49 PM >>>> To: adrian@olddog.co.uk; 'Ong, Lyndon'; ccamp@ietf.org >>>> Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; >>>> dbrungard@att.com >>>> Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >>>> >>>> Is it not the case that the old LSP is broken? In which case it >>> needs >>>> to be cleaned up and re-signaled. >>>> >>>> Sent from my iPhone >>>> >>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf Of Adrian Farrel >>>>> Sent: Wednesday, August 01, 2012 11:02 AM >>>>> To: 'Ong, Lyndon'; ccamp@ietf.org >>>>> Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org; >>>>> dbrungard@att.com >>>>> Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >>>>> >>>>> Hello again, >>>>> >>>>>> Thank you for the fast evaluation of the errata. It sounds >> like >>>>>> the >>>>> correction that I >>>>>> suggested has ended up overspecifying the method to do >> reversion >>>> with >>>>>> full rerouting when it is very possible to support a form of >>>>> reversion >>>>>> that doesn't involve maintaining the old LSP. >>>>> >>>>> Right, I understand that you want to allow the option of >> retaining >>>>> the old working LSP. Also that you have no intention to remove >> the >>>>> option of removing the old working LSP. >>>>> >>>>>> From your response I believe that you do agree that it was not >>> the >>>>>> intent of >>>>> the >>>>>> original specification text to imply that reversion with full >>>>>> rerouting is not >>>>> allowed >>>>> >>>>> Definitely not the intent to imply that reversion with full >>>>> rerouting is not allowed. >>>>> Does the text say or even imply this? >>>>> >>>>>> (or to require that the old LSP always be torn down in full >>>>> rerouting) >>>>> >>>>> Also no intention to *require* the old LSP to be torn down. >>>>> My view is that the text is fully conformant with that. >>>>> I understand that the text does not make an explicit statement >>>>> of >>>> this. >>>>> >>>>>> so hopefully >>>>>> with some more discussion we can determine if there is >>>>>> anything that could be done to make that clearer. >>>>> >>>>> There is, of course, a lot that could be done to make it clearer. >>>>> But is there really a need? We discussed the point. We agreed it >>>>> is not prohibited in the RFC. Can we not just move on? >>>>> >>>>> Cheers, >>>>> Adrian >>>>>> -----Original Message----- >>>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>>>> Sent: Tuesday, July 31, 2012 6:28 PM >>>>>> To: ccamp@ietf.org >>>>>> Cc: jplang@ieee.org; yakov@juniper.net; >>>>> dimitri.papadimitriou@alcatel- >>>>>> lucent.be; stbryant@cisco.com; lberger@labn.net; >>>>>> dbrungard@att.com; Ong, Lyndon >>>>>> Subject: RE: [Technical Errata Reported] RFC4872 (3304) >>>>>> >>>>>> Hi CCAMP, >>>>>> >>>>>> I find that this erratum is raised against two sections one of >>>>>> which >>>>> I >>>>> supplied text >>>>>> for. If this get contentious, I will call on Stewart to call >>>>> consensus >>>>>> and >>>>> handle the >>>>>> Erratum in the system. >>>>>> >>>>>> In my opinion, this proposal goes further than the intention >>>>>> of the authors/WG >>>>> in >>>>>> publishing 4872. >>>>>> >>>>>> With regard to the proposed addition to section 11... >>>>>> The use of mb4b is already in scope. The existing text says >> "The >>>>>> new LSP resources can be established using the make-before- >> break >>>>>> mechanism," so there is no need to re-state "The new LSP can >>>>>> be established without tearing down >>>>> the >>>>>> old LSP". >>>>>> >>>>>> I think your concern here is whether the old LSP is ever torn >>> down. >>>> I >>>>>> think >>>>> that >>>>>> you are worried that if the old LSP is torn down, it might be >>>>>> impossible to >>>>> perform >>>>>> reversion because, after repair, an attempt to revert (also >>>>>> using >>>>>> mb4b) might >>>>> find >>>>>> that key resources have been "stolen" by some other LSP. I >> don't >>>>>> see this as >>>>> at all >>>>>> different from the issue of the protection LSP itself. That >>>>>> is, >>> it >>>> is >>>>>> of the >>>>> nature of >>>>>> LSP Rerouting as a protection mechanism that: >>>>>> a. protection may fail because of lack of resources b. >> reversion >>>>>> may fail >>>>> because >>>>>> of lack of resources >>>>>> >>>>>> *If* reversion is so important, I don't quite see why >> protection >>>>>> is not >>>>> important. >>>>>> If protection is important then you should be using a proper >>>>>> protection mechanism and not waiting for post facto rerouting. >>>>>> Furthermore, if you >>>>> require >>>>>> that the LSP be retained for restoration, why are you not >>>>>> using a protection mechanism? >>>>>> >>>>>> But the general paradigm here is that you are willing to use >> the >>>> best >>>>> available LSP >>>>>> when it is set up in the first place, the best available LSP >>>>>> when >>>> you >>>>>> re-route >>>>> after >>>>>> failure, and the best available LSP when you "revert". >>>>>> >>>>>> Lastly, it *does* remain an _option_ to retain the failed LSP >> in >>>>> order >>>>>> to >>>>> switch >>>>>> back. Nothing in the old text precludes that, although I >>>>>> understand that there >>>>> is >>>>>> an implication that it might be expected to be torn down. >>>>>> >>>>>> So I conclude that the proposed addition to section 12 is not >>> what >>>>> the >>>>>> authors/WG intended. >>>>>> >>>>>> We should discuss further. >>>>>> >>>>>> Adrian >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>>>> Sent: 31 July 2012 17:39 >>>>>>> To: jplang@ieee.org; yakov@juniper.net; >>>>>>> dimitri.papadimitriou@alcatel- lucent.be; >>>>>>> stbryant@cisco.com; adrian@olddog.co.uk; lberger@labn.net; >>>>>>> dbrungard@att.com >>>>>>> Cc: lyong@ciena.com; ccamp@ietf.org; rfc-editor@rfc- >> editor.org >>>>>>> Subject: [Technical Errata Reported] RFC4872 (3304) >>>>>>> >>>>>>> >>>>>>> The following errata report has been submitted for RFC4872, >>>>>>> "RSVP- >>>>> TE >>>>>>> Extensions in Support of End-to-End Generalized Multi- >> Protocol >>>>> Label >>>>>>> Switching (GMPLS) Recovery". >>>>>>> >>>>>>> -------------------------------------- >>>>>>> You may review the report below and at: >>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D4872&eid=3D330 >>>>>>> 4 >>>>>>> >>>>>>> -------------------------------------- >>>>>>> Type: Technical >>>>>>> Reported by: Lyndon Ong >>>>>>> >>>>>>> Section: 11 & 12 >>>>>>> >>>>>>> Original Text >>>>>>> ------------- >>>>>>> Section 11 says: >>>>>>> >>>>>>> >>>>>>> (Full) LSP rerouting will be initiated by the head-end >> node >>>> that >>>>> has >>>>>>> either detected the LSP failure or received a Notify >>>>>>> message >>>>> and/or a >>>>>>> PathErr message with the new error code/sub-code "Notify >>>>> Error/LSP >>>>>>> Locally Failed" for this LSP. The new LSP resources can >> be >>>>>>> established using the make-before-break mechanism, where >>>>>>> the >>>> new >>>>> LSP >>>>>>> is set up before the old LSP is torn down. This is done >> by >>>>> using the >>>>>>> mechanisms of the SESSION_ATTRIBUTE object and the >>>>>>> Shared- >>>>> Explicit >>>>>>> (SE) reservation style (see [RFC3209]). Both the new and >>> old >>>>> LSPs >>>>>>> can share resources at common nodes. >>>>>>> >>>>>>> Section 12 says: >>>>>>> >>>>>>> [No text on reversion for (full) LSP Rerouting.] >>>>>>> >>>>>>> Corrected Text >>>>>>> -------------- >>>>>>> Section 11 should say: >>>>>>> >>>>>>> >>>>>>> (Full) LSP rerouting will be initiated by the head-end >> node >>>> that >>>>> has >>>>>>> either detected the LSP failure or received a Notify >>>>>>> message >>>>> and/or a >>>>>>> PathErr message with the new error code/sub-code "Notify >>>>> Error/LSP >>>>>>> Locally Failed" for this LSP. The new LSP resources can >> be >>>>>>> established using the make-before-break mechanism, where >>>>>>> the >>>> new >>>>> LSP >>>>>>> is set up before the old LSP is torn down. This is done >> by >>>>> using the >>>>>>> mechanisms of the SESSION_ATTRIBUTE object and the >>>>>>> Shared- >>>>> Explicit >>>>>>> (SE) reservation style (see [RFC3209]). Both the new and >>> old >>>>> LSPs >>>>>>> can share resources at common nodes. The new LSP can be >>>>> established >>>>>>> without tearing down the old LSP in case of reversion >>>>>>> (see >>>>> section 12). >>>>>>> >>>>>>> Section 12 should say: >>>>>>> >>>>>>> For "(full) LSP Rerouting", reversion implies that the >>>>>>> old LSP >>>>> is not >>>>>>> torn down by the head-end node after the new LSP is >>>> established. >>>>> For >>>>>>> reversion, the head-end node re-activates the old LSP >> after >>>> this >>>>> has >>>>>>> recovered. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Notes >>>>>>> ----- >>>>>>> Current text in RFC 4872 describes reversion in the cases of >>> 1+1 >>>>>>> bidirectional Protection, 1:N Protection with Extra Traffic >>>>>>> and Rerouting Without Extra >>>>>> Traffic, >>>>>>> however it has no description of reversion with (Full) LSP >>>>> Rerouting. >>>>>>> For (full) LSP Rerouting, the description in Section 11 >>>>>>> instead implies that >>>>>> the old >>>>>>> LSP is torn down. This has led to some confusion as to >> whether >>>>>>> reversion with >>>>>>> (full) LSP Rerouting is allowed or not allowed by the RFC. >>>>>>> We believe this was >>>>>> not >>>>>>> intentional. The additions would make it clear that >>>>>>> reversion can >>>>> be >>>>>>> supported with (Full) LSP Rerouting. >>>>>>> >>>>>>> Instructions: >>>>>>> ------------- >>>>>>> This errata is currently posted as "Reported". If necessary, >>>> please >>>>>>> use "Reply All" to discuss whether it should be verified or >>>>> rejected. >>>>>>> When a decision is reached, the verifying party (IESG) can >> log >>>>>>> in >>>>> to >>>>>>> change the status and edit the report, if necessary. >>>>>>> >>>>>>> -------------------------------------- >>>>>>> RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) >>>>>>> -------------------------------------- >>>>>>> Title : RSVP-TE Extensions in Support of End- >> to- >>> End >>>>> Generalized >>>>>> Multi- >>>>>>> Protocol Label Switching (GMPLS) Recovery >>>>>>> Publication Date : May 2007 >>>>>>> Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. >>>>> Papadimitriou, Ed. >>>>>>> Category : PROPOSED STANDARD >>>>>>> Source : Common Control and Measurement Plane >>>>>>> Area : Routing >>>>>>> Stream : IETF >>>>>>> Verifying Party : IESG >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp From adrian@olddog.co.uk Thu Aug 2 13:56:21 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F84911E80FE for ; Thu, 2 Aug 2012 13:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIhvd-yDec06 for ; Thu, 2 Aug 2012 13:56:20 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 61F9E11E80FD for ; Thu, 2 Aug 2012 13:56:20 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q72KuACB001085; Thu, 2 Aug 2012 21:56:10 +0100 Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q72Ku29m001065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 21:56:07 +0100 From: "Adrian Farrel" To: "'Zafar Ali \(zali\)'" , References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> In-Reply-To: Date: Thu, 2 Aug 2012 21:56:00 +0100 Message-ID: <01cf01cd70f1$3e459830$bad0c890$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJG0ydQ2iZ1PPA/LaXiFWLC86ukfAJY9gBGAdMGi++WMtq4MA== Content-Language: en-gb Cc: jplang@ieee.org, dimitri.papadimitriou@alcatel-lucent.be, dbrungard@att.com Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 20:56:21 -0000 Zafar, [snip] > > But the general paradigm here is that you are willing to use the best > > available LSP when it is set up in the first place, the best available LSP > > when you re-route after failure, and the best available LSP when you > > "revert". > > The original paths in the network may be explicit (with mix of dynamic for other > services). In this case, service of a LSP may not come back to the original explicit > paths if some other (dynamic) LSP "stole" the resources for the failed working > LSP (if resources are released during a failure) - as you noted above. Hmmm. You are saying that when the initial LSP is established it is OK to use and ERO to "force" it down the path you want. You are not saying that the network resources must be pre-reserved for the initial LSP. Why is it not good enough to use an ERO to "force" reversion? [BTW: the discussion of whether you might want to do it (that we are having now) is orthogonal to whether it is possible. I have no issue that it is possible, and I don't think any changes are needed to any documents to enable it or to say that it is possible.] Adrian From adrian@olddog.co.uk Thu Aug 2 14:08:25 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFA211E814B for ; Thu, 2 Aug 2012 14:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4xf8vi6PoFg for ; Thu, 2 Aug 2012 14:08:24 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id E5FAC11E814E for ; Thu, 2 Aug 2012 14:08:23 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q72L8Mbf012920 for ; Thu, 2 Aug 2012 22:08:22 +0100 Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q72L8FWm012888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 2 Aug 2012 22:08:21 +0100 From: "Adrian Farrel" To: Date: Thu, 2 Aug 2012 22:08:14 +0100 Message-ID: <01d101cd70f2$f2959be0$d7c0d3a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1w8rAv+6e8rpIvRn6nPAgrl9BHCw== Content-Language: en-gb Subject: [CCAMP] What is an Erratum? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:08:25 -0000 Hi, There seems to be some doubt about what to use an Erratum for. http://www.rfc-editor.org/status_type_desc.html shows the two types of Erratum: Technical: Error in the technical content (Note that changes in the usage of RFC 2119 keywords are considered technical.) Editorial: A spelling, grammar, punctuation, or syntax error that does not affect the technical meaning. IMHO the issue for RFC 4872 does not fall into either category. You have some proposed additional / revised text that you believe would make the document easier to understand, but which (if captured correctly) would not change the technical meaning. That is not an Editorial Erratum. We fix this type of error by capturing the understanding on the mailing list, or by writing an Informational RFC that adds an explanation. OTOH, if the belief is that there is an error in the technical content of the document such that the proposed change will change the technical consequences of the document, then this also does not feel into either category since it is not a documentation error, but a content error. We fix this type of error by writing an Update or by rev'ing the RFC. http://www.ietf.org/iesg/statement/errata-processing.html gives further guidelines about how the IESG will treat errata that it receives. Lastly, you might want to catch up with the thread "RFC Errata: when to file, and when not to" on the IETF Discussion list. The observation there is that the Errata System is not a place to raise tickets for things to be included in future revisions. Your working group has access to a trouble ticket system for that type of thing. Cheers, Adrian From zali@cisco.com Thu Aug 2 14:12:47 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C91211E8177 for ; Thu, 2 Aug 2012 14:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEgq9WMxnSgl for ; Thu, 2 Aug 2012 14:12:46 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 205DF11E8174 for ; Thu, 2 Aug 2012 14:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zali@cisco.com; l=2541; q=dns/txt; s=iport; t=1343941966; x=1345151566; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6LW/AeApnxl6y3ecbHo5JVBflLi0JuaToQQjMt1Emdk=; b=mK8CXrkr+JIJmIHg67kL4NbT8LaepWqeeE8/i2zjWbA+GrRkcWtsDkfh bZAaWT4pHm4PdDGnwwkrXUIG9Udaq+IXFh9vU33qo31pSKnlNrU1t16ko /dqk3jPa3VA7tbWr/ZpKJ2Q1REAPz/oEIBo6knmuEgs58LENT2MhnK/S2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKPrGlCtJXG8/2dsb2JhbABFuRuBB4IgAQEBBBIBJz8MBAIBCBEEAQELFAkHMhQJCAIEAQ0FCBqHa5x6oEeLSoYkYAOjboFmgl8 X-IronPort-AV: E=Sophos;i="4.77,703,1336348800"; d="scan'208";a="108000030" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 02 Aug 2012 21:12:44 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q72LChQq029870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 21:12:43 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.69]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 16:12:43 -0500 From: "Zafar Ali (zali)" To: "adrian@olddog.co.uk" , "ccamp@ietf.org" Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNbzsfFZzh5ZC7+kKOIa930++KWJdEfyWAgAEr+aCAAayuAP//roTQ Date: Thu, 2 Aug 2012 21:12:43 +0000 Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <01cf01cd70f1$3e459830$bad0c890$@olddog.co.uk> In-Reply-To: <01cf01cd70f1$3e459830$bad0c890$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.60] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.000 x-tm-as-result: No--50.438800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jplang@ieee.org" , "dimitri.papadimitriou@alcatel-lucent.be" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:12:47 -0000 Hi Adrian-=20 Please see in-line.=20 Thanks Regards ... Zafar=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Thursday, August 02, 2012 4:56 PM > To: Zafar Ali (zali); ccamp@ietf.org > Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org; > dbrungard@att.com > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >=20 > Zafar, >=20 > [snip] >=20 > > > But the general paradigm here is that you are willing to use the > best > > > available LSP when it is set up in the first place, the best > available LSP > > > when you re-route after failure, and the best available LSP when you > > > "revert". > > > > The original paths in the network may be explicit (with mix of dynamic > for > other > > services). In this case, service of a LSP may not come back to the > original > explicit > > paths if some other (dynamic) LSP "stole" the resources for the failed > working > > LSP (if resources are released during a failure) - as you noted above. >=20 > Hmmm. >=20 > You are saying that when the initial LSP is established it is OK to use > and ERO > to "force" it down the path you want. You are not saying that the > network > resources must be pre-reserved for the initial LSP. >=20 > Why is it not good enough to use an ERO to "force" reversion? >=20 I did not understand what you meant by "use an ERO to "force" reversion". T= he issue in my mind is as follows:=20 1. We are at time t0.=20 2. Working LSP is setup on THE nominal path (P) with setup/ holder priority= (s,h). For simplicity assume P is explicitly configured by SP.=20 3. At time t1 > t0, a resource, say link L fails, along the nominal Path (P= ).=20 4. Ingress tears down working LSP.=20 5. A restore LSP or protecting LSP starts to carry traffic.=20 6. Link L comes back up at t2 > t1.=20 7. Some other LSP(s) with setup/ hold priority better than working LSP setu= p/ holder priority (s,h) claims resources from L.=20 8. Nominal Path P is no longer available for working LSP and this is the on= ly Path SP wants the working LSP to take.=20 9. Reversion cannot be applied as working LSP stays down.=20 Thanks Regards... Zafar=20 > [BTW: the discussion of whether you might want to do it (that we are > having now) > is orthogonal to whether it is possible. I have no issue that it is > possible, > and I don't think any changes are needed to any documents to enable it > or to say > that it is possible.] >=20 > Adrian From adrian@olddog.co.uk Thu Aug 2 14:33:23 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1003011E808E for ; Thu, 2 Aug 2012 14:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZok5p4AnYxr for ; Thu, 2 Aug 2012 14:33:22 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id DEC3F21F89D9 for ; Thu, 2 Aug 2012 14:33:21 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q72LWg32004269; Thu, 2 Aug 2012 22:32:42 +0100 Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q72LWZZ0004232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 22:32:39 +0100 From: "Adrian Farrel" To: "'Zafar Ali \(zali\)'" , References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <01cf01cd70f1$3e459830$bad0c890$@olddog.co.uk> In-Reply-To: Date: Thu, 2 Aug 2012 22:32:34 +0100 Message-ID: <01de01cd70f6$58503690$08f0a3b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJG0ydQ2iZ1PPA/LaXiFWLC86ukfAJY9gBGAdMGi+8Ce6l5JwH40YBglg89ZyA= Content-Language: en-gb Cc: jplang@ieee.org, dimitri.papadimitriou@alcatel-lucent.be, dbrungard@att.com Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:33:23 -0000 Oh dear. First, let me re-assert... The discussion of whether you might want to do it (that we are having now) is orthogonal to whether it is possible. I have no issue that it is possible, and I don't think any changes are needed to any documents to enable it or to say that it is possible. Now to your details... > 1. We are at time t0. > 2. Working LSP is setup on THE nominal path (P) with setup/ holder > priority (s,h). For simplicity assume P is explicitly configured by SP. > 3. At time t1 > t0, a resource, say link L fails, along the nominal Path (P). > 4. Ingress tears down working LSP. Better not? You do this and you are not doing mb4b. > 5. A restore LSP or protecting LSP starts to carry traffic. > 6. Link L comes back up at t2 > t1. > 7. Some other LSP(s) with setup/ hold priority better than working > LSP setup/holder priority (s,h) claims resources from L. > 8. Nominal Path P is no longer available for working LSP and this is the > only Path SP wants the working LSP to take. If the setup/holding priorities are higher, then these new LSPs would take the resources in any case. Probably, the interesting case for you is that the new LSPs have identical (s,h). > 9. Reversion cannot be applied as working LSP stays down. Correct. Now consider... 1a. We are at time t0. 2a. Some other LSP(s) with setup/ hold priority better than working LSP setup/holder priority (s,h) claims resources from L. 3a. Working LSP is attempted on THE nominal path (P) with setup/ holder priority (s,h). 4a. Nominal Path P is no longer available for working LSP and this is the only Path SP wants the working LSP to take. 5a. Service cannot be set up as working LSP stays down. My point being: when you decided that you did not want to use protection, you signed up to a particular service level. Of course you would like to apply reversion, but it is not essential. Alternatively, when you decided to allow other LSPs to be able to use "your" network resources, you signed up to a way of operating your network where that can happen. A From prvs=3561bf1d5b=lyong@ciena.com Thu Aug 2 15:18:43 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AC021E80CB for ; Thu, 2 Aug 2012 15:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.062 X-Spam-Level: X-Spam-Status: No, score=-102.062 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HQNIugysRry for ; Thu, 2 Aug 2012 15:18:42 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 764C821E80C9 for ; Thu, 2 Aug 2012 15:18:42 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q72MG8cq009688; Thu, 2 Aug 2012 18:18:33 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 16g11gr63d-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 02 Aug 2012 18:18:32 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT01.ciena.com (10.4.140.138) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 2 Aug 2012 18:18:33 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Thu, 2 Aug 2012 18:18:33 -0400 From: "Ong, Lyndon" To: "adrian@olddog.co.uk" , "'Zafar Ali (zali)'" , "ccamp@ietf.org" Date: Thu, 2 Aug 2012 18:18:28 -0400 Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQJG0ydQ2iZ1PPA/LaXiFWLC86ukfAJY9gBGAdMGi+8Ce6l5JwH40YBglg89ZyCAAAst0A== Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <01cf01cd70f1$3e459830$bad0c890$@olddog.co.uk> <01de01cd70f6$58503690$08f0a3b0$@olddog.co.uk> In-Reply-To: <01de01cd70f6$58503690$08f0a3b0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-19082.000 X-TM-AS-Result: No--21.462000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-02_08:2012-08-02, 2012-08-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208020262 Cc: "jplang@ieee.org" , "dimitri.papadimitriou@alcatel-lucent.be" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:18:43 -0000 Hi Adrian, I'm glad that you say that this (LSP rerouting with reversion) is possible = within the existing text, hopefully we can all accept this as conclusive. Probably this issue would have been clearer if there was a formal definitio= n of "implies" in RFC 2119! Cheers, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of A= drian Farrel Sent: Thursday, August 02, 2012 2:33 PM To: 'Zafar Ali (zali)'; ccamp@ietf.org Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; dbrungard@att= .com Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Oh dear. First, let me re-assert... The discussion of whether you might want to do it (that we are having now) = is orthogonal to whether it is possible. I have no issue that it is possibl= e, and I don't think any changes are needed to any documents to enable it o= r to say that it is possible.=20 Now to your details... > 1. We are at time t0. > 2. Working LSP is setup on THE nominal path (P) with setup/ holder=20 > priority (s,h). For simplicity assume P is explicitly configured by SP. > 3. At time t1 > t0, a resource, say link L fails, along the nominal Path = (P). > 4. Ingress tears down working LSP. Better not? You do this and you are not doing mb4b. > 5. A restore LSP or protecting LSP starts to carry traffic. > 6. Link L comes back up at t2 > t1. > 7. Some other LSP(s) with setup/ hold priority better than working LSP=20 > setup/holder priority (s,h) claims resources from L. > 8. Nominal Path P is no longer available for working LSP and this is=20 > the only Path SP wants the working LSP to take. If the setup/holding priorities are higher, then these new LSPs would take = the resources in any case. Probably, the interesting case for you is that the new LSPs have identical = (s,h). > 9. Reversion cannot be applied as working LSP stays down. Correct. Now consider... 1a. We are at time t0. 2a. Some other LSP(s) with setup/ hold priority better than working LSP set= up/holder priority (s,h) claims resources from L. 3a. Working LSP is attempted on THE nominal path (P) with setup/ holder pri= ority (s,h). 4a. Nominal Path P is no longer available for working LSP and this is the o= nly Path SP wants the working LSP to take. 5a. Service cannot be set up as working LSP stays down. My point being: when you decided that you did not want to use protection, y= ou signed up to a particular service level. Of course you would like to app= ly reversion, but it is not essential. Alternatively, when you decided to allow other LSPs to be able to use "your= " network resources, you signed up to a way of operating your network where t= hat can happen. A _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From adrian@olddog.co.uk Thu Aug 2 15:32:10 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10E821E8091 for ; Thu, 2 Aug 2012 15:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vHAY9P0dAb1 for ; Thu, 2 Aug 2012 15:32:09 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1F35D21E8090 for ; Thu, 2 Aug 2012 15:32:08 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q72MVXGc001155; Thu, 2 Aug 2012 23:31:33 +0100 Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q72MVPBf001120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 23:31:29 +0100 From: "Adrian Farrel" To: "'Ong, Lyndon'" , , "'Zafar Ali \(zali\)'" , References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <01cf01cd70f1$3e459830$bad0c890$@olddog.co.uk> <01de01cd70f6$58503690$08f0a3b0$@olddog.co.uk> In-Reply-To: Date: Thu, 2 Aug 2012 23:31:23 +0100 Message-ID: <020c01cd70fe$91238280$b36a8780$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJG0ydQ2iZ1PPA/LaXiFWLC86ukfAJY9gBGAdMGi+8Ce6l5JwH40YBgAXoz0+ACK6yFppXyI+Sg Content-Language: en-gb Cc: jplang@ieee.org, dimitri.papadimitriou@alcatel-lucent.be, dbrungard@att.com Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:32:10 -0000 Lyndon, That all depends on what you mean by "in". A > -----Original Message----- > From: Ong, Lyndon [mailto:Lyong@ciena.com] > Sent: 02 August 2012 23:18 > To: adrian@olddog.co.uk; 'Zafar Ali (zali)'; ccamp@ietf.org > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > dbrungard@att.com > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > Hi Adrian, > > I'm glad that you say that this (LSP rerouting with reversion) is possible within the > existing text, hopefully we can all accept this as conclusive. > Probably this issue would have been clearer if there was a formal definition of > "implies" in RFC 2119! > > > Cheers, > > Lyndon > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: Thursday, August 02, 2012 2:33 PM > To: 'Zafar Ali (zali)'; ccamp@ietf.org > Cc: jplang@ieee.org; dimitri.papadimitriou@alcatel-lucent.be; > dbrungard@att.com > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) > > Oh dear. > > First, let me re-assert... > > The discussion of whether you might want to do it (that we are having now) is > orthogonal to whether it is possible. I have no issue that it is possible, and I don't > think any changes are needed to any documents to enable it or to say that it is > possible. > > > Now to your details... > > > 1. We are at time t0. > > 2. Working LSP is setup on THE nominal path (P) with setup/ holder > > priority (s,h). For simplicity assume P is explicitly configured by SP. > > 3. At time t1 > t0, a resource, say link L fails, along the nominal Path (P). > > 4. Ingress tears down working LSP. > > Better not? > You do this and you are not doing mb4b. > > > 5. A restore LSP or protecting LSP starts to carry traffic. > > 6. Link L comes back up at t2 > t1. > > 7. Some other LSP(s) with setup/ hold priority better than working LSP > > setup/holder priority (s,h) claims resources from L. > > 8. Nominal Path P is no longer available for working LSP and this is > > the only Path SP wants the working LSP to take. > > If the setup/holding priorities are higher, then these new LSPs would take the > resources in any case. > Probably, the interesting case for you is that the new LSPs have identical (s,h). > > > 9. Reversion cannot be applied as working LSP stays down. > > Correct. > > Now consider... > > 1a. We are at time t0. > 2a. Some other LSP(s) with setup/ hold priority better than working LSP > setup/holder priority (s,h) claims resources from L. > 3a. Working LSP is attempted on THE nominal path (P) with setup/ holder priority > (s,h). > 4a. Nominal Path P is no longer available for working LSP and this is the only Path > SP wants the working LSP to take. > 5a. Service cannot be set up as working LSP stays down. > > My point being: when you decided that you did not want to use protection, you > signed up to a particular service level. Of course you would like to apply > reversion, but it is not essential. > > Alternatively, when you decided to allow other LSPs to be able to use "your" > network resources, you signed up to a way of operating your network where that > can happen. > > A > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From julien.meuric@orange.com Thu Aug 2 16:28:22 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CF611E81CB for ; Thu, 2 Aug 2012 16:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.062 X-Spam-Level: X-Spam-Status: No, score=-6.062 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJKn493h27ng for ; Thu, 2 Aug 2012 16:28:22 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id A0EB611E81C5 for ; Thu, 2 Aug 2012 16:28:21 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CE332E30252; Fri, 3 Aug 2012 01:30:07 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id C1001E30251; Fri, 3 Aug 2012 01:30:07 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Aug 2012 01:28:20 +0200 Received: from [10.193.116.28] ([10.193.116.28]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Aug 2012 01:28:19 +0200 Message-ID: <501B0D10.5070702@orange.com> Date: Fri, 03 Aug 2012 01:28:16 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Papadimitriou, Dimitri (Dimitri)" References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <03ea01cd700f$bdbdb800$39392800$@olddog.co.uk> <5019A35A.7090906@labn.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Aug 2012 23:28:19.0829 (UTC) FILETIME=[8034AA50:01CD7106] Cc: "ccamp@ietf.org" , "jplang@ieee.org" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:28:23 -0000 Hi Dimitri. The initial trigger of the discussion has been resolved, but I wanted to comment your introspection below. Whether it is revertive or not (as said by Zafar), LSP rerouting "increases recovery time" with respect to 1+1 protection, but *decreases* resource consumption with respect to 1+1. Thus the rationale for LSP rerouting at large. Resource consumption increases only (slightly) when you compare non-revertive rerouting with revertive rerouting. This over-consumption is only true during failure time, which is not supposed to be a long situation. Minimizing this short-life over-consumption is usually not a requirement, while reversion (very) often is. My 2 (Canadian) cents, Julien Le 02/08/2012 17:24, Papadimitriou, Dimitri (Dimitri) a écrit : > I miss the rationales for a "scenario" that increases recovery time*and* resource consumption. From zhang.fei3@zte.com.cn Fri Aug 3 01:38:23 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9E121F8D64 for ; Fri, 3 Aug 2012 01:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.291 X-Spam-Level: X-Spam-Status: No, score=-99.291 tagged_above=-999 required=5 tests=[AWL=2.547, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-oojfYjkaHX for ; Fri, 3 Aug 2012 01:38:23 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id B536A21F8D65 for ; Fri, 3 Aug 2012 01:38:22 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 10723473195744; Fri, 3 Aug 2012 16:26:59 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 26282.4555706507; Fri, 3 Aug 2012 16:38:18 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q738c6X1000914; Fri, 3 Aug 2012 16:38:06 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) To: Lou Berger MIME-Version: 1.0 X-KeepSent: 4C60DE0A:448BA6CC-48257A4F:000CAF72; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 3 Aug 2012 16:37:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-03 16:37:57, Serialize complete at 2012-08-03 16:37:57 Content-Type: multipart/alternative; boundary="=_alternative 002F67E248257A4F_=" X-MAIL: mse01.zte.com.cn q738c6X1000914 Cc: venkat.mahalingams@gmail.com, ccamp@ietf.org Subject: [CCAMP] Request for comments: the next step about the draft draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 08:38:23 -0000 This is a multipart message in MIME format. --=_alternative 002F67E248257A4F_= Content-Type: text/plain; charset="US-ASCII" Hi Lou Thanks you for your suggestion in the merging the solution into the existing WG documents to push this work forward. :) IMHO, there are three potential WG documents, like (1) draft-ietf-ccamp-assoc-ext-03.txt This draft is now in IESG processing, which defines the extensions of the Association object, and is irrelevant with the specific association types. (2) draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08 The proposed text can be added in section 3.2, a new TLV or the Association object with the defined new association type, which carring back the Z9_tunnel_num in the Resv message, needs to be defined there. This draft is WG last call, and I have sent out the corresponding comments, hope to hear the authors' opinion. (3)draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp If the proposed texts are added in this draft, the subject needs to be enlarged to cover both the associated and corouted bidirectional LSPs. Maybe the first step is to determine which draft is the better choice for merging, then we will submit the proposed texts. Any WG's feedbacks are welcome Best regards Fei --=_alternative 002F67E248257A4F_= Content-Type: text/html; charset="US-ASCII"
Hi Lou

Thanks you for your suggestion in the merging the solution into the existing WG documents to push this work forward. :)

IMHO, there are three potential WG documents, like

(1) draft-ietf-ccamp-assoc-ext-03.txt

This draft is now in IESG processing, which defines the extensions of the Association object, and is irrelevant with the specific association types.

(2) draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08
The proposed text can be added in section 3.2, a new TLV or the Association object with the defined new association type, which carring back the Z9_tunnel_num in the Resv message, needs to be defined there. This draft is WG last call, and I have sent out the corresponding comments, hope to hear the authors' opinion.

(3)draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp  
If the proposed texts are added in this draft, the subject needs to be enlarged to cover both the associated and corouted bidirectional LSPs.

Maybe the first step is to determine which draft is the better choice for merging, then we will submit the proposed texts.

Any WG's feedbacks are welcome

Best regards

Fei --=_alternative 002F67E248257A4F_=-- From zhang.fei3@zte.com.cn Fri Aug 3 02:16:55 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C813C21F8D6F for ; Fri, 3 Aug 2012 02:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.135 X-Spam-Level: X-Spam-Status: No, score=-96.135 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, J_CHICKENPOX_93=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSykrZ4iRfm0 for ; Fri, 3 Aug 2012 02:16:54 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5015E21F8D6E for ; Fri, 3 Aug 2012 02:16:53 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723473195744; Fri, 3 Aug 2012 17:04:32 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 2435.4947443848; Fri, 3 Aug 2012 17:16:35 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q739GW8H068491; Fri, 3 Aug 2012 17:16:32 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: "Rakesh Gandhi (rgandhi)" MIME-Version: 1.0 X-KeepSent: FA741204:33C58679-48257A4F:003061FA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 3 Aug 2012 17:16:19 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-03 17:16:23, Serialize complete at 2012-08-03 17:16:23 Content-Type: multipart/alternative; boundary="=_alternative 0032EA6348257A4F_=" X-MAIL: mse01.zte.com.cn q739GW8H068491 Cc: "Robert Sawaya \(rsawaya\)" , "yang.fan5@zte.com.cn" , CCAMP , "jingrq@ctbri.com.cn" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 09:16:55 -0000 This is a multipart message in MIME format. --=_alternative 0032EA6348257A4F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUmFrZXNoDQoNClNuaXBwZWQgdGhlIG90aGVyIHBhcnRzIGZvciBlYXN5IHJlYWRpbmcsIHNv cnJ5IGZvciB0aGUgZGVsYXllZCByZXNwb25zZSANCg0KPFJHMz4gVGhlcmUgYXJlIGFwcGxpY2F0 aW9ucyB0aGF0IHJlcXVpcmUgY28tcm91dGVkIExTUHMuIFNvIEkgdGhpbmsgd2UgDQpzaG91bGQg aGF2ZSBhIGZsYWcgdG8gaW5kaWNhdGUgdGhhdCBMU1BzIG11c3QgYmUgY28tcm91dGVkLCBlbHNl IG5vZGUgd2lsbCANCnNlbmQgYSBwYXRoIGVycm9yIGZvciBleGFtcGxlIGlmIHJlcXVlc3QgY2Fu bm90IGJlIG1ldC4gIEkgYWdyZWUgd2l0aCB5b3UgDQphYm91dCBjb21wbGV4aXR5IHdpdGggZG91 YmxlIHNpZGVkIHByb3Zpc2lvbmluZyBtb2RlbCB0aG91Z2guIA0KDQo8ZmVpPiBTaW5jZSB5b3Ug YmVsaWV2ZSB0aGF0IGEgY29tbW9uIG1lY2hhbmlzbSB1c2VkIGZvciB0aGUgbm9uLWNvcm91dGVk IA0KYW5kIGNvcm91dGVkIGNhc2VzIGlzIHVzZWZ1bCwgd2Ugd2lsbCBhZGQgdGhlIHRleHRzIGlu IHRoZSBuZXh0IHZlcnNpb24uDQoNCjxSRzM+IE9rLCB3ZSBwcm9iYWJseSBzaG91bGQgYWRkIHVz ZSBjYXNlcyBmb3IgdmFyaW91cyBtZXRob2RzLiBJIGNhbiBzZWUgDQptZXRob2QgMSBiZWluZyB1 c2VkIGZvciBzZXR0aW5nIHVwIGJpZGlyZWN0aW9uYWwgTFNQcyBidXQgSSBhbSBub3Qgc3VyZSAN CmFib3V0IG1ldGhvZCAyIGZvciBleGFtcGxlLiBPbmUgd29ycnkgaXMgdGhhdCBkaWZmZXJlbnQg bWV0aG9kcyBjYW4gbGVhZCANCnRvIGludGVyb3AgaXNzdWVzIGlmIG9uZSB2ZW5kb3IgaW1wbGVt ZW50cyBtZXRob2QgMSBhbmQgc2Vjb25kIHZlbmRvciANCm1ldGhvZCAyLg0KQXNzb2NpYXRpb24g b2JqZWN0IGlzIGJlaW5nIHVzZWQgZm9yIGRpZmZlcmVudCBhc3NvY2lhdGlvbiB0eXBlcyAoUkZD IA0KNDg3MjogdHlwZSAxOiBSZWNvdmVyeSksIChSRkMgNDg3My0gdHlwZSAyOiBSZXNvdXJjZSBz aGFyaW5nKSwgZXRjLiBhbmQgDQp0aGVzZSBSRkNzIGRlZmluZSBzcGVjaWZpYyBwcm9jZWR1cmVz IGZvciB0aGUgZ2l2ZW4gYXNzb2NpYXRpb24gdHlwZS4gU28gDQpJTUhPLCBpdCBtYXkgYmUgb2sg dG8gZGVmaW5lIGEgc3RyaWN0ZXIgcHJvY2VkdXJlIGZvciBwb3B1bGF0aW5nIGV4dCANCmFzc29j aWF0aW9uIG9iamVjdCBmb3IgdGhlIG5ldyBCaWRpcmVjdGlvbmFsIExTUHMgYXNzb2NpYXRpb24g dHlwZS4NCg0KPGZlaT4gTWV0aG9kIDIgd29ya3Mgd2VsbCwgYW5kIHRoZSBvbmx5IGRpZmZlcmVu Y2UgaXMgdCBob3cgdG8gcmVwcmVzZW50IA0KdGhlIGdsb2JhbCB1bmlxdWUgaWRlbnRpZmllci4g Rm9yIHRoZSBhc3NvY2lhdGlvbiBpcyBiYXNlZCBvbiB0aGUgZnVsbCANCm1hdGNoIG9mIHRoZSBF QSBvYmplY3RzLCB0aGUgRUEgb2JqZWN0IGlzIGp1c3QgY29waWVkIGZyb20gdGhlIHBhdGggDQpt ZXNzYWdlIGludG8gYW5vdGhlciBwYXRoIG1lc3NhZ2UgaW4gc2luZ2xlIHNpZGVkIHByb3Zpc2lv bmluZyBtb2RlbC4gQXMgDQp0byB0aGUgZG91YmxlZCBzaWRlZCBwcm92aXNpb25pbmcgbW9kZWws IHRoZSBFQSBvYmplY3RzIGlzIGFsc28gdGhlIHNhbWUuIA0KSU1ITywgdGhlcmUgaXMgbm8gaW50 ZXJvcCBpc3N1ZXMsIG9yIGRvIEkgaGF2ZSBzb21lIG1pc3VuZGVyc3RhbmRpbmc/IA0KDQpZZWFo LCB3ZSBjYW4gZGVmaW5lIGEgc3RyaWN0ZXIgcHJvZGVkdXJlLCBJIGFtIG5vdCBzdXJlIHRoaXMg aXMgYSBnb29kIHdheSANCmluIHN0YW5kYXJkLCBuZWVkIG1vcmUgZmVlZGJhY2sgZnJvbSB0aGUg V0cuDQoNCkNoZWVyDQoNCkZlaQ0KDQoNCg0KIlJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIiA8cmdh bmRoaUBjaXNjby5jb20+IA0KMjAxMi0wOC0wMSAwMToyNA0KDQrK1bz+yMsNCiJ6aGFuZy5mZWkz QHp0ZS5jb20uY24iIDx6aGFuZy5mZWkzQHp0ZS5jb20uY24+DQqzrcvNDQoiRXJpYyBPc2Jvcm5l IChlb3Nib3JuZSkiIDxlb3Nib3JuZUBjaXNjby5jb20+LCAiamlhbmcud2VpbGlhbkB6dGUuY29t LmNuIiANCjxqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY24+LCAiamluZ3JxQGN0YnJpLmNvbS5jbiIg PGppbmdycUBjdGJyaS5jb20uY24+LCANCiJSb2JlcnQgU2F3YXlhIChyc2F3YXlhKSIgPHJzYXdh eWFAY2lzY28uY29tPiwgIkdlb3JnZSBTd2FsbG93IChzd2FsbG93KSIgDQo8c3dhbGxvd0BjaXNj by5jb20+LCAieWFuZy5mYW41QHp0ZS5jb20uY24iIDx5YW5nLmZhbjVAenRlLmNvbS5jbj4sIEND QU1QIA0KPGNjYW1wQGlldGYub3JnPg0K1vfM4g0KUkU6IENvbW1lbnRzIG9uIGRyYWZ0LWlldGYt Y2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTAzDQoNCg0KDQoNCg0KDQpI aSBGZWksDQogDQpUaGFua3MgZm9yIHlvdXIga2luZCByZXBseS4gUGxlYXNlIHNlZSBpbmxpbmUu LjxSRzM+Li4NCiANCjxTbmlwcGVkIGVtYWlsIHRvIGZvY3VzIG9uIG9wZW4gaXRlbXM+DQogDQog DQpGcm9tOiB6aGFuZy5mZWkzQHp0ZS5jb20uY24gW21haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20u Y25dIA0KU2VudDogTW9uZGF5LCBKdWx5IDMwLCAyMDEyIDEwOjA0IFBNDQpUbzogUmFrZXNoIEdh bmRoaSAocmdhbmRoaSkNCkNjOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKTsgamlhbmcud2VpbGlh bkB6dGUuY29tLmNuOyANCmppbmdycUBjdGJyaS5jb20uY247IFJvYmVydCBTYXdheWEgKHJzYXdh eWEpOyBHZW9yZ2UgU3dhbGxvdyAoc3dhbGxvdyk7IA0KeWFuZy5mYW41QHp0ZS5jb20uY247IEND QU1QDQpTdWJqZWN0OiBSRTogQ29tbWVudHMgb24gDQpkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAt cnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wMw0KDQpUaGFuayB5b3UgUmFrZXNoIGZvciBzaGFy aW5nIHlvdXIgaWRlYSwgSSB0aGluayB3ZSBhcmUgcm91Z2hseSBpbiANCmFncmVlbWVudCBhbmQg bmVlZCB0byBoZWFyIG1vcmUgdm9pY2VzIGZyb20gdGhlIFdHLiA6KSANCg0KU2VlIGlubGluZSA8 ZmVpPjwvZmVpPg0KDQpCZXN0IA0KDQpGZWkgDQoNCjIpIERlZmluZSBvbmUgZmxhZyBmb3IgY28t cm91dGVkIG9yIG5vbi1jb3JvdXRlZC4gSWYgdGhlIGNvLXJvdXRlZCBiaWRpciANCmlzIHRoZSBk ZWZhdWx0IGJlaGF2aW9yLCB3aHkgbm90IHVzaW5nIHRoZSBwcm9jZWR1cmUgZGVmaW5lZCBpbiBS RkMzNDczPyBJIA0KYW0gYWZyYWlkIGl0IGlzIGhhcmQgDQp0byBwZXJzdWFkZSB0aGUgV0cgdG8g ZG8gc28uIE1heWJlIHRoZSBiZXR0ZXIgd2F5IGlzIHRoYXQgbm9uLWNvcm91dGVkIA0KYmlkaXIg aXMgdGhlIGRlZmF1bHQsIGFuZCB0aGUgc2V0IG9mIHRoZSBjby1yb3V0ZWQgZmxhZyBvbmx5IG1l YW5zIHRoYXQgaXQgDQppcyByZWNvbW1lbmRlZCwgbm90IG1hbmRhdG9yeSwgdGhlIGNoZWNraW5n IHdoZXRoZXIgdGhlIExTUCBpcyBjby1yb3V0ZWQgDQpjYW4gYmUgZG9uZSBieSBjb21wYXJpbmcg dGhlIFJSTyBvYmplY3RzLiBXaGF0IGlzIHlvdXIgb3Bpbmlvbj8gDQo8UkcxPiBJdCBpcyBmaW5l IHRvIGhhdmUgbm9uIGNvLXJvdXRlZCBhcyBkZWZhdWx0LiBSRkMgMzQ3MyBpcyBhIEdNUExTIA0K c2lnbmFsaW5nIHByb2NlZHVyZS4gSXQgbWF5IG5vdCBiZSBvcHRpbWFsICB0byBoYXZlIHR3byBk aWZmZXJlbnQgDQpzaWduYWxpbmcgcHJvY2VkdXJlcywgb25lIGZvciBub24gY28tcm91dGVkIChl eHQgYXNzb2NpYXRlZCBvYmplY3QpIGFuZCANCm9uZSBmb3IgY28tcm91dGVkIChSRkMgMzQ3Mykg cHJvY2VkdXJlcy4gQnkgYWRkaW5nIGEgZmxhZyBmb3IgY28tcm91dGVkLCANCnNhbWUgc2lnbmFs aW5nIChleHQgYXNzb2NpYXRlZCBvYmplY3QpIGNhbiBiZSB1c2VkIGZvciBib3RoIHdoaWNoIGlz IG5pY2UuIA0KV2UgYmVsaWV2ZSBjb21wYXJpbmcgb2YgUlJPIGNhbiBiZSBtaXNsZWFkaW5nIGJl Y2F1c2UgdHdvIExTUHMgY2FuIGJlIG9uIA0KdGhlIHNhbWUgcGF0aCBldmVuIHRob3VnaCBwcm92 aXNpb25lZCB0byBiZSBub24gY28tcm91dGVkLiANCg0KPGZlaT4gDQpTb3JyeSB0aGF0IHdoYXQg SSBzdWdnZXN0ZWQgbWF5YmUgbWlzbGVhZCB5b3UsIHRoZSBmb2xsb3dpbmcgZGVzY3JpcGl0b25z IA0KYXJlIG1vcmUgYWNjdXJhdGUuIDopIA0KIDEpVGhlIGRlZmF1bHQgYmVoYXZpb3IgKG5vbi1j b3JvdXRlZCkgbWVhbnMgdGhhdCBpdCBpcyBub3QgcmVxdWlyZWQgdG8gYmUgDQpjby1yb3V0ZWQu IEluIG90aGVyIHdvcmRzLCBpdCBpcyBhbHNvIE9LIHRoYXQgdGhlIHR3byBwYXRocyBhcmUgYWxv bmcgdGhlIA0Kc2FtZSBwYXRoDQogDQouIA0KPFJHMz4gQWdyZWUuDQoNCiAyKVRoZSBmbGFnIHNl dCBtZWFucyB0aGF0IGNvLXJvdXRlZCBpcyByZWNvbW1lbmRlZC4gSW4gb3RoZXIgd29yZHMsIHRo ZSANCnJldmVyc2UgTFNQIFNIT1VMRCBiZSBlc3RhYmxpc2hlZCBpbiB0aGUgc2FtZSBwYXRoIGFz IG11Y2ggYXMgcG9zc2libGUuIElmIA0KdGhlIGZsYWcgc2V0IG1lYW5zIA0KdGhhdCBjby1yb3V0 ZWQgaXMgbWFuZGF0b3J5LHRoZSBwcm9jZWR1cmVzIHdpbGwgYmUgdmVyeSBjb21wbGV4IGluIGRv dWJsZSANCnNpZGVkIHByb3Zpc2lvbmluZyBtb2RlbC4gDQo8L2ZlaT4gDQo8UkczPiBUaGVyZSBh cmUgYXBwbGljYXRpb25zIHRoYXQgcmVxdWlyZSBjby1yb3V0ZWQgTFNQcy4gU28gSSB0aGluayB3 ZSANCnNob3VsZCBoYXZlIGEgZmxhZyB0byBpbmRpY2F0ZSB0aGF0IExTUHMgbXVzdCBiZSBjby1y b3V0ZWQsIGVsc2Ugbm9kZSB3aWxsIA0Kc2VuZCBhIHBhdGggZXJyb3IgZm9yIGV4YW1wbGUgaWYg cmVxdWVzdCBjYW5ub3QgYmUgbWV0LiAgSSBhZ3JlZSB3aXRoIHlvdSANCmFib3V0IGNvbXBsZXhp dHkgd2l0aCBkb3VibGUgc2lkZWQgcHJvdmlzaW9uaW5nIG1vZGVsIHRob3VnaC4gDQoNCg0KMylB cyB0byB0aGUgdHVwbGUgb2YgPGxvd2VyIGlwIGFkZHJlc3MsIGhpZ2ggaXAgYWRkcmVzcywgYXNz b2NpYXRpb24gaWQ+LCANCnllYWgsIGl0IGlzIG9uZSBraW5kIG9mIGltcGxlbWVudGF0aW9uLCBi dXQgdGhlcmUgYXJlIHBvdGVudGlhbCBzb21lIG90aGVyIA0KcmVhbGl6YXRpb25zLCBsaWtlIHVz aW5nIG9uZSBvZiB0aGUgcm91dGVyIGlkIHBsdXMgdGhlIHR1bm5lbCBpZC4gSSB0aGluayANCndl IGhhZCBiZXR0ZXIgbm90IHJlc3RyaWN0IHRoZSBleGVjdXRpb24gdG8gc3VjaCBhIG5hcnJvdyBz Y29wZS4gV2hhdCANCmFib3V0IHRoZSBFQSBmb3JtYXQgbGlzdGVkIGJlbG93PyANCg0KICAgICAg ICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAg ICAgICAzDQogICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgfCAgICAgICAgICAgIExlbmd0 aCAgICAgICAgICAgICB8IENsYXNzLU51bSgxOTkpfCAgQy1UeXBlIChUQkEpIHwNCiAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KICAgIHwgICAgICAgQXNzb2NpYXRpb24gVHlwZSAgICAgICAgfCAgICAgICBBc3NvY2lh dGlvbiBJRCAgICAgICAgICB8DQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICB8ICAgICAgICAgICAgICAgICAg ICBJUHY0IEFzc29jaWF0aW9uIFNvdXJjZSAgICAgICAgICAgICAgICAgICAgfA0KICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogICAgfCAgICAgICAgICAgICAgICAgICBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlICAg ICAgICAgICAgICAgICAgIHwNCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgIHxFeHRlbmRlZCBBc3NvY2lhdGlv biBGbGFncy4gICAgfEV4dGVuZGVkIEFzc29jaWF0aW9uIElEIC4uLiAgICB8IA0KICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKyANCiAgICAgfC4uLi4oY29udGludWUpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDoNCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQo8Ukc+IERvIHlvdSBtZWFuIHRv IGhhdmUgZXh0ZW5kZWQgYXNzb2NpYXRpb24gSUQgYXMgdHVubmVsIElEICgxNiBiaXRzKSArIA0K SVAgYWRkcmVzcyAoMzIgYml0cykgaW4gdGhpcyBvYmplY3Q/IA0KUGxlYXNlIHNlZSBpbmxpbmUg YmVsb3cuLjxSRzE+Li4gDQoNCjxmZWk+IA0KTm8uIEkgd2FudCB0byBzYXkgdGhhdCB0aGlzIGZv cm1hdCBvZiBFQSBvYmplY3RzIGNhbiBhY2NvbW9kYXRlIG1vcmUga2luZHMgDQpvZiBpbXBsZW1l bnRhdGlvbnMuIExpa2UgDQoNCjEpQXNzb2NpYXRpb24gSUQ6IHVzZXIgcHJvdmlzaW9uZWQgaWRl bnRpYWwgdmFsdWU7IEFzc29jaWF0aW9uIFNvdXJjZTogdGhlIA0KbG93ZSBpcCBhZGRyZXNzOyBF QSBJRDogdGhlIGhpZ2hlciBJUCBhZGRyZXNzLiBBcyB5b3Ugc3VnZ2VzdGVkIA0KDQoyKUFzc29j aWF0aW9uIElEOiB0dW5uZWwgSUQgb3IgdXNlciBwcm92aXNpb25lZCB2YWx1ZTsgQXNzb2NpYXRp b24gDQpTb3VyY2U6VHVubmVsIHNlbmRlciBhZGRyZXNzIG9yIHVzZXIgcHJvdmlzaW9uZWQ7IEVB IElEOiBiZSBlbXB0eSBvciBMU1AgDQpJRCBvciBhbnkgb3RoZXIgaW5mb3JtYXRpb24uIA0KDQoz KVRoZSBwb3RlbnRpYWwgb3RoZXIgaW1wbGVtZW50YXRpb25zLi4uIA0KDQpJTUhPLCB0aGUgRUEg SUQgY2FuIGJlIElQIGFkZHJlc3Mgb3IgYW55IG90aGVyIHZhbHVlcyBpbiB0aGUgY29udGV4dCBv ZiANCkFzc29jaWF0aW9uIFNvdXJjZSBwbHVzIEFzc29jaWF0aW9uIElELCB3aGljaCBpcyBiYWNr d2FyZCBjb21wYXRpYmxlLiANCg0KPC9mZWk+IA0KPFJHMz4gT2ssIHdlIHByb2JhYmx5IHNob3Vs ZCBhZGQgdXNlIGNhc2VzIGZvciB2YXJpb3VzIG1ldGhvZHMuIEkgY2FuIHNlZSANCm1ldGhvZCAx IGJlaW5nIHVzZWQgZm9yIHNldHRpbmcgdXAgYmlkaXJlY3Rpb25hbCBMU1BzIGJ1dCBJIGFtIG5v dCBzdXJlIA0KYWJvdXQgbWV0aG9kIDIgZm9yIGV4YW1wbGUuIE9uZSB3b3JyeSBpcyB0aGF0IGRp ZmZlcmVudCBtZXRob2RzIGNhbiBsZWFkIA0KdG8gaW50ZXJvcCBpc3N1ZXMgaWYgb25lIHZlbmRv ciBpbXBsZW1lbnRzIG1ldGhvZCAxIGFuZCBzZWNvbmQgdmVuZG9yIA0KbWV0aG9kIDIuDQpBc3Nv Y2lhdGlvbiBvYmplY3QgaXMgYmVpbmcgdXNlZCBmb3IgZGlmZmVyZW50IGFzc29jaWF0aW9uIHR5 cGVzIChSRkMgDQo0ODcyOiB0eXBlIDE6IFJlY292ZXJ5KSwgKFJGQyA0ODczLSB0eXBlIDI6IFJl c291cmNlIHNoYXJpbmcpLCBldGMuIGFuZCANCnRoZXNlIFJGQ3MgZGVmaW5lIHNwZWNpZmljIHBy b2NlZHVyZXMgZm9yIHRoZSBnaXZlbiBhc3NvY2lhdGlvbiB0eXBlLiBTbyANCklNSE8sIGl0IG1h eSBiZSBvayB0byBkZWZpbmUgYSBzdHJpY3RlciBwcm9jZWR1cmUgZm9yIHBvcHVsYXRpbmcgZXh0 IA0KYXNzb2NpYXRpb24gb2JqZWN0IGZvciB0aGUgbmV3IEJpZGlyZWN0aW9uYWwgTFNQcyBhc3Nv Y2lhdGlvbiB0eXBlLg0KIA0KVGhhbmtzLA0KUmFrZXNoDQoNCg0KDQoNCg0KDQo= --=_alternative 0032EA6348257A4F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJha2VzaDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U25pcHBlZCB0aGUgb3RoZXIg cGFydHMgZm9yIGVhc3kgcmVhZGluZywNCnNvcnJ5IGZvciB0aGUgZGVsYXllZCByZXNwb25zZSA8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4mbHQ7UkczJmd0OyBUaGVyZQ0KYXJlIGFwcGxpY2F0aW9ucyB0aGF0IHJlcXVp cmUgY28tcm91dGVkIExTUHMuIFNvIEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUNCmEgZmxhZyB0byBp bmRpY2F0ZSB0aGF0IExTUHMgbXVzdCBiZSBjby1yb3V0ZWQsIGVsc2Ugbm9kZSB3aWxsIHNlbmQg YSBwYXRoDQplcnJvciBmb3IgZXhhbXBsZSBpZiByZXF1ZXN0IGNhbm5vdCBiZSBtZXQuICZuYnNw O0kgYWdyZWUgd2l0aCB5b3UgYWJvdXQNCmNvbXBsZXhpdHkgd2l0aCBkb3VibGUgc2lkZWQgcHJv dmlzaW9uaW5nIG1vZGVsIHRob3VnaC4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mbHQ7ZmVpJmd0OyBTaW5jZSB5b3UgYmVsaWV2ZSB0aGF0IGENCmNv bW1vbiBtZWNoYW5pc20gdXNlZCBmb3IgdGhlIG5vbi1jb3JvdXRlZCBhbmQgY29yb3V0ZWQgY2Fz ZXMgaXMgdXNlZnVsLA0Kd2Ugd2lsbCBhZGQgdGhlIHRleHRzIGluIHRoZSBuZXh0IHZlcnNpb24u PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj0jMWY0OTdkPiZsdDtSRzMmZ3Q7 IE9rLCB3ZSBwcm9iYWJseSBzaG91bGQgYWRkIHVzZQ0KY2FzZXMgZm9yIHZhcmlvdXMgbWV0aG9k cy4gSSBjYW4gc2VlIG1ldGhvZCAxIGJlaW5nIHVzZWQgZm9yIHNldHRpbmcgdXANCmJpZGlyZWN0 aW9uYWwgTFNQcyBidXQgSSBhbSBub3Qgc3VyZSBhYm91dCBtZXRob2QgMiBmb3IgZXhhbXBsZS4g T25lIHdvcnJ5DQppcyB0aGF0IGRpZmZlcmVudCBtZXRob2RzIGNhbiBsZWFkIHRvIGludGVyb3Ag aXNzdWVzIGlmIG9uZSB2ZW5kb3IgaW1wbGVtZW50cw0KbWV0aG9kIDEgYW5kIHNlY29uZCB2ZW5k b3IgbWV0aG9kIDIuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj0jMWY0OTdkPkFzc29j aWF0aW9uIG9iamVjdCBpcyBiZWluZyB1c2VkIGZvciBkaWZmZXJlbnQNCmFzc29jaWF0aW9uIHR5 cGVzIChSRkMgNDg3MjogdHlwZSAxOiBSZWNvdmVyeSksIChSRkMgNDg3My0gdHlwZSAyOiBSZXNv dXJjZQ0Kc2hhcmluZyksIGV0Yy4gYW5kIHRoZXNlIFJGQ3MgZGVmaW5lIHNwZWNpZmljIHByb2Nl ZHVyZXMgZm9yIHRoZSBnaXZlbg0KYXNzb2NpYXRpb24gdHlwZS4gU28gSU1ITywgaXQgbWF5IGJl IG9rIHRvIGRlZmluZSBhIHN0cmljdGVyIHByb2NlZHVyZQ0KZm9yIHBvcHVsYXRpbmcgZXh0IGFz c29jaWF0aW9uIG9iamVjdCBmb3IgdGhlIG5ldyBCaWRpcmVjdGlvbmFsIExTUHMgYXNzb2NpYXRp b24NCnR5cGUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbHQ7ZmVpJmd0OyBNZXRob2QgMiB3b3JrcyB3ZWxsLCBhbmQNCnRoZSBvbmx5IGRpZmZlcmVu Y2UgaXMgdCBob3cgdG8gcmVwcmVzZW50IHRoZSBnbG9iYWwgdW5pcXVlIGlkZW50aWZpZXIuDQpG b3IgdGhlIGFzc29jaWF0aW9uIGlzIGJhc2VkIG9uIHRoZSBmdWxsIG1hdGNoIG9mIHRoZSBFQSBv YmplY3RzLCB0aGUgRUENCm9iamVjdCBpcyBqdXN0IGNvcGllZCBmcm9tIHRoZSBwYXRoIG1lc3Nh Z2UgaW50byBhbm90aGVyIHBhdGggbWVzc2FnZSBpbg0Kc2luZ2xlIHNpZGVkIHByb3Zpc2lvbmlu ZyBtb2RlbC4gQXMgdG8gdGhlIGRvdWJsZWQgc2lkZWQgcHJvdmlzaW9uaW5nIG1vZGVsLA0KdGhl IEVBIG9iamVjdHMgaXMgYWxzbyB0aGUgc2FtZS4gSU1ITywgdGhlcmUgaXMgbm8gaW50ZXJvcCBp c3N1ZXMsIG9yIGRvDQpJIGhhdmUgc29tZSBtaXN1bmRlcnN0YW5kaW5nPyA8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllYWgsIHdlIGNhbiBkZWZpbmUg YSBzdHJpY3RlciBwcm9kZWR1cmUsDQpJIGFtIG5vdCBzdXJlIHRoaXMgaXMgYSBnb29kIHdheSBp biBzdGFuZGFyZCwgbmVlZCBtb3JlIGZlZWRiYWNrIGZyb20gdGhlDQpXRy48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNoZWVyPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2 JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7UmFrZXNoIEdhbmRoaSAo cmdhbmRoaSkmcXVvdDsNCiZsdDtyZ2FuZGhpQGNpc2NvLmNvbSZndDs8L2I+IDwvZm9udD4NCjxw Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTA4LTAxIDAxOjI0PC9mb250Pg0K PHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O3po YW5nLmZlaTNAenRlLmNvbS5jbiZxdW90OyAmbHQ7emhhbmcuZmVpM0B6dGUuY29tLmNuJmd0Ozwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7RXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkmcXVvdDsNCiZs dDtlb3Nib3JuZUBjaXNjby5jb20mZ3Q7LCAmcXVvdDtqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY24m cXVvdDsgJmx0O2ppYW5nLndlaWxpYW5AenRlLmNvbS5jbiZndDssDQomcXVvdDtqaW5ncnFAY3Ri cmkuY29tLmNuJnF1b3Q7ICZsdDtqaW5ncnFAY3RicmkuY29tLmNuJmd0OywgJnF1b3Q7Um9iZXJ0 DQpTYXdheWEgKHJzYXdheWEpJnF1b3Q7ICZsdDtyc2F3YXlhQGNpc2NvLmNvbSZndDssICZxdW90 O0dlb3JnZSBTd2FsbG93DQooc3dhbGxvdykmcXVvdDsgJmx0O3N3YWxsb3dAY2lzY28uY29tJmd0 OywgJnF1b3Q7eWFuZy5mYW41QHp0ZS5jb20uY24mcXVvdDsNCiZsdDt5YW5nLmZhbjVAenRlLmNv bS5jbiZndDssIENDQU1QICZsdDtjY2FtcEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PlJFOiBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3Nv Y2lhdGVkLWxzcC0wMzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SGkgRmVpLDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPlRoYW5rcyBmb3IgeW91ciBraW5kDQpyZXBseS4gUGxlYXNlIHNlZSBp bmxpbmUuLiZsdDtSRzMmZ3Q7Li48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbHQ7U25pcHBlZCBlbWFpbA0K dG8gZm9jdXMgb24gb3BlbiBpdGVtcyZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IHpoYW5nLmZlaTNA enRlLmNvbS5jbiBbbWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbl0NCjxiPjxicj4NClNlbnQ6 PC9iPiBNb25kYXksIEp1bHkgMzAsIDIwMTIgMTA6MDQgUE08Yj48YnI+DQpUbzo8L2I+IFJha2Vz aCBHYW5kaGkgKHJnYW5kaGkpPGI+PGJyPg0KQ2M6PC9iPiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5l KTsgamlhbmcud2VpbGlhbkB6dGUuY29tLmNuOyBqaW5ncnFAY3RicmkuY29tLmNuOw0KUm9iZXJ0 IFNhd2F5YSAocnNhd2F5YSk7IEdlb3JnZSBTd2FsbG93IChzd2FsbG93KTsgeWFuZy5mYW41QHp0 ZS5jb20uY247DQpDQ0FNUDxiPjxicj4NClN1YmplY3Q6PC9iPiBSRTogQ29tbWVudHMgb24gZHJh ZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDM8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDgwMDAgZmFjZT0iQXJpYWwiPjxicj4NClRoYW5r IHlvdSBSYWtlc2ggZm9yIHNoYXJpbmcgeW91ciBpZGVhLCBJIHRoaW5rIHdlIGFyZSByb3VnaGx5 IGluIGFncmVlbWVudA0KYW5kIG5lZWQgdG8gaGVhciBtb3JlIHZvaWNlcyBmcm9tIHRoZSBXRy4g Oik8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNv bG9yPSMwMDgwMDAgZmFjZT0iQXJpYWwiPlNlZSBpbmxpbmUgJmx0O2ZlaSZndDsmbHQ7L2ZlaSZn dDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzAw ODAwMCBmYWNlPSJBcmlhbCI+PGJyPg0KQmVzdDwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjwv Zm9udD48Zm9udCBzaXplPTIgY29sb3I9IzAwODAwMCBmYWNlPSJBcmlhbCI+PGJyPg0KRmVpPC9m b250Pjxmb250IHNpemU9Mz4gPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+MikgRGVmaW5lIG9uZSBmbGFnIGZvciBjby1yb3V0ZWQgb3Igbm9uLWNvcm91dGVkLg0K SWYgdGhlIGNvLXJvdXRlZCBiaWRpciBpcyB0aGUgZGVmYXVsdCBiZWhhdmlvciwgd2h5IG5vdCB1 c2luZyB0aGUgcHJvY2VkdXJlDQpkZWZpbmVkIGluIFJGQzM0NzM/IEkgYW0gYWZyYWlkIGl0IGlz IGhhcmQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCnRvIHBlcnN1YWRlIHRoZSBXRyB0byBkbyBzby4gTWF5YmUg dGhlIGJldHRlciB3YXkgaXMgdGhhdCBub24tY29yb3V0ZWQNCmJpZGlyIGlzIHRoZSBkZWZhdWx0 LCBhbmQgdGhlIHNldCBvZiB0aGUgY28tcm91dGVkIGZsYWcgb25seSBtZWFucyB0aGF0DQppdCBp cyByZWNvbW1lbmRlZCwgbm90IG1hbmRhdG9yeSwgdGhlIGNoZWNraW5nIHdoZXRoZXIgdGhlIExT UCBpcyBjby1yb3V0ZWQNCmNhbiBiZSBkb25lIGJ5IGNvbXBhcmluZyB0aGUgUlJPIG9iamVjdHMu IFdoYXQgaXMgeW91ciBvcGluaW9uPzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPg0K PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jYzA1MDRkIGZhY2U9IkNhbGlicmkiPjxicj4NCiZs dDtSRzEmZ3Q7IEl0IGlzIGZpbmUgdG8gaGF2ZSBub24gY28tcm91dGVkIGFzIGRlZmF1bHQuIFJG QyAzNDczIGlzIGENCkdNUExTIHNpZ25hbGluZyBwcm9jZWR1cmUuIEl0IG1heSBub3QgYmUgb3B0 aW1hbCAmbmJzcDt0byBoYXZlIHR3byBkaWZmZXJlbnQNCnNpZ25hbGluZyBwcm9jZWR1cmVzLCBv bmUgZm9yIG5vbiBjby1yb3V0ZWQgKGV4dCBhc3NvY2lhdGVkIG9iamVjdCkgYW5kDQpvbmUgZm9y IGNvLXJvdXRlZCAoUkZDIDM0NzMpIHByb2NlZHVyZXMuIEJ5IGFkZGluZyBhIGZsYWcgZm9yIGNv LXJvdXRlZCwNCnNhbWUgc2lnbmFsaW5nIChleHQgYXNzb2NpYXRlZCBvYmplY3QpIGNhbiBiZSB1 c2VkIGZvciBib3RoIHdoaWNoIGlzIG5pY2UuDQpXZSBiZWxpZXZlIGNvbXBhcmluZyBvZiBSUk8g Y2FuIGJlIG1pc2xlYWRpbmcgYmVjYXVzZSB0d28gTFNQcyBjYW4gYmUgb24NCnRoZSBzYW1lIHBh dGggZXZlbiB0aG91Z2ggcHJvdmlzaW9uZWQgdG8gYmUgbm9uIGNvLXJvdXRlZC48L2ZvbnQ+PGZv bnQgc2l6ZT0zPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA4MDAwIGZhY2U9 IkFyaWFsIj48YnI+DQombHQ7ZmVpJmd0OzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9u dCBzaXplPTIgY29sb3I9IzAwODAwMCBmYWNlPSJBcmlhbCI+PGJyPg0KU29ycnkgdGhhdCB3aGF0 IEkgc3VnZ2VzdGVkIG1heWJlIG1pc2xlYWQgeW91LCB0aGUgZm9sbG93aW5nIGRlc2NyaXBpdG9u cw0KYXJlIG1vcmUgYWNjdXJhdGUuIDopPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250 IHNpemU9MiBjb2xvcj0jMDA4MDAwIGZhY2U9IkFyaWFsIj48YnI+DQogMSlUaGUgZGVmYXVsdCBi ZWhhdmlvciAobm9uLWNvcm91dGVkKSBtZWFucyB0aGF0IGl0IGlzIG5vdCByZXF1aXJlZCB0bw0K YmUgY28tcm91dGVkLiBJbiBvdGhlciB3b3JkcywgaXQgaXMgYWxzbyBPSyB0aGF0IHRoZSB0d28g cGF0aHMgYXJlIGFsb25nDQp0aGUgc2FtZSBwYXRoPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBj b2xvcj0jMWY0OTdkIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMDA4MDAwIGZhY2U9IkFyaWFsIj4uPC9mb250Pjxmb250IHNpemU9 Mz4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+Jmx0O1JHMyZndDsgQWdyZWUuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj0jMDA4MDAwIGZhY2U9IkFyaWFsIj48YnI+DQogMilUaGUgZmxhZyBzZXQgbWVhbnMgdGhhdCBj by1yb3V0ZWQgaXMgcmVjb21tZW5kZWQuIEluIG90aGVyIHdvcmRzLCB0aGUNCnJldmVyc2UgTFNQ IFNIT1VMRCBiZSBlc3RhYmxpc2hlZCBpbiB0aGUgc2FtZSBwYXRoIGFzIG11Y2ggYXMgcG9zc2li bGUuDQpJZiB0aGUgZmxhZyBzZXQgbWVhbnM8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGNvbG9yPSMwMDgwMDAgZmFjZT0iQXJpYWwiPjxicj4NCnRoYXQgY28tcm91dGVk IGlzIG1hbmRhdG9yeSx0aGUgcHJvY2VkdXJlcyB3aWxsIGJlIHZlcnkgY29tcGxleCBpbiBkb3Vi bGUNCnNpZGVkIHByb3Zpc2lvbmluZyBtb2RlbC48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDgwMDAgZmFjZT0iQXJpYWwiPjxicj4NCiZsdDsvZmVpJmd0 OzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFm NDk3ZCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZsdDtSRzMmZ3Q7IFRoZXJlDQphcmUgYXBwbGlj YXRpb25zIHRoYXQgcmVxdWlyZSBjby1yb3V0ZWQgTFNQcy4gU28gSSB0aGluayB3ZSBzaG91bGQg aGF2ZQ0KYSBmbGFnIHRvIGluZGljYXRlIHRoYXQgTFNQcyBtdXN0IGJlIGNvLXJvdXRlZCwgZWxz ZSBub2RlIHdpbGwgc2VuZCBhIHBhdGgNCmVycm9yIGZvciBleGFtcGxlIGlmIHJlcXVlc3QgY2Fu bm90IGJlIG1ldC4gJm5ic3A7SSBhZ3JlZSB3aXRoIHlvdSBhYm91dA0KY29tcGxleGl0eSB3aXRo IGRvdWJsZSBzaWRlZCBwcm92aXNpb25pbmcgbW9kZWwgdGhvdWdoLiA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj48YnI+DQozKUFzIHRvIHRoZSB0dXBsZSBvZiAmbHQ7bG93ZXIgaXAgYWRkcmVzcywgaGln aCBpcCBhZGRyZXNzLCBhc3NvY2lhdGlvbg0KaWQmZ3Q7LCB5ZWFoLCBpdCBpcyBvbmUga2luZCBv ZiBpbXBsZW1lbnRhdGlvbiwgYnV0IHRoZXJlIGFyZSBwb3RlbnRpYWwNCnNvbWUgb3RoZXIgcmVh bGl6YXRpb25zLCBsaWtlIHVzaW5nIG9uZSBvZiB0aGUgcm91dGVyIGlkIHBsdXMgdGhlIHR1bm5l bA0KaWQuIEkgdGhpbmsgd2UgaGFkIGJldHRlciBub3QgcmVzdHJpY3QgdGhlIGV4ZWN1dGlvbiB0 byBzdWNoIGEgbmFycm93IHNjb3BlLg0KV2hhdCBhYm91dCB0aGUgRUEgZm9ybWF0IGxpc3RlZCBi ZWxvdz88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFy aWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAyICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAzPGJyPg0KICZuYnNwOyAmbmJzcDsgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNw0KOCA5IDAgMTxicj4NCiAmbmJzcDsgJm5ic3A7Ky0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSs8YnI+DQogJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtMZW5ndGggJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwgQ2xhc3MtTnVtKDE5OSl8ICZuYnNwO0MtVHlwZSAoVEJBKQ0KfDxicj4NCiAmbmJzcDsgJm5i c3A7Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSs8YnI+DQogJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXNz b2NpYXRpb24gVHlwZSAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7fCAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBBc3NvY2lhdGlvbiBJRCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw O3w8YnI+DQogJm5ic3A7ICZuYnNwOystKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPGJyPg0KICZuYnNwOyAmbmJzcDt8ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDtJUHY0IEFzc29jaWF0aW9uIFNvdXJjZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiAmbmJz cDsgJm5ic3A7Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSs8YnI+DQogJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IEdsb2JhbCBBc3Nv Y2lhdGlvbiBTb3VyY2UgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQogJm5ic3A7ICZuYnNwOystKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPGJyPg0K ICZuYnNwOyAmbmJzcDt8RXh0ZW5kZWQgQXNzb2NpYXRpb24gRmxhZ3MuICZuYnNwOyAmbmJzcDt8 RXh0ZW5kZWQgQXNzb2NpYXRpb24NCklEIC4uLiAmbmJzcDsgJm5ic3A7fCA8YnI+DQogJm5ic3A7 ICZuYnNwOyArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KPGJyPg0KICZuYnNwOyAmbmJzcDsgfC4uLi4oY29udGludWUpICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOjxi cj4NCiAmbmJzcDsgJm5ic3A7Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9I2MwNTA0ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQombHQ7Ukcm Z3Q7IERvIHlvdSBtZWFuIHRvIGhhdmUgZXh0ZW5kZWQgYXNzb2NpYXRpb24gSUQgYXMgdHVubmVs IElEICgxNg0KYml0cykgKyBJUCBhZGRyZXNzICgzMiBiaXRzKSBpbiB0aGlzIG9iamVjdD88L2Zv bnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSNjMDUwNGQgZmFjZT0i Q2FsaWJyaSI+PGJyPg0KUGxlYXNlIHNlZSBpbmxpbmUgYmVsb3cuLiZsdDtSRzEmZ3Q7Li48L2Zv bnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDgwMDAg ZmFjZT0iQXJpYWwiPjxicj4NCiZsdDtmZWkmZ3Q7PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250 Pjxmb250IHNpemU9MiBjb2xvcj0jMDA4MDAwIGZhY2U9IkFyaWFsIj48YnI+DQpOby4gSSB3YW50 IHRvIHNheSB0aGF0IHRoaXMgZm9ybWF0IG9mIEVBIG9iamVjdHMgY2FuIGFjY29tb2RhdGUgbW9y ZSBraW5kcw0Kb2YgaW1wbGVtZW50YXRpb25zLiBMaWtlPC9mb250Pjxmb250IHNpemU9Mz4gPGJy Pg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA4MDAwIGZhY2U9IkFyaWFsIj48YnI+DQox KUFzc29jaWF0aW9uIElEOiB1c2VyIHByb3Zpc2lvbmVkIGlkZW50aWFsIHZhbHVlOyBBc3NvY2lh dGlvbiBTb3VyY2U6DQp0aGUgbG93ZSBpcCBhZGRyZXNzOyBFQSBJRDogdGhlIGhpZ2hlciBJUCBh ZGRyZXNzLiBBcyB5b3Ugc3VnZ2VzdGVkPC9mb250Pjxmb250IHNpemU9Mz4NCjxicj4NCjwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9IzAwODAwMCBmYWNlPSJBcmlhbCI+PGJyPg0KMilBc3NvY2lh dGlvbiBJRDogdHVubmVsIElEIG9yIHVzZXIgcHJvdmlzaW9uZWQgdmFsdWU7IEFzc29jaWF0aW9u IFNvdXJjZTpUdW5uZWwNCnNlbmRlciBhZGRyZXNzIG9yIHVzZXIgcHJvdmlzaW9uZWQ7IEVBIElE OiBiZSBlbXB0eSBvciBMU1AgSUQgb3IgYW55IG90aGVyDQppbmZvcm1hdGlvbi48L2ZvbnQ+PGZv bnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDgwMDAgZmFjZT0i QXJpYWwiPjxicj4NCjMpVGhlIHBvdGVudGlhbCBvdGhlciBpbXBsZW1lbnRhdGlvbnMuLi48L2Zv bnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDgwMDAg ZmFjZT0iQXJpYWwiPjxicj4NCklNSE8sIHRoZSBFQSBJRCBjYW4gYmUgSVAgYWRkcmVzcyBvciBh bnkgb3RoZXIgdmFsdWVzIGluIHRoZSBjb250ZXh0IG9mDQpBc3NvY2lhdGlvbiBTb3VyY2UgcGx1 cyBBc3NvY2lhdGlvbiBJRCwgd2hpY2ggaXMgYmFja3dhcmQgY29tcGF0aWJsZS48L2ZvbnQ+PGZv bnQgc2l6ZT0zPg0KPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdk IGZhY2U9IkFyaWFsIj4mbHQ7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA4MDAwIGZhY2U9 IkFyaWFsIj4vZmVpJmd0OzwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGNvbG9yPSMxZjQ5N2Q+PGJyPg0KJmx0O1JHMyZndDsgT2ssIHdlIHByb2JhYmx5IHNob3VsZCBh ZGQgdXNlIGNhc2VzIGZvciB2YXJpb3VzIG1ldGhvZHMuIEkNCmNhbiBzZWUgbWV0aG9kIDEgYmVp bmcgdXNlZCBmb3Igc2V0dGluZyB1cCBiaWRpcmVjdGlvbmFsIExTUHMgYnV0IEkgYW0NCm5vdCBz dXJlIGFib3V0IG1ldGhvZCAyIGZvciBleGFtcGxlLiBPbmUgd29ycnkgaXMgdGhhdCBkaWZmZXJl bnQgbWV0aG9kcw0KY2FuIGxlYWQgdG8gaW50ZXJvcCBpc3N1ZXMgaWYgb25lIHZlbmRvciBpbXBs ZW1lbnRzIG1ldGhvZCAxIGFuZCBzZWNvbmQNCnZlbmRvciBtZXRob2QgMi48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2Q+QXNzb2NpYXRpb24gb2JqZWN0IGlzIGJlaW5nIHVz ZWQgZm9yIGRpZmZlcmVudA0KYXNzb2NpYXRpb24gdHlwZXMgKFJGQyA0ODcyOiB0eXBlIDE6IFJl Y292ZXJ5KSwgKFJGQyA0ODczLSB0eXBlIDI6IFJlc291cmNlDQpzaGFyaW5nKSwgZXRjLiBhbmQg dGhlc2UgUkZDcyBkZWZpbmUgc3BlY2lmaWMgcHJvY2VkdXJlcyBmb3IgdGhlIGdpdmVuDQphc3Nv Y2lhdGlvbiB0eXBlLiBTbyBJTUhPLCBpdCBtYXkgYmUgb2sgdG8gZGVmaW5lIGEgc3RyaWN0ZXIg cHJvY2VkdXJlDQpmb3IgcG9wdWxhdGluZyBleHQgYXNzb2NpYXRpb24gb2JqZWN0IGZvciB0aGUg bmV3IEJpZGlyZWN0aW9uYWwgTFNQcyBhc3NvY2lhdGlvbg0KdHlwZS48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2Q+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBj b2xvcj0jMWY0OTdkPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5 N2Q+UmFrZXNoPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KPC9m b250Pg0KPHA+PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4NCjwvZm9udD4NCjxwPg0K --=_alternative 0032EA6348257A4F_=-- From zali@cisco.com Fri Aug 3 02:36:15 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC6021F8D8D for ; Fri, 3 Aug 2012 02:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXM-z5E0VKZ1 for ; Fri, 3 Aug 2012 02:36:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 84F7E21F8D82 for ; Fri, 3 Aug 2012 02:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zali@cisco.com; l=811; q=dns/txt; s=iport; t=1343986574; x=1345196174; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Dt2HsVNijI1qdrryMeNY05Bl/WgntuuJYZgxlrCQUZE=; b=k/Nliz6WGK0R7J48z02f/gGOexs1WayKRXP8wGVahJgheX8PJss6YbwB 9MVdhadsglwQzW01TyBXBof32I/cE+gKMd+y9qbWkWzgT/PIbBadh0Spo jPhbB0quLpUAbwT4VxNkCcoJr2qRsiOfHlQo2Qhy/Mja9xmb0jSHHDBoG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAB6bG1CtJXHA/2dsb2JhbABFhTSzcoEHgiABAQEEEgEnPwwEAgEIEQQBAQsUCQcyFAkIAgQBDQUIGodrnEqgLYtHhiRgA6NvgWaCXw X-IronPort-AV: E=Sophos;i="4.77,706,1336348800"; d="scan'208";a="108136905" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 03 Aug 2012 09:36:14 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q739aD9e006867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 09:36:13 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.69]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 04:36:13 -0500 From: "Zafar Ali (zali)" To: "adrian@olddog.co.uk" , "ccamp@ietf.org" Thread-Topic: [CCAMP] [Technical Errata Reported] RFC4872 (3304) Thread-Index: AQHNbzsfFZzh5ZC7+kKOIa930++KWJdEfyWAgAEr+aCAAayuAP//roTQgABbswCAAHSdYA== Date: Fri, 3 Aug 2012 09:36:12 +0000 Message-ID: References: <20120731163915.6B942621A0@rfc-editor.org> <024801cd6f84$ea1d5710$be580530$@olddog.co.uk> <01cf01cd70f1$3e459830$bad0c890$@olddog.co.uk> <01de01cd70f6$58503690$08f0a3b0$@olddog.co.uk> In-Reply-To: <01de01cd70f6$58503690$08f0a3b0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.152] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.002 x-tm-as-result: No--27.459000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jplang@ieee.org" , "dimitri.papadimitriou@alcatel-lucent.be" , "dbrungard@att.com" Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 09:36:15 -0000 Hi Adrian-=20 Please see in-line.=20 Thanks Regards ... Zafar=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Thursday, August 02, 2012 5:33 PM > To: Zafar Ali (zali); ccamp@ietf.org > Cc: dimitri.papadimitriou@alcatel-lucent.be; jplang@ieee.org; > dbrungard@att.com > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304) >=20 > Oh dear. >=20 > First, let me re-assert... >=20 > The discussion of whether you might want to do it (that we are having > now) is > orthogonal to whether it is possible. I have no issue that it is > possible, and I > don't think any changes are needed to any documents to enable it or to > say that > it is possible. >=20 Yes, agreed!=20 =20 From rgandhi@cisco.com Fri Aug 3 05:12:02 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A960D21F8D7F for ; Fri, 3 Aug 2012 05:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FR_3TAG_3TAG=1.758, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, J_CHICKENPOX_93=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mea6Shj8TXHq for ; Fri, 3 Aug 2012 05:12:00 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4B53221F8D7D for ; Fri, 3 Aug 2012 05:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=36883; q=dns/txt; s=iport; t=1343995920; x=1345205520; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=E5yTDrrWSYZoA06qdlvf2HDcNMihQnmMIU361mLmjMQ=; b=HfHyo/7cfNODpgrCNbsfQPuHoaE7sgM8rmyXNgweJeTodR3+rye0V1Jb iV6QtMiC1viEhCVJa1IGRv96QnQyUs6+JU57svwC0dBtC1oFa2C0MLRCp ycw19d58L2AnQjlRUkwKgZA45zeSE+B3fEaPm2FLPBK6yG69GpJK8p2/E Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAA2/G1CtJXHA/2dsb2JhbABFgkqDMbIodYEHgiABAQEEEgEaTBACAQYCEQQBAQsWAQYFAgIwFAkIAgQOBQgah2ucO40TCJMWi0iFbjZgA6NxgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,706,1336348800"; d="scan'208,217";a="108201942" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 03 Aug 2012 12:11:58 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q73CBwCG018759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 12:11:58 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.202]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 07:11:57 -0500 From: "Rakesh Gandhi (rgandhi)" To: "zhang.fei3@zte.com.cn" Thread-Topic: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 Thread-Index: AQHNWlnLzkulPBoZQRGX7309/bFmI5cz9gXQgAT+uQCAAB3KsIABhIgAgAeIEfCAAQFrgIAAozjggASMooD//9ocsA== Date: Fri, 3 Aug 2012 12:11:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.246.164] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.002 x-tm-as-result: No--57.362700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_B7D2A316AA32B6469D9670B6A81B7C2404C87Axmbalnx07ciscocom_" MIME-Version: 1.0 Cc: "Robert Sawaya \(rsawaya\)" , "yang.fan5@zte.com.cn" , CCAMP , "jingrq@ctbri.com.cn" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 12:12:02 -0000 --_000_B7D2A316AA32B6469D9670B6A81B7C2404C87Axmbalnx07ciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmtzIEZlaS4gV2UgYXJlIGFsbW9zdCB0aGVyZS4gUGxlYXNlIHNlZSBpbmxpbmUuLjxSRzQ+ Lg0KDQpGcm9tOiB6aGFuZy5mZWkzQHp0ZS5jb20uY24gW21haWx0bzp6aGFuZy5mZWkzQHp0ZS5j b20uY25dDQpTZW50OiBGcmlkYXksIEF1Z3VzdCAwMywgMjAxMiA1OjE2IEFNDQpUbzogUmFrZXNo IEdhbmRoaSAocmdhbmRoaSkNCkNjOiBDQ0FNUDsgRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7IGpp YW5nLndlaWxpYW5AenRlLmNvbS5jbjsgamluZ3JxQGN0YnJpLmNvbS5jbjsgUm9iZXJ0IFNhd2F5 YSAocnNhd2F5YSk7IEdlb3JnZSBTd2FsbG93IChzd2FsbG93KTsgeWFuZy5mYW41QHp0ZS5jb20u Y24NClN1YmplY3Q6IFJFOiBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2 cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wMw0KDQoNCkhpIFJha2VzaA0KDQpTbmlwcGVkIHRoZSBv dGhlciBwYXJ0cyBmb3IgZWFzeSByZWFkaW5nLCBzb3JyeSBmb3IgdGhlIGRlbGF5ZWQgcmVzcG9u c2UNCg0KPFJHMz4gVGhlcmUgYXJlIGFwcGxpY2F0aW9ucyB0aGF0IHJlcXVpcmUgY28tcm91dGVk IExTUHMuIFNvIEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSBmbGFnIHRvIGluZGljYXRlIHRoYXQg TFNQcyBtdXN0IGJlIGNvLXJvdXRlZCwgZWxzZSBub2RlIHdpbGwgc2VuZCBhIHBhdGggZXJyb3Ig Zm9yIGV4YW1wbGUgaWYgcmVxdWVzdCBjYW5ub3QgYmUgbWV0LiAgSSBhZ3JlZSB3aXRoIHlvdSBh Ym91dCBjb21wbGV4aXR5IHdpdGggZG91YmxlIHNpZGVkIHByb3Zpc2lvbmluZyBtb2RlbCB0aG91 Z2guDQoNCjxmZWk+IFNpbmNlIHlvdSBiZWxpZXZlIHRoYXQgYSBjb21tb24gbWVjaGFuaXNtIHVz ZWQgZm9yIHRoZSBub24tY29yb3V0ZWQgYW5kIGNvcm91dGVkIGNhc2VzIGlzIHVzZWZ1bCwgd2Ug d2lsbCBhZGQgdGhlIHRleHRzIGluIHRoZSBuZXh0IHZlcnNpb24uDQo8Ukc0PiBUaGlzIGlzIGdy ZWF0LiBUaGFua3MuDQoNCg0KPFJHMz4gT2ssIHdlIHByb2JhYmx5IHNob3VsZCBhZGQgdXNlIGNh c2VzIGZvciB2YXJpb3VzIG1ldGhvZHMuIEkgY2FuIHNlZSBtZXRob2QgMSBiZWluZyB1c2VkIGZv ciBzZXR0aW5nIHVwIGJpZGlyZWN0aW9uYWwgTFNQcyBidXQgSSBhbSBub3Qgc3VyZSBhYm91dCBt ZXRob2QgMiBmb3IgZXhhbXBsZS4gT25lIHdvcnJ5IGlzIHRoYXQgZGlmZmVyZW50IG1ldGhvZHMg Y2FuIGxlYWQgdG8gaW50ZXJvcCBpc3N1ZXMgaWYgb25lIHZlbmRvciBpbXBsZW1lbnRzIG1ldGhv ZCAxIGFuZCBzZWNvbmQgdmVuZG9yIG1ldGhvZCAyLg0KQXNzb2NpYXRpb24gb2JqZWN0IGlzIGJl aW5nIHVzZWQgZm9yIGRpZmZlcmVudCBhc3NvY2lhdGlvbiB0eXBlcyAoUkZDIDQ4NzI6IHR5cGUg MTogUmVjb3ZlcnkpLCAoUkZDIDQ4NzMtIHR5cGUgMjogUmVzb3VyY2Ugc2hhcmluZyksIGV0Yy4g YW5kIHRoZXNlIFJGQ3MgZGVmaW5lIHNwZWNpZmljIHByb2NlZHVyZXMgZm9yIHRoZSBnaXZlbiBh c3NvY2lhdGlvbiB0eXBlLiBTbyBJTUhPLCBpdCBtYXkgYmUgb2sgdG8gZGVmaW5lIGEgc3RyaWN0 ZXIgcHJvY2VkdXJlIGZvciBwb3B1bGF0aW5nIGV4dCBhc3NvY2lhdGlvbiBvYmplY3QgZm9yIHRo ZSBuZXcgQmlkaXJlY3Rpb25hbCBMU1BzIGFzc29jaWF0aW9uIHR5cGUuDQoNCjxmZWk+IE1ldGhv ZCAyIHdvcmtzIHdlbGwsIGFuZCB0aGUgb25seSBkaWZmZXJlbmNlIGlzIHQgaG93IHRvIHJlcHJl c2VudCB0aGUgZ2xvYmFsIHVuaXF1ZSBpZGVudGlmaWVyLiBGb3IgdGhlIGFzc29jaWF0aW9uIGlz IGJhc2VkIG9uIHRoZSBmdWxsIG1hdGNoIG9mIHRoZSBFQSBvYmplY3RzLCB0aGUgRUEgb2JqZWN0 IGlzIGp1c3QgY29waWVkIGZyb20gdGhlIHBhdGggbWVzc2FnZSBpbnRvIGFub3RoZXIgcGF0aCBt ZXNzYWdlIGluIHNpbmdsZSBzaWRlZCBwcm92aXNpb25pbmcgbW9kZWwuIEFzIHRvIHRoZSBkb3Vi bGVkIHNpZGVkIHByb3Zpc2lvbmluZyBtb2RlbCwgdGhlIEVBIG9iamVjdHMgaXMgYWxzbyB0aGUg c2FtZS4gSU1ITywgdGhlcmUgaXMgbm8gaW50ZXJvcCBpc3N1ZXMsIG9yIGRvIEkgaGF2ZSBzb21l IG1pc3VuZGVyc3RhbmRpbmc/DQoNClllYWgsIHdlIGNhbiBkZWZpbmUgYSBzdHJpY3RlciBwcm9k ZWR1cmUsIEkgYW0gbm90IHN1cmUgdGhpcyBpcyBhIGdvb2Qgd2F5IGluIHN0YW5kYXJkLCBuZWVk IG1vcmUgZmVlZGJhY2sgZnJvbSB0aGUgV0cuDQo8Ukc0PiBJIGFncmVlIHRoYXQgaWYgYm90aCB2 ZW5kb3JzIGltcGxlbWVudCBzYXkgbWV0aG9kIDEgb3IgYm90aCB2ZW5kb3JzIGltcGxlbWVudCBz YXkgbWV0aG9kIDIgdGhlbiB0aGV5IHdvdWxkIGludGVyb3BlcmF0ZSwgYW5kICBleHQgRUEgb2Jq ZWN0cyBhcmUgdGhlIHNhbWUuIEJ1dCBtZXRob2QgMSBhbmQgbWV0aG9kIDIgbWF5IG5vdCBpbnRl cm9wZXJhdGUgdG9nZXRoZXIuICBOb3Qgc3VyZSBpZiB3ZSB3YW50IHRvIGhhdmUgYSBzZXBhcmF0 ZSBmbGFnIHRvIGluZGljYXRlIGlmIGV4dCBhc3NvY2lhdGlvbiBvYmplY3QgaXMgcG9wdWxhdGVk IHdpdGggbWV0aG9kIDEgb3IgMiB0byBjb3ZlciB0aGlzIGNhc2U/ICAgSXQgaXMgZmluZSB0byBo YXZlIG1vcmUgdGhhbiBvbmUgbWV0aG9kIGluIHRoZSBkcmFmdCBmb3IgZmxleGliaWxpdHkgYW5k IGZ1dHVyZSB1c2UgYnV0IGdvb2QgdG8gZWxhYm9yYXRlIG9uIHRoZSBwb3NzaWJsZSB1c2UgY2Fz ZSBpZiB3ZSBrbm93IG9mIGFueS4NClRoYW5rcywNClJha2VzaA0KDQoNCkNoZWVyDQoNCkZlaQ0K DQoiUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkiIDxyZ2FuZGhpQGNpc2NvLmNvbTxtYWlsdG86cmdh bmRoaUBjaXNjby5jb20+Pg0KDQoyMDEyLTA4LTAxIDAxOjI0DQoNCsrVvP7Iyw0KDQoiemhhbmcu ZmVpM0B6dGUuY29tLmNuPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+IiA8emhhbmcuZmVp M0B6dGUuY29tLmNuPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+Pg0KDQqzrcvNDQoNCiJF cmljIE9zYm9ybmUgKGVvc2Jvcm5lKSIgPGVvc2Jvcm5lQGNpc2NvLmNvbTxtYWlsdG86ZW9zYm9y bmVAY2lzY28uY29tPj4sICJqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY248bWFpbHRvOmppYW5nLndl aWxpYW5AenRlLmNvbS5jbj4iIDxqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY248bWFpbHRvOmppYW5n LndlaWxpYW5AenRlLmNvbS5jbj4+LCAiamluZ3JxQGN0YnJpLmNvbS5jbjxtYWlsdG86amluZ3Jx QGN0YnJpLmNvbS5jbj4iIDxqaW5ncnFAY3RicmkuY29tLmNuPG1haWx0bzpqaW5ncnFAY3Ricmku Y29tLmNuPj4sICJSb2JlcnQgU2F3YXlhIChyc2F3YXlhKSIgPHJzYXdheWFAY2lzY28uY29tPG1h aWx0bzpyc2F3YXlhQGNpc2NvLmNvbT4+LCAiR2VvcmdlIFN3YWxsb3cgKHN3YWxsb3cpIiA8c3dh bGxvd0BjaXNjby5jb208bWFpbHRvOnN3YWxsb3dAY2lzY28uY29tPj4sICJ5YW5nLmZhbjVAenRl LmNvbS5jbjxtYWlsdG86eWFuZy5mYW41QHp0ZS5jb20uY24+IiA8eWFuZy5mYW41QHp0ZS5jb20u Y248bWFpbHRvOnlhbmcuZmFuNUB6dGUuY29tLmNuPj4sIENDQU1QIDxjY2FtcEBpZXRmLm9yZzxt YWlsdG86Y2NhbXBAaWV0Zi5vcmc+Pg0KDQrW98ziDQoNClJFOiBDb21tZW50cyBvbiBkcmFmdC1p ZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wMw0KDQoNCg0KDQoN Cg0KDQpIaSBGZWksDQoNClRoYW5rcyBmb3IgeW91ciBraW5kIHJlcGx5LiBQbGVhc2Ugc2VlIGlu bGluZS4uPFJHMz4uLg0KDQo8U25pcHBlZCBlbWFpbCB0byBmb2N1cyBvbiBvcGVuIGl0ZW1zPg0K DQoNCkZyb206IHpoYW5nLmZlaTNAenRlLmNvbS5jbjxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29t LmNuPiBbbWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbl08bWFpbHRvOlttYWlsdG86emhhbmcu ZmVpM0B6dGUuY29tLmNuXT4NClNlbnQ6IE1vbmRheSwgSnVseSAzMCwgMjAxMiAxMDowNCBQTQ0K VG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQpDYzogRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7 IGppYW5nLndlaWxpYW5AenRlLmNvbS5jbjxtYWlsdG86amlhbmcud2VpbGlhbkB6dGUuY29tLmNu PjsgamluZ3JxQGN0YnJpLmNvbS5jbjxtYWlsdG86amluZ3JxQGN0YnJpLmNvbS5jbj47IFJvYmVy dCBTYXdheWEgKHJzYXdheWEpOyBHZW9yZ2UgU3dhbGxvdyAoc3dhbGxvdyk7IHlhbmcuZmFuNUB6 dGUuY29tLmNuPG1haWx0bzp5YW5nLmZhbjVAenRlLmNvbS5jbj47IENDQU1QDQpTdWJqZWN0OiBS RTogQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2Np YXRlZC1sc3AtMDMNCg0KVGhhbmsgeW91IFJha2VzaCBmb3Igc2hhcmluZyB5b3VyIGlkZWEsIEkg dGhpbmsgd2UgYXJlIHJvdWdobHkgaW4gYWdyZWVtZW50IGFuZCBuZWVkIHRvIGhlYXIgbW9yZSB2 b2ljZXMgZnJvbSB0aGUgV0cuIDopDQoNClNlZSBpbmxpbmUgPGZlaT48L2ZlaT4NCg0KQmVzdA0K DQpGZWkNCg0KMikgRGVmaW5lIG9uZSBmbGFnIGZvciBjby1yb3V0ZWQgb3Igbm9uLWNvcm91dGVk LiBJZiB0aGUgY28tcm91dGVkIGJpZGlyIGlzIHRoZSBkZWZhdWx0IGJlaGF2aW9yLCB3aHkgbm90 IHVzaW5nIHRoZSBwcm9jZWR1cmUgZGVmaW5lZCBpbiBSRkMzNDczPyBJIGFtIGFmcmFpZCBpdCBp cyBoYXJkDQp0byBwZXJzdWFkZSB0aGUgV0cgdG8gZG8gc28uIE1heWJlIHRoZSBiZXR0ZXIgd2F5 IGlzIHRoYXQgbm9uLWNvcm91dGVkIGJpZGlyIGlzIHRoZSBkZWZhdWx0LCBhbmQgdGhlIHNldCBv ZiB0aGUgY28tcm91dGVkIGZsYWcgb25seSBtZWFucyB0aGF0IGl0IGlzIHJlY29tbWVuZGVkLCBu b3QgbWFuZGF0b3J5LCB0aGUgY2hlY2tpbmcgd2hldGhlciB0aGUgTFNQIGlzIGNvLXJvdXRlZCBj YW4gYmUgZG9uZSBieSBjb21wYXJpbmcgdGhlIFJSTyBvYmplY3RzLiBXaGF0IGlzIHlvdXIgb3Bp bmlvbj8NCjxSRzE+IEl0IGlzIGZpbmUgdG8gaGF2ZSBub24gY28tcm91dGVkIGFzIGRlZmF1bHQu IFJGQyAzNDczIGlzIGEgR01QTFMgc2lnbmFsaW5nIHByb2NlZHVyZS4gSXQgbWF5IG5vdCBiZSBv cHRpbWFsICB0byBoYXZlIHR3byBkaWZmZXJlbnQgc2lnbmFsaW5nIHByb2NlZHVyZXMsIG9uZSBm b3Igbm9uIGNvLXJvdXRlZCAoZXh0IGFzc29jaWF0ZWQgb2JqZWN0KSBhbmQgb25lIGZvciBjby1y b3V0ZWQgKFJGQyAzNDczKSBwcm9jZWR1cmVzLiBCeSBhZGRpbmcgYSBmbGFnIGZvciBjby1yb3V0 ZWQsIHNhbWUgc2lnbmFsaW5nIChleHQgYXNzb2NpYXRlZCBvYmplY3QpIGNhbiBiZSB1c2VkIGZv ciBib3RoIHdoaWNoIGlzIG5pY2UuIFdlIGJlbGlldmUgY29tcGFyaW5nIG9mIFJSTyBjYW4gYmUg bWlzbGVhZGluZyBiZWNhdXNlIHR3byBMU1BzIGNhbiBiZSBvbiB0aGUgc2FtZSBwYXRoIGV2ZW4g dGhvdWdoIHByb3Zpc2lvbmVkIHRvIGJlIG5vbiBjby1yb3V0ZWQuDQoNCjxmZWk+DQpTb3JyeSB0 aGF0IHdoYXQgSSBzdWdnZXN0ZWQgbWF5YmUgbWlzbGVhZCB5b3UsIHRoZSBmb2xsb3dpbmcgZGVz Y3JpcGl0b25zIGFyZSBtb3JlIGFjY3VyYXRlLiA6KQ0KMSlUaGUgZGVmYXVsdCBiZWhhdmlvciAo bm9uLWNvcm91dGVkKSBtZWFucyB0aGF0IGl0IGlzIG5vdCByZXF1aXJlZCB0byBiZSBjby1yb3V0 ZWQuIEluIG90aGVyIHdvcmRzLCBpdCBpcyBhbHNvIE9LIHRoYXQgdGhlIHR3byBwYXRocyBhcmUg YWxvbmcgdGhlIHNhbWUgcGF0aA0KDQouDQo8UkczPiBBZ3JlZS4NCg0KMilUaGUgZmxhZyBzZXQg bWVhbnMgdGhhdCBjby1yb3V0ZWQgaXMgcmVjb21tZW5kZWQuIEluIG90aGVyIHdvcmRzLCB0aGUg cmV2ZXJzZSBMU1AgU0hPVUxEIGJlIGVzdGFibGlzaGVkIGluIHRoZSBzYW1lIHBhdGggYXMgbXVj aCBhcyBwb3NzaWJsZS4gSWYgdGhlIGZsYWcgc2V0IG1lYW5zDQp0aGF0IGNvLXJvdXRlZCBpcyBt YW5kYXRvcnksdGhlIHByb2NlZHVyZXMgd2lsbCBiZSB2ZXJ5IGNvbXBsZXggaW4gZG91YmxlIHNp ZGVkIHByb3Zpc2lvbmluZyBtb2RlbC4NCjwvZmVpPg0KPFJHMz4gVGhlcmUgYXJlIGFwcGxpY2F0 aW9ucyB0aGF0IHJlcXVpcmUgY28tcm91dGVkIExTUHMuIFNvIEkgdGhpbmsgd2Ugc2hvdWxkIGhh dmUgYSBmbGFnIHRvIGluZGljYXRlIHRoYXQgTFNQcyBtdXN0IGJlIGNvLXJvdXRlZCwgZWxzZSBu b2RlIHdpbGwgc2VuZCBhIHBhdGggZXJyb3IgZm9yIGV4YW1wbGUgaWYgcmVxdWVzdCBjYW5ub3Qg YmUgbWV0LiAgSSBhZ3JlZSB3aXRoIHlvdSBhYm91dCBjb21wbGV4aXR5IHdpdGggZG91YmxlIHNp ZGVkIHByb3Zpc2lvbmluZyBtb2RlbCB0aG91Z2guDQoNCg0KMylBcyB0byB0aGUgdHVwbGUgb2Yg PGxvd2VyIGlwIGFkZHJlc3MsIGhpZ2ggaXAgYWRkcmVzcywgYXNzb2NpYXRpb24gaWQ+LCB5ZWFo LCBpdCBpcyBvbmUga2luZCBvZiBpbXBsZW1lbnRhdGlvbiwgYnV0IHRoZXJlIGFyZSBwb3RlbnRp YWwgc29tZSBvdGhlciByZWFsaXphdGlvbnMsIGxpa2UgdXNpbmcgb25lIG9mIHRoZSByb3V0ZXIg aWQgcGx1cyB0aGUgdHVubmVsIGlkLiBJIHRoaW5rIHdlIGhhZCBiZXR0ZXIgbm90IHJlc3RyaWN0 IHRoZSBleGVjdXRpb24gdG8gc3VjaCBhIG5hcnJvdyBzY29wZS4gV2hhdCBhYm91dCB0aGUgRUEg Zm9ybWF0IGxpc3RlZCBiZWxvdz8NCg0KICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAg ICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogICB8ICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgIHwgQ2xhc3MtTnVtKDE5OSl8 ICBDLVR5cGUgKFRCQSkgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgQXNzb2NpYXRpb24gVHlw ZSAgICAgICAgfCAgICAgICBBc3NvY2lhdGlvbiBJRCAgICAgICAgICB8DQogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K ICAgfCAgICAgICAgICAgICAgICAgICAgSVB2NCBBc3NvY2lhdGlvbiBTb3VyY2UgICAgICAgICAg ICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgIEdsb2JhbCBB c3NvY2lhdGlvbiBTb3VyY2UgICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHxF eHRlbmRlZCBBc3NvY2lhdGlvbiBGbGFncy4gICAgfEV4dGVuZGVkIEFzc29jaWF0aW9uIElEIC4u LiAgICB8DQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICB8Li4uLihjb250aW51ZSkgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOg0KICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KPFJHPiBE byB5b3UgbWVhbiB0byBoYXZlIGV4dGVuZGVkIGFzc29jaWF0aW9uIElEIGFzIHR1bm5lbCBJRCAo MTYgYml0cykgKyBJUCBhZGRyZXNzICgzMiBiaXRzKSBpbiB0aGlzIG9iamVjdD8NClBsZWFzZSBz ZWUgaW5saW5lIGJlbG93Li48UkcxPi4uDQoNCjxmZWk+DQpOby4gSSB3YW50IHRvIHNheSB0aGF0 IHRoaXMgZm9ybWF0IG9mIEVBIG9iamVjdHMgY2FuIGFjY29tb2RhdGUgbW9yZSBraW5kcyBvZiBp bXBsZW1lbnRhdGlvbnMuIExpa2UNCg0KMSlBc3NvY2lhdGlvbiBJRDogdXNlciBwcm92aXNpb25l ZCBpZGVudGlhbCB2YWx1ZTsgQXNzb2NpYXRpb24gU291cmNlOiB0aGUgbG93ZSBpcCBhZGRyZXNz OyBFQSBJRDogdGhlIGhpZ2hlciBJUCBhZGRyZXNzLiBBcyB5b3Ugc3VnZ2VzdGVkDQoNCjIpQXNz b2NpYXRpb24gSUQ6IHR1bm5lbCBJRCBvciB1c2VyIHByb3Zpc2lvbmVkIHZhbHVlOyBBc3NvY2lh dGlvbiBTb3VyY2U6VHVubmVsIHNlbmRlciBhZGRyZXNzIG9yIHVzZXIgcHJvdmlzaW9uZWQ7IEVB IElEOiBiZSBlbXB0eSBvciBMU1AgSUQgb3IgYW55IG90aGVyIGluZm9ybWF0aW9uLg0KDQozKVRo ZSBwb3RlbnRpYWwgb3RoZXIgaW1wbGVtZW50YXRpb25zLi4uDQoNCklNSE8sIHRoZSBFQSBJRCBj YW4gYmUgSVAgYWRkcmVzcyBvciBhbnkgb3RoZXIgdmFsdWVzIGluIHRoZSBjb250ZXh0IG9mIEFz c29jaWF0aW9uIFNvdXJjZSBwbHVzIEFzc29jaWF0aW9uIElELCB3aGljaCBpcyBiYWNrd2FyZCBj b21wYXRpYmxlLg0KDQo8L2ZlaT4NCjxSRzM+IE9rLCB3ZSBwcm9iYWJseSBzaG91bGQgYWRkIHVz ZSBjYXNlcyBmb3IgdmFyaW91cyBtZXRob2RzLiBJIGNhbiBzZWUgbWV0aG9kIDEgYmVpbmcgdXNl ZCBmb3Igc2V0dGluZyB1cCBiaWRpcmVjdGlvbmFsIExTUHMgYnV0IEkgYW0gbm90IHN1cmUgYWJv dXQgbWV0aG9kIDIgZm9yIGV4YW1wbGUuIE9uZSB3b3JyeSBpcyB0aGF0IGRpZmZlcmVudCBtZXRo b2RzIGNhbiBsZWFkIHRvIGludGVyb3AgaXNzdWVzIGlmIG9uZSB2ZW5kb3IgaW1wbGVtZW50cyBt ZXRob2QgMSBhbmQgc2Vjb25kIHZlbmRvciBtZXRob2QgMi4NCkFzc29jaWF0aW9uIG9iamVjdCBp cyBiZWluZyB1c2VkIGZvciBkaWZmZXJlbnQgYXNzb2NpYXRpb24gdHlwZXMgKFJGQyA0ODcyOiB0 eXBlIDE6IFJlY292ZXJ5KSwgKFJGQyA0ODczLSB0eXBlIDI6IFJlc291cmNlIHNoYXJpbmcpLCBl dGMuIGFuZCB0aGVzZSBSRkNzIGRlZmluZSBzcGVjaWZpYyBwcm9jZWR1cmVzIGZvciB0aGUgZ2l2 ZW4gYXNzb2NpYXRpb24gdHlwZS4gU28gSU1ITywgaXQgbWF5IGJlIG9rIHRvIGRlZmluZSBhIHN0 cmljdGVyIHByb2NlZHVyZSBmb3IgcG9wdWxhdGluZyBleHQgYXNzb2NpYXRpb24gb2JqZWN0IGZv ciB0aGUgbmV3IEJpZGlyZWN0aW9uYWwgTFNQcyBhc3NvY2lhdGlvbiB0eXBlLg0KDQpUaGFua3Ms DQpSYWtlc2gNCg0KDQo= --_000_B7D2A316AA32B6469D9670B6A81B7C2404C87Axmbalnx07ciscocom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Thanks Fei. We are almost= there. Please see inline..<RG4>.

 <= /p>

From: zhang.fe= i3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]
Sent: Friday, August 03, 2012 5:16 AM
To: Rakesh Gandhi (rgandhi)
Cc: CCAMP; Eric Osborne (eosborne); jiang.weilian@zte.com.cn; jingrq= @ctbri.com.cn; Robert Sawaya (rsawaya); George Swallow (swallow); yang.fan5= @zte.com.cn
Subject: RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associa= ted-lsp-03

 


Hi Rakesh

Snipped the other parts for easy reading, sorry for the delayed = response

<RG3> There are applications that requi= re co-routed LSPs. So I think we should have a flag to indicate that LSPs m= ust be co-routed, else node will send a path error for example if request cannot be met.  I agree with you about complexity with dou= ble sided provisioning model though.

<fei> Since you believe that a common mechanism used for t= he non-corouted and corouted cases is useful, we will add the texts in the = next version.

<RG4> This is great. Thanks.



<RG3> Ok, we probably should add use ca= ses for various methods. I can see method 1 being used for setting up bidir= ectional LSPs but I am not sure about method 2 for example. One worry is th= at different methods can lead to interop issues if one vendor implements method 1 and second vendor method 2.
Association object is being used for differen= t association types (RFC 4872: type 1: Recovery), (RFC 4873- type 2: Resour= ce sharing), etc. and these RFCs define specific procedures for the given a= ssociation type. So IMHO, it may be ok to define a stricter procedure for populating ext association object fo= r the new Bidirectional LSPs association type.

<fei> Method 2 works well, and the only difference is t ho= w to represent the global unique identifier. For the association is based o= n the full match of the EA objects, the EA object is just copied from the path message into another path message in single sided provisioni= ng model. As to the doubled sided provisioning model, the EA objects is als= o the same. IMHO, there is no interop issues, or do I have some misundersta= nding?

Yeah, we can define a stricter prodedure, I am not sure this is = a good way in standard, need more feedback from the WG.

<RG4> I agree that if both vendors implement say method 1 or bo= th vendors implement say method 2 then they would interoperate, and  ext EA objects are the same. But method 1 and method 2 may not i= nteroperate together.  Not sure if we want to have a separate flag to = indicate if ext association object is populated with method 1 or 2 to cover= this case?   It is fine to have more than one method in the draft for flexibility and future use but good to elabora= te on the possible use case if we know of any.

Thanks,

Rakesh



Cheer

Fei

"Rakesh Gandhi (rgandhi)" <= ;rgandhi@cisco.com><= span style=3D"font-size:7.5pt;font-family:"Arial","sans-seri= f"">

2012-08-01 01:24

=CA=D5=BC=FE=C8=CB<= /p>

"zhang.fei3@zte.com.cn" <zhang.fei3@zte.com.cn>

=B3=AD=CB=CD

"Eric Osborne (eosborne)" <eosborne@cisco.com>, "jiang.weilian@zte.com.cn" &= lt;jiang.weilian@zte.com.cn= >, "jingrq@ctbri.com.cn"= <jingrq@ctbri.com.cn>, &q= uot;Robert Sawaya (rsawaya)" <= rsawaya@cisco.com>, "George Swallow (swallow)" <swallow@cisco.com>, "yang.fan5@zte.com.cn&quo= t; <yang.fan5@zte.com.cn>= , CCAMP <ccamp@ietf.org>

=D6=F7=CC=E2

RE: Comments on draft-ietf-ccamp-mpls-tp-r= svpte-ext-associated-lsp-03

 




Hi Fei,
 
Thanks for your kind reply. Please see inline= ..<RG3>..
 
<Snipped email to focus on open items><= /span>
 
 
From: zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]
Sent: Monday, July 30, 2012 10:04 PM
To: Rakesh Gandhi (rgandhi)
Cc: Eric Osborne (eosborne); jiang.weilian@zte.com.cn; jingrq@ctbri.com.cn; Robert Sawa= ya (rsawaya); George Swallow (swallow); yang.fan5@zte.com.cn; CCAMP<= br> Subject: RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated= -lsp-03

Thank you Rakesh for sharing your idea, I think we are roughly in agreement= and need to hear more voices from the WG. :)

See inline <fei></fei>

Best

Fei

2) Define one flag for co-routed or non-corouted. If the co-rout= ed bidir is the default behavior, why not using the procedure defined in RF= C3473? I am afraid it is hard
to persuade the WG to do so. Maybe the better way is that non-corouted bidi= r is the default, and the set of the co-routed flag only means that it is r= ecommended, not mandatory, the checking whether the LSP is co-routed can be= done by comparing the RRO objects. What is your opinion?
<RG1> It is fine to have non co-routed as default. RFC 3473 is a GMPL= S signaling procedure. It may not be optimal  to have two different si= gnaling procedures, one for non co-routed (ext associated object) and one f= or co-routed (RFC 3473) procedures. By adding a flag for co-routed, same signaling (ext associated object) can be used f= or both which is nice. We believe comparing of RRO can be misleading becaus= e two LSPs can be on the same path even though provisioned to be non co-rou= ted.

<fei>
Sorry that what I suggested maybe mislead you, the following descripitons a= re more accurate. :)
1)The default behavior (non-corouted) means that it is not required to be c= o-routed. In other words, it is also OK that the two paths are along the sa= me path
 
.
<RG3> Agree.

2)The flag set means that co-routed is recommended. In other words, the rev= erse LSP SHOULD be established in the same path as much as possible. If the= flag set means
that co-routed is mandatory,the procedures will be very complex in double s= ided provisioning model.
</fei>
<RG3> There are applications that requi= re co-routed LSPs. So I think we should have a flag to indicate that LSPs m= ust be co-routed, else node will send a path error for example if request cannot be met.  I agree with you about complexity with dou= ble sided provisioning model though.


3)As to the tuple of <lower ip address, high ip address, association id&= gt;, yeah, it is one kind of implementation, but there are potential some o= ther realizations, like using one of the router id plus the tunnel id. I th= ink we had better not restrict the execution to such a narrow scope. What about the EA format listed below?

       0             &nb= sp;     1                =   2                   3<= br>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |            Length    = ;         | Class-Num(199)|  C-Type (TBA) |
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |       Association Type       &= nbsp;|       Association ID         &nbs= p;|
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |                 &nbs= p;  IPv4 Association Source             =        |
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |                 &nbs= p; Global Association Source             &nbs= p;     |
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |Extended Association Flags.    |Extended Associatio= n ID ...    |
    +-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+
    |....(continue)             &nb= sp;                     &= nbsp;             :
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+

<RG> Do you mean to have extended association ID as tunnel ID (16 bit= s) + IP address (32 bits) in this object?
Please see inline below..<RG1>..

<fei>
No. I want to say that this format of EA objects can accomodate more kinds = of implementations. Like

1)Association ID: user provisioned idential value; Association Source: the = lowe ip address; EA ID: the higher IP address. As you suggested

2)Association ID: tunnel ID or user provisioned value; Association Source:T= unnel sender address or user provisioned; EA ID: be empty or LSP ID or any = other information.

3)The potential other implementations...

IMHO, the EA ID can be IP address or any other values in the context of Ass= ociation Source plus Association ID, which is backward compatible.

</fei>
<RG3> Ok, we probably should add use cases for various methods. I can= see method 1 being used for setting up bidirectional LSPs but I am not sur= e about method 2 for example. One worry is that different methods can lead = to interop issues if one vendor implements method 1 and second vendor method 2.
Association object is being used for differen= t association types (RFC 4872: type 1: Recovery), (RFC 4873- type 2: Resour= ce sharing), etc. and these RFCs define specific procedures for the given a= ssociation type. So IMHO, it may be ok to define a stricter procedure for populating ext association object fo= r the new Bidirectional LSPs association type.
 
Thanks,
Rakesh

 

--_000_B7D2A316AA32B6469D9670B6A81B7C2404C87Axmbalnx07ciscocom_-- From lberger@labn.net Fri Aug 3 14:14:03 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB9411E80A6 for ; Fri, 3 Aug 2012 14:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.088 X-Spam-Level: X-Spam-Status: No, score=-97.088 tagged_above=-999 required=5 tests=[AWL=1.584, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ2jGxoa0oA7 for ; Fri, 3 Aug 2012 14:14:02 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id A1A4E11E8091 for ; Fri, 3 Aug 2012 14:14:02 -0700 (PDT) Received: (qmail 10903 invoked by uid 0); 3 Aug 2012 21:14:00 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 3 Aug 2012 21:14:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=ZiBYC/D+ZAFctJ1ncWTm9zfAbedfLyOkEgSCo5kt/pk=; b=JOxBXvVJoWwGe1qISKbXOBhgcQV2kdQQe4XOrQZgGcULukFdr/NqcQ7LRfGqwqscDRbgMmWv7LEfJMU4lnhkwtHdvG+KcLw5ASqR13KusMbi4tPu6mcCHrpjs0l7Kkb8; Received: from box313.bluehost.com ([69.89.31.113]:60537 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1SxPC4-0003Oa-C8 for ccamp@ietf.org; Fri, 03 Aug 2012 15:14:00 -0600 Message-ID: <501C3F18.9060202@labn.net> Date: Fri, 03 Aug 2012 17:14:00 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] For discussion: Planned milestone update X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 21:14:03 -0000 All, As mentioned in yesterday's session we are planning an update the WG milestones. Please comment on the dates listed below and if you think we are missing current (or close to) WG documents. Although, keep in mind that not every draft needs to be reflected in its own milestone. All dates are as presented. Much thanks, Lou (and Deborah) Updates to current milestones Aug 2012 - Submit OAM configuration framework for IESG review Group drafts Aug 2012 - Submit first set of OAM configuration solutions for IESG review Sep 2012 - Submit LMP Negotiation for IESG review Dec 2012 - Submit G.709 enhancements framework for IESG review Dec 2012 - Submit G.709 enhancements solutions for IESG review Dec 2012 - Submit WSON routing related for IESG review Mar 2012 - First versions of impairments related solutions Working Group drafts Mar 2013 - First version of LMP for G.709 enhancements Working Group drafts Sep 2013 - Submit LMP for G.709 enhancements for IESG review Dec 2013 - Submit final OAM configuration solutions for IESG review Dec 2013 - Submit impairments related solutions for IESG review Nov 2014 - Recharter or close Working Group Based on identified WG items and current drafts: Apr 2013 – First version GMPLS E-NNI Working Group draft Apr 2013 – First version flexigrid requirements/framework Working Group draft Aug 2013 - Submit MPLS-TP Association to IESG From lberger@labn.net Fri Aug 3 14:26:19 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC19821E8092 for ; Fri, 3 Aug 2012 14:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.884 X-Spam-Level: X-Spam-Status: No, score=-97.884 tagged_above=-999 required=5 tests=[AWL=2.277, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FV0n+dXrM0CX for ; Fri, 3 Aug 2012 14:26:18 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 2575821E8091 for ; Fri, 3 Aug 2012 14:26:18 -0700 (PDT) Received: (qmail 5300 invoked by uid 0); 3 Aug 2012 21:26:17 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 3 Aug 2012 21:26:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=XuWYDXNzNA8spqyvH6Ecapx+gsMX+G4k7kQYUUY7ozM=; b=BDwBApNvVtjyHW8KdedwnCLZsPAGNreyTZXALCnCq2+6OuZNFISJkSuf/vYQiNu1lx0fg4FHdkgAtsUmnjDKkhPHvHuU7Mty+Wl0jXBtlCHZteDbXpxUcxJk1/oy30vE; Received: from box313.bluehost.com ([69.89.31.113]:33443 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1SxPNw-0007Mx-Us; Fri, 03 Aug 2012 15:26:17 -0600 Message-ID: <501C41F7.30500@labn.net> Date: Fri, 03 Aug 2012 17:26:15 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: RFC Errata System References: <20120731163915.6B942621A0@rfc-editor.org> In-Reply-To: <20120731163915.6B942621A0@rfc-editor.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: dimitri.papadimitriou@alcatel-lucent.be, ccamp@ietf.org, jplang@ieee.org, dbrungard@att.com Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 21:26:19 -0000 All, Based on the discussion in response to this Errata, the chairs recommend that (a) this Errata be closed/rejected as it is the general opinion of the WG that there is no technical issue and that (b) if any WG participants wish to document how the current mechanisms can be used to support a particular usage/application that they are free to do so in a new informational draft. Thank you, Deborah and Lou On 7/31/2012 12:39 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC4872, > "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4872&eid=3304 > > -------------------------------------- > Type: Technical > Reported by: Lyndon Ong > > Section: 11 & 12 > > Original Text > ------------- > Section 11 says: > > > > > > (Full) LSP rerouting will be initiated by the head-end node that has > > either detected the LSP failure or received a Notify message and/or a > > PathErr message with the new error code/sub-code "Notify Error/LSP > > Locally Failed" for this LSP. The new LSP resources can be > > established using the make-before-break mechanism, where the new LSP > > is set up before the old LSP is torn down. This is done by using the > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > can share resources at common nodes. > > > > Section 12 says: > > > > [No text on reversion for (full) LSP Rerouting.] > > Corrected Text > -------------- > Section 11 should say: > > > > > > (Full) LSP rerouting will be initiated by the head-end node that has > > either detected the LSP failure or received a Notify message and/or a > > PathErr message with the new error code/sub-code "Notify Error/LSP > > Locally Failed" for this LSP. The new LSP resources can be > > established using the make-before-break mechanism, where the new LSP > > is set up before the old LSP is torn down. This is done by using the > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > can share resources at common nodes. The new LSP can be established > > without tearing down the old LSP in case of reversion (see section 12). > > > > Section 12 should say: > > > > For "(full) LSP Rerouting", reversion implies that the old LSP is not > > torn down by the head-end node after the new LSP is established. For > > reversion, the head-end node re-activates the old LSP after this has > > recovered. > > > > > > Notes > ----- > Current text in RFC 4872 describes reversion in the cases of 1+1 bidirectional Protection, 1:N Protection with Extra Traffic and Rerouting Without Extra Traffic, however it has no description of reversion with (Full) LSP Rerouting. > > For (full) LSP Rerouting, the description in Section 11 instead implies that the old LSP is torn down. This has led to some confusion as to whether reversion with (full) LSP Rerouting is allowed or not allowed by the RFC. We believe this was not intentional. The additions would make it clear that reversion can be supported with (Full) LSP Rerouting. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > -------------------------------------- > Title : RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery > Publication Date : May 2007 > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed. > Category : PROPOSED STANDARD > Source : Common Control and Measurement Plane > Area : Routing > Stream : IETF > Verifying Party : IESG > > > > From adrian@olddog.co.uk Fri Aug 3 14:28:26 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A3121E8039 for ; Fri, 3 Aug 2012 14:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKiVyZTJe8Vm for ; Fri, 3 Aug 2012 14:28:25 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id D81F121F8D9B for ; Fri, 3 Aug 2012 14:28:18 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q73LS4PZ016825; Fri, 3 Aug 2012 22:28:04 +0100 Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q73LRuN8016783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 Aug 2012 22:28:00 +0100 From: "Adrian Farrel" To: "'Lou Berger'" References: <20120731163915.6B942621A0@rfc-editor.org> <501C41F7.30500@labn.net> In-Reply-To: <501C41F7.30500@labn.net> Date: Fri, 3 Aug 2012 22:27:55 +0100 Message-ID: <03ff01cd71be$dd1e0730$975a1590$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJG0ydQ2iZ1PPA/LaXiFWLC86ukfAHHFwg+lkeefLA= Content-Language: en-gb Cc: dimitri.papadimitriou@alcatel-lucent.be, ccamp@ietf.org, jplang@ieee.org, dbrungard@att.com Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 21:28:26 -0000 Thanks Lou, I'll let this sit in the WG for a couple of days and then take action. Adrian > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: 03 August 2012 22:26 > To: RFC Errata System > Cc: jplang@ieee.org; yakov@juniper.net; dimitri.papadimitriou@alcatel- > lucent.be; stbryant@cisco.com; adrian@olddog.co.uk; dbrungard@att.com; > lyong@ciena.com; ccamp@ietf.org > Subject: Re: [Technical Errata Reported] RFC4872 (3304) > > All, > Based on the discussion in response to this Errata, the chairs > recommend that (a) this Errata be closed/rejected as it is the general > opinion of the WG that there is no technical issue and that (b) if any > WG participants wish to document how the current mechanisms can be used > to support a particular usage/application that they are free to do so in > a new informational draft. > > Thank you, > Deborah and Lou > > On 7/31/2012 12:39 PM, RFC Errata System wrote: > > The following errata report has been submitted for RFC4872, > > "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label > Switching (GMPLS) Recovery". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=4872&eid=3304 > > > > -------------------------------------- > > Type: Technical > > Reported by: Lyndon Ong > > > > Section: 11 & 12 > > > > Original Text > > ------------- > > Section 11 says: > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end node that has > > > > either detected the LSP failure or received a Notify message and/or a > > > > PathErr message with the new error code/sub-code "Notify Error/LSP > > > > Locally Failed" for this LSP. The new LSP resources can be > > > > established using the make-before-break mechanism, where the new LSP > > > > is set up before the old LSP is torn down. This is done by using the > > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > > > can share resources at common nodes. > > > > > > > > Section 12 says: > > > > > > > > [No text on reversion for (full) LSP Rerouting.] > > > > Corrected Text > > -------------- > > Section 11 should say: > > > > > > > > > > > > (Full) LSP rerouting will be initiated by the head-end node that has > > > > either detected the LSP failure or received a Notify message and/or a > > > > PathErr message with the new error code/sub-code "Notify Error/LSP > > > > Locally Failed" for this LSP. The new LSP resources can be > > > > established using the make-before-break mechanism, where the new LSP > > > > is set up before the old LSP is torn down. This is done by using the > > > > mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit > > > > (SE) reservation style (see [RFC3209]). Both the new and old LSPs > > > > can share resources at common nodes. The new LSP can be established > > > > without tearing down the old LSP in case of reversion (see section 12). > > > > > > > > Section 12 should say: > > > > > > > > For "(full) LSP Rerouting", reversion implies that the old LSP is not > > > > torn down by the head-end node after the new LSP is established. For > > > > reversion, the head-end node re-activates the old LSP after this has > > > > recovered. > > > > > > > > > > > > Notes > > ----- > > Current text in RFC 4872 describes reversion in the cases of 1+1 bidirectional > Protection, 1:N Protection with Extra Traffic and Rerouting Without Extra Traffic, > however it has no description of reversion with (Full) LSP Rerouting. > > > > For (full) LSP Rerouting, the description in Section 11 instead implies that the old > LSP is torn down. This has led to some confusion as to whether reversion with > (full) LSP Rerouting is allowed or not allowed by the RFC. We believe this was not > intentional. The additions would make it clear that reversion can be supported > with (Full) LSP Rerouting. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) > > -------------------------------------- > > Title : RSVP-TE Extensions in Support of End-to-End Generalized Multi- > Protocol Label Switching (GMPLS) Recovery > > Publication Date : May 2007 > > Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed. > > Category : PROPOSED STANDARD > > Source : Common Control and Measurement Plane > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > > > > > > > From lberger@labn.net Fri Aug 3 14:35:46 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7535111E80AD for ; Fri, 3 Aug 2012 14:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.955 X-Spam-Level: X-Spam-Status: No, score=-97.955 tagged_above=-999 required=5 tests=[AWL=2.206, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJuSgvyrVMmH for ; Fri, 3 Aug 2012 14:35:42 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 4D6E511E80A3 for ; Fri, 3 Aug 2012 14:35:42 -0700 (PDT) Received: (qmail 16769 invoked by uid 0); 3 Aug 2012 21:35:41 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 3 Aug 2012 21:35:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=qtZZ2jYnFu5Ja+j0sLp5X1lJRvNKlb8npqCqvEL/IX8=; b=OwaW5Y4hmXfNOR3wRpC1gIpU6EdMAcqUhv647M/g5+T/Txp5CZtTasfV1XGrf8HoxAWE79J+1nGKGq2vGRW/lvwCyMJG6UjKcncfkaqpczON7O4Ma1pQpjRlYi56BgFK; Received: from box313.bluehost.com ([69.89.31.113]:34295 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1SxPX3-0001mb-H8; Fri, 03 Aug 2012 15:35:41 -0600 Message-ID: <501C442C.2000103@labn.net> Date: Fri, 03 Aug 2012 17:35:40 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: venkat.mahalingams@gmail.com, ccamp@ietf.org Subject: Re: [CCAMP] Request for comments: the next step about the draft draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 21:35:46 -0000 Fei, My request was a bit more specific. The request was/is for the authors to propose, on the list, text that would merge support for the function discussed in the draft (and agreed to on the list) into draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp. The WG could then react to this proposal and agree/disagree to the proposed merge. Lou On 8/3/2012 4:37 AM, zhang.fei3@zte.com.cn wrote: > > Hi Lou > > Thanks you for your suggestion in the merging the solution into the > existing WG documents to push this work forward. :) > > IMHO, there are three potential WG documents, like > > (1) draft-ietf-ccamp-assoc-ext-03.txt > > > This draft is now in IESG processing, which defines the extensions of > the Association object, and is irrelevant with the specific association > types. > > (2) draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08 > > > The proposed text can be added in section 3.2, a new TLV or the > Association object with the defined new association type, which carring > back the Z9_tunnel_num in the Resv message, needs to be defined there. > This draft is WG last call, and I have sent out the corresponding > comments, hope to hear the authors' opinion. > > (3) draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp > > > > If the proposed texts are added in this draft, the subject needs to be > enlarged to cover both the associated and corouted bidirectional LSPs. > > Maybe the first step is to determine which draft is the better choice > for merging, then we will submit the proposed texts. > > Any WG's feedbacks are welcome > > Best regards > > Fei From adrian@olddog.co.uk Sun Aug 5 07:04:09 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3716821F84E7 for ; Sun, 5 Aug 2012 07:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cNovzs7LEEZ for ; Sun, 5 Aug 2012 07:04:07 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF7F21F84E6 for ; Sun, 5 Aug 2012 07:04:06 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q75E3qqD004508; Sun, 5 Aug 2012 15:03:53 +0100 Received: from 950129200 ([80.187.201.11]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q75E3nwT004477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 5 Aug 2012 15:03:50 +0100 From: "Adrian Farrel" To: "'Acee Lindem'" References: <76B81EC9-E7C5-45E3-9245-B07F013F8324@ericsson.com> In-Reply-To: <76B81EC9-E7C5-45E3-9245-B07F013F8324@ericsson.com> Date: Sun, 5 Aug 2012 15:03:48 +0100 Message-ID: <00b501cd7313$2426ae20$6c740a60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B6_01CD731B.8602E3E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHmp3O6WyH+lF6HaQYADw5Nnwdx1ZcY1UTQ Content-Language: en-gb Cc: 'CCAMP' , 'Andy Malis' Subject: Re: [CCAMP] Last Call: (ASON Routing for OSPFv2 Protocols) to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 14:04:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B6_01CD731B.8602E3E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, I am worried by this... 1. The document is in IETF last call. Comments and discussions MUST be sent to the IETF discussion list unless they are specifically sent direct to the IESG. It is inappropriate to have the discussion in private or limited to the CCAMP list. 2. I disagree with the changes made as they do not recognise how GMPLS is used to provide the necessary naming and addressing. 3. I find the proposed inclusion of text on ASON terminology to be imprecise. Furthermore, it is questionable whether it is appropriate to attempt to define in an IETF document a term that is (or should be) defined in an ITU-T document. Additionally, RFC 4397 was constructed to provide mapping of terminology and was carefully reviewed in the IETF and ITU-T; any attempt to provide additional mapping will require further cross-review. Can we please start this from the top? Action: Someone says on the IETF Discuss list: "I have the following concerns and issues. I think they can be addressed by these text changes." Don't just propose changes. Give reasons. Thanks, Adrian From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: 02 August 2012 01:26 To: iesg-secretary@ietf.org Cc: CCAMP; Stephen Shew; Adrian Farrel; Andy Malis; Lyndon Ong; Dimitri (Dimitri) Papadimitriou Subject: RE: Last Call: (ASON Routing for OSPFv2 Protocols) to Proposed Standard All, The authors have received comments from Stephen Shew regarding our references to ASON name spaces and would like to change the text to clarify these references. The proposed changes are included below. Unless anyone has any serious objections, we intend to make these changes as part of the IETF last call process. Any further discussion will take place on the CCAMP list. Thanks, Acee Lindem dhcp-421c:Desktop ealflin$ diff -c draft-ietf-ccamp-rfc5787bis-05.txt.orig draft-ietf-ccamp-rfc5787bis-05.txt *** draft-ietf-ccamp-rfc5787bis-05.txt.orig 2012-07-24 20:51:22.000000000 -0400 --- draft-ietf-ccamp-rfc5787bis-05.txt 2012-07-31 21:26:18.000000000 -0400 *************** *** 354,366 **** and corresponding identifiers defined for GMPLS routing, and how these support the physical (or logical) separation of transport plane entities and control plane components. GMPLS supports this ! separation of identifiers and planes. In the context of OSPF Traffic Engineering (TE), an ASON transport node corresponds to a unique OSPF TE node. An OSPF TE node is uniquely identified by the TE Router Address TLV [RFC3630]. In this document, this TE Router Address is referred to as the TE Router ID, ! which is in the ASON SCN name space. The TE Router ID should not be confused with the OSPF Router ID which uniquely identifies an OSPF router within an OSPF routing domain [RFC2328] and is in a name space for control plane components. --- 354,387 ---- and corresponding identifiers defined for GMPLS routing, and how these support the physical (or logical) separation of transport plane entities and control plane components. GMPLS supports this ! separation of identifiers and planes. ! ! ASON refers to transport plane identifiers as SubNetwork Points or ! (SNPs). An SNP is an abstraction that represents an actual or ! potential underlying connection point (CP) (or connection termination ! point (CTP)) or an actual or potential termination connection point ! (TCP) or trail termination point (TTP). Several SNPs (in different ! subnetwork partitions) may represent the same TCP or CP [G.8080]. ! A collection of SNPs used for ASON routing is referred to as the ! SubNetork Point Pool (SNPP) and its identifiers are from the SNPP ! name space. In this context, an SNPP would refer to Optical ! Transport Network (OTN) switch and an SNP would be an identifier ! for an optical channel. ! ! Conversely, the Signaling Control Network (SCN) consists of the ! communication paths over which ASON Protocol Controller (PC) ! adjacencies are established, and the control plane consists of the ! ASON PC instances and their corresponding adjacencies. Given ! that OSPF is always transpored over IP, the SCN and control plane ! will normally coincide. However, a given ASON PC instance may ! establish adjacencies over multiple SCNs and multiple ASON PC ! instances can use the same SCN. In the context of OSPF Traffic Engineering (TE), an ASON transport node corresponds to a unique OSPF TE node. An OSPF TE node is uniquely identified by the TE Router Address TLV [RFC3630]. In this document, this TE Router Address is referred to as the TE Router ID, ! which is in the ASON SNPP name space. The TE Router ID should not be confused with the OSPF Router ID which uniquely identifies an OSPF router within an OSPF routing domain [RFC2328] and is in a name space for control plane components. *************** *** 370,376 **** OSPF TE node IP address, i.e., the IP address is always reachable when there is IP connectivity to the associated OSPF TE node. However, in the context of the OSPF ASON operation, the TE Router ID ! is an identifier within the ASON SCN. ASON defines a Routing Controller (RC) as an entity that handles (abstract) information needed for routing and the routing information --- 391,397 ---- OSPF TE node IP address, i.e., the IP address is always reachable when there is IP connectivity to the associated OSPF TE node. However, in the context of the OSPF ASON operation, the TE Router ID ! is an identifier within the ASON SNPP name space. ASON defines a Routing Controller (RC) as an entity that handles (abstract) information needed for routing and the routing information *************** *** 398,404 **** In ASON, reachability refers to the set of endpoints reachable in the transport plane by an associated ASON transport node. Reachable ! entities are identified in the ASON SCN name space. In order to advertise blocks of reachable address prefixes, a summarization mechanism is introduced that is based on the techniques --- 419,426 ---- In ASON, reachability refers to the set of endpoints reachable in the transport plane by an associated ASON transport node. Reachable ! entities are identified in the ASON SNPP name space, and the transport ! topology is identified from that name space. In order to advertise blocks of reachable address prefixes, a summarization mechanism is introduced that is based on the techniques *************** *** 636,642 **** of ASON information as described herein. If it is not included in a Node Attribute TLV or a value of 0 is specified for the Local TE Router Identifier, the Note Attribute TLV will not be used for ! determining ASON SCN reachability. Additionally, the condition SHOULD be logged for possible action by the network operator. 7. Routing Information Dissemination --- 658,664 ---- of ASON information as described herein. If it is not included in a Node Attribute TLV or a value of 0 is specified for the Local TE Router Identifier, the Note Attribute TLV will not be used for ! determining ASON SNPP reachability. Additionally, the condition SHOULD be logged for possible action by the network operator. 7. Routing Information Dissemination The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'ASON Routing for OSPFv2 Protocols' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf at ietf.org mailing lists by 2012-08-17. Exceptionally, comments may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This is a four- week last call period because it spans the IETF-84 meeting. Abstract The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/ballot/ No IPR declarations have been submitted directly on this I-D. ------=_NextPart_000_00B6_01CD731B.8602E3E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I am worried by = this...

 

1. The document is in IETF = last call. Comments and discussions MUST be sent to the IETF discussion = list unless they are specifically sent direct to the IESG. It is = inappropriate to have the discussion in private or limited to the CCAMP = list.

 

2. I disagree with the changes = made as they do not recognise how GMPLS is used to provide the necessary = naming and addressing.

 

3. I find the proposed = inclusion of text on ASON terminology to be imprecise. Furthermore, it = is questionable whether it is appropriate to attempt to define in an = IETF document a term that is (or should be) defined in an ITU-T = document. Additionally, RFC 4397 was constructed to provide mapping of = terminology and was carefully reviewed in the IETF and ITU-T; any = attempt to provide additional mapping will require further = cross-review.

 

Can we please start this from = the top?

Action: Someone says on the = IETF Discuss list: "I have the following concerns and issues. I = think they can be addressed by these text = changes."

 

Don't just propose changes. = Give reasons.

 

Thanks,

Adrian

 

From: Acee Lindem = [mailto:acee.lindem@ericsson.com]
Sent: 02 August 2012 = 01:26
To: iesg-secretary@ietf.org
Cc: CCAMP; Stephen = Shew; Adrian Farrel; Andy Malis; Lyndon Ong; Dimitri (Dimitri) = Papadimitriou
Subject: RE: Last Call: = <draft-ietf-ccamp-rfc5787bis-05.txt> (ASON Routing for OSPFv2 = Protocols) to Proposed Standard

 

All,

 

The authors have = received comments from Stephen Shew regarding our references to ASON = name spaces and would like to 

change the text to clarify these references. The proposed = changes are included below. Unless = anyone 

has any serious = objections, we intend to make these changes as part of the = IETF last call process. 

Any further discussion will take place on the CCAMP = list.

 

Thanks,

Acee Lindem

 

dhcp-421c:Desktop ealflin$ diff -c = draft-ietf-ccamp-rfc5787bis-05.txt.orig = draft-ietf-ccamp-rfc5787bis-05.txt

*** draft-ietf-ccamp-rfc5787bis-05.txt.orig = 2012-07-24 20:51:22.000000000 = -0400

--- = draft-ietf-ccamp-rfc5787bis-05.txt        = ;  2012-07-31 21:26:18.000000000 = -0400

***************

*** 354,366 ****

     and corresponding identifiers defined for = GMPLS routing, and how

     these support the physical (or logical) = separation of transport plane

     entities and control plane components. =  GMPLS supports this

!    separation of identifiers and = planes.

  

     In the context of OSPF Traffic Engineering = (TE), an ASON transport

     node corresponds to a unique OSPF TE node. =  An OSPF TE node is

     uniquely identified by the TE Router Address = TLV [RFC3630]. In this

     document, this TE Router Address is referred = to as the TE Router ID,

!    which is in the ASON SCN name space.  The TE = Router ID should not be

     confused with the OSPF Router ID which = uniquely identifies an OSPF

     router within an OSPF routing domain = [RFC2328] and is in a name space

     for control plane = components.

--- 354,387 = ----

    =  and corresponding identifiers defined for GMPLS routing, and = how

    =  these support the physical (or logical) separation of transport = plane

    =  entities and control plane components.  GMPLS supports = this

!   =  separation of identifiers and = planes. 

! 

!    ASON refers to transport plane identifiers as = SubNetwork Points or 

!    (SNPs). An SNP is an abstraction that represents = an actual or 

!    potential underlying connection point (CP) (or = connection termination

!    point (CTP)) or an actual or potential = termination connection point

!    (TCP) or trail termination point (TTP). Several = SNPs (in different 

!    subnetwork partitions) may represent the same TCP = or CP [G.8080]. 

!    A collection of SNPs used for ASON routing is = referred to as the

!    SubNetork Point Pool (SNPP) and its identifiers = are from the SNPP

!    name space. In this context, an SNPP would refer = to Optical 

!    Transport Network (OTN) switch and an SNP would = be an identifier

!    for an optical = channel. 

! 

!    Conversely, the Signaling Control Network (SCN) = consists of the 

!    communication paths over which ASON Protocol = Controller (PC) 

!    adjacencies are established, and the control = plane consists of the

!    ASON PC instances and their corresponding = adjacencies.  Given 

!    that OSPF is always transpored over IP, the SCN = and control plane

!    will normally coincide. However, a given ASON PC = instance may 

!    establish adjacencies over multiple SCNs and = multiple ASON PC 

!    instances can use the same = SCN.

  

     In the context of OSPF Traffic Engineering = (TE), an ASON transport

     node corresponds to a unique OSPF TE node. =  An OSPF TE node is

     uniquely identified by the TE Router Address = TLV [RFC3630]. In this

     document, this TE Router Address is referred = to as the TE Router ID,

!    which is in the ASON SNPP name space.  The = TE Router ID should not be

     confused with the OSPF Router ID which = uniquely identifies an OSPF

     router within an OSPF routing domain = [RFC2328] and is in a name space

     for control plane = components.

***************

*** 370,376 ****

     OSPF TE node IP address, i.e., the IP = address is always reachable

     when there is IP connectivity to the = associated OSPF TE node.

     However, in the context of the OSPF ASON = operation, the TE Router ID

!    is an identifier within the ASON = SCN. 

  

     ASON defines a Routing Controller (RC) as an = entity that handles

     (abstract) information needed for routing = and the routing information

--- 391,397 ----

     OSPF TE node IP address, i.e., the IP = address is always reachable

     when there is IP connectivity to the = associated OSPF TE node.

     However, in the context of the OSPF ASON = operation, the TE Router ID

!    is an identifier within the ASON SNPP name = space. 

  

     ASON defines a Routing Controller (RC) as an = entity that handles

     (abstract) information needed for routing = and the routing information

***************

*** 398,404 ****

  

     In ASON, reachability refers to the set of = endpoints reachable in the

     transport plane by an associated ASON = transport node. Reachable

!    entities are identified in the ASON SCN name = space. 

  

     In order to advertise blocks of reachable = address prefixes, a

     summarization mechanism is introduced that = is based on the techniques

--- 419,426 ----

  

     In ASON, reachability refers to the set of = endpoints reachable in the

     transport plane by an associated ASON = transport node. Reachable

!    entities are identified in the ASON SNPP name = space, and the transport

!    topology is identified from that name = space. 

  

     In order to advertise blocks of reachable = address prefixes, a

     summarization mechanism is introduced that = is based on the techniques

***************

*** 636,642 ****

     of ASON information as described herein. If = it is not included in a

     Node Attribute TLV or a value of 0 is = specified for the Local TE

     Router Identifier, the Note Attribute TLV = will not be used for

!    determining ASON SCN reachability. =  Additionally, the condition

     SHOULD be logged for possible action by the = network operator. 

  

  7.  Routing Information = Dissemination

--- 658,664 = ----

    =  of ASON information as described herein. If it is not included in = a

    =  Node Attribute TLV or a value of 0 is specified for the Local = TE

    =  Router Identifier, the Note Attribute TLV will not be used = for

!   =  determining ASON SNPP reachability.  Additionally, the = condition

    =  SHOULD be logged for possible action by the network = operator. 

  

  7.  Routing Information = Dissemination

 

The IESG has =
received a request from the Common Control and =
Measurement
Plane WG (ccamp) to consider the =
following document:
- 'ASON Routing for OSPFv2 =
Protocols'
  =
<draft-ietf-ccamp-rfc5787bis-05.txt> as Proposed =
Standard
 
The IESG plans =
to make a decision in the next few weeks, and =
solicits
final comments on this action. Please send =
substantive comments to the
ietf at ietf.org mailing lists by 2012-08-17. =
Exceptionally, comments may be
sent to iesg at ietf.org instead. In either case, please =
retain the
beginning of the Subject line to allow =
automated sorting. This is a four-
week last call =
period because it spans the IETF-84 =
meeting.
 
Abstract
 
   The ITU-T has defined an =
architecture and requirements for operating
   an Automatically Switched =
Optical Network =
(ASON).
 
   The Generalized =
Multiprotocol Label Switching (GMPLS) protocol =
suite
   =
is designed to provide a control plane for a range of =
network
   technologies including =
optical networks such as time division
   multiplexing (TDM) =
networks including SONET/SDH and Optical =
Transport
   Networks (OTNs), and =
lambda switching optical =
networks.
 
   The requirements for =
GMPLS routing to satisfy the requirements of
   ASON routing, and an =
evaluation of existing GMPLS routing =
protocols
   are provided in other =
documents.  This document =
defines extensions to
   the OSPFv2 Link State =
Routing Protocol to meet the requirements for
   routing in an =
ASON.
 
   Note that this work is =
scoped to the requirements and evaluation
   expressed in RFC 4258 and =
RFC 4652 and the ITU-T Recommendations
   current when those =
documents were written.  =
Future extensions of
   revisions of this work =
may be necessary if the ITU-T Recommendations
   are revised or if new =
requirements are introduced into a revision =
of
   =
RFC 4258. This document obsoletes RFC 5787 and updates RFC =
5786.
 
 <=
/pre>
 
The file can be obtained =
via
htt=
p://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/<=
/pre>
 
IESG discussion can be tracked =
via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/ballot/
 
No IPR declarations =
have been submitted directly on this =
I-D.
= ------=_NextPart_000_00B6_01CD731B.8602E3E0-- From acee.lindem@ericsson.com Sun Aug 5 08:40:12 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D38F21F84C9 for ; Sun, 5 Aug 2012 08:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U76u2eu-Xs0s for ; Sun, 5 Aug 2012 08:40:10 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8A121F849B for ; Sun, 5 Aug 2012 08:40:10 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q75Fe4q3019537; Sun, 5 Aug 2012 10:40:05 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.190]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sun, 5 Aug 2012 11:39:58 -0400 From: Acee Lindem To: "adrian@olddog.co.uk" Date: Sun, 5 Aug 2012 11:39:55 -0400 Thread-Topic: Last Call: (ASON Routing for OSPFv2 Protocols) to Proposed Standard Thread-Index: Ac1zIJGqYwymupxnRfesqz2CgLjiHA== Message-ID: <20FD8252-CD49-45D1-8214-736A07DA46E8@ericsson.com> References: <76B81EC9-E7C5-45E3-9245-B07F013F8324@ericsson.com> <00b501cd7313$2426ae20$6c740a60$@olddog.co.uk> In-Reply-To: <00b501cd7313$2426ae20$6c740a60$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-17-801775039"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: CCAMP , Andy Malis Subject: Re: [CCAMP] Last Call: (ASON Routing for OSPFv2 Protocols) to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 15:40:12 -0000 --Apple-Mail-17-801775039 Content-Type: multipart/alternative; boundary=Apple-Mail-16-801775024 --Apple-Mail-16-801775024 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Adrian,=20 On Aug 5, 2012, at 10:03 AM, Adrian Farrel wrote: > All, > =20 > I am worried by this... > =20 > 1. The document is in IETF last call. Comments and discussions MUST be = sent to the IETF discussion list unless they are specifically sent = direct to the IESG. It is inappropriate to have the discussion in = private or limited to the CCAMP list. This was my problem. IETF announce was copied but of course it bounced.=20= > =20 > 2. I disagree with the changes made as they do not recognise how GMPLS = is used to provide the necessary naming and addressing. > =20 > 3. I find the proposed inclusion of text on ASON terminology to be = imprecise. Furthermore, it is questionable whether it is appropriate to = attempt to define in an IETF document a term that is (or should be) = defined in an ITU-T document. Additionally, RFC 4397 was constructed to = provide mapping of terminology and was carefully reviewed in the IETF = and ITU-T; any attempt to provide additional mapping will require = further cross-review. Other than including the two paragraphs describing ASON terminology, the = change is basically "s/ASON SCN/ASON SNPP/".=20 Furthermore, the ASON term SNPP is included in section 3.9.2 of RFC 4397 = and Appendix A of this draft.=20 > =20 > Can we please start this from the top? > Action: Someone says on the IETF Discuss list: "I have the following = concerns and issues. I think they can be addressed by these text = changes." I'm about to go on a vacation for a couple weeks and this was my attempt = to handle the comment swiftly. Since "s/ASON SCN/ASON SNPP/" is viewed = as a less than innocuous editorial change, I'll leave it to Lyndon, = Stephen, or someone else participating in the ITU. =20 > =20 > Don't just propose changes. Give reasons. It was my understanding that the term "ASON SCN" was viewed as = incorrect. However, I'll defer to Stephen.=20 Thanks, Acee=20 > =20 > Thanks, > Adrian > =20 > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: 02 August 2012 01:26 > To: iesg-secretary@ietf.org > Cc: CCAMP; Stephen Shew; Adrian Farrel; Andy Malis; Lyndon Ong; = Dimitri (Dimitri) Papadimitriou > Subject: RE: Last Call: (ASON = Routing for OSPFv2 Protocols) to Proposed Standard > =20 > All, > =20 > The authors have received comments from Stephen Shew regarding our = references to ASON name spaces and would like to=20 > change the text to clarify these references. The proposed changes are = included below. Unless anyone=20 > has any serious objections, we intend to make these changes as part of = the IETF last call process.=20 > Any further discussion will take place on the CCAMP list. > =20 > Thanks, > Acee Lindem > =20 > dhcp-421c:Desktop ealflin$ diff -c = draft-ietf-ccamp-rfc5787bis-05.txt.orig = draft-ietf-ccamp-rfc5787bis-05.txt > *** draft-ietf-ccamp-rfc5787bis-05.txt.orig 2012-07-24 = 20:51:22.000000000 -0400 > --- draft-ietf-ccamp-rfc5787bis-05.txt 2012-07-31 = 21:26:18.000000000 -0400 > *************** > *** 354,366 **** > and corresponding identifiers defined for GMPLS routing, and how > these support the physical (or logical) separation of transport = plane > entities and control plane components. GMPLS supports this > ! separation of identifiers and planes. > =20 > In the context of OSPF Traffic Engineering (TE), an ASON = transport > node corresponds to a unique OSPF TE node. An OSPF TE node is > uniquely identified by the TE Router Address TLV [RFC3630]. In = this > document, this TE Router Address is referred to as the TE Router = ID, > ! which is in the ASON SCN name space. The TE Router ID should not = be > confused with the OSPF Router ID which uniquely identifies an = OSPF > router within an OSPF routing domain [RFC2328] and is in a name = space > for control plane components. > --- 354,387 ---- > and corresponding identifiers defined for GMPLS routing, and how > these support the physical (or logical) separation of transport = plane > entities and control plane components. GMPLS supports this > ! separation of identifiers and planes.=20 > !=20 > ! ASON refers to transport plane identifiers as SubNetwork Points = or=20 > ! (SNPs). An SNP is an abstraction that represents an actual or=20 > ! potential underlying connection point (CP) (or connection = termination > ! point (CTP)) or an actual or potential termination connection = point > ! (TCP) or trail termination point (TTP). Several SNPs (in = different=20 > ! subnetwork partitions) may represent the same TCP or CP [G.8080].=20= > ! A collection of SNPs used for ASON routing is referred to as the > ! SubNetork Point Pool (SNPP) and its identifiers are from the SNPP > ! name space. In this context, an SNPP would refer to Optical=20 > ! Transport Network (OTN) switch and an SNP would be an identifier > ! for an optical channel.=20 > !=20 > ! Conversely, the Signaling Control Network (SCN) consists of the=20= > ! communication paths over which ASON Protocol Controller (PC)=20 > ! adjacencies are established, and the control plane consists of = the > ! ASON PC instances and their corresponding adjacencies. Given=20 > ! that OSPF is always transpored over IP, the SCN and control plane > ! will normally coincide. However, a given ASON PC instance may=20 > ! establish adjacencies over multiple SCNs and multiple ASON PC=20 > ! instances can use the same SCN. > =20 > In the context of OSPF Traffic Engineering (TE), an ASON = transport > node corresponds to a unique OSPF TE node. An OSPF TE node is > uniquely identified by the TE Router Address TLV [RFC3630]. In = this > document, this TE Router Address is referred to as the TE Router = ID, > ! which is in the ASON SNPP name space. The TE Router ID should = not be > confused with the OSPF Router ID which uniquely identifies an = OSPF > router within an OSPF routing domain [RFC2328] and is in a name = space > for control plane components. > *************** > *** 370,376 **** > OSPF TE node IP address, i.e., the IP address is always reachable > when there is IP connectivity to the associated OSPF TE node. > However, in the context of the OSPF ASON operation, the TE Router = ID > ! is an identifier within the ASON SCN.=20 > =20 > ASON defines a Routing Controller (RC) as an entity that handles > (abstract) information needed for routing and the routing = information > --- 391,397 ---- > OSPF TE node IP address, i.e., the IP address is always reachable > when there is IP connectivity to the associated OSPF TE node. > However, in the context of the OSPF ASON operation, the TE Router = ID > ! is an identifier within the ASON SNPP name space.=20 > =20 > ASON defines a Routing Controller (RC) as an entity that handles > (abstract) information needed for routing and the routing = information > *************** > *** 398,404 **** > =20 > In ASON, reachability refers to the set of endpoints reachable in = the > transport plane by an associated ASON transport node. Reachable > ! entities are identified in the ASON SCN name space.=20 > =20 > In order to advertise blocks of reachable address prefixes, a > summarization mechanism is introduced that is based on the = techniques > --- 419,426 ---- > =20 > In ASON, reachability refers to the set of endpoints reachable in = the > transport plane by an associated ASON transport node. Reachable > ! entities are identified in the ASON SNPP name space, and the = transport > ! topology is identified from that name space.=20 > =20 > In order to advertise blocks of reachable address prefixes, a > summarization mechanism is introduced that is based on the = techniques > *************** > *** 636,642 **** > of ASON information as described herein. If it is not included in = a > Node Attribute TLV or a value of 0 is specified for the Local TE > Router Identifier, the Note Attribute TLV will not be used for > ! determining ASON SCN reachability. Additionally, the condition > SHOULD be logged for possible action by the network operator.=20 > =20 > 7. Routing Information Dissemination > --- 658,664 ---- > of ASON information as described herein. If it is not included in = a > Node Attribute TLV or a value of 0 is specified for the Local TE > Router Identifier, the Note Attribute TLV will not be used for > ! determining ASON SNPP reachability. Additionally, the condition > SHOULD be logged for possible action by the network operator.=20 > =20 > 7. Routing Information Dissemination > =20 > The IESG has received a request from the Common Control and = Measurement > Plane WG (ccamp) to consider the following document: > - 'ASON Routing for OSPFv2 Protocols' > as Proposed Standard > =20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf at ietf.org mailing lists by 2012-08-17. Exceptionally, comments = may be > sent to iesg at ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. This is a = four- > week last call period because it spans the IETF-84 meeting. > =20 > Abstract > =20 > The ITU-T has defined an architecture and requirements for = operating > an Automatically Switched Optical Network (ASON). > =20 > The Generalized Multiprotocol Label Switching (GMPLS) protocol = suite > is designed to provide a control plane for a range of network > technologies including optical networks such as time division > multiplexing (TDM) networks including SONET/SDH and Optical = Transport > Networks (OTNs), and lambda switching optical networks. > =20 > The requirements for GMPLS routing to satisfy the requirements of > ASON routing, and an evaluation of existing GMPLS routing protocols > are provided in other documents. This document defines extensions = to > the OSPFv2 Link State Routing Protocol to meet the requirements for > routing in an ASON. > =20 > Note that this work is scoped to the requirements and evaluation > expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations > current when those documents were written. Future extensions of > revisions of this work may be necessary if the ITU-T = Recommendations > are revised or if new requirements are introduced into a revision = of > RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. > =20 > =20 > =20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/ > =20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/ballot/ > =20 > No IPR declarations have been submitted directly on this I-D. > =20 --Apple-Mail-16-801775024 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Adrian, 

On Aug 5, 2012, = at 10:03 AM, Adrian Farrel wrote:

I am = worried by this...
1. = The document is in IETF last call. Comments and discussions MUST be sent = to the IETF discussion list unless they are specifically sent direct to = the IESG. It is inappropriate to have the discussion in private or = limited to the CCAMP = list.

This= was my problem. IETF announce was copied but of course it = bounced. 


2. I = disagree with the changes made as they do not recognise how GMPLS is = used to provide the necessary naming and = addressing.
3. I = find the proposed inclusion of text on ASON terminology to be imprecise. = Furthermore, it is questionable whether it is appropriate to attempt to = define in an IETF document a term that is (or should be) defined in an = ITU-T document. Additionally, RFC 4397 was constructed to provide = mapping of terminology and was carefully reviewed in the IETF and ITU-T; = any attempt to provide additional mapping will require further = cross-review.

<= div>Other than including the two paragraphs describing ASON terminology, = the change is basically "s/ASON SCN/ASON = SNPP/". 
Furthermore, the ASON term SNPP is included in = section 3.9.2 of RFC 4397 and Appendix A of this = draft. 

Can = we please start this from the top?
Action: Someone says on the IETF = Discuss list: "I have the following concerns and issues. I think they = can be addressed by these text = changes."

= I'm about to go on a vacation for a couple weeks and this was my attempt = to handle the comment swiftly. Since "s/ASON SCN/ASON SNPP/" is viewed = as a less than innocuous editorial change, I'll leave it to Lyndon, = Stephen, or someone else participating in the ITU.   =  

Don't = just propose changes. Give = reasons.

I= t was my understanding that the term "ASON SCN" was viewed as incorrect. = However, I'll defer to = Stephen. 

Thanks,
Acee 
= 
The IESG has received a =
request from the Common Control and Measurement
- 'ASON Routing for OSPFv2 =
Protocols'
  =
<draft-ietf-ccamp-rfc5787bis-05.txt> as Proposed =
Standard
 
final comments on this action. Please send =
substantive comments to the
ietf at ietf.org mailing lists by 2012-08-17. Exceptionally, =
comments may be
sent to iesg at ietf.org instead. In either case, please retain =
the
beginning of the Subject line to allow automated =
sorting. This is a four-
week last call period because it =
spans the IETF-84 meeting.
Abstract
   The ITU-T has =
defined an architecture and requirements for =
operating
   an Automatically =
Switched Optical Network (ASON).
   The Generalized =
Multiprotocol Label Switching (GMPLS) protocol =
suite
   is designed to provide a =
control plane for a range of network
   =
multiplexing (TDM) networks including SONET/SDH and Optical =
Transport
   Networks (OTNs), =
and lambda switching optical networks.
   The requirements =
for GMPLS routing to satisfy the requirements of
   are =
provided in other documents.  This document defines =
extensions to
   the OSPFv2 =
Link State Routing Protocol to meet the requirements =
for
   routing in an =
ASON.
 
   Note that =
this work is scoped to the requirements and =
evaluation
   expressed in RFC =
4258 and RFC 4652 and the ITU-T Recommendations
   are =
revised or if new requirements are introduced into a revision =
of
   RFC 4258. This document =
obsoletes RFC 5787 and updates RFC 5786.
 
The file can be obtained =
via
 
IESG discussion can be tracked =
via
 
No IPR declarations have been =
submitted directly on this I-D.
X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A161311E80F1 for ; Tue, 7 Aug 2012 14:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.092 X-Spam-Level: X-Spam-Status: No, score=-5.092 tagged_above=-999 required=5 tests=[AWL=1.507, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq-TN-Prf5Xs for ; Tue, 7 Aug 2012 14:58:00 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id E2ED511E80D5 for ; Tue, 7 Aug 2012 14:57:59 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUCGPZlmoYSqJuyfNsFHVOJZV8YWlPb34@postini.com; Tue, 07 Aug 2012 14:57:59 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 7 Aug 2012 14:56:24 -0700 From: John E Drake To: Lou Berger , "dbrungard@att.com" Date: Tue, 7 Aug 2012 14:56:22 -0700 Thread-Topic: Last Call for OTN Routing and Signaling Drafts Thread-Index: Ac1053uvBPA59RPeSl+ZzKKFCO5j8Q== Message-ID: <5E893DB832F57341992548CDBB333163A5A9667A34@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: [CCAMP] Last Call for OTN Routing and Signaling Drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 21:58:00 -0000 Lou and Deborah, Given that we expeditiously address the remaining small number of issues in= the OTN Routing and Signaling drafts, is there any reason why we need to w= ait until the next IETF meeting to initiate a Last Call on them? As has be= en pointed out many times, a WG's work is done on its mailing list and not = in its face-to-face meetings. Thanks, John =20 Sent from my iPhone From lberger@labn.net Tue Aug 7 15:03:58 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F8111E80FC for ; Tue, 7 Aug 2012 15:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.076 X-Spam-Level: X-Spam-Status: No, score=-98.076 tagged_above=-999 required=5 tests=[AWL=2.085, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gnIGpO3qCQn for ; Tue, 7 Aug 2012 15:03:57 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id B946A11E80D5 for ; Tue, 7 Aug 2012 15:03:57 -0700 (PDT) Received: (qmail 12184 invoked by uid 0); 7 Aug 2012 22:03:56 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 7 Aug 2012 22:03:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=E6q8KNVEJSKwyoFew6Cmw278o606+GgVFqDx1vtnk4I=; b=RjhnfKy5BjDFB6fSymyntewGZXxShuPiVbxg9awrbIxy8jWejThtBLcJvmWnL6H8EuNRfqtd6gNV5Ukp2371weM+5K4x6DU/3jvlsxJI2vO3wdtEnkM3Upvk7LEWOBYs; Received: from box313.bluehost.com ([69.89.31.113]:49690 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Syrsa-00040G-9g; Tue, 07 Aug 2012 16:03:56 -0600 Message-ID: <502190CA.9050305@labn.net> Date: Tue, 07 Aug 2012 18:03:54 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John E Drake References: <5E893DB832F57341992548CDBB333163A5A9667A34@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A5A9667A34@EMBX01-HQ.jnpr.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" , "dbrungard@att.com" Subject: Re: [CCAMP] Last Call for OTN Routing and Signaling Drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 22:03:58 -0000 John, I take it that this message is in response to: On 8/3/2012 5:14 PM, Lou Berger wrote: > Subject: [CCAMP] For discussion: Planned milestone update > Dec 2012 - Submit G.709 enhancements framework for IESG review > Dec 2012 - Submit G.709 enhancements solutions for IESG review What date are you proposing? I generally feel that the milestone date should be an upper limit and that reaching a milestone early is good, while missing one is not. Lou On 8/7/2012 5:56 PM, John E Drake wrote: > Lou and Deborah, > > Given that we expeditiously address the remaining small number of > issues in the OTN Routing and Signaling drafts, is there any reason > why we need to wait until the next IETF meeting to initiate a Last > Call on them? As has been pointed out many times, a WG's work is > done on its mailing list and not in its face-to-face meetings. > > Thanks, > > John > > Sent from my iPhone > > > > > > From jdrake@juniper.net Tue Aug 7 15:12:28 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3809C21F853E for ; Tue, 7 Aug 2012 15:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.131 X-Spam-Level: X-Spam-Status: No, score=-5.131 tagged_above=-999 required=5 tests=[AWL=1.468, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxIm00GUONgu for ; Tue, 7 Aug 2012 15:12:27 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8041821F8587 for ; Tue, 7 Aug 2012 15:12:27 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUCGSya2rM6avU7PTYGOb56LSLYVm/M71@postini.com; Tue, 07 Aug 2012 15:12:27 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 7 Aug 2012 15:10:57 -0700 From: John E Drake To: Lou Berger Date: Tue, 7 Aug 2012 15:10:55 -0700 Thread-Topic: Last Call for OTN Routing and Signaling Drafts Thread-Index: Ac106YTWFkimJqV8Romx8WJ8Trxryw== Message-ID: References: <5E893DB832F57341992548CDBB333163A5A9667A34@EMBX01-HQ.jnpr.net> <502190CA.9050305@labn.net> In-Reply-To: <502190CA.9050305@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "dbrungard@att.com" Subject: Re: [CCAMP] Last Call for OTN Routing and Signaling Drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 22:12:28 -0000 Lou, Yes it is and I'm sorry for my late response. I would check with Daniele a= nd Fatai but I would hope within a month. We have been working on these fo= r quite some time and they seem quite stable. Thanks, John Sent from my iPhone On Aug 7, 2012, at 6:03 PM, "Lou Berger" wrote: > John, > I take it that this message is in response to: >=20 > On 8/3/2012 5:14 PM, Lou Berger wrote: >> Subject: [CCAMP] For discussion: Planned milestone update >> Dec 2012 - Submit G.709 enhancements framework for IESG=0B review >> Dec 2012 - Submit G.709 enhancements solutions for IESG review >=20 > What date are you proposing? >=20 > I generally feel that the milestone date should be an upper limit and > that reaching a milestone early is good, while missing one is not. >=20 > Lou >=20 > On 8/7/2012 5:56 PM, John E Drake wrote: >> Lou and Deborah, >>=20 >> Given that we expeditiously address the remaining small number of >> issues in the OTN Routing and Signaling drafts, is there any reason >> why we need to wait until the next IETF meeting to initiate a Last >> Call on them? As has been pointed out many times, a WG's work is >> done on its mailing list and not in its face-to-face meetings. >>=20 >> Thanks, >>=20 >> John =20 >>=20 >> Sent from my iPhone >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 From adrian@olddog.co.uk Wed Aug 8 00:19:25 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1D511E808E for ; Wed, 8 Aug 2012 00:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08DrHMdbIzhr for ; Wed, 8 Aug 2012 00:19:24 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 19D4D21F85BB for ; Wed, 8 Aug 2012 00:19:23 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q787JLVs021943; Wed, 8 Aug 2012 08:19:21 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q787JJ3K021931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Aug 2012 08:19:20 +0100 From: "Adrian Farrel" To: Date: Wed, 8 Aug 2012 08:19:19 +0100 Message-ID: <021a01cd7536$2104aa10$630dfe30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac11NY6nevEXepS5RqKUu/wkiJbhHg== Content-Language: en-gb Cc: 'CCAMP' Subject: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 07:19:25 -0000 Hi, I have done my usual AD review of this document prior to issuing IETF last call. The purpose of my review is to catch any issues that might come up in last call or IESG evaluation, and so smooth the path of the document. This seems to be a well-written I-D, thanks. I have just a few small points that are mainly stylistic. A quick respin should address them. I start with one fundamental question that I hope can be answered by email. Thanks, Adrian === To start with, a key question: Why does the working group want to publish this as an RFC when there is no immediate intention to implement for any of the many scenarios described in the document? Will this become just another Standards Track RFC that gathers dust and obfuscates the real protocol specs, or is there good reason to publish it? --- I can see how this updates 4872. I am not convinced about this being an update to 2205, 3209 and 3473. Let me ask the question as follows: Is this document needed in order to produce a conformant implementation of RFC 2205 RSVP? In other words: is it your intention that all new implementations of RSVP MUST include an implementation of this document? If the document does make the updates stated, it would be good if some part of the document (maybe a new section, maybe just the Introduction) contained text that described what has been updated. Does Section 6.2 imply an update to RFC 4873? --- Section 1 Some ambiguity, since it looks like the extension is to recovery contexts other than GMPLS! OLD This document expands the possible usage of the ASSOCIATION object to non-GMPLS recovery contexts. NEW This document expands the possible usage of the ASSOCIATION object to contexts other than GMPLS recovery. END --- Section 1 Voice Call Waiting However, there is no way in RSVP today to share the resources between the A->B and A->C subflows of the call since by definition the RSVP reservations for these subflows must have different IP addresses in the SESSION objects. Since you are defining such a mechanism, "there is no way today" is not true. I suggest... Since, by definition, the RSVP reservations for the subflows A->B and A->C of the call must have different IP addresses in the SESSION objects, this document defines a new mechanism to associate the subflows and allow them to share resources. Similarly... OLD o Voice Shared Line: A single number that rings multiple endpoints (which may be geographically diverse), such as phone lines on a manager's desk and their assistant. A VoIP system that models these calls as multiple P2P unicast pre-ring reservations would result in significantly over-counting bandwidth on shared links, since today unicast reservations to different endpoints cannot share bandwidth. NEW o Voice Shared Line: A voice shared line is a single number that rings multiple endpoints (which may be geographically diverse), such as phone lines to a manager's desk and to their assistant. A VoIP system that models these calls as multiple P2P unicast pre-ring reservations would result in significantly over-counting bandwidth on shared links, since RSVP unicast reservations to different endpoints cannot share bandwidth. So a new mechanism is defined in this document allowing separate unicast reservations to be associated and share resources. END And... OLD o Symmetric NAT: RSVP permits sharing of resources between multiple flows addressed to the same destination D, even from different senders S1 and S2. However, if D is behind a NAT operating in symmetric mode [RFC5389], it is possible that the destination port of the flows S1->D and S2->D may be different outside the NAT. In this case, these flows cannot share resources using RSVP today, since the SESSION objects for these two flows outside the NAT would have different ports. NEW o Symmetric NAT: RSVP permits sharing of resources between multiple flows addressed to the same destination D, even from different senders S1 and S2. However, if D is behind a NAT operating in symmetric mode [RFC5389], it is possible that the destination port of the flows S1->D and S2->D may be different outside the NAT. In this case, these flows cannot share resources using RSVP, since the SESSION objects for these two flows outside the NAT have different ports. This document defines a new mechanisms to associate these flows and allow them to share resources. END --- Globally... s/extended ASSOCIATION/Extended ASSOCIATION/ --- Section 1 OLD This document also defines the extended ASSOCIATION objects which can be used in the context of Transport Profile of Multiprotocol Label Switching (MPLS-TP). Although, the scope of the extended ASSOCIATION objects is not limited to MPLS-TP. NEW This document also defines the Extended ASSOCIATION objects which can be used in the context of the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The scope of the Extended ASSOCIATION objects is not limited to MPLS-TP. END --- As with the previous ambiguity... OLD 3. Non-GMPLS Recovery Usage NEW 3. Uses other Than GMPLS Recovery END --- Section 3.1 s/defined generic/defines generic/ --- Section 3.1.2 A node that wishes to allow downstream nodes to associate Path state across RSVP sessions MUST include an ASSOCIATION object in the outgoing Path messages corresponding to the RSVP sessions to be associated. Yuck! Are the sessions to be associated in the outgoing Path messages or the Association object, or both. Actually, I don't think this needs a MUST, but can be converted to descriptive text as follows. A node that wishes to allow downstream nodes to associate Path state across RSVP sessions sends a Path message corresponding to one RSVP session and includes in that message an ASSOCIATION object that indicates the associated RSVP sessions. Then you have... In the absence of Association Type-specific rules for identifying association, the included ASSOCIATION objects MUST be identical across all associated sessions. I know what you mean, but what you have said would require that a Path message must contain an Association object that refers to itself. I think what you need has to be more verbose to be accurate. In the absence of Association Type-specific rules for identifying association, each Path message for a session in a set of associated sessions MUST include an ASSOCIATION object that indicates all the other sessions in the set. --- 3.1.1 vs 3.2.1 In 3.1.1 you have... Relative ordering of ASSOCIATION objects of the same type SHOULD be preserved by transit nodes. In 3.2.1 you have... Relative ordering of ASSOCIATION objects of the same type MUST be preserved by transit nodes. Association type specific ordering requirements MAY be defined in the future. 1. Why is 3.1.1 SHOULD and 3.1.2 MUST? 2. Why does 3.2.1 consider association type-specific rules, but these are not in 3.1.1? 3. s/type specific/Type-specific/ 4. Why "MAY" not "may"? --- 3.2.2 s/This section apply/This section applies/ --- 3.3.1 Once an association is identified, resources SHOULD be shared across the identified sessions. This use of "SHOULD" begs the question: under what circumstances MAY resource sharing not be applied? --- Globally... Please be consistent with: - Association ID - association-id --- Section 4.1 Global Association Source: 4 bytes This field contains a value that is a unique global identifier. This field MAY contain the 2-octet or 4-octet value of the provider's Autonomous System Number (ASN). It is expected that the global identifier will be derived from the globally unique ASN of the autonomous system hosting the Association Source. The special value of zero (0) indicates that no global identifier is present. Note that a Global Association Source of zero SHOULD be limited to entities contained within a single operator. Given the statement that the content is globally unique, I don't think there is room for you to pontificate about how this field might be filled. You need to make a definitive statement. Otherwise the content cannot be guaranteed to be globally unique (unless you envisage a central registration system!). --- Section 4.1 Extended Association ID: variable, 4-byte aligned This field contains data that is additional information to support unique identification. The length and contents of this field is determined by the Association Source. This field MAY be omitted, i.e., have a zero length. This field MUST be padded with zeros (0s) to ensure 32-bit alignment. This is confusing. I think that the length of the field is chosen by the Association source and determined by the Length field of the Association object. But your text implies that the contents of the field may be different from a four octet quantity. Since you have not included a separate length indicator, this cannot be. The object length must always be a multiple of 4 (says RFC 2205) and so there is no difference between a zero padded field and a field where the zeros have meaning. You *could* say that the length of this field is Association Type- specific, but that would be ugly. --- While you're at it, please note that draft-ietf-ccamp-assoc-info has been published as RFC 6689 From zhang.fei3@zte.com.cn Wed Aug 8 00:41:41 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC0221F86A1 for ; Wed, 8 Aug 2012 00:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.926 X-Spam-Level: X-Spam-Status: No, score=-95.926 tagged_above=-999 required=5 tests=[AWL=-1.249, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, J_CHICKENPOX_93=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kt8l4vJhmgFB for ; Wed, 8 Aug 2012 00:41:39 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id C889F21F869D for ; Wed, 8 Aug 2012 00:41:38 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723473195744; Wed, 8 Aug 2012 15:29:07 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 56952.4947443848; Wed, 8 Aug 2012 15:41:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q787fMM0002609; Wed, 8 Aug 2012 15:41:22 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: "Rakesh Gandhi (rgandhi)" MIME-Version: 1.0 X-KeepSent: 38A9EAF6:89BD6860-48257A54:00286E96; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Wed, 8 Aug 2012 15:41:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-08 15:41:20, Serialize complete at 2012-08-08 15:41:20 Content-Type: multipart/alternative; boundary="=_alternative 002A32AE48257A54_=" X-MAIL: mse02.zte.com.cn q787fMM0002609 Cc: "Robert Sawaya \(rsawaya\)" , "yang.fan5@zte.com.cn" , CCAMP , "jingrq@ctbri.com.cn" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 07:41:42 -0000 This is a multipart message in MIME format. --=_alternative 002A32AE48257A54_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhhbmsgeW91IFJha2VzaCBmb3IgeW91ciBwcm9tcHQgcmVzcG9uc2UgOikNCg0KU25pcHBlZCB0 aGUgYWdyZWVhYmxlIHBhcnRzLCBzZWUgaW4gbGluZSB3aXRoIDxmZWkxPg0KDQo8Ukc0PiBJIGFn cmVlIHRoYXQgaWYgYm90aCB2ZW5kb3JzIGltcGxlbWVudCBzYXkgbWV0aG9kIDEgb3IgYm90aCB2 ZW5kb3JzIA0KaW1wbGVtZW50IHNheSBtZXRob2QgMiB0aGVuIHRoZXkgd291bGQgaW50ZXJvcGVy YXRlLCBhbmQgIGV4dCBFQSBvYmplY3RzIA0KYXJlIHRoZSBzYW1lLiBCdXQgbWV0aG9kIDEgYW5k IG1ldGhvZCAyIG1heSBub3QgaW50ZXJvcGVyYXRlIHRvZ2V0aGVyLiBOb3QgDQpzdXJlIGlmIHdl IHdhbnQgdG8gaGF2ZSBhIHNlcGFyYXRlIGZsYWcgdG8gaW5kaWNhdGUgaWYgZXh0IGFzc29jaWF0 aW9uIA0Kb2JqZWN0IGlzIHBvcHVsYXRlZCB3aXRoIG1ldGhvZCAxIG9yIDIgdG8gY292ZXIgdGhp cyBjYXNlPyAgIEl0IGlzIGZpbmUgdG8gDQpoYXZlIG1vcmUgdGhhbiBvbmUgbWV0aG9kIGluIHRo ZSBkcmFmdCBmb3IgZmxleGliaWxpdHkgYW5kIGZ1dHVyZSB1c2UgYnV0IA0KZ29vZCB0byBlbGFi b3JhdGUgb24gdGhlIHBvc3NpYmxlIHVzZSBjYXNlIGlmIHdlIGtub3cgb2YgYW55Lg0KDQo8ZmVp MT4gSU1ITywgdGhlIG9ubHkgZGlmZmVyZW5jZSBpcyB0aGUgdW5pcXVlIHJlcHJlc2VudGF0aW9u IG9mIHRoZSANCmFzc29jaWF0aW9uLCB1c2luZyBTQSthc3NvY2lhdGlvbi1pZChJRCBpcyB1bmlx dWUgdW5kZXIgU0EgKW9yIA0KU0ErREErYXNzb2NpYXRpb24taWQgKElEIGlzIHVuaXF1ZSB1bmRl ciB0aGUgY29tYmluYXRpb24gb2YgU0EgYW5kIERBKSANCndoaWNoIGlzIG1vcmUgc3RyaWN0ZXIu IEkgYWdyZWUgdGhhdCB3ZSBoYWQgYmV0dGVyIGFkb3B0aW5nIG9uZSBvZiB0aGVtIA0KYmVjYXVz ZSBvZiB0aGUgaW50ZXJvcCBpc3N1ZS4NCg0KTGV0J3MgY29uc2lkZXIgdGhlIGF1dG8tbWVzaCB0 dW5uZWxzIHdoaWNoIHlvdSBwcm92aWRlZCBpbiB0aGUgcHJldmlvdXMgDQplbWFpbC4gICI8Ukc+ IFRoZXJlIGlzIGEgdXNlIGNhc2UgZm9yIGF1dG8tbWVzaCB0dW5uZWxzIHdoZXJlIHNvdXJjZSBu b2RlIA0KbWF5IG9yaWdpbmF0ZSB0dW5uZWxzIHRvIG1hbnkgZGVzdGluYXRpb25zIHVzaW5nIHRo ZSBzYW1lIGFzc29jaWF0aW9uIA0Kc291cmNlIGFuZCBhc3NvY2lhdGlvbi1pZC4gSW4gdGhpcyBj YXNlLCBkaWZmZXJlbnQgdmFsdWVzIGZvciBleHRlbmRlZCANCmFzc29jaWF0aW9uIElEIHByb3Zp ZGUgdW5pcXVlIGV4dGVuZGVkIGFzc29jaWF0aW9uIG9iamVjdC4iDQpDYW4geW91IGNsYXJpZnkg d2hhdCBpcyB0aGUgYmVuZWZpdHMgb2YgdXNpbmcgdGhlIHNhbWUgYXNzb2NpYXRpb24taWQgDQoo ZGlmZmVyZW50IGFzc29jaWF0aW9uLWlkIHdvcmtzIHdlbGwgYWxzbyksIHNvIHRoYXQgd2UgY2Fu IHBlcnN1YWRlIHRoZSBXRyANCnRoYXQgdGhpcyBzdHJpY3QgaW1wbGVtZW50YXRpb24gaXMgYSBi ZXR0ZXIgY2hvaWNlIGFuZCBhZGQgdGhlIHVzZWNhc2UgaWYgDQpuZWNlc3NhcnkuDQoNCk9yIGFu eSBvdGhlciB1c2VjYXNlcz8NCg0KUGxlYXNlIGRvIG5vdCBoZXNpdGF0ZSB0byBsZXQgbWUga25v dyBpZiBJIGhhdmUgYSBtaXN0YWtlDQoNCkJlc3QgcmVnYXJkcw0KDQpGZWkNCg0KDQoNCiJSYWtl c2ggR2FuZGhpIChyZ2FuZGhpKSIgPHJnYW5kaGlAY2lzY28uY29tPiANCjIwMTItMDgtMDMgMjA6 MTENCg0KytW8/sjLDQoiemhhbmcuZmVpM0B6dGUuY29tLmNuIiA8emhhbmcuZmVpM0B6dGUuY29t LmNuPg0Ks63LzQ0KQ0NBTVAgPGNjYW1wQGlldGYub3JnPiwgIkVyaWMgT3Nib3JuZSAoZW9zYm9y bmUpIiA8ZW9zYm9ybmVAY2lzY28uY29tPiwgDQoiamlhbmcud2VpbGlhbkB6dGUuY29tLmNuIiA8 amlhbmcud2VpbGlhbkB6dGUuY29tLmNuPiwgDQoiamluZ3JxQGN0YnJpLmNvbS5jbiIgPGppbmdy cUBjdGJyaS5jb20uY24+LCAiUm9iZXJ0IFNhd2F5YSAocnNhd2F5YSkiIA0KPHJzYXdheWFAY2lz Y28uY29tPiwgIkdlb3JnZSBTd2FsbG93IChzd2FsbG93KSIgPHN3YWxsb3dAY2lzY28uY29tPiwg DQoieWFuZy5mYW41QHp0ZS5jb20uY24iIDx5YW5nLmZhbjVAenRlLmNvbS5jbj4NCtb3zOINClJF OiBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lh dGVkLWxzcC0wMw0KDQoNCg0KDQoNCg0KVGhhbmtzIEZlaS4gV2UgYXJlIGFsbW9zdCB0aGVyZS4g UGxlYXNlIHNlZSBpbmxpbmUuLjxSRzQ+Lg0KIA0KRnJvbTogemhhbmcuZmVpM0B6dGUuY29tLmNu IFttYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuXSANClNlbnQ6IEZyaWRheSwgQXVndXN0IDAz LCAyMDEyIDU6MTYgQU0NClRvOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KQ2M6IENDQU1QOyBF cmljIE9zYm9ybmUgKGVvc2Jvcm5lKTsgamlhbmcud2VpbGlhbkB6dGUuY29tLmNuOyANCmppbmdy cUBjdGJyaS5jb20uY247IFJvYmVydCBTYXdheWEgKHJzYXdheWEpOyBHZW9yZ2UgU3dhbGxvdyAo c3dhbGxvdyk7IA0KeWFuZy5mYW41QHp0ZS5jb20uY24NClN1YmplY3Q6IFJFOiBDb21tZW50cyBv biANCmRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTAz DQogDQoNCkhpIFJha2VzaCANCg0KU25pcHBlZCB0aGUgb3RoZXIgcGFydHMgZm9yIGVhc3kgcmVh ZGluZywgc29ycnkgZm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlIA0KDQo8UkczPiBUaGVyZSBhcmUg YXBwbGljYXRpb25zIHRoYXQgcmVxdWlyZSBjby1yb3V0ZWQgTFNQcy4gU28gSSB0aGluayB3ZSAN CnNob3VsZCBoYXZlIGEgZmxhZyB0byBpbmRpY2F0ZSB0aGF0IExTUHMgbXVzdCBiZSBjby1yb3V0 ZWQsIGVsc2Ugbm9kZSB3aWxsIA0Kc2VuZCBhIHBhdGggZXJyb3IgZm9yIGV4YW1wbGUgaWYgcmVx dWVzdCBjYW5ub3QgYmUgbWV0LiAgSSBhZ3JlZSB3aXRoIHlvdSANCmFib3V0IGNvbXBsZXhpdHkg d2l0aCBkb3VibGUgc2lkZWQgcHJvdmlzaW9uaW5nIG1vZGVsIHRob3VnaC4gDQoNCjxmZWk+IFNp bmNlIHlvdSBiZWxpZXZlIHRoYXQgYSBjb21tb24gbWVjaGFuaXNtIHVzZWQgZm9yIHRoZSBub24t Y29yb3V0ZWQgDQphbmQgY29yb3V0ZWQgY2FzZXMgaXMgdXNlZnVsLCB3ZSB3aWxsIGFkZCB0aGUg dGV4dHMgaW4gdGhlIG5leHQgdmVyc2lvbi4gDQo8Ukc0PiBUaGlzIGlzIGdyZWF0LiBUaGFua3Mu IA0KDQoNCjxSRzM+IE9rLCB3ZSBwcm9iYWJseSBzaG91bGQgYWRkIHVzZSBjYXNlcyBmb3IgdmFy aW91cyBtZXRob2RzLiBJIGNhbiBzZWUgDQptZXRob2QgMSBiZWluZyB1c2VkIGZvciBzZXR0aW5n IHVwIGJpZGlyZWN0aW9uYWwgTFNQcyBidXQgSSBhbSBub3Qgc3VyZSANCmFib3V0IG1ldGhvZCAy IGZvciBleGFtcGxlLiBPbmUgd29ycnkgaXMgdGhhdCBkaWZmZXJlbnQgbWV0aG9kcyBjYW4gbGVh ZCANCnRvIGludGVyb3AgaXNzdWVzIGlmIG9uZSB2ZW5kb3IgaW1wbGVtZW50cyBtZXRob2QgMSBh bmQgc2Vjb25kIHZlbmRvciANCm1ldGhvZCAyLiANCkFzc29jaWF0aW9uIG9iamVjdCBpcyBiZWlu ZyB1c2VkIGZvciBkaWZmZXJlbnQgYXNzb2NpYXRpb24gdHlwZXMgKFJGQyANCjQ4NzI6IHR5cGUg MTogUmVjb3ZlcnkpLCAoUkZDIDQ4NzMtIHR5cGUgMjogUmVzb3VyY2Ugc2hhcmluZyksIGV0Yy4g YW5kIA0KdGhlc2UgUkZDcyBkZWZpbmUgc3BlY2lmaWMgcHJvY2VkdXJlcyBmb3IgdGhlIGdpdmVu IGFzc29jaWF0aW9uIHR5cGUuIFNvIA0KSU1ITywgaXQgbWF5IGJlIG9rIHRvIGRlZmluZSBhIHN0 cmljdGVyIHByb2NlZHVyZSBmb3IgcG9wdWxhdGluZyBleHQgDQphc3NvY2lhdGlvbiBvYmplY3Qg Zm9yIHRoZSBuZXcgQmlkaXJlY3Rpb25hbCBMU1BzIGFzc29jaWF0aW9uIHR5cGUuIA0KDQo8ZmVp PiBNZXRob2QgMiB3b3JrcyB3ZWxsLCBhbmQgdGhlIG9ubHkgZGlmZmVyZW5jZSBpcyB0IGhvdyB0 byByZXByZXNlbnQgDQp0aGUgZ2xvYmFsIHVuaXF1ZSBpZGVudGlmaWVyLiBGb3IgdGhlIGFzc29j aWF0aW9uIGlzIGJhc2VkIG9uIHRoZSBmdWxsIA0KbWF0Y2ggb2YgdGhlIEVBIG9iamVjdHMsIHRo ZSBFQSBvYmplY3QgaXMganVzdCBjb3BpZWQgZnJvbSB0aGUgcGF0aCANCm1lc3NhZ2UgaW50byBh bm90aGVyIHBhdGggbWVzc2FnZSBpbiBzaW5nbGUgc2lkZWQgcHJvdmlzaW9uaW5nIG1vZGVsLiBB cyANCnRvIHRoZSBkb3VibGVkIHNpZGVkIHByb3Zpc2lvbmluZyBtb2RlbCwgdGhlIEVBIG9iamVj dHMgaXMgYWxzbyB0aGUgc2FtZS4gDQpJTUhPLCB0aGVyZSBpcyBubyBpbnRlcm9wIGlzc3Vlcywg b3IgZG8gSSBoYXZlIHNvbWUgbWlzdW5kZXJzdGFuZGluZz8gDQoNClllYWgsIHdlIGNhbiBkZWZp bmUgYSBzdHJpY3RlciBwcm9kZWR1cmUsIEkgYW0gbm90IHN1cmUgdGhpcyBpcyBhIGdvb2Qgd2F5 IA0KaW4gc3RhbmRhcmQsIG5lZWQgbW9yZSBmZWVkYmFjayBmcm9tIHRoZSBXRy4gDQo8Ukc0PiBJ IGFncmVlIHRoYXQgaWYgYm90aCB2ZW5kb3JzIGltcGxlbWVudCBzYXkgbWV0aG9kIDEgb3IgYm90 aCB2ZW5kb3JzIA0KaW1wbGVtZW50IHNheSBtZXRob2QgMiB0aGVuIHRoZXkgd291bGQgaW50ZXJv cGVyYXRlLCBhbmQgIGV4dCBFQSBvYmplY3RzIA0KYXJlIHRoZSBzYW1lLiBCdXQgbWV0aG9kIDEg YW5kIG1ldGhvZCAyIG1heSBub3QgaW50ZXJvcGVyYXRlIHRvZ2V0aGVyLiBOb3QgDQpzdXJlIGlm IHdlIHdhbnQgdG8gaGF2ZSBhIHNlcGFyYXRlIGZsYWcgdG8gaW5kaWNhdGUgaWYgZXh0IGFzc29j aWF0aW9uIA0Kb2JqZWN0IGlzIHBvcHVsYXRlZCB3aXRoIG1ldGhvZCAxIG9yIDIgdG8gY292ZXIg dGhpcyBjYXNlPyAgIEl0IGlzIGZpbmUgdG8gDQpoYXZlIG1vcmUgdGhhbiBvbmUgbWV0aG9kIGlu IHRoZSBkcmFmdCBmb3IgZmxleGliaWxpdHkgYW5kIGZ1dHVyZSB1c2UgYnV0IA0KZ29vZCB0byBl bGFib3JhdGUgb24gdGhlIHBvc3NpYmxlIHVzZSBjYXNlIGlmIHdlIGtub3cgb2YgYW55Lg0KVGhh bmtzLA0KUmFrZXNoDQoNCg0KQ2hlZXIgDQoNCkZlaSANCg0KDQoiUmFrZXNoIEdhbmRoaSAocmdh bmRoaSkiIDxyZ2FuZGhpQGNpc2NvLmNvbT4gDQoyMDEyLTA4LTAxIDAxOjI0IA0KDQoNCsrVvP7I yw0KInpoYW5nLmZlaTNAenRlLmNvbS5jbiIgPHpoYW5nLmZlaTNAenRlLmNvbS5jbj4gDQqzrcvN DQoiRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkiIDxlb3Nib3JuZUBjaXNjby5jb20+LCAiamlhbmcu d2VpbGlhbkB6dGUuY29tLmNuIiANCjxqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY24+LCAiamluZ3Jx QGN0YnJpLmNvbS5jbiIgPGppbmdycUBjdGJyaS5jb20uY24+LCANCiJSb2JlcnQgU2F3YXlhIChy c2F3YXlhKSIgPHJzYXdheWFAY2lzY28uY29tPiwgIkdlb3JnZSBTd2FsbG93IChzd2FsbG93KSIg DQo8c3dhbGxvd0BjaXNjby5jb20+LCAieWFuZy5mYW41QHp0ZS5jb20uY24iIDx5YW5nLmZhbjVA enRlLmNvbS5jbj4sIENDQU1QIA0KPGNjYW1wQGlldGYub3JnPiANCtb3zOINClJFOiBDb21tZW50 cyBvbiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0w Mw0KIA0KDQoNCg0KDQoNCg0KDQoNCkhpIEZlaSwgDQogIA0KVGhhbmtzIGZvciB5b3VyIGtpbmQg cmVwbHkuIFBsZWFzZSBzZWUgaW5saW5lLi48UkczPi4uIA0KICANCjxTbmlwcGVkIGVtYWlsIHRv IGZvY3VzIG9uIG9wZW4gaXRlbXM+IA0KICANCiAgDQpGcm9tOiB6aGFuZy5mZWkzQHp0ZS5jb20u Y24gW21haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY25dIA0KU2VudDogTW9uZGF5LCBKdWx5IDMw LCAyMDEyIDEwOjA0IFBNDQpUbzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCkNjOiBFcmljIE9z Ym9ybmUgKGVvc2Jvcm5lKTsgamlhbmcud2VpbGlhbkB6dGUuY29tLmNuOyBqaW5ncnFAY3Ricmku Y29tLmNuDQo7IFJvYmVydCBTYXdheWEgKHJzYXdheWEpOyBHZW9yZ2UgU3dhbGxvdyAoc3dhbGxv dyk7IHlhbmcuZmFuNUB6dGUuY29tLmNuOyANCkNDQU1QDQpTdWJqZWN0OiBSRTogQ29tbWVudHMg b24gDQpkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0w MyANCg0KVGhhbmsgeW91IFJha2VzaCBmb3Igc2hhcmluZyB5b3VyIGlkZWEsIEkgdGhpbmsgd2Ug YXJlIHJvdWdobHkgaW4gDQphZ3JlZW1lbnQgYW5kIG5lZWQgdG8gaGVhciBtb3JlIHZvaWNlcyBm cm9tIHRoZSBXRy4gOikgDQoNClNlZSBpbmxpbmUgPGZlaT48L2ZlaT4NCg0KQmVzdCANCg0KRmVp IA0KDQoyKSBEZWZpbmUgb25lIGZsYWcgZm9yIGNvLXJvdXRlZCBvciBub24tY29yb3V0ZWQuIElm IHRoZSBjby1yb3V0ZWQgYmlkaXIgDQppcyB0aGUgZGVmYXVsdCBiZWhhdmlvciwgd2h5IG5vdCB1 c2luZyB0aGUgcHJvY2VkdXJlIGRlZmluZWQgaW4gUkZDMzQ3Mz8gSSANCmFtIGFmcmFpZCBpdCBp cyBoYXJkIA0KdG8gcGVyc3VhZGUgdGhlIFdHIHRvIGRvIHNvLiBNYXliZSB0aGUgYmV0dGVyIHdh eSBpcyB0aGF0IG5vbi1jb3JvdXRlZCANCmJpZGlyIGlzIHRoZSBkZWZhdWx0LCBhbmQgdGhlIHNl dCBvZiB0aGUgY28tcm91dGVkIGZsYWcgb25seSBtZWFucyB0aGF0IGl0IA0KaXMgcmVjb21tZW5k ZWQsIG5vdCBtYW5kYXRvcnksIHRoZSBjaGVja2luZyB3aGV0aGVyIHRoZSBMU1AgaXMgY28tcm91 dGVkIA0KY2FuIGJlIGRvbmUgYnkgY29tcGFyaW5nIHRoZSBSUk8gb2JqZWN0cy4gV2hhdCBpcyB5 b3VyIG9waW5pb24/IA0KPFJHMT4gSXQgaXMgZmluZSB0byBoYXZlIG5vbiBjby1yb3V0ZWQgYXMg ZGVmYXVsdC4gUkZDIDM0NzMgaXMgYSBHTVBMUyANCnNpZ25hbGluZyBwcm9jZWR1cmUuIEl0IG1h eSBub3QgYmUgb3B0aW1hbCAgdG8gaGF2ZSB0d28gZGlmZmVyZW50IA0Kc2lnbmFsaW5nIHByb2Nl ZHVyZXMsIG9uZSBmb3Igbm9uIGNvLXJvdXRlZCAoZXh0IGFzc29jaWF0ZWQgb2JqZWN0KSBhbmQg DQpvbmUgZm9yIGNvLXJvdXRlZCAoUkZDIDM0NzMpIHByb2NlZHVyZXMuIEJ5IGFkZGluZyBhIGZs YWcgZm9yIGNvLXJvdXRlZCwgDQpzYW1lIHNpZ25hbGluZyAoZXh0IGFzc29jaWF0ZWQgb2JqZWN0 KSBjYW4gYmUgdXNlZCBmb3IgYm90aCB3aGljaCBpcyBuaWNlLiANCldlIGJlbGlldmUgY29tcGFy aW5nIG9mIFJSTyBjYW4gYmUgbWlzbGVhZGluZyBiZWNhdXNlIHR3byBMU1BzIGNhbiBiZSBvbiAN CnRoZSBzYW1lIHBhdGggZXZlbiB0aG91Z2ggcHJvdmlzaW9uZWQgdG8gYmUgbm9uIGNvLXJvdXRl ZC4gDQoNCjxmZWk+IA0KU29ycnkgdGhhdCB3aGF0IEkgc3VnZ2VzdGVkIG1heWJlIG1pc2xlYWQg eW91LCB0aGUgZm9sbG93aW5nIGRlc2NyaXBpdG9ucyANCmFyZSBtb3JlIGFjY3VyYXRlLiA6KSAN CjEpVGhlIGRlZmF1bHQgYmVoYXZpb3IgKG5vbi1jb3JvdXRlZCkgbWVhbnMgdGhhdCBpdCBpcyBu b3QgcmVxdWlyZWQgdG8gYmUgDQpjby1yb3V0ZWQuIEluIG90aGVyIHdvcmRzLCBpdCBpcyBhbHNv IE9LIHRoYXQgdGhlIHR3byBwYXRocyBhcmUgYWxvbmcgdGhlIA0Kc2FtZSBwYXRoIA0KICANCi4g DQo8UkczPiBBZ3JlZS4gDQoNCjIpVGhlIGZsYWcgc2V0IG1lYW5zIHRoYXQgY28tcm91dGVkIGlz IHJlY29tbWVuZGVkLiBJbiBvdGhlciB3b3JkcywgdGhlIA0KcmV2ZXJzZSBMU1AgU0hPVUxEIGJl IGVzdGFibGlzaGVkIGluIHRoZSBzYW1lIHBhdGggYXMgbXVjaCBhcyBwb3NzaWJsZS4gSWYgDQp0 aGUgZmxhZyBzZXQgbWVhbnMgDQp0aGF0IGNvLXJvdXRlZCBpcyBtYW5kYXRvcnksdGhlIHByb2Nl ZHVyZXMgd2lsbCBiZSB2ZXJ5IGNvbXBsZXggaW4gZG91YmxlIA0Kc2lkZWQgcHJvdmlzaW9uaW5n IG1vZGVsLiANCjwvZmVpPiANCjxSRzM+IFRoZXJlIGFyZSBhcHBsaWNhdGlvbnMgdGhhdCByZXF1 aXJlIGNvLXJvdXRlZCBMU1BzLiBTbyBJIHRoaW5rIHdlIA0Kc2hvdWxkIGhhdmUgYSBmbGFnIHRv IGluZGljYXRlIHRoYXQgTFNQcyBtdXN0IGJlIGNvLXJvdXRlZCwgZWxzZSBub2RlIHdpbGwgDQpz ZW5kIGEgcGF0aCBlcnJvciBmb3IgZXhhbXBsZSBpZiByZXF1ZXN0IGNhbm5vdCBiZSBtZXQuICBJ IGFncmVlIHdpdGggeW91IA0KYWJvdXQgY29tcGxleGl0eSB3aXRoIGRvdWJsZSBzaWRlZCBwcm92 aXNpb25pbmcgbW9kZWwgdGhvdWdoLiANCg0KDQozKUFzIHRvIHRoZSB0dXBsZSBvZiA8bG93ZXIg aXAgYWRkcmVzcywgaGlnaCBpcCBhZGRyZXNzLCBhc3NvY2lhdGlvbiBpZD4sIA0KeWVhaCwgaXQg aXMgb25lIGtpbmQgb2YgaW1wbGVtZW50YXRpb24sIGJ1dCB0aGVyZSBhcmUgcG90ZW50aWFsIHNv bWUgb3RoZXIgDQpyZWFsaXphdGlvbnMsIGxpa2UgdXNpbmcgb25lIG9mIHRoZSByb3V0ZXIgaWQg cGx1cyB0aGUgdHVubmVsIGlkLiBJIHRoaW5rIA0Kd2UgaGFkIGJldHRlciBub3QgcmVzdHJpY3Qg dGhlIGV4ZWN1dGlvbiB0byBzdWNoIGEgbmFycm93IHNjb3BlLiBXaGF0IA0KYWJvdXQgdGhlIEVB IGZvcm1hdCBsaXN0ZWQgYmVsb3c/IA0KDQogICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAg ICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiAgIHwgICAgICAgICAgICBMZW5ndGggICAgICAgICAgICAgfCBDbGFzcy1OdW0oMTk5 KXwgIEMtVHlwZSAoVEJBKSB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICBBc3NvY2lhdGlvbiBU eXBlICAgICAgICB8ICAgICAgIEFzc29jaWF0aW9uIElEICAgICAgICAgIHwNCiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICB8ICAgICAgICAgICAgICAgICAgICBJUHY0IEFzc29jaWF0aW9uIFNvdXJjZSAgICAgICAg ICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICAgR2xvYmFs IEFzc29jaWF0aW9uIFNvdXJjZSAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAg fEV4dGVuZGVkIEFzc29jaWF0aW9uIEZsYWdzLiAgICB8RXh0ZW5kZWQgQXNzb2NpYXRpb24gSUQg Li4uICAgIHwgDQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsgDQogICAgfC4uLi4oY29udGludWUpICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDoNCiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCjxS Rz4gRG8geW91IG1lYW4gdG8gaGF2ZSBleHRlbmRlZCBhc3NvY2lhdGlvbiBJRCBhcyB0dW5uZWwg SUQgKDE2IGJpdHMpICsgDQpJUCBhZGRyZXNzICgzMiBiaXRzKSBpbiB0aGlzIG9iamVjdD8gDQpQ bGVhc2Ugc2VlIGlubGluZSBiZWxvdy4uPFJHMT4uLiANCg0KPGZlaT4gDQpOby4gSSB3YW50IHRv IHNheSB0aGF0IHRoaXMgZm9ybWF0IG9mIEVBIG9iamVjdHMgY2FuIGFjY29tb2RhdGUgbW9yZSBr aW5kcyANCm9mIGltcGxlbWVudGF0aW9ucy4gTGlrZSANCg0KMSlBc3NvY2lhdGlvbiBJRDogdXNl ciBwcm92aXNpb25lZCBpZGVudGlhbCB2YWx1ZTsgQXNzb2NpYXRpb24gU291cmNlOiB0aGUgDQps b3dlIGlwIGFkZHJlc3M7IEVBIElEOiB0aGUgaGlnaGVyIElQIGFkZHJlc3MuIEFzIHlvdSBzdWdn ZXN0ZWQgDQoNCjIpQXNzb2NpYXRpb24gSUQ6IHR1bm5lbCBJRCBvciB1c2VyIHByb3Zpc2lvbmVk IHZhbHVlOyBBc3NvY2lhdGlvbiANClNvdXJjZTpUdW5uZWwgc2VuZGVyIGFkZHJlc3Mgb3IgdXNl ciBwcm92aXNpb25lZDsgRUEgSUQ6IGJlIGVtcHR5IG9yIExTUCANCklEIG9yIGFueSBvdGhlciBp bmZvcm1hdGlvbi4gDQoNCjMpVGhlIHBvdGVudGlhbCBvdGhlciBpbXBsZW1lbnRhdGlvbnMuLi4g DQoNCklNSE8sIHRoZSBFQSBJRCBjYW4gYmUgSVAgYWRkcmVzcyBvciBhbnkgb3RoZXIgdmFsdWVz IGluIHRoZSBjb250ZXh0IG9mIA0KQXNzb2NpYXRpb24gU291cmNlIHBsdXMgQXNzb2NpYXRpb24g SUQsIHdoaWNoIGlzIGJhY2t3YXJkIGNvbXBhdGlibGUuIA0KDQo8L2ZlaT4gDQo8UkczPiBPaywg d2UgcHJvYmFibHkgc2hvdWxkIGFkZCB1c2UgY2FzZXMgZm9yIHZhcmlvdXMgbWV0aG9kcy4gSSBj YW4gc2VlIA0KbWV0aG9kIDEgYmVpbmcgdXNlZCBmb3Igc2V0dGluZyB1cCBiaWRpcmVjdGlvbmFs IExTUHMgYnV0IEkgYW0gbm90IHN1cmUgDQphYm91dCBtZXRob2QgMiBmb3IgZXhhbXBsZS4gT25l IHdvcnJ5IGlzIHRoYXQgZGlmZmVyZW50IG1ldGhvZHMgY2FuIGxlYWQgDQp0byBpbnRlcm9wIGlz c3VlcyBpZiBvbmUgdmVuZG9yIGltcGxlbWVudHMgbWV0aG9kIDEgYW5kIHNlY29uZCB2ZW5kb3Ig DQptZXRob2QgMi4gDQpBc3NvY2lhdGlvbiBvYmplY3QgaXMgYmVpbmcgdXNlZCBmb3IgZGlmZmVy ZW50IGFzc29jaWF0aW9uIHR5cGVzIChSRkMgDQo0ODcyOiB0eXBlIDE6IFJlY292ZXJ5KSwgKFJG QyA0ODczLSB0eXBlIDI6IFJlc291cmNlIHNoYXJpbmcpLCBldGMuIGFuZCANCnRoZXNlIFJGQ3Mg ZGVmaW5lIHNwZWNpZmljIHByb2NlZHVyZXMgZm9yIHRoZSBnaXZlbiBhc3NvY2lhdGlvbiB0eXBl LiBTbyANCklNSE8sIGl0IG1heSBiZSBvayB0byBkZWZpbmUgYSBzdHJpY3RlciBwcm9jZWR1cmUg Zm9yIHBvcHVsYXRpbmcgZXh0IA0KYXNzb2NpYXRpb24gb2JqZWN0IGZvciB0aGUgbmV3IEJpZGly ZWN0aW9uYWwgTFNQcyBhc3NvY2lhdGlvbiB0eXBlLiANCiAgDQpUaGFua3MsIA0KUmFrZXNoDQog DQoNCg== --=_alternative 002A32AE48257A54_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rIHlvdSBSYWtlc2ggZm9y IHlvdXIgcHJvbXB0IHJlc3BvbnNlDQo6KTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+U25pcHBlZCB0aGUgYWdyZWVhYmxlIHBhcnRzLCBzZWUgaW4NCmxp bmUgd2l0aCAmbHQ7ZmVpMSZndDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jmx0O1JHNCZndDsgSSBhZ3JlZSB0aGF0DQppZiBib3Ro IHZlbmRvcnMgaW1wbGVtZW50IHNheSBtZXRob2QgMSBvciBib3RoIHZlbmRvcnMgaW1wbGVtZW50 IHNheSBtZXRob2QNCjIgdGhlbiB0aGV5IHdvdWxkIGludGVyb3BlcmF0ZSwgYW5kICZuYnNwO2V4 dCBFQSBvYmplY3RzIGFyZSB0aGUgc2FtZS4NCkJ1dCBtZXRob2QgMSBhbmQgbWV0aG9kIDIgbWF5 IG5vdCBpbnRlcm9wZXJhdGUgdG9nZXRoZXIuICZuYnNwO05vdCBzdXJlDQppZiB3ZSB3YW50IHRv IGhhdmUgYSBzZXBhcmF0ZSBmbGFnIHRvIGluZGljYXRlIGlmIGV4dCBhc3NvY2lhdGlvbiBvYmpl Y3QNCmlzIHBvcHVsYXRlZCB3aXRoIG1ldGhvZCAxIG9yIDIgdG8gY292ZXIgdGhpcyBjYXNlPyAm bmJzcDsgSXQgaXMgZmluZSB0bw0KaGF2ZSBtb3JlIHRoYW4gb25lIG1ldGhvZCBpbiB0aGUgZHJh ZnQgZm9yIGZsZXhpYmlsaXR5IGFuZCBmdXR1cmUgdXNlIGJ1dA0KZ29vZCB0byBlbGFib3JhdGUg b24gdGhlIHBvc3NpYmxlIHVzZSBjYXNlIGlmIHdlIGtub3cgb2YgYW55LjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0O2ZlaTEmZ3Q7IElNSE8sIHRo ZSBvbmx5IGRpZmZlcmVuY2UNCmlzIHRoZSB1bmlxdWUgcmVwcmVzZW50YXRpb24gb2YgdGhlIGFz c29jaWF0aW9uLCB1c2luZyBTQSthc3NvY2lhdGlvbi1pZChJRA0KaXMgdW5pcXVlIHVuZGVyIFNB IClvciBTQStEQSthc3NvY2lhdGlvbi1pZCAoSUQgaXMgdW5pcXVlIHVuZGVyIHRoZSBjb21iaW5h dGlvbg0Kb2YgU0EgYW5kIERBKSB3aGljaCBpcyBtb3JlIHN0cmljdGVyLiBJIGFncmVlIHRoYXQg d2UgaGFkIGJldHRlciBhZG9wdGluZw0Kb25lIG9mIHRoZW0gYmVjYXVzZSBvZiB0aGUgaW50ZXJv cCBpc3N1ZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PkxldCdzIGNvbnNpZGVyIHRoZSBhdXRvLW1lc2ggdHVubmVscw0Kd2hpY2ggeW91IHByb3ZpZGVk IGluIHRoZSBwcmV2aW91cyBlbWFpbC4gJm5ic3A7JnF1b3Q7PC9mb250Pjxmb250IHNpemU9MiBj b2xvcj0jMWY0OTdkIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtSRyZndDsNClRoZXJlIGlzIGEgdXNl IGNhc2UgZm9yIGF1dG8tbWVzaCB0dW5uZWxzIHdoZXJlIHNvdXJjZSBub2RlIG1heSBvcmlnaW5h dGUNCnR1bm5lbHMgdG8gbWFueSBkZXN0aW5hdGlvbnMgdXNpbmcgdGhlIHNhbWUgYXNzb2NpYXRp b24gc291cmNlIGFuZCBhc3NvY2lhdGlvbi1pZC4NCkluIHRoaXMgY2FzZSwgZGlmZmVyZW50IHZh bHVlcyBmb3IgZXh0ZW5kZWQgYXNzb2NpYXRpb24gSUQgcHJvdmlkZSB1bmlxdWUNCmV4dGVuZGVk IGFzc29jaWF0aW9uIG9iamVjdC48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZxdW90OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Q2FuIHlv dSBjbGFyaWZ5IHdoYXQgaXMgdGhlIGJlbmVmaXRzDQpvZiB1c2luZyB0aGUgc2FtZSBhc3NvY2lh dGlvbi1pZCAoZGlmZmVyZW50IGFzc29jaWF0aW9uLWlkIHdvcmtzIHdlbGwgYWxzbyksDQpzbyB0 aGF0IHdlIGNhbiBwZXJzdWFkZSB0aGUgV0cgdGhhdCB0aGlzIHN0cmljdCBpbXBsZW1lbnRhdGlv biBpcyBhIGJldHRlcg0KY2hvaWNlIGFuZCBhZGQgdGhlIHVzZWNhc2UgaWYgbmVjZXNzYXJ5Ljwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+T3IgYW55IG90 aGVyIHVzZWNhc2VzPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+UGxlYXNlIGRvIG5vdCBoZXNpdGF0ZSB0byBsZXQgbWUga25vdw0KaWYgSSBoYXZlIGEg bWlzdGFrZTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ QmVzdCByZWdhcmRzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5GZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+JnF1b3Q7UmFrZXNoIEdhbmRoaSAocmdhbmRoaSkmcXVvdDsNCiZsdDtyZ2FuZGhpQGNp c2NvLmNvbSZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4yMDEyLTA4LTAzIDIwOjExPC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O3poYW5nLmZlaTNAenRlLmNvbS5jbiZxdW90OyAmbHQ7 emhhbmcuZmVpM0B6dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Q0NBTVAgJmx0O2Nj YW1wQGlldGYub3JnJmd0OywgJnF1b3Q7RXJpYw0KT3Nib3JuZSAoZW9zYm9ybmUpJnF1b3Q7ICZs dDtlb3Nib3JuZUBjaXNjby5jb20mZ3Q7LCAmcXVvdDtqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY24m cXVvdDsNCiZsdDtqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY24mZ3Q7LCAmcXVvdDtqaW5ncnFAY3Ri cmkuY29tLmNuJnF1b3Q7ICZsdDtqaW5ncnFAY3RicmkuY29tLmNuJmd0OywNCiZxdW90O1JvYmVy dCBTYXdheWEgKHJzYXdheWEpJnF1b3Q7ICZsdDtyc2F3YXlhQGNpc2NvLmNvbSZndDssICZxdW90 O0dlb3JnZQ0KU3dhbGxvdyAoc3dhbGxvdykmcXVvdDsgJmx0O3N3YWxsb3dAY2lzY28uY29tJmd0 OywgJnF1b3Q7eWFuZy5mYW41QHp0ZS5jb20uY24mcXVvdDsNCiZsdDt5YW5nLmZhbjVAenRlLmNv bS5jbiZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJFOiBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWNj YW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wMzwvZm9udD48L3RhYmxlPg0K PGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48 L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPlRoYW5rcyBGZWkuIFdlIGFyZSBhbG1vc3QNCnRoZXJlLiBQbGVhc2Ugc2VlIGlu bGluZS4uJmx0O1JHNCZndDsuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdk IGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFo b21hIj48Yj5Gcm9tOjwvYj4gemhhbmcuZmVpM0B6dGUuY29tLmNuIFttYWlsdG86emhhbmcuZmVp M0B6dGUuY29tLmNuXQ0KPGI+PGJyPg0KU2VudDo8L2I+IEZyaWRheSwgQXVndXN0IDAzLCAyMDEy IDU6MTYgQU08Yj48YnI+DQpUbzo8L2I+IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpPGI+PGJyPg0K Q2M6PC9iPiBDQ0FNUDsgRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7IGppYW5nLndlaWxpYW5AenRl LmNvbS5jbjsgamluZ3JxQGN0YnJpLmNvbS5jbjsNClJvYmVydCBTYXdheWEgKHJzYXdheWEpOyBH ZW9yZ2UgU3dhbGxvdyAoc3dhbGxvdyk7IHlhbmcuZmFuNUB6dGUuY29tLmNuPGI+PGJyPg0KU3Vi amVjdDo8L2I+IFJFOiBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRl LWV4dC1hc3NvY2lhdGVkLWxzcC0wMzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KSGkgUmFrZXNoPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0K PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KU25pcHBlZCB0aGUgb3RoZXIg cGFydHMgZm9yIGVhc3kgcmVhZGluZywgc29ycnkgZm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlDQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCiZsdDtSRzMm Z3Q7IFRoZXJlIGFyZSBhcHBsaWNhdGlvbnMgdGhhdCByZXF1aXJlIGNvLXJvdXRlZCBMU1BzLiBT byBJIHRoaW5rDQp3ZSBzaG91bGQgaGF2ZSBhIGZsYWcgdG8gaW5kaWNhdGUgdGhhdCBMU1BzIG11 c3QgYmUgY28tcm91dGVkLCBlbHNlIG5vZGUNCndpbGwgc2VuZCBhIHBhdGggZXJyb3IgZm9yIGV4 YW1wbGUgaWYgcmVxdWVzdCBjYW5ub3QgYmUgbWV0LiAmbmJzcDtJIGFncmVlDQp3aXRoIHlvdSBh Ym91dCBjb21wbGV4aXR5IHdpdGggZG91YmxlIHNpZGVkIHByb3Zpc2lvbmluZyBtb2RlbCB0aG91 Z2guDQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiZsdDtmZWkmZ3Q7IFNpbmNlIHlvdSBiZWxp ZXZlIHRoYXQgYSBjb21tb24gbWVjaGFuaXNtIHVzZWQgZm9yIHRoZSBub24tY29yb3V0ZWQNCmFu ZCBjb3JvdXRlZCBjYXNlcyBpcyB1c2VmdWwsIHdlIHdpbGwgYWRkIHRoZSB0ZXh0cyBpbiB0aGUg bmV4dCB2ZXJzaW9uLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jmx0O1JH NCZndDsgVGhpcyBpcyBncmVhdC4NClRoYW5rcy4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2Qg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KJmx0O1JHMyZndDsgT2ssIHdlIHByb2JhYmx5IHNob3Vs ZCBhZGQgdXNlIGNhc2VzIGZvciB2YXJpb3VzIG1ldGhvZHMuIEkNCmNhbiBzZWUgbWV0aG9kIDEg YmVpbmcgdXNlZCBmb3Igc2V0dGluZyB1cCBiaWRpcmVjdGlvbmFsIExTUHMgYnV0IEkgYW0NCm5v dCBzdXJlIGFib3V0IG1ldGhvZCAyIGZvciBleGFtcGxlLiBPbmUgd29ycnkgaXMgdGhhdCBkaWZm ZXJlbnQgbWV0aG9kcw0KY2FuIGxlYWQgdG8gaW50ZXJvcCBpc3N1ZXMgaWYgb25lIHZlbmRvciBp bXBsZW1lbnRzIG1ldGhvZCAxIGFuZCBzZWNvbmQNCnZlbmRvciBtZXRob2QgMi48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMx ZjQ5N2QgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQXNzb2NpYXRpb24gb2JqZWN0IGlzIGJlaW5n IHVzZWQgZm9yIGRpZmZlcmVudCBhc3NvY2lhdGlvbiB0eXBlcyAoUkZDIDQ4NzI6DQp0eXBlIDE6 IFJlY292ZXJ5KSwgKFJGQyA0ODczLSB0eXBlIDI6IFJlc291cmNlIHNoYXJpbmcpLCBldGMuIGFu ZCB0aGVzZQ0KUkZDcyBkZWZpbmUgc3BlY2lmaWMgcHJvY2VkdXJlcyBmb3IgdGhlIGdpdmVuIGFz c29jaWF0aW9uIHR5cGUuIFNvIElNSE8sDQppdCBtYXkgYmUgb2sgdG8gZGVmaW5lIGEgc3RyaWN0 ZXIgcHJvY2VkdXJlIGZvciBwb3B1bGF0aW5nIGV4dCBhc3NvY2lhdGlvbg0Kb2JqZWN0IGZvciB0 aGUgbmV3IEJpZGlyZWN0aW9uYWwgTFNQcyBhc3NvY2lhdGlvbiB0eXBlLjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj48YnI+DQombHQ7ZmVpJmd0OyBNZXRob2QgMiB3b3JrcyB3ZWxsLCBhbmQgdGhlIG9u bHkgZGlmZmVyZW5jZSBpcyB0IGhvdyB0byByZXByZXNlbnQNCnRoZSBnbG9iYWwgdW5pcXVlIGlk ZW50aWZpZXIuIEZvciB0aGUgYXNzb2NpYXRpb24gaXMgYmFzZWQgb24gdGhlIGZ1bGwNCm1hdGNo IG9mIHRoZSBFQSBvYmplY3RzLCB0aGUgRUEgb2JqZWN0IGlzIGp1c3QgY29waWVkIGZyb20gdGhl IHBhdGggbWVzc2FnZQ0KaW50byBhbm90aGVyIHBhdGggbWVzc2FnZSBpbiBzaW5nbGUgc2lkZWQg cHJvdmlzaW9uaW5nIG1vZGVsLiBBcyB0byB0aGUNCmRvdWJsZWQgc2lkZWQgcHJvdmlzaW9uaW5n IG1vZGVsLCB0aGUgRUEgb2JqZWN0cyBpcyBhbHNvIHRoZSBzYW1lLiBJTUhPLA0KdGhlcmUgaXMg bm8gaW50ZXJvcCBpc3N1ZXMsIG9yIGRvIEkgaGF2ZSBzb21lIG1pc3VuZGVyc3RhbmRpbmc/IDwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KWWVhaCwgd2UgY2FuIGRlZmluZSBhIHN0cmljdGVyIHBy b2RlZHVyZSwgSSBhbSBub3Qgc3VyZSB0aGlzIGlzIGEgZ29vZA0Kd2F5IGluIHN0YW5kYXJkLCBu ZWVkIG1vcmUgZmVlZGJhY2sgZnJvbSB0aGUgV0cuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJDYWxpYnJpIj4mbHQ7Ukc0Jmd0OyBJIGFncmVlIHRoYXQNCmlmIGJvdGggdmVuZG9ycyBpbXBs ZW1lbnQgc2F5IG1ldGhvZCAxIG9yIGJvdGggdmVuZG9ycyBpbXBsZW1lbnQgc2F5IG1ldGhvZA0K MiB0aGVuIHRoZXkgd291bGQgaW50ZXJvcGVyYXRlLCBhbmQgJm5ic3A7ZXh0IEVBIG9iamVjdHMg YXJlIHRoZSBzYW1lLg0KQnV0IG1ldGhvZCAxIGFuZCBtZXRob2QgMiBtYXkgbm90IGludGVyb3Bl cmF0ZSB0b2dldGhlci4gJm5ic3A7Tm90IHN1cmUNCmlmIHdlIHdhbnQgdG8gaGF2ZSBhIHNlcGFy YXRlIGZsYWcgdG8gaW5kaWNhdGUgaWYgZXh0IGFzc29jaWF0aW9uIG9iamVjdA0KaXMgcG9wdWxh dGVkIHdpdGggbWV0aG9kIDEgb3IgMiB0byBjb3ZlciB0aGlzIGNhc2U/ICZuYnNwOyBJdCBpcyBm aW5lIHRvDQpoYXZlIG1vcmUgdGhhbiBvbmUgbWV0aG9kIGluIHRoZSBkcmFmdCBmb3IgZmxleGli aWxpdHkgYW5kIGZ1dHVyZSB1c2UgYnV0DQpnb29kIHRvIGVsYWJvcmF0ZSBvbiB0aGUgcG9zc2li bGUgdXNlIGNhc2UgaWYgd2Uga25vdyBvZiBhbnkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBj b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+UmFrZXNoPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj48YnI+DQpDaGVlcjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkZlaTwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD4NCjxwPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0xNSU+PGZvbnQgc2l6ZT0x IGZhY2U9IkFyaWFsIj48Yj4mcXVvdDtSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSZxdW90Ow0KJmx0 OzwvYj48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cmdhbmRoaUBjaXNjby5jb20+PGZvbnQgc2l6ZT0x IGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxiPjx1PnJnYW5kaGlAY2lzY28uY29tPC91PjwvYj48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+PGI+Jmd0OzwvYj4NCjwvZm9udD4N CjxwPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+MjAxMi0wOC0wMSAwMToyNDwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9ODQlPg0KPGJy Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yJT4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9u dD48L2Rpdj4NCjx0ZCB3aWR0aD05NyU+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mcXVvdDs8 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPjxmb250IHNpemU9MSBj b2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT56aGFuZy5mZWkzQHp0ZS5jb20uY248L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90Ow0KJmx0OzwvZm9udD48YSBocmVm PW1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFj ZT0iQXJpYWwiPjx1PnpoYW5nLmZlaTNAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9MSBmYWNlPSJBcmlhbCI+Jmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9IkFyaWFsIj4mcXVvdDtFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSZxdW90OyAm bHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmVvc2Jvcm5lQGNpc2NvLmNvbT48Zm9udCBzaXplPTEg Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+ZW9zYm9ybmVAY2lzY28uY29tPC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mZ3Q7LA0KJnF1b3Q7PC9mb250PjxhIGhyZWY9 bWFpbHRvOmppYW5nLndlaWxpYW5AenRlLmNvbS5jbj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBm YWNlPSJBcmlhbCI+PHU+amlhbmcud2VpbGlhbkB6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mcXVvdDsNCiZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86 amlhbmcud2VpbGlhbkB6dGUuY29tLmNuPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFy aWFsIj48dT5qaWFuZy53ZWlsaWFuQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTEgZmFjZT0iQXJpYWwiPiZndDssDQomcXVvdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86amluZ3Jx QGN0YnJpLmNvbS5jbj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+amlu Z3JxQGN0YnJpLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+ JnF1b3Q7DQombHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmppbmdycUBjdGJyaS5jb20uY24+PGZv bnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PmppbmdycUBjdGJyaS5jb20uY248 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZndDssDQomcXVvdDtSb2Jl cnQgU2F3YXlhIChyc2F3YXlhKSZxdW90OyAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnJzYXdh eWFAY2lzY28uY29tPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5yc2F3 YXlhQGNpc2NvLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jmd0 OywNCiZxdW90O0dlb3JnZSBTd2FsbG93IChzd2FsbG93KSZxdW90OyAmbHQ7PC9mb250PjxhIGhy ZWY9bWFpbHRvOnN3YWxsb3dAY2lzY28uY29tPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9 IkFyaWFsIj48dT5zd2FsbG93QGNpc2NvLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBm YWNlPSJBcmlhbCI+Jmd0OywNCiZxdW90OzwvZm9udD48YSBocmVmPW1haWx0bzp5YW5nLmZhbjVA enRlLmNvbS5jbj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+eWFuZy5m YW41QHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZx dW90Ow0KJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzp5YW5nLmZhbjVAenRlLmNvbS5jbj48Zm9u dCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+eWFuZy5mYW41QHp0ZS5jb20uY248 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZndDssDQpDQ0FNUCAmbHQ7 PC9mb250PjxhIGhyZWY9bWFpbHRvOmNjYW1wQGlldGYub3JnPjxmb250IHNpemU9MSBjb2xvcj1i bHVlIGZhY2U9IkFyaWFsIj48dT5jY2FtcEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9MSBmYWNlPSJBcmlhbCI+Jmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9IkFyaWFsIj5SRTogQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1tcGxz LXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDM8L2ZvbnQ+PC90YWJsZT4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPHA+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0ZCB3aWR0 aD01MCU+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQpIaSBGZWksPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PGJyPg0KVGhhbmtzIGZvciB5b3VyIGtpbmQgcmVwbHkuIFBsZWFzZSBzZWUgaW5s aW5lLi4mbHQ7UkczJmd0Oy4uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i Pjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4N CiZsdDtTbmlwcGVkIGVtYWlsIHRvIGZvY3VzIG9uIG9wZW4gaXRlbXMmZ3Q7PC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFm NDk3ZCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+ DQpGcm9tOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnpoYW5nLmZlaTNAenRlLmNv bS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPg0KPC9mb250Pjxh IGhyZWY9bWFpbHRvOlttYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuXT48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PlttYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNu XTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPg0KPGI+PGJyPg0KU2Vu dDo8L2I+IE1vbmRheSwgSnVseSAzMCwgMjAxMiAxMDowNCBQTTxiPjxicj4NClRvOjwvYj4gUmFr ZXNoIEdhbmRoaSAocmdhbmRoaSk8Yj48YnI+DQpDYzo8L2I+IEVyaWMgT3Nib3JuZSAoZW9zYm9y bmUpOyA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86amlhbmcud2VpbGlhbkB6dGUuY29tLmNuPjxmb250 IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+amlhbmcud2VpbGlhbkB6dGUuY29t LmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+Ow0KPC9mb250Pjxh IGhyZWY9bWFpbHRvOmppbmdycUBjdGJyaS5jb20uY24+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT0iVGFob21hIj48dT5qaW5ncnFAY3RicmkuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQg c2l6ZT0yIGZhY2U9IlRhaG9tYSI+Ow0KUm9iZXJ0IFNhd2F5YSAocnNhd2F5YSk7IEdlb3JnZSBT d2FsbG93IChzd2FsbG93KTsgPC9mb250PjxhIGhyZWY9bWFpbHRvOnlhbmcuZmFuNUB6dGUuY29t LmNuPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+eWFuZy5mYW41QHp0 ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj47DQpDQ0FN UDxiPjxicj4NClN1YmplY3Q6PC9iPiBSRTogQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1t cGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA4MDAwIGZhY2U9 IkFyaWFsIj48YnI+DQo8YnI+DQpUaGFuayB5b3UgUmFrZXNoIGZvciBzaGFyaW5nIHlvdXIgaWRl YSwgSSB0aGluayB3ZSBhcmUgcm91Z2hseSBpbiBhZ3JlZW1lbnQNCmFuZCBuZWVkIHRvIGhlYXIg bW9yZSB2b2ljZXMgZnJvbSB0aGUgV0cuIDopPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzAwODAwMCBmYWNlPSJB cmlhbCI+PGJyPg0KU2VlIGlubGluZSAmbHQ7ZmVpJmd0OyZsdDsvZmVpJmd0Ozxicj4NCjxicj4N CkJlc3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGNvbG9yPSMwMDgwMDAgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCkZlaTwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQXJpYWwiPjxicj4NCjIpIERlZmluZSBvbmUgZmxhZyBmb3IgY28tcm91dGVkIG9yIG5v bi1jb3JvdXRlZC4gSWYgdGhlIGNvLXJvdXRlZCBiaWRpcg0KaXMgdGhlIGRlZmF1bHQgYmVoYXZp b3IsIHdoeSBub3QgdXNpbmcgdGhlIHByb2NlZHVyZSBkZWZpbmVkIGluIFJGQzM0NzM/DQpJIGFt IGFmcmFpZCBpdCBpcyBoYXJkPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+IDwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCnRvIHBlcnN1YWRlIHRoZSBXRyB0byBk byBzby4gTWF5YmUgdGhlIGJldHRlciB3YXkgaXMgdGhhdCBub24tY29yb3V0ZWQNCmJpZGlyIGlz IHRoZSBkZWZhdWx0LCBhbmQgdGhlIHNldCBvZiB0aGUgY28tcm91dGVkIGZsYWcgb25seSBtZWFu cyB0aGF0DQppdCBpcyByZWNvbW1lbmRlZCwgbm90IG1hbmRhdG9yeSwgdGhlIGNoZWNraW5nIHdo ZXRoZXIgdGhlIExTUCBpcyBjby1yb3V0ZWQNCmNhbiBiZSBkb25lIGJ5IGNvbXBhcmluZyB0aGUg UlJPIG9iamVjdHMuIFdoYXQgaXMgeW91ciBvcGluaW9uPzwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iQXJpYWwiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jYzA1MDRkIGZhY2U9IkNhbGli cmkiPjxicj4NCiZsdDtSRzEmZ3Q7IEl0IGlzIGZpbmUgdG8gaGF2ZSBub24gY28tcm91dGVkIGFz IGRlZmF1bHQuIFJGQyAzNDczIGlzIGENCkdNUExTIHNpZ25hbGluZyBwcm9jZWR1cmUuIEl0IG1h eSBub3QgYmUgb3B0aW1hbCAmbmJzcDt0byBoYXZlIHR3byBkaWZmZXJlbnQNCnNpZ25hbGluZyBw cm9jZWR1cmVzLCBvbmUgZm9yIG5vbiBjby1yb3V0ZWQgKGV4dCBhc3NvY2lhdGVkIG9iamVjdCkg YW5kDQpvbmUgZm9yIGNvLXJvdXRlZCAoUkZDIDM0NzMpIHByb2NlZHVyZXMuIEJ5IGFkZGluZyBh IGZsYWcgZm9yIGNvLXJvdXRlZCwNCnNhbWUgc2lnbmFsaW5nIChleHQgYXNzb2NpYXRlZCBvYmpl Y3QpIGNhbiBiZSB1c2VkIGZvciBib3RoIHdoaWNoIGlzIG5pY2UuDQpXZSBiZWxpZXZlIGNvbXBh cmluZyBvZiBSUk8gY2FuIGJlIG1pc2xlYWRpbmcgYmVjYXVzZSB0d28gTFNQcyBjYW4gYmUgb24N CnRoZSBzYW1lIHBhdGggZXZlbiB0aG91Z2ggcHJvdmlzaW9uZWQgdG8gYmUgbm9uIGNvLXJvdXRl ZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNp emU9MiBjb2xvcj0jMDA4MDAwIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQombHQ7ZmVpJmd0Ozwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIg Y29sb3I9IzAwODAwMCBmYWNlPSJBcmlhbCI+PGJyPg0KU29ycnkgdGhhdCB3aGF0IEkgc3VnZ2Vz dGVkIG1heWJlIG1pc2xlYWQgeW91LCB0aGUgZm9sbG93aW5nIGRlc2NyaXBpdG9ucw0KYXJlIG1v cmUgYWNjdXJhdGUuIDopPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9m b250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA4MDAwIGZhY2U9IkFyaWFsIj48YnI+DQoxKVRoZSBk ZWZhdWx0IGJlaGF2aW9yIChub24tY29yb3V0ZWQpIG1lYW5zIHRoYXQgaXQgaXMgbm90IHJlcXVp cmVkIHRvDQpiZSBjby1yb3V0ZWQuIEluIG90aGVyIHdvcmRzLCBpdCBpcyBhbHNvIE9LIHRoYXQg dGhlIHR3byBwYXRocyBhcmUgYWxvbmcNCnRoZSBzYW1lIHBhdGg8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDgwMDAgZmFjZT0iQXJp YWwiPjxicj4NCi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQom bHQ7UkczJmd0OyBBZ3JlZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDgwMDAgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4N CjIpVGhlIGZsYWcgc2V0IG1lYW5zIHRoYXQgY28tcm91dGVkIGlzIHJlY29tbWVuZGVkLiBJbiBv dGhlciB3b3JkcywgdGhlDQpyZXZlcnNlIExTUCBTSE9VTEQgYmUgZXN0YWJsaXNoZWQgaW4gdGhl IHNhbWUgcGF0aCBhcyBtdWNoIGFzIHBvc3NpYmxlLg0KSWYgdGhlIGZsYWcgc2V0IG1lYW5zPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBj b2xvcj0jMDA4MDAwIGZhY2U9IkFyaWFsIj48YnI+DQp0aGF0IGNvLXJvdXRlZCBpcyBtYW5kYXRv cnksdGhlIHByb2NlZHVyZXMgd2lsbCBiZSB2ZXJ5IGNvbXBsZXggaW4gZG91YmxlDQpzaWRlZCBw cm92aXNpb25pbmcgbW9kZWwuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4g PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA4MDAwIGZhY2U9IkFyaWFsIj48YnI+DQombHQ7 L2ZlaSZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQombHQ7 UkczJmd0OyBUaGVyZSBhcmUgYXBwbGljYXRpb25zIHRoYXQgcmVxdWlyZSBjby1yb3V0ZWQgTFNQ cy4gU28gSSB0aGluaw0Kd2Ugc2hvdWxkIGhhdmUgYSBmbGFnIHRvIGluZGljYXRlIHRoYXQgTFNQ cyBtdXN0IGJlIGNvLXJvdXRlZCwgZWxzZSBub2RlDQp3aWxsIHNlbmQgYSBwYXRoIGVycm9yIGZv ciBleGFtcGxlIGlmIHJlcXVlc3QgY2Fubm90IGJlIG1ldC4gJm5ic3A7SSBhZ3JlZQ0Kd2l0aCB5 b3UgYWJvdXQgY29tcGxleGl0eSB3aXRoIGRvdWJsZSBzaWRlZCBwcm92aXNpb25pbmcgbW9kZWwg dGhvdWdoLg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KMylBcyB0byB0aGUgdHVwbGUgb2Yg Jmx0O2xvd2VyIGlwIGFkZHJlc3MsIGhpZ2ggaXAgYWRkcmVzcywgYXNzb2NpYXRpb24NCmlkJmd0 OywgeWVhaCwgaXQgaXMgb25lIGtpbmQgb2YgaW1wbGVtZW50YXRpb24sIGJ1dCB0aGVyZSBhcmUg cG90ZW50aWFsDQpzb21lIG90aGVyIHJlYWxpemF0aW9ucywgbGlrZSB1c2luZyBvbmUgb2YgdGhl IHJvdXRlciBpZCBwbHVzIHRoZSB0dW5uZWwNCmlkLiBJIHRoaW5rIHdlIGhhZCBiZXR0ZXIgbm90 IHJlc3RyaWN0IHRoZSBleGVjdXRpb24gdG8gc3VjaCBhIG5hcnJvdyBzY29wZS4NCldoYXQgYWJv dXQgdGhlIEVBIGZvcm1hdCBsaXN0ZWQgYmVsb3c/PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJB cmlhbCI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgMCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgMSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgMiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KMzxicj4NCiAmbmJzcDsgJm5ic3A7MCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4DQo5IDAgMTxicj4NCiAm bmJzcDsgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSs8YnI+DQogJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtMZW5ndGggJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHwgQ2xhc3MtTnVtKDE5OSl8ICZuYnNwO0MtVHlwZSAoVEJBKSB8PGJyPg0KICZuYnNw OyArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKzxicj4NCiAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBc3NvY2lhdGlv biBUeXBlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IEFzc29jaWF0aW9uIElEICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0K ICZuYnNwOyArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKzxicj4NCiAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7SVB2NCBBc3NvY2lh dGlvbiBTb3VyY2UgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQogJm5ic3A7ICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPGJyPg0KICZu YnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQpHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8PGJyPg0KICZu YnNwOyArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKzxicj4NCiAmbmJzcDsgfEV4dGVuZGVkIEFzc29jaWF0aW9uIEZsYWdzLiAm bmJzcDsgJm5ic3A7fEV4dGVuZGVkIEFzc29jaWF0aW9uDQpJRCAuLi4gJm5ic3A7ICZuYnNwO3wg PGJyPg0KICZuYnNwOyAmbmJzcDsrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPGJyPg0KICZuYnNwOyAmbmJzcDt8Li4uLihj b250aW51ZSkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA6PGJyPg0KICZuYnNwOyArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9 I2MwNTA0ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8YnI+DQombHQ7UkcmZ3Q7IERvIHlvdSBtZWFu IHRvIGhhdmUgZXh0ZW5kZWQgYXNzb2NpYXRpb24gSUQgYXMgdHVubmVsIElEICgxNg0KYml0cykg KyBJUCBhZGRyZXNzICgzMiBiaXRzKSBpbiB0aGlzIG9iamVjdD88L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jYzA1MDRkIGZh Y2U9IkNhbGlicmkiPjxicj4NClBsZWFzZSBzZWUgaW5saW5lIGJlbG93Li4mbHQ7UkcxJmd0Oy4u PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9IzAwODAwMCBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KJmx0O2ZlaSZndDs8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNv bG9yPSMwMDgwMDAgZmFjZT0iQXJpYWwiPjxicj4NCk5vLiBJIHdhbnQgdG8gc2F5IHRoYXQgdGhp cyBmb3JtYXQgb2YgRUEgb2JqZWN0cyBjYW4gYWNjb21vZGF0ZSBtb3JlIGtpbmRzDQpvZiBpbXBs ZW1lbnRhdGlvbnMuIExpa2U8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDgwMDAgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4N CjEpQXNzb2NpYXRpb24gSUQ6IHVzZXIgcHJvdmlzaW9uZWQgaWRlbnRpYWwgdmFsdWU7IEFzc29j aWF0aW9uIFNvdXJjZToNCnRoZSBsb3dlIGlwIGFkZHJlc3M7IEVBIElEOiB0aGUgaGlnaGVyIElQ IGFkZHJlc3MuIEFzIHlvdSBzdWdnZXN0ZWQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA4MDAwIGZhY2U9IkFyaWFsIj48 YnI+DQo8YnI+DQoyKUFzc29jaWF0aW9uIElEOiB0dW5uZWwgSUQgb3IgdXNlciBwcm92aXNpb25l ZCB2YWx1ZTsgQXNzb2NpYXRpb24gU291cmNlOlR1bm5lbA0Kc2VuZGVyIGFkZHJlc3Mgb3IgdXNl ciBwcm92aXNpb25lZDsgRUEgSUQ6IGJlIGVtcHR5IG9yIExTUCBJRCBvciBhbnkgb3RoZXINCmlu Zm9ybWF0aW9uLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48 Zm9udCBzaXplPTIgY29sb3I9IzAwODAwMCBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KMylUaGUg cG90ZW50aWFsIG90aGVyIGltcGxlbWVudGF0aW9ucy4uLjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDgwMDAgZmFjZT0i QXJpYWwiPjxicj4NCjxicj4NCklNSE8sIHRoZSBFQSBJRCBjYW4gYmUgSVAgYWRkcmVzcyBvciBh bnkgb3RoZXIgdmFsdWVzIGluIHRoZSBjb250ZXh0IG9mDQpBc3NvY2lhdGlvbiBTb3VyY2UgcGx1 cyBBc3NvY2lhdGlvbiBJRCwgd2hpY2ggaXMgYmFja3dhcmQgY29tcGF0aWJsZS48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBj b2xvcj0jMWY0OTdkIGZhY2U9IkFyaWFsIj48YnI+DQombHQ7PC9mb250Pjxmb250IHNpemU9MiBj b2xvcj0jMDA4MDAwIGZhY2U9IkFyaWFsIj4vZmVpJmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KJmx0O1JHMyZndDsgT2ssIHdlIHByb2JhYmx5IHNob3VsZCBhZGQg dXNlIGNhc2VzIGZvciB2YXJpb3VzIG1ldGhvZHMuIEkNCmNhbiBzZWUgbWV0aG9kIDEgYmVpbmcg dXNlZCBmb3Igc2V0dGluZyB1cCBiaWRpcmVjdGlvbmFsIExTUHMgYnV0IEkgYW0NCm5vdCBzdXJl IGFib3V0IG1ldGhvZCAyIGZvciBleGFtcGxlLiBPbmUgd29ycnkgaXMgdGhhdCBkaWZmZXJlbnQg bWV0aG9kcw0KY2FuIGxlYWQgdG8gaW50ZXJvcCBpc3N1ZXMgaWYgb25lIHZlbmRvciBpbXBsZW1l bnRzIG1ldGhvZCAxIGFuZCBzZWNvbmQNCnZlbmRvciBtZXRob2QgMi48L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2Qg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQXNzb2NpYXRpb24gb2JqZWN0IGlzIGJlaW5nIHVzZWQg Zm9yIGRpZmZlcmVudCBhc3NvY2lhdGlvbiB0eXBlcyAoUkZDIDQ4NzI6DQp0eXBlIDE6IFJlY292 ZXJ5KSwgKFJGQyA0ODczLSB0eXBlIDI6IFJlc291cmNlIHNoYXJpbmcpLCBldGMuIGFuZCB0aGVz ZQ0KUkZDcyBkZWZpbmUgc3BlY2lmaWMgcHJvY2VkdXJlcyBmb3IgdGhlIGdpdmVuIGFzc29jaWF0 aW9uIHR5cGUuIFNvIElNSE8sDQppdCBtYXkgYmUgb2sgdG8gZGVmaW5lIGEgc3RyaWN0ZXIgcHJv Y2VkdXJlIGZvciBwb3B1bGF0aW5nIGV4dCBhc3NvY2lhdGlvbg0Kb2JqZWN0IGZvciB0aGUgbmV3 IEJpZGlyZWN0aW9uYWwgTFNQcyBhc3NvY2lhdGlvbiB0eXBlLjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NClRoYW5rcyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K UmFrZXNoPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwv Zm9udD4NCjxwPg0K --=_alternative 002A32AE48257A54_=-- From zhang.fei3@zte.com.cn Wed Aug 8 01:33:53 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E9F11E80D5 for ; Wed, 8 Aug 2012 01:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.949 X-Spam-Level: X-Spam-Status: No, score=-95.949 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VucDMZcsueQx for ; Wed, 8 Aug 2012 01:33:52 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id D995911E808E for ; Wed, 8 Aug 2012 01:33:51 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723473195744; Wed, 8 Aug 2012 16:21:33 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 56952.4555706507; Wed, 8 Aug 2012 16:33:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q788XXrg078228; Wed, 8 Aug 2012 16:33:33 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <501C442C.2000103@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: DACD0E47:4AAF0AAD-48257A54:002341DA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Wed, 8 Aug 2012 16:33:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-08 16:33:31, Serialize complete at 2012-08-08 16:33:31 Content-Type: multipart/alternative; boundary="=_alternative 002EFA0148257A54_=" X-MAIL: mse02.zte.com.cn q788XXrg078228 Cc: venkat.mahalingams@gmail.com, ccamp@ietf.org Subject: Re: [CCAMP] Request for comments: the next step about the draft draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 08:33:53 -0000 This is a multipart message in MIME format. --=_alternative 002EFA0148257A54_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TG91IA0KDQpTb3JyeSBmb3IgdGhlIG1pc3VuZGVyc3RhbmRpbmcsIHRoZSBwcm9wb3NhbCBpcyBs aXN0ZWQgYmVsb3cuIA0KDQp3ZSBkZWZpbmUgdGhlIG5ldyBBc3NvY2lhdGlvbiBUeXBlICJMU1Ag aWRlbnRpZmllcnMiIGFuZCBpdCdzIHNlbWFudGljcyBpbiANCnRoZSBkcmFmdCBkcmFmdC16aGFu Zy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS0wMy4gRnVydGhlcm1vcmUsIA0K dGhpcyBkcmFmdCB3aWxsIG9ubHkgZm9jdXMgb24gdGhlIGNvcm91dGVkIGJpZGlyZWN0aW9uYWwg TFNQLCBhbmQgdGhpcyANCnR5cGUgb2YgdGhlIEFzc29jaWF0aW9uIG9iamVjdCBjYW4gYmUgY2Fy cmllZCBpbiB0aGUgUmVzdiBtZXNzYWdlIHRvIGxldCANCkExIG5vZGUga25vdyB0aGUgR2xvYmFs IElEIGFuZCB0dW5uZWwgbnVtYmVyIG9mIFo5IG5vZGUuDQoNCkFzIHRvIHRoZSBhc3NvY2lhdGVk IGJpZHJlY3Rpb25hbCBMU1AsIFo5IGFuZCBBMSBub2RlIG5lZWRzIHRvIGVhY2ggDQpvdGhlcidz IGdsb2JhbCBJRCBpbiBjZXJ0YWluIHNjZW5hcmlvcyAoQ1YgY29uZmlndXJhdGlvbiBpZiB0aGUg TFNQIGFjcm9zcyANCmRpZmZlcmVudCBkb21haW5zKS4gd2Ugd2lsbCBhZGQgb25lIHNlY3Rpb24g aW4gdGhlIGRyYWZ0IA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2Ft cC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDMgDQp0byBkZXNjcmliZSB0aGUg c2NlbmFyaW9zIGFuZCBjaXRlIHRoZSBleHRlbnNpb24gZGVmaW5lZCBpbiB0aGUgZHJhZnQgDQpk cmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS0wMy4gSW4gb3Ro ZXIgd29yZHMsIGlmIENWIA0KY29uZmlndXJhdGlvbiBpcyByZXF1aXJlZCBhbmQgdGhlIExTUCBp cyBhY3Jvc3MgZGlmZmVyZW50IGRvbWFpbnMsIHR3byANCkFzc29jaWF0aW9uIG9iamVjdCB3aWxs IGJlIGNhcnJpZWQgYXQgbGVhc3QsIG9uZSBpcyB0aGUgQXNzb2NpYXRpb24gVHlwZSANCiJhc3Nv Y2lhdGllZCBiaWRpcmVjdGlvbmFsIGxzcCIgdG8gcmVwcmVzZW50IHRoZSBhc3NvY2lhdGlvbiBh bmQgdGhlIG90aGVyIA0KaXMgdGhlIEFzc29jaWF0aW9uIFR5cGUgIkxTUCBpZGVudGlmaWVycyIg dXNlZCBmb3IgQ1YgY29uZmlndXJhdGlvbi4NCg0KSW4gdGhpcyB3YXksIHRoZSBzdWJqZWN0cyBv ZiB0aGVzZSB0d28gZHJhZnRzIGFyZSB1bmFtYmlndW91cywgb25lIGlzIA0KY29yb3V0ZWQgYW5k IHRoZSBvdGhlciBpcyBhc3NvY2lhdGVkLiBJTUhPLCB0aGUgdmVuZG9yIHdpbGwgaW1wbGVtZW50 IA0KY29yb3V0ZWQgb3IgYXNzb2NpYXRlZCBiaWRyZWN0aW9uYWwgTFNQcywgYnV0IG1heSBub3Qg aW1wbGVtZW50IGJvdGggb2YgDQp0aGVtLiBDb25zaWRlciB0aGUgcmVhc29uIGxpc3RlZCBhYm92 ZSwgSSB3b3VsZCBsaWtlIHRvIGtlZXAgdGhlIHR3byANCmRyYWZ0cyByZWxhdGl2ZWx5IGluZGVw ZW5kZW50IGFuZCByZWx1bmN0YW50IHRvIHB1dCBhbGwgdGhlc2UgY29udGVudCBpbnRvIA0Kb25l IGRyYWZ0IA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1tcGxz LXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDMuDQoNCkFueSBjb21tZW50cyBhcmUgd2Vs Y29tZQ0KDQpUaGFua3MNCg0KRmVpDQoNCg0KDQpMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0 PiANCjIwMTItMDgtMDQgMDU6MzUNCg0KytW8/sjLDQp6aGFuZy5mZWkzQHp0ZS5jb20uY24NCrOt y80NCmNjYW1wQGlldGYub3JnLCB2ZW5rYXQubWFoYWxpbmdhbXNAZ21haWwuY29tLCB4dXl1bmJp bkBtYWlsLnJpdHQuY29tLmNuLCANCmJhby54aWFvMUB6dGUuY29tLmNuDQrW98ziDQpSZTogUmVx dWVzdCBmb3IgY29tbWVudHM6IHRoZSBuZXh0IHN0ZXAgYWJvdXQgdGhlIGRyYWZ0IA0KZHJhZnQt emhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDMNCg0KDQoNCg0KDQoN Cg0KRmVpLA0KICAgICAgICAgICAgICAgICBNeSByZXF1ZXN0IHdhcyBhIGJpdCBtb3JlIHNwZWNp ZmljLiAgVGhlIHJlcXVlc3Qgd2FzL2lzIA0KZm9yIHRoZSBhdXRob3JzDQp0byBwcm9wb3NlLCBv biB0aGUgbGlzdCwgdGV4dCB0aGF0IHdvdWxkIG1lcmdlIHN1cHBvcnQgZm9yIHRoZSBmdW5jdGlv bg0KZGlzY3Vzc2VkIGluIHRoZSBkcmFmdCAoYW5kIGFncmVlZCB0byBvbiB0aGUgbGlzdCkgaW50 bw0KZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AuICBU aGUgV0cgY291bGQgdGhlbg0KcmVhY3QgdG8gdGhpcyBwcm9wb3NhbCBhbmQgYWdyZWUvZGlzYWdy ZWUgdG8gdGhlIHByb3Bvc2VkIG1lcmdlLg0KDQpMb3UNCg0KT24gOC8zLzIwMTIgNDozNyBBTSwg emhhbmcuZmVpM0B6dGUuY29tLmNuIHdyb3RlOg0KPg0KPiBIaSBMb3UNCj4gDQo+IFRoYW5rcyB5 b3UgZm9yIHlvdXIgc3VnZ2VzdGlvbiBpbiB0aGUgbWVyZ2luZyB0aGUgc29sdXRpb24gaW50byB0 aGUNCj4gZXhpc3RpbmcgV0cgZG9jdW1lbnRzIHRvIHB1c2ggdGhpcyB3b3JrIGZvcndhcmQuIDop DQo+IA0KPiBJTUhPLCB0aGVyZSBhcmUgdGhyZWUgcG90ZW50aWFsIFdHIGRvY3VtZW50cywgbGlr ZQ0KPiANCj4gKDEpIGRyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0LTAzLnR4dA0KPiA8aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDMudHh0Pg0K PiANCj4gVGhpcyBkcmFmdCBpcyBub3cgaW4gSUVTRyBwcm9jZXNzaW5nLCB3aGljaCBkZWZpbmVz IHRoZSBleHRlbnNpb25zIG9mDQo+IHRoZSBBc3NvY2lhdGlvbiBvYmplY3QsIGFuZCBpcyBpcnJl bGV2YW50IHdpdGggdGhlIHNwZWNpZmljIGFzc29jaWF0aW9uDQo+IHR5cGVzLg0KPiANCj4gKDIp IGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1tcGxzLXRwLW9hbS1leHQtMDgNCj4gPGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1tcGxzLXRwLW9hbS1l eHQtMDg+DQo+IA0KPiBUaGUgcHJvcG9zZWQgdGV4dCBjYW4gYmUgYWRkZWQgaW4gc2VjdGlvbiAz LjIsIGEgbmV3IFRMViBvciB0aGUNCj4gQXNzb2NpYXRpb24gb2JqZWN0IHdpdGggdGhlIGRlZmlu ZWQgbmV3IGFzc29jaWF0aW9uIHR5cGUsIHdoaWNoIGNhcnJpbmcNCj4gYmFjayB0aGUgWjlfdHVu bmVsX251bSBpbiB0aGUgUmVzdiBtZXNzYWdlLCBuZWVkcyB0byBiZSBkZWZpbmVkIHRoZXJlLg0K PiBUaGlzIGRyYWZ0IGlzIFdHIGxhc3QgY2FsbCwgYW5kIEkgaGF2ZSBzZW50IG91dCB0aGUgY29y cmVzcG9uZGluZw0KPiBjb21tZW50cywgaG9wZSB0byBoZWFyIHRoZSBhdXRob3JzJyBvcGluaW9u Lg0KPiANCj4gKDMpIGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0 ZWQtbHNwDQo+IDwNCmh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9jY2FtcC9kcmFmdC1pZXRmLWNj YW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC8NCj4NCj4gDQo+IA0KPiBJZiB0 aGUgcHJvcG9zZWQgdGV4dHMgYXJlIGFkZGVkIGluIHRoaXMgZHJhZnQsIHRoZSBzdWJqZWN0IG5l ZWRzIHRvIGJlDQo+IGVubGFyZ2VkIHRvIGNvdmVyIGJvdGggdGhlIGFzc29jaWF0ZWQgYW5kIGNv cm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcy4NCj4gDQo+IE1heWJlIHRoZSBmaXJzdCBzdGVwIGlz IHRvIGRldGVybWluZSB3aGljaCBkcmFmdCBpcyB0aGUgYmV0dGVyIGNob2ljZQ0KPiBmb3IgbWVy Z2luZywgdGhlbiB3ZSB3aWxsIHN1Ym1pdCB0aGUgcHJvcG9zZWQgdGV4dHMuDQo+IA0KPiBBbnkg V0cncyBmZWVkYmFja3MgYXJlIHdlbGNvbWUNCj4gDQo+IEJlc3QgcmVnYXJkcw0KPiANCj4gRmVp DQoNCg0KDQo= --=_alternative 002EFA0148257A54_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxvdSA8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNvcnJ5IGZvciB0aGUgbWlzdW5kZXJz dGFuZGluZywgdGhlDQpwcm9wb3NhbCBpcyBsaXN0ZWQgYmVsb3cuIDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+d2UgZGVmaW5lIHRoZSBuZXcgQXNzb2Np YXRpb24gVHlwZSAmcXVvdDtMU1ANCmlkZW50aWZpZXJzJnF1b3Q7IGFuZCBpdCdzIHNlbWFudGlj cyBpbiB0aGUgZHJhZnQgZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5l bC1udW0tMDMuDQpGdXJ0aGVybW9yZSwgdGhpcyBkcmFmdCB3aWxsIG9ubHkgZm9jdXMgb24gdGhl IGNvcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLA0KYW5kIHRoaXMgdHlwZSBvZiB0aGUgQXNzb2Np YXRpb24gb2JqZWN0IGNhbiBiZSBjYXJyaWVkIGluIHRoZSBSZXN2IG1lc3NhZ2UNCnRvIGxldCBB MSBub2RlIGtub3cgdGhlIEdsb2JhbCBJRCBhbmQgdHVubmVsIG51bWJlciBvZiBaOSBub2RlLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgdG8gdGhl IGFzc29jaWF0ZWQgYmlkcmVjdGlvbmFsIExTUCwNClo5IGFuZCBBMSBub2RlIG5lZWRzIHRvIGVh Y2ggb3RoZXIncyBnbG9iYWwgSUQgaW4gY2VydGFpbiBzY2VuYXJpb3MgKENWDQpjb25maWd1cmF0 aW9uIGlmIHRoZSBMU1AgYWNyb3NzIGRpZmZlcmVudCBkb21haW5zKS4gd2Ugd2lsbCBhZGQgb25l IHNlY3Rpb24NCmluIHRoZSBkcmFmdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wMw0KdG8gZGVzY3Jp YmUgdGhlIHNjZW5hcmlvcyBhbmQgY2l0ZSB0aGUgZXh0ZW5zaW9uIGRlZmluZWQgaW4gdGhlIGRy YWZ0IGRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTAzLg0K SW4gb3RoZXIgd29yZHMsIGlmIENWIGNvbmZpZ3VyYXRpb24gaXMgcmVxdWlyZWQgYW5kIHRoZSBM U1AgaXMgYWNyb3NzIGRpZmZlcmVudA0KZG9tYWlucywgdHdvIEFzc29jaWF0aW9uIG9iamVjdCB3 aWxsIGJlIGNhcnJpZWQgYXQgbGVhc3QsIG9uZSBpcyB0aGUgQXNzb2NpYXRpb24NClR5cGUgJnF1 b3Q7YXNzb2NpYXRpZWQgYmlkaXJlY3Rpb25hbCBsc3AmcXVvdDsgdG8gcmVwcmVzZW50IHRoZSBh c3NvY2lhdGlvbg0KYW5kIHRoZSBvdGhlciBpcyB0aGUgQXNzb2NpYXRpb24gVHlwZSAmcXVvdDtM U1AgaWRlbnRpZmllcnMmcXVvdDsgdXNlZA0KZm9yIENWIGNvbmZpZ3VyYXRpb24uPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JbiB0aGlzIHdheSwgdGhl IHN1YmplY3RzIG9mIHRoZXNlIHR3bw0KZHJhZnRzIGFyZSB1bmFtYmlndW91cywgb25lIGlzIGNv cm91dGVkIGFuZCB0aGUgb3RoZXIgaXMgYXNzb2NpYXRlZC4gSU1ITywNCnRoZSB2ZW5kb3Igd2ls bCBpbXBsZW1lbnQgY29yb3V0ZWQgb3IgYXNzb2NpYXRlZCBiaWRyZWN0aW9uYWwgTFNQcywgYnV0 DQptYXkgbm90IGltcGxlbWVudCBib3RoIG9mIHRoZW0uIENvbnNpZGVyIHRoZSByZWFzb24gbGlz dGVkIGFib3ZlLCBJIHdvdWxkDQpsaWtlIHRvIGtlZXAgdGhlIHR3byBkcmFmdHMgcmVsYXRpdmVs eSBpbmRlcGVuZGVudCBhbmQgcmVsdW5jdGFudCB0byBwdXQNCmFsbCB0aGVzZSBjb250ZW50IGlu dG8gb25lIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAt bXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTAzLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3M8L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9udD4N Cjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Mb3UgQmVyZ2Vy ICZsdDtsYmVyZ2VyQGxhYm4ubmV0Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4yMDEyLTA4LTA0IDA1OjM1PC9mb250Pg0KPHRkIHdpZHRoPTYzJT4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnpoYW5nLmZlaTNAenRlLmNvbS5jbjwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+Y2NhbXBAaWV0Zi5vcmcsIHZlbmthdC5tYWhhbGluZ2Ftc0BnbWFp bC5jb20sDQp4dXl1bmJpbkBtYWlsLnJpdHQuY29tLmNuLCBiYW8ueGlhbzFAenRlLmNvbS5jbjwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFJlcXVlc3QgZm9yIGNvbW1lbnRzOiB0aGUgbmV4dCBzdGVw DQphYm91dCB0aGUgZHJhZnQgZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1 bm5lbC1udW0tMDM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPjxicj4NCkZlaSw8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KTXkgcmVxdWVzdCB3YXMgYSBiaXQgbW9yZSBz cGVjaWZpYy4gJm5ic3A7VGhlIHJlcXVlc3Qgd2FzL2lzIGZvciB0aGUgYXV0aG9yczxicj4NCnRv IHByb3Bvc2UsIG9uIHRoZSBsaXN0LCB0ZXh0IHRoYXQgd291bGQgbWVyZ2Ugc3VwcG9ydCBmb3Ig dGhlIGZ1bmN0aW9uPGJyPg0KZGlzY3Vzc2VkIGluIHRoZSBkcmFmdCAoYW5kIGFncmVlZCB0byBv biB0aGUgbGlzdCkgaW50bzxicj4NCmRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0 LWFzc29jaWF0ZWQtbHNwLiAmbmJzcDtUaGUgV0cgY291bGQNCnRoZW48YnI+DQpyZWFjdCB0byB0 aGlzIHByb3Bvc2FsIGFuZCBhZ3JlZS9kaXNhZ3JlZSB0byB0aGUgcHJvcG9zZWQgbWVyZ2UuPGJy Pg0KPGJyPg0KTG91PGJyPg0KPGJyPg0KT24gOC8zLzIwMTIgNDozNyBBTSwgemhhbmcuZmVpM0B6 dGUuY29tLmNuIHdyb3RlOjxicj4NCiZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgSGkgTG91PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyB5b3UgZm9yIHlvdXIg c3VnZ2VzdGlvbiBpbiB0aGUgbWVyZ2luZyB0aGUgc29sdXRpb24gaW50byB0aGU8YnI+DQomZ3Q7 IGV4aXN0aW5nIFdHIGRvY3VtZW50cyB0byBwdXNoIHRoaXMgd29yayBmb3J3YXJkLiA6KTxicj4N CiZndDsgPGJyPg0KJmd0OyBJTUhPLCB0aGVyZSBhcmUgdGhyZWUgcG90ZW50aWFsIFdHIGRvY3Vt ZW50cywgbGlrZTxicj4NCiZndDsgPGJyPg0KJmd0OyAoMSkgZHJhZnQtaWV0Zi1jY2FtcC1hc3Nv Yy1leHQtMDMudHh0PGJyPg0KJmd0OyAmbHQ7aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDMudHh0Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBU aGlzIGRyYWZ0IGlzIG5vdyBpbiBJRVNHIHByb2Nlc3NpbmcsIHdoaWNoIGRlZmluZXMgdGhlIGV4 dGVuc2lvbnMNCm9mPGJyPg0KJmd0OyB0aGUgQXNzb2NpYXRpb24gb2JqZWN0LCBhbmQgaXMgaXJy ZWxldmFudCB3aXRoIHRoZSBzcGVjaWZpYyBhc3NvY2lhdGlvbjxicj4NCiZndDsgdHlwZXMuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICgyKSBkcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtbXBscy10cC1v YW0tZXh0LTA4PGJyPg0KJmd0OyAmbHQ7aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1jY2FtcC1yc3ZwLXRlLW1wbHMtdHAtb2FtLWV4dC0wOCZndDs8YnI+DQomZ3Q7IDxicj4N CiZndDsgVGhlIHByb3Bvc2VkIHRleHQgY2FuIGJlIGFkZGVkIGluIHNlY3Rpb24gMy4yLCBhIG5l dyBUTFYgb3IgdGhlPGJyPg0KJmd0OyBBc3NvY2lhdGlvbiBvYmplY3Qgd2l0aCB0aGUgZGVmaW5l ZCBuZXcgYXNzb2NpYXRpb24gdHlwZSwgd2hpY2ggY2FycmluZzxicj4NCiZndDsgYmFjayB0aGUg WjlfdHVubmVsX251bSBpbiB0aGUgUmVzdiBtZXNzYWdlLCBuZWVkcyB0byBiZSBkZWZpbmVkIHRo ZXJlLjxicj4NCiZndDsgVGhpcyBkcmFmdCBpcyBXRyBsYXN0IGNhbGwsIGFuZCBJIGhhdmUgc2Vu dCBvdXQgdGhlIGNvcnJlc3BvbmRpbmc8YnI+DQomZ3Q7IGNvbW1lbnRzLCBob3BlIHRvIGhlYXIg dGhlIGF1dGhvcnMnIG9waW5pb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICgzKSBkcmFmdC1pZXRm LWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcDxicj4NCiZndDsgJmx0O2h0 dHA6Ly90b29scy5pZXRmLm9yZy93Zy9jY2FtcC9kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2 cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC8mZ3Q7PGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7IDxi cj4NCiZndDsgSWYgdGhlIHByb3Bvc2VkIHRleHRzIGFyZSBhZGRlZCBpbiB0aGlzIGRyYWZ0LCB0 aGUgc3ViamVjdCBuZWVkcyB0bw0KYmU8YnI+DQomZ3Q7IGVubGFyZ2VkIHRvIGNvdmVyIGJvdGgg dGhlIGFzc29jaWF0ZWQgYW5kIGNvcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcy48YnI+DQomZ3Q7 IDxicj4NCiZndDsgTWF5YmUgdGhlIGZpcnN0IHN0ZXAgaXMgdG8gZGV0ZXJtaW5lIHdoaWNoIGRy YWZ0IGlzIHRoZSBiZXR0ZXIgY2hvaWNlPGJyPg0KJmd0OyBmb3IgbWVyZ2luZywgdGhlbiB3ZSB3 aWxsIHN1Ym1pdCB0aGUgcHJvcG9zZWQgdGV4dHMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFueSBX RydzIGZlZWRiYWNrcyBhcmUgd2VsY29tZTxicj4NCiZndDsgPGJyPg0KJmd0OyBCZXN0IHJlZ2Fy ZHM8YnI+DQomZ3Q7IDxicj4NCiZndDsgRmVpPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+ DQo= --=_alternative 002EFA0148257A54_=-- From daniele.ceccarelli@ericsson.com Wed Aug 8 01:34:23 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A201511E80E1 for ; Wed, 8 Aug 2012 01:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.221 X-Spam-Level: X-Spam-Status: No, score=-3.221 tagged_above=-999 required=5 tests=[AWL=3.028, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ODeUpVFmGTA for ; Wed, 8 Aug 2012 01:34:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6F53711E80D5 for ; Wed, 8 Aug 2012 01:34:22 -0700 (PDT) X-AuditID: c1b4fb2d-b7fd66d0000004ad-9e-5022248de880 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E9.CA.01197.D8422205; Wed, 8 Aug 2012 10:34:21 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.63]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 8 Aug 2012 10:34:11 +0200 From: Daniele Ceccarelli To: John E Drake , Lou Berger Date: Wed, 8 Aug 2012 10:34:09 +0200 Thread-Topic: Last Call for OTN Routing and Signaling Drafts Thread-Index: Ac106YTWFkimJqV8Romx8WJ8TrxrywAViQAQ Message-ID: References: <5E893DB832F57341992548CDBB333163A5A9667A34@EMBX01-HQ.jnpr.net> <502190CA.9050305@labn.net> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+JvrW6vilKAwcXz0hZP5txgsdi+cwmL xZy7zhYdzW9ZHFg8XvbPYfRYsuQnk8f1pqvsHh82NbMFsERx2aSk5mSWpRbp2yVwZWyYuoix 4IhQxb2Da1kbGJ/zdTFyckgImEi82riUBcIWk7hwbz1bFyMXh5DAKUaJX6fXMEE48xklzv3f wtrFyMHBJmAl8eSQD0iDiICLxPpnGxhBbGYBP4mfu46zgdgsAioSN69MABsqLGAt8W7GJRaI ehuJSR2NzCBjRASMJK5NEwYJ8wqES+w/cAusREhgHqPElWuRIDangL3Ej1NvmEFsRgFZiQm7 F0GtEpe49WQ+E8TNAhJL9pxnhrBFJV4+/scKUS8j8WvTN1aIej2JG1OnsEHY2hLLFr5mhtgr KHFy5hOWCYxis5CMnYWkZRaSlllIWhYwsqxiFM5NzMxJLzfUSy3KTC4uzs/TK07dxAiMr4Nb fuvuYDx1TuQQozQHi5I4L1fSfn8hgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjGkL/Ho+VK3N M1yxfU2kbQjbcb9ZjRceuG3PCt73JUCYM3ai9g5rifMdmzhFrl71+HLm9xoFb7eSII4TJkfy HDPqlnhPO8wtIPgqOKdU5MVd0U2z+d8tNzJJuWK6K2V5VfKUxS/l1n05lBZ85ctJXi23gECP q8e8qm7X7G2cr62nZshryf7ophJLcUaioRZzUXEiAJ2dn659AgAA Cc: "ccamp@ietf.org" , "dbrungard@att.com" Subject: Re: [CCAMP] Last Call for OTN Routing and Signaling Drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 08:34:23 -0000 John, Lou, Agree on the stability of routing and signaling but maybe the framework and= info model should be last called before them. What about 1 month for the f= irst couple and 2 for the second one? Possibly 1 month is enough for the al= l of them but it could be better to give the WG more time for a carefully L= C review. A new version of the FWK needs to be issued soon addressing your comment on= the backward compatibility issue (MAY vs MUST) Thanks, Daniele >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 >On Behalf Of John E Drake >Sent: mercoled=EC 8 agosto 2012 0.11 >To: Lou Berger >Cc: ccamp@ietf.org; dbrungard@att.com >Subject: Re: [CCAMP] Last Call for OTN Routing and Signaling Drafts > >Lou, > >Yes it is and I'm sorry for my late response. I would check=20 >with Daniele and Fatai but I would hope within a month. We=20 >have been working on these for quite some time and they seem=20 >quite stable. > >Thanks, > >John > >Sent from my iPhone > >On Aug 7, 2012, at 6:03 PM, "Lou Berger" wrote: > >> John, >> I take it that this message is in response to: >>=20 >> On 8/3/2012 5:14 PM, Lou Berger wrote: >>> Subject: [CCAMP] For discussion: Planned milestone update=20 >Dec 2012 -=20 >>> Submit G.709 enhancements framework for IESG > review >>> Dec 2012 - Submit G.709 enhancements solutions for IESG review >>=20 >> What date are you proposing? >>=20 >> I generally feel that the milestone date should be an upper=20 >limit and=20 >> that reaching a milestone early is good, while missing one is not. >>=20 >> Lou >>=20 >> On 8/7/2012 5:56 PM, John E Drake wrote: >>> Lou and Deborah, >>>=20 >>> Given that we expeditiously address the remaining small number of=20 >>> issues in the OTN Routing and Signaling drafts, is there any reason=20 >>> why we need to wait until the next IETF meeting to initiate a Last=20 >>> Call on them? As has been pointed out many times, a WG's work is=20 >>> done on its mailing list and not in its face-to-face meetings. >>>=20 >>> Thanks, >>>=20 >>> John >>>=20 >>> Sent from my iPhone >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp >= From lberger@labn.net Wed Aug 8 05:33:27 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C4B21F861C for ; Wed, 8 Aug 2012 05:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.192 X-Spam-Level: X-Spam-Status: No, score=-98.192 tagged_above=-999 required=5 tests=[AWL=1.969, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCxfmMGRg6Lr for ; Wed, 8 Aug 2012 05:33:26 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 9C6DB21F85F7 for ; Wed, 8 Aug 2012 05:33:26 -0700 (PDT) Received: (qmail 3936 invoked by uid 0); 8 Aug 2012 12:33:25 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 8 Aug 2012 12:33:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=hPRdhmP1EKjmCtak4lv4ex2bsFXn9+94EfM7naYgaJo=; b=04/sA5XKzhNExk3td1fZXvT42+uvIwNBP5T/UGLAq4CsN/DcmsTmTIkuMVh/WWEfL5WERhdQdVjRujfFudhj8PPXW4BYYUbhAlEKiKHErAVRX5YcJtDD2TCwqgXvdKR1; Received: from box313.bluehost.com ([69.89.31.113]:41308 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Sz5S1-0006h9-CC; Wed, 08 Aug 2012 06:33:25 -0600 Message-ID: <50225C94.60407@labn.net> Date: Wed, 08 Aug 2012 08:33:24 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Daniele Ceccarelli References: <5E893DB832F57341992548CDBB333163A5A9667A34@EMBX01-HQ.jnpr.net> <502190CA.9050305@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" , "dbrungard@att.com" Subject: Re: [CCAMP] Last Call for OTN Routing and Signaling Drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 12:33:27 -0000 Daniele, John, It sounds like the December date is a "safe" date, maybe 1 or 2 more months than we need. As chair, I'd prefer to leave the milestone date as December and aim to have the LC sooner (and before the next IETF) if possible. I'll respond to the compatibility comment in a separate message. Lou On 8/8/2012 4:34 AM, Daniele Ceccarelli wrote: > John, Lou, > > Agree on the stability of routing and signaling but maybe the > framework and info model should be last called before them. What > about 1 month for the first couple and 2 for the second one? Possibly > 1 month is enough for the all of them but it could be better to give > the WG more time for a carefully LC review. > > A new version of the FWK needs to be issued soon addressing your > comment on the backward compatibility issue (MAY vs MUST) > > Thanks, > Daniele > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >> On Behalf Of John E Drake >> Sent: mercoledì 8 agosto 2012 0.11 >> To: Lou Berger >> Cc: ccamp@ietf.org; dbrungard@att.com >> Subject: Re: [CCAMP] Last Call for OTN Routing and Signaling Drafts >> >> Lou, >> >> Yes it is and I'm sorry for my late response. I would check >> with Daniele and Fatai but I would hope within a month. We >> have been working on these for quite some time and they seem >> quite stable. >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> On Aug 7, 2012, at 6:03 PM, "Lou Berger" wrote: >> >>> John, >>> I take it that this message is in response to: >>> >>> On 8/3/2012 5:14 PM, Lou Berger wrote: >>>> Subject: [CCAMP] For discussion: Planned milestone update >> Dec 2012 - >>>> Submit G.709 enhancements framework for IESG >> review >>>> Dec 2012 - Submit G.709 enhancements solutions for IESG review >>> >>> What date are you proposing? >>> >>> I generally feel that the milestone date should be an upper >> limit and >>> that reaching a milestone early is good, while missing one is not. >>> >>> Lou >>> >>> On 8/7/2012 5:56 PM, John E Drake wrote: >>>> Lou and Deborah, >>>> >>>> Given that we expeditiously address the remaining small number of >>>> issues in the OTN Routing and Signaling drafts, is there any reason >>>> why we need to wait until the next IETF meeting to initiate a Last >>>> Call on them? As has been pointed out many times, a WG's work is >>>> done on its mailing list and not in its face-to-face meetings. >>>> >>>> Thanks, >>>> >>>> John >>>> >>>> Sent from my iPhone >>>> >>>> >>>> >>>> >>>> >>>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > > > From lberger@labn.net Wed Aug 8 05:59:23 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173E721F8604 for ; Wed, 8 Aug 2012 05:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.245 X-Spam-Level: X-Spam-Status: No, score=-98.245 tagged_above=-999 required=5 tests=[AWL=1.916, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRPXS7bsTwrB for ; Wed, 8 Aug 2012 05:59:22 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id E3C7021F85C7 for ; Wed, 8 Aug 2012 05:59:21 -0700 (PDT) Received: (qmail 8191 invoked by uid 0); 8 Aug 2012 12:59:21 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 8 Aug 2012 12:59:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Cut11gGpCSQv7SeSFv+99L+kwVLqBHUAS9x4Q55Oml0=; b=xVb0HYPDKm/OSm2+ralypcF/jnQL1iiEjzxKp/tSGtkOuJLj3cpuiXr053lDKOiXxkzrNJYaOD4qLsbU3B2bzEHRrvGvaPBuPAt2ByyFEMue5rkveE7uADDJd4vOcCK2; Received: from box313.bluehost.com ([69.89.31.113]:43874 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Sz5r7-0007hI-80; Wed, 08 Aug 2012 06:59:21 -0600 Message-ID: <502262A8.3070007@labn.net> Date: Wed, 08 Aug 2012 08:59:20 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Leeyoung References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED70@dfweml511-mbs.china.huawei.com> <48F63A76-53E9-4C38-A266-8B8BAB9F7838@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905EEC1@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172905EEC1@dfweml511-mbs.china.huawei.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 12:59:23 -0000 Young, On 8/2/2012 12:56 PM, Leeyoung wrote: > YOUNG>> We are expanding the label set concept from 3471. I am not > sure if there is a new name needed here. I defer this to WG chairs. I think it's reasonable to try to have the participants/contributors to try to choose the name. In general having multiple fields with the same name can be confusing and is a situation that I personally prefer to avoid. That said it has happened before, in multiple protocols. If there's an impasse, we (the chairs) can make a proposal. Lou On 8/2/2012 12:56 PM, Leeyoung wrote: > Hi Giovanni, > > Please see in-line for my responses. > > Thanks. > > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: Thursday, August 02, 2012 11:16 AM > To: Leeyoung > Cc: CCAMP > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority > > Hi Young, > > btw first just a naming issue (I guess a question for the wg in general) the object label_set here has the same name name as the label_set form rfc3471 but it has actually a different encoding, so just asking if worth figuring out a little different name. If no one complain I'm fine too. > > YOUNG>> We are expanding the label set concept from 3471. I am not sure if there is a new name needed here. I defer this to WG chairs. > > please see inline > > On Aug 2, 2012, at 1:18 , Leeyoung wrote: > >> >> On Aug 2, 2012, at 24:25 , Leeyoung wrote: >> >>> Hi Giovanni, >>> >>> The wavelength priority you propose seems different from the what we encoded per Rao Rajan's suggestion. What we encoded in section 2.3 of gen encode is not giving wavelength a priority level, among which I believe your wavelength property specifies. >>> >>> What we are proposing is what labels are available/not available for each priority level (similar to LSP reservation or holding priority) as the following encoding dictates: >>> >> >> >> GM> So at the end is a "Label Priority" ? With the Label_Set granularity instead of the single Label? >> >> YOUNG>> No, this is not "label priority". Label is not "assigned" a priority. Label is neutral. Say, you have five wavelengths available for grab and you have two priorities you are aware of which is service level (e.g., LSP). For higher priority service, you may want to all your five wavelengths (w1-w5) available for grab while for lower priority, you may restrict to less number of wavelengths, say three wavelengths only (e.g., w1-w3). > > > GM> Well I'm not sure I'm following you, you say that labels are not assigned to a priority but then there is a priority associated to a label set. For sure label is neutral but "someone" decide if it goes in a label set with a certain priority, or in another (or in both label_set ). So, to me this means associate (is this term better than assign?) a priority to a label. > > YOUNG>> I think I explained enough what the current encoding is. This is about what labels are available for LSP priority. Some labels may be available for more than one LSP priority. There is no 1:1 "association" between label and priority per se. > >> Here you can see individual wavelength is not assigned a priority. > > > GM> the granularity is the label_set so you can easily see that's equivalent to individual label, anyway single label or label-set its not a substantial difference to me. > > > >> This is analogous to how much BW availability for each priority in MPLS network, except that we need to express in wavelength level. >> >> >> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |A| Reserved | Priority Flags| Reserved | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Label Set Field | >>> : : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Where >>> >>> A (Availability bit) = 1 or 0 indicates that the labels listed in >>> the following label set field are available or not available, >>> respectively, for use at a given priority level as indicated by the >>> Priority Flags. >> >> >> GM> The reading here suggest me that there could be multiple objects (I bet up to 8) packed up somewere (e.g. something like sub-tlvs in the link advertisement). Is my interpretation correct? >> >> YOUNG>> Yes. >> > > GM> two encoding question here: > GM> 1/ why using flags instead of classical three bits? > GM> 2/ What the usage of A? I mean you have an Available_label object and then you set A=0 which means that labels are not available... could you please clarify better? > > YOUNG>> Yes, three bits can do that. We put A=0 (not available) --just to give more flexibility. That's all. If you want to restrict some ranges of labels to lower LSP, using A bit (A=0) would be more efficient to express such need. > > Cheers > G > > > >> Cheers >> G >> >> >>> >>> Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 >>> corresponds to priority level 7. If a bit is set then the labels in >>> the label set field are available or not available as indicated by >>> the A bit for use at that particular priority level. >>> >>> Let's begin if we are in agreement with this point. >>> >>> Thanks. >>> Young >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Giovanni Martinelli (giomarti) >>> Sent: Wednesday, August 01, 2012 12:40 PM >>> To: Giovanni Martinelli (giomarti) >>> Cc: CCAMP >>> Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority >>> >>> Here my latest mail with comments on wavelength priority... >>> >>> Here my memory on past discussion (please correct if wrong) >>> - last short thread was during ieft83 (around 26/28 march), last mail was from me and did not get answers. The content here below cover that mail as well. >>> - discussions about wl priority happens among authors not on ccamp mailing list. On the mailing list you announce draft update around dec 2011. >>> >>> Well, I'm not complaining about how discussion happen, simply I saw a not-trivial addition to wg document, hence my comments. >>> >>> Cheers >>> G >>> >>> >>> >>> On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: >>> >>>> Dear authors / ccamp, >>>> >>>> here a few comments related to the priority field added to draft-ietf-ccamp-general-constraint-encode: >>>> >>>> A couple of editorial comments >>>> 1) "wavelenght priority" appears in a draft that claim to be general. In fact is available in "Available Labels Sub-TLV" and "Shared Backup Labels Sub-TLV". So is a wavelength or label-like priority? >>>> 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0 .. 7]? >>>> >>>> >>>> Then few other comments >>>> 3) How the priority is used versus the A flag . Draft text report >>>> " >>>> A (Availability bit) = 1 or 0 indicates that the labels listed in >>>> the following label set field are available or not available, >>>> respectively, for use at a given priority level as indicated by the >>>> Priority Flags. >>>> >>>> " >>>> So does it means that there could be different "available labels sub-TLVs" advertised? >>>> >>>> 4) Still unclear to me how this priority is different from the one reported in http://tools.ietf.org/html/draft-kattan-wson-property-01 and eventually if this "priority" could fit the LSP priority already available (as one of the comment we received at that time) >>>> >>>> Cheers >>>> G >>>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Wed Aug 8 06:06:32 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6460A21F860D for ; Wed, 8 Aug 2012 06:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.295 X-Spam-Level: X-Spam-Status: No, score=-98.295 tagged_above=-999 required=5 tests=[AWL=1.866, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ksby0sENRY-m for ; Wed, 8 Aug 2012 06:06:31 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 7B23D21F8600 for ; Wed, 8 Aug 2012 06:06:31 -0700 (PDT) Received: (qmail 23568 invoked by uid 0); 8 Aug 2012 13:06:30 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 8 Aug 2012 13:06:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=7knKA75KX+/EHPBreFsAPHbnlsMNtWBt4iN5z+kFbwQ=; b=FQG0QYUW2/B8jvcu5yOBBmoxDUJONjY8t2SOplYloOTHoIC6KFCIB4lZkj4ZWwg7oKvnRGUFQqK8fWyYTJmrDnsE67fSpU80MrBxy91bqISMY94ydL+X5KtJop3yyZtH; Received: from box313.bluehost.com ([69.89.31.113]:44506 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Sz5y2-0001oD-Fl; Wed, 08 Aug 2012 07:06:30 -0600 Message-ID: <50226455.1040803@labn.net> Date: Wed, 08 Aug 2012 09:06:29 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Rajan Rao References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED70@dfweml511-mbs.china.huawei.com> <48F63A76-53E9-4C38-A266-8B8BAB9F7838@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905EEC1@dfweml511-mbs.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D347EE54E@SV-EXDB-PROD2.infinera.com> In-Reply-To: <650AA355E323C34D9D4AAEED952E053D347EE54E@SV-EXDB-PROD2.infinera.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 13:06:32 -0000 Rajan/Young, I think it also would be helpful to have a description *in the draft* of how & when the availability bit=0 is used. (For example, what does it mean to have the bit =0 and an label set with an exclusive action?) Lou (as WG participant) On 8/2/2012 1:39 PM, Rajan Rao wrote: > Giovanni, > > My comment few months ago was to cover bandwidth advertisement at > all 8 priority levels as in PSC, TDM & TDM-OTN switching cases. > The priority based advertisement in WSON/LSC is no different from > other cases. > > What might be useful is to add couple of examples to show how this is > used along with other flags. > > Hope this helps. > Thanks > Rajan > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Leeyoung > Sent: Thursday, August 02, 2012 9:57 AM > To: Giovanni Martinelli (giomarti) > Cc: CCAMP > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority > > Hi Giovanni, > > Please see in-line for my responses. > > Thanks. > > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: Thursday, August 02, 2012 11:16 AM > To: Leeyoung > Cc: CCAMP > Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority > > Hi Young, > > btw first just a naming issue (I guess a question for the wg in general) the object label_set here has the same name name as the label_set form rfc3471 but it has actually a different encoding, so just asking if worth figuring out a little different name. If no one complain I'm fine too. > > YOUNG>> We are expanding the label set concept from 3471. I am not sure if there is a new name needed here. I defer this to WG chairs. > > please see inline > > On Aug 2, 2012, at 1:18 , Leeyoung wrote: > >> >> On Aug 2, 2012, at 24:25 , Leeyoung wrote: >> >>> Hi Giovanni, >>> >>> The wavelength priority you propose seems different from the what we encoded per Rao Rajan's suggestion. What we encoded in section 2.3 of gen encode is not giving wavelength a priority level, among which I believe your wavelength property specifies. >>> >>> What we are proposing is what labels are available/not available for each priority level (similar to LSP reservation or holding priority) as the following encoding dictates: >>> >> >> >> GM> So at the end is a "Label Priority" ? With the Label_Set granularity instead of the single Label? >> >> YOUNG>> No, this is not "label priority". Label is not "assigned" a priority. Label is neutral. Say, you have five wavelengths available for grab and you have two priorities you are aware of which is service level (e.g., LSP). For higher priority service, you may want to all your five wavelengths (w1-w5) available for grab while for lower priority, you may restrict to less number of wavelengths, say three wavelengths only (e.g., w1-w3). > > > GM> Well I'm not sure I'm following you, you say that labels are not assigned to a priority but then there is a priority associated to a label set. For sure label is neutral but "someone" decide if it goes in a label set with a certain priority, or in another (or in both label_set ). So, to me this means associate (is this term better than assign?) a priority to a label. > > YOUNG>> I think I explained enough what the current encoding is. This is about what labels are available for LSP priority. Some labels may be available for more than one LSP priority. There is no 1:1 "association" between label and priority per se. > >> Here you can see individual wavelength is not assigned a priority. > > > GM> the granularity is the label_set so you can easily see that's equivalent to individual label, anyway single label or label-set its not a substantial difference to me. > > > >> This is analogous to how much BW availability for each priority in MPLS network, except that we need to express in wavelength level. >> >> >> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |A| Reserved | Priority Flags| Reserved | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Label Set Field | >>> : : >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Where >>> >>> A (Availability bit) = 1 or 0 indicates that the labels listed in >>> the following label set field are available or not available, >>> respectively, for use at a given priority level as indicated by the >>> Priority Flags. >> >> >> GM> The reading here suggest me that there could be multiple objects (I bet up to 8) packed up somewere (e.g. something like sub-tlvs in the link advertisement). Is my interpretation correct? >> >> YOUNG>> Yes. >> > > GM> two encoding question here: > GM> 1/ why using flags instead of classical three bits? > GM> 2/ What the usage of A? I mean you have an Available_label object and then you set A=0 which means that labels are not available... could you please clarify better? > > YOUNG>> Yes, three bits can do that. We put A=0 (not available) --just to give more flexibility. That's all. If you want to restrict some ranges of labels to lower LSP, using A bit (A=0) would be more efficient to express such need. > > Cheers > G > > > >> Cheers >> G >> >> >>> >>> Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 >>> corresponds to priority level 7. If a bit is set then the labels in >>> the label set field are available or not available as indicated by >>> the A bit for use at that particular priority level. >>> >>> Let's begin if we are in agreement with this point. >>> >>> Thanks. >>> Young >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>> Behalf Of Giovanni Martinelli (giomarti) >>> Sent: Wednesday, August 01, 2012 12:40 PM >>> To: Giovanni Martinelli (giomarti) >>> Cc: CCAMP >>> Subject: Re: [CCAMP] Comment on >>> draft-ietf-ccamp-general-constraint-encode-08: priority >>> >>> Here my latest mail with comments on wavelength priority... >>> >>> Here my memory on past discussion (please correct if wrong) >>> - last short thread was during ieft83 (around 26/28 march), last mail was from me and did not get answers. The content here below cover that mail as well. >>> - discussions about wl priority happens among authors not on ccamp mailing list. On the mailing list you announce draft update around dec 2011. >>> >>> Well, I'm not complaining about how discussion happen, simply I saw a not-trivial addition to wg document, hence my comments. >>> >>> Cheers >>> G >>> >>> >>> >>> On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: >>> >>>> Dear authors / ccamp, >>>> >>>> here a few comments related to the priority field added to draft-ietf-ccamp-general-constraint-encode: >>>> >>>> A couple of editorial comments >>>> 1) "wavelenght priority" appears in a draft that claim to be general. In fact is available in "Available Labels Sub-TLV" and "Shared Backup Labels Sub-TLV". So is a wavelength or label-like priority? >>>> 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0 .. 7]? >>>> >>>> >>>> Then few other comments >>>> 3) How the priority is used versus the A flag . Draft text report " >>>> A (Availability bit) = 1 or 0 indicates that the labels listed in >>>> the following label set field are available or not available, >>>> respectively, for use at a given priority level as indicated by the >>>> Priority Flags. >>>> >>>> " >>>> So does it means that there could be different "available labels sub-TLVs" advertised? >>>> >>>> 4) Still unclear to me how this priority is different from the one >>>> reported in http://tools.ietf.org/html/draft-kattan-wson-property-01 >>>> and eventually if this "priority" could fit the LSP priority already >>>> available (as one of the comment we received at that time) >>>> >>>> Cheers >>>> G >>>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From rgandhi@cisco.com Wed Aug 8 06:15:14 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B65821F861A for ; Wed, 8 Aug 2012 06:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_93=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1mhAX27RGpv for ; Wed, 8 Aug 2012 06:15:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 65F6B21F8616 for ; Wed, 8 Aug 2012 06:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58130; q=dns/txt; s=iport; t=1344431710; x=1345641310; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NbZSMMbEMLhwmVZ98Or9AwM3ONh/UpZQ5/JUXL+n8Qk=; b=mBY1qudqsmi/W8oJaW1bUh/zy+dNSTupUm/quQYFBzWGLIo9fwCXtmUH 9woTo5JEAIw8lvEhECXHLQIhZbw4Ft+yied4R/LpCLdqN0RBDebWv+4tB 1kXJ0xZJidhxrp1zqAE54H83vuymShsaTb1Vxeyo04j6RVd5bc81wAyjC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAJtlIlCtJXHA/2dsb2JhbAA7CoJKgzeyanGBB4IgAQEBBBIBBxNMEAIBBgIRBAEBCxYBBgUCAjAUCQgCBA4FCBqHa5o5jRMIkyCLEhCFOjZgA6NygWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,733,1336348800"; d="scan'208,217";a="106571672" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 08 Aug 2012 13:14:46 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q78DEjss030333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 13:14:45 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Wed, 8 Aug 2012 08:14:44 -0500 From: "Rakesh Gandhi (rgandhi)" To: "zhang.fei3@zte.com.cn" Thread-Topic: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 Thread-Index: AQHNWlnLzkulPBoZQRGX7309/bFmI5cz9gXQgAT+uQCAAB3KsIABhIgAgAeIEfCAAQFrgIAAozjggASMooD//9ocsIAH5wAAgAAGuvA= Date: Wed, 8 Aug 2012 13:14:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.221.138] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19094.000 x-tm-as-result: No--60.143700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_B7D2A316AA32B6469D9670B6A81B7C24066C8Fxmbalnx07ciscocom_" MIME-Version: 1.0 Cc: "Robert Sawaya \(rsawaya\)" , "yang.fan5@zte.com.cn" , CCAMP , "jingrq@ctbri.com.cn" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 13:15:14 -0000 --_000_B7D2A316AA32B6469D9670B6A81B7C24066C8Fxmbalnx07ciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRmVpLA0KDQpUaGFua3MgZm9yIHlvdXIgaW5zaWdodC4gSSB1bmRlcnN0YW5kIHdoYXQgeW91 IGFyZSBzYXlpbmcsIHBsZWFzZSBzZWUgaW5saW5lLi48Ukc1Pg0KDQpGcm9tOiB6aGFuZy5mZWkz QHp0ZS5jb20uY24gW21haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY25dDQpTZW50OiBXZWRuZXNk YXksIEF1Z3VzdCAwOCwgMjAxMiAzOjQxIEFNDQpUbzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkN CkNjOiBDQ0FNUDsgRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7IGppYW5nLndlaWxpYW5AenRlLmNv bS5jbjsgamluZ3JxQGN0YnJpLmNvbS5jbjsgUm9iZXJ0IFNhd2F5YSAocnNhd2F5YSk7IEdlb3Jn ZSBTd2FsbG93IChzd2FsbG93KTsgeWFuZy5mYW41QHp0ZS5jb20uY24NClN1YmplY3Q6IFJFOiBD b21tZW50cyBvbiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVk LWxzcC0wMw0KDQoNClRoYW5rIHlvdSBSYWtlc2ggZm9yIHlvdXIgcHJvbXB0IHJlc3BvbnNlIDop DQoNClNuaXBwZWQgdGhlIGFncmVlYWJsZSBwYXJ0cywgc2VlIGluIGxpbmUgd2l0aCA8ZmVpMT4N Cg0KPFJHND4gSSBhZ3JlZSB0aGF0IGlmIGJvdGggdmVuZG9ycyBpbXBsZW1lbnQgc2F5IG1ldGhv ZCAxIG9yIGJvdGggdmVuZG9ycyBpbXBsZW1lbnQgc2F5IG1ldGhvZCAyIHRoZW4gdGhleSB3b3Vs ZCBpbnRlcm9wZXJhdGUsIGFuZCAgZXh0IEVBIG9iamVjdHMgYXJlIHRoZSBzYW1lLiBCdXQgbWV0 aG9kIDEgYW5kIG1ldGhvZCAyIG1heSBub3QgaW50ZXJvcGVyYXRlIHRvZ2V0aGVyLiAgTm90IHN1 cmUgaWYgd2Ugd2FudCB0byBoYXZlIGEgc2VwYXJhdGUgZmxhZyB0byBpbmRpY2F0ZSBpZiBleHQg YXNzb2NpYXRpb24gb2JqZWN0IGlzIHBvcHVsYXRlZCB3aXRoIG1ldGhvZCAxIG9yIDIgdG8gY292 ZXIgdGhpcyBjYXNlPyAgIEl0IGlzIGZpbmUgdG8gaGF2ZSBtb3JlIHRoYW4gb25lIG1ldGhvZCBp biB0aGUgZHJhZnQgZm9yIGZsZXhpYmlsaXR5IGFuZCBmdXR1cmUgdXNlIGJ1dCBnb29kIHRvIGVs YWJvcmF0ZSBvbiB0aGUgcG9zc2libGUgdXNlIGNhc2UgaWYgd2Uga25vdyBvZiBhbnkuDQoNCjxm ZWkxPiBJTUhPLCB0aGUgb25seSBkaWZmZXJlbmNlIGlzIHRoZSB1bmlxdWUgcmVwcmVzZW50YXRp b24gb2YgdGhlIGFzc29jaWF0aW9uLCB1c2luZyBTQSthc3NvY2lhdGlvbi1pZChJRCBpcyB1bmlx dWUgdW5kZXIgU0EgKW9yIFNBK0RBK2Fzc29jaWF0aW9uLWlkIChJRCBpcyB1bmlxdWUgdW5kZXIg dGhlIGNvbWJpbmF0aW9uIG9mIFNBIGFuZCBEQSkgd2hpY2ggaXMgbW9yZSBzdHJpY3Rlci4gSSBh Z3JlZSB0aGF0IHdlIGhhZCBiZXR0ZXIgYWRvcHRpbmcgb25lIG9mIHRoZW0gYmVjYXVzZSBvZiB0 aGUgaW50ZXJvcCBpc3N1ZS4NCg0KTGV0J3MgY29uc2lkZXIgdGhlIGF1dG8tbWVzaCB0dW5uZWxz IHdoaWNoIHlvdSBwcm92aWRlZCBpbiB0aGUgcHJldmlvdXMgZW1haWwuICAiPFJHPiBUaGVyZSBp cyBhIHVzZSBjYXNlIGZvciBhdXRvLW1lc2ggdHVubmVscyB3aGVyZSBzb3VyY2Ugbm9kZSBtYXkg b3JpZ2luYXRlIHR1bm5lbHMgdG8gbWFueSBkZXN0aW5hdGlvbnMgdXNpbmcgdGhlIHNhbWUgYXNz b2NpYXRpb24gc291cmNlIGFuZCBhc3NvY2lhdGlvbi1pZC4gSW4gdGhpcyBjYXNlLCBkaWZmZXJl bnQgdmFsdWVzIGZvciBleHRlbmRlZCBhc3NvY2lhdGlvbiBJRCBwcm92aWRlIHVuaXF1ZSBleHRl bmRlZCBhc3NvY2lhdGlvbiBvYmplY3QuIg0KQ2FuIHlvdSBjbGFyaWZ5IHdoYXQgaXMgdGhlIGJl bmVmaXRzIG9mIHVzaW5nIHRoZSBzYW1lIGFzc29jaWF0aW9uLWlkIChkaWZmZXJlbnQgYXNzb2Np YXRpb24taWQgd29ya3Mgd2VsbCBhbHNvKSwgc28gdGhhdCB3ZSBjYW4gcGVyc3VhZGUgdGhlIFdH IHRoYXQgdGhpcyBzdHJpY3QgaW1wbGVtZW50YXRpb24gaXMgYSBiZXR0ZXIgY2hvaWNlIGFuZCBh ZGQgdGhlIHVzZWNhc2UgaWYgbmVjZXNzYXJ5Lg0KDQo8Ukc1PiBGb3Igc2luZ2xlIHNpZGVkIHBy b3Zpc2lvbmluZywgd2hlcmUgcmVtb3RlIGVuZCBzaW1wbHkgY29waWVzIHRoZSByZWNlaXZlZCBF eHQgQXNzb2NpYXRpb24gT2JqZWN0LCBhc3NvY2lhdGlvbi1pZCBjYW4gYmUgdW5pcXVlIGZvciBT QS4gQnV0IGZvciBkb3VibGUgc2lkZWQgcHJvdmlzaW9uaW5nLCB3aGVyZSBhc3NvY2lhdGlvbi1p ZCBpcyB1c2VkIHRvIGdsdWUgdGhlIHR3byBMU1BzIKhDIGZvcndhcmQgYW5kIHJldmVyc2UgZGly ZWN0aW9uIExTUHMsIGFzc29jaWF0aW9uLWlkIGlzIHVzZWQgdG8gaWRlbnRpZnkgdGhlIG1hdGNo aW5nIExTUHMgYW5kIGhlbmNlIG5lZWQgdG8gYmUgdW5pcXVlIHBlciBTQStEQS4NClNpbWlsYXIg dG8gc3RhdGljIHR1bm5lbHMsIGF1dG8tdHVubmVsIG1lc2ggY2FuIGFsc28gYmUgcHJvdmlzaW9u ZWQgdXNpbmcgaWRlbnRpY2FsIGFzc29jaWF0aW9uLWlkcyBvbiBib3RoIHNpZGVzLiBUaGlzIHdh eSBzYW1lIG1ldGhvZCB3b3JrcyBmb3IgYm90aC4NClRoYW5rcywNClJha2VzaA0KDQpPciBhbnkg b3RoZXIgdXNlY2FzZXM/DQoNClBsZWFzZSBkbyBub3QgaGVzaXRhdGUgdG8gbGV0IG1lIGtub3cg aWYgSSBoYXZlIGEgbWlzdGFrZQ0KDQpCZXN0IHJlZ2FyZHMNCg0KRmVpDQoNCiJSYWtlc2ggR2Fu ZGhpIChyZ2FuZGhpKSIgPHJnYW5kaGlAY2lzY28uY29tPG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNv bT4+DQoNCjIwMTItMDgtMDMgMjA6MTENCg0KytW8/sjLDQoNCiJ6aGFuZy5mZWkzQHp0ZS5jb20u Y248bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj4iIDx6aGFuZy5mZWkzQHp0ZS5jb20uY248 bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj4+DQoNCrOty80NCg0KQ0NBTVAgPGNjYW1wQGll dGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4+LCAiRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSki IDxlb3Nib3JuZUBjaXNjby5jb208bWFpbHRvOmVvc2Jvcm5lQGNpc2NvLmNvbT4+LCAiamlhbmcu d2VpbGlhbkB6dGUuY29tLmNuPG1haWx0bzpqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY24+IiA8amlh bmcud2VpbGlhbkB6dGUuY29tLmNuPG1haWx0bzpqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY24+Piwg ImppbmdycUBjdGJyaS5jb20uY248bWFpbHRvOmppbmdycUBjdGJyaS5jb20uY24+IiA8amluZ3Jx QGN0YnJpLmNvbS5jbjxtYWlsdG86amluZ3JxQGN0YnJpLmNvbS5jbj4+LCAiUm9iZXJ0IFNhd2F5 YSAocnNhd2F5YSkiIDxyc2F3YXlhQGNpc2NvLmNvbTxtYWlsdG86cnNhd2F5YUBjaXNjby5jb20+ PiwgIkdlb3JnZSBTd2FsbG93IChzd2FsbG93KSIgPHN3YWxsb3dAY2lzY28uY29tPG1haWx0bzpz d2FsbG93QGNpc2NvLmNvbT4+LCAieWFuZy5mYW41QHp0ZS5jb20uY248bWFpbHRvOnlhbmcuZmFu NUB6dGUuY29tLmNuPiIgPHlhbmcuZmFuNUB6dGUuY29tLmNuPG1haWx0bzp5YW5nLmZhbjVAenRl LmNvbS5jbj4+DQoNCtb3zOINCg0KUkU6IENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtY2NhbXAtbXBs cy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTAzDQoNCg0KDQoNCg0KDQoNClRoYW5rcyBG ZWkuIFdlIGFyZSBhbG1vc3QgdGhlcmUuIFBsZWFzZSBzZWUgaW5saW5lLi48Ukc0Pi4NCg0KRnJv bTogemhhbmcuZmVpM0B6dGUuY29tLmNuPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+IFtt YWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuXTxtYWlsdG86W21haWx0bzp6aGFuZy5mZWkzQHp0 ZS5jb20uY25dPg0KU2VudDogRnJpZGF5LCBBdWd1c3QgMDMsIDIwMTIgNToxNiBBTQ0KVG86IFJh a2VzaCBHYW5kaGkgKHJnYW5kaGkpDQpDYzogQ0NBTVA7IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUp OyBqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY248bWFpbHRvOmppYW5nLndlaWxpYW5AenRlLmNvbS5j bj47IGppbmdycUBjdGJyaS5jb20uY248bWFpbHRvOmppbmdycUBjdGJyaS5jb20uY24+OyBSb2Jl cnQgU2F3YXlhIChyc2F3YXlhKTsgR2VvcmdlIFN3YWxsb3cgKHN3YWxsb3cpOyB5YW5nLmZhbjVA enRlLmNvbS5jbjxtYWlsdG86eWFuZy5mYW41QHp0ZS5jb20uY24+DQpTdWJqZWN0OiBSRTogQ29t bWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1s c3AtMDMNCg0KDQpIaSBSYWtlc2gNCg0KU25pcHBlZCB0aGUgb3RoZXIgcGFydHMgZm9yIGVhc3kg cmVhZGluZywgc29ycnkgZm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlDQoNCjxSRzM+IFRoZXJlIGFy ZSBhcHBsaWNhdGlvbnMgdGhhdCByZXF1aXJlIGNvLXJvdXRlZCBMU1BzLiBTbyBJIHRoaW5rIHdl IHNob3VsZCBoYXZlIGEgZmxhZyB0byBpbmRpY2F0ZSB0aGF0IExTUHMgbXVzdCBiZSBjby1yb3V0 ZWQsIGVsc2Ugbm9kZSB3aWxsIHNlbmQgYSBwYXRoIGVycm9yIGZvciBleGFtcGxlIGlmIHJlcXVl c3QgY2Fubm90IGJlIG1ldC4gIEkgYWdyZWUgd2l0aCB5b3UgYWJvdXQgY29tcGxleGl0eSB3aXRo IGRvdWJsZSBzaWRlZCBwcm92aXNpb25pbmcgbW9kZWwgdGhvdWdoLg0KDQo8ZmVpPiBTaW5jZSB5 b3UgYmVsaWV2ZSB0aGF0IGEgY29tbW9uIG1lY2hhbmlzbSB1c2VkIGZvciB0aGUgbm9uLWNvcm91 dGVkIGFuZCBjb3JvdXRlZCBjYXNlcyBpcyB1c2VmdWwsIHdlIHdpbGwgYWRkIHRoZSB0ZXh0cyBp biB0aGUgbmV4dCB2ZXJzaW9uLg0KPFJHND4gVGhpcyBpcyBncmVhdC4gVGhhbmtzLg0KDQoNCjxS RzM+IE9rLCB3ZSBwcm9iYWJseSBzaG91bGQgYWRkIHVzZSBjYXNlcyBmb3IgdmFyaW91cyBtZXRo b2RzLiBJIGNhbiBzZWUgbWV0aG9kIDEgYmVpbmcgdXNlZCBmb3Igc2V0dGluZyB1cCBiaWRpcmVj dGlvbmFsIExTUHMgYnV0IEkgYW0gbm90IHN1cmUgYWJvdXQgbWV0aG9kIDIgZm9yIGV4YW1wbGUu IE9uZSB3b3JyeSBpcyB0aGF0IGRpZmZlcmVudCBtZXRob2RzIGNhbiBsZWFkIHRvIGludGVyb3Ag aXNzdWVzIGlmIG9uZSB2ZW5kb3IgaW1wbGVtZW50cyBtZXRob2QgMSBhbmQgc2Vjb25kIHZlbmRv ciBtZXRob2QgMi4NCkFzc29jaWF0aW9uIG9iamVjdCBpcyBiZWluZyB1c2VkIGZvciBkaWZmZXJl bnQgYXNzb2NpYXRpb24gdHlwZXMgKFJGQyA0ODcyOiB0eXBlIDE6IFJlY292ZXJ5KSwgKFJGQyA0 ODczLSB0eXBlIDI6IFJlc291cmNlIHNoYXJpbmcpLCBldGMuIGFuZCB0aGVzZSBSRkNzIGRlZmlu ZSBzcGVjaWZpYyBwcm9jZWR1cmVzIGZvciB0aGUgZ2l2ZW4gYXNzb2NpYXRpb24gdHlwZS4gU28g SU1ITywgaXQgbWF5IGJlIG9rIHRvIGRlZmluZSBhIHN0cmljdGVyIHByb2NlZHVyZSBmb3IgcG9w dWxhdGluZyBleHQgYXNzb2NpYXRpb24gb2JqZWN0IGZvciB0aGUgbmV3IEJpZGlyZWN0aW9uYWwg TFNQcyBhc3NvY2lhdGlvbiB0eXBlLg0KDQo8ZmVpPiBNZXRob2QgMiB3b3JrcyB3ZWxsLCBhbmQg dGhlIG9ubHkgZGlmZmVyZW5jZSBpcyB0IGhvdyB0byByZXByZXNlbnQgdGhlIGdsb2JhbCB1bmlx dWUgaWRlbnRpZmllci4gRm9yIHRoZSBhc3NvY2lhdGlvbiBpcyBiYXNlZCBvbiB0aGUgZnVsbCBt YXRjaCBvZiB0aGUgRUEgb2JqZWN0cywgdGhlIEVBIG9iamVjdCBpcyBqdXN0IGNvcGllZCBmcm9t IHRoZSBwYXRoIG1lc3NhZ2UgaW50byBhbm90aGVyIHBhdGggbWVzc2FnZSBpbiBzaW5nbGUgc2lk ZWQgcHJvdmlzaW9uaW5nIG1vZGVsLiBBcyB0byB0aGUgZG91YmxlZCBzaWRlZCBwcm92aXNpb25p bmcgbW9kZWwsIHRoZSBFQSBvYmplY3RzIGlzIGFsc28gdGhlIHNhbWUuIElNSE8sIHRoZXJlIGlz IG5vIGludGVyb3AgaXNzdWVzLCBvciBkbyBJIGhhdmUgc29tZSBtaXN1bmRlcnN0YW5kaW5nPw0K DQpZZWFoLCB3ZSBjYW4gZGVmaW5lIGEgc3RyaWN0ZXIgcHJvZGVkdXJlLCBJIGFtIG5vdCBzdXJl IHRoaXMgaXMgYSBnb29kIHdheSBpbiBzdGFuZGFyZCwgbmVlZCBtb3JlIGZlZWRiYWNrIGZyb20g dGhlIFdHLg0KPFJHND4gSSBhZ3JlZSB0aGF0IGlmIGJvdGggdmVuZG9ycyBpbXBsZW1lbnQgc2F5 IG1ldGhvZCAxIG9yIGJvdGggdmVuZG9ycyBpbXBsZW1lbnQgc2F5IG1ldGhvZCAyIHRoZW4gdGhl eSB3b3VsZCBpbnRlcm9wZXJhdGUsIGFuZCAgZXh0IEVBIG9iamVjdHMgYXJlIHRoZSBzYW1lLiBC dXQgbWV0aG9kIDEgYW5kIG1ldGhvZCAyIG1heSBub3QgaW50ZXJvcGVyYXRlIHRvZ2V0aGVyLiAg Tm90IHN1cmUgaWYgd2Ugd2FudCB0byBoYXZlIGEgc2VwYXJhdGUgZmxhZyB0byBpbmRpY2F0ZSBp ZiBleHQgYXNzb2NpYXRpb24gb2JqZWN0IGlzIHBvcHVsYXRlZCB3aXRoIG1ldGhvZCAxIG9yIDIg dG8gY292ZXIgdGhpcyBjYXNlPyAgIEl0IGlzIGZpbmUgdG8gaGF2ZSBtb3JlIHRoYW4gb25lIG1l dGhvZCBpbiB0aGUgZHJhZnQgZm9yIGZsZXhpYmlsaXR5IGFuZCBmdXR1cmUgdXNlIGJ1dCBnb29k IHRvIGVsYWJvcmF0ZSBvbiB0aGUgcG9zc2libGUgdXNlIGNhc2UgaWYgd2Uga25vdyBvZiBhbnku DQpUaGFua3MsDQpSYWtlc2gNCg0KDQpDaGVlcg0KDQpGZWkNCiJSYWtlc2ggR2FuZGhpIChyZ2Fu ZGhpKSIgPHJnYW5kaGlAY2lzY28uY29tPG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNvbT4+DQoNCjIw MTItMDgtMDEgMDE6MjQNCg0KDQrK1bz+yMsNCg0KInpoYW5nLmZlaTNAenRlLmNvbS5jbjxtYWls dG86emhhbmcuZmVpM0B6dGUuY29tLmNuPiIgPHpoYW5nLmZlaTNAenRlLmNvbS5jbjxtYWlsdG86 emhhbmcuZmVpM0B6dGUuY29tLmNuPj4NCg0Ks63LzQ0KDQoiRXJpYyBPc2Jvcm5lIChlb3Nib3Ju ZSkiIDxlb3Nib3JuZUBjaXNjby5jb208bWFpbHRvOmVvc2Jvcm5lQGNpc2NvLmNvbT4+LCAiamlh bmcud2VpbGlhbkB6dGUuY29tLmNuPG1haWx0bzpqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY24+IiA8 amlhbmcud2VpbGlhbkB6dGUuY29tLmNuPG1haWx0bzpqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY24+ PiwgImppbmdycUBjdGJyaS5jb20uY248bWFpbHRvOmppbmdycUBjdGJyaS5jb20uY24+IiA8amlu Z3JxQGN0YnJpLmNvbS5jbjxtYWlsdG86amluZ3JxQGN0YnJpLmNvbS5jbj4+LCAiUm9iZXJ0IFNh d2F5YSAocnNhd2F5YSkiIDxyc2F3YXlhQGNpc2NvLmNvbTxtYWlsdG86cnNhd2F5YUBjaXNjby5j b20+PiwgIkdlb3JnZSBTd2FsbG93IChzd2FsbG93KSIgPHN3YWxsb3dAY2lzY28uY29tPG1haWx0 bzpzd2FsbG93QGNpc2NvLmNvbT4+LCAieWFuZy5mYW41QHp0ZS5jb20uY248bWFpbHRvOnlhbmcu ZmFuNUB6dGUuY29tLmNuPiIgPHlhbmcuZmFuNUB6dGUuY29tLmNuPG1haWx0bzp5YW5nLmZhbjVA enRlLmNvbS5jbj4+LCBDQ0FNUCA8Y2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3Jn Pj4NCg0K1vfM4g0KDQpSRTogQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJz dnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDMNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIaSBGZWks DQoNClRoYW5rcyBmb3IgeW91ciBraW5kIHJlcGx5LiBQbGVhc2Ugc2VlIGlubGluZS4uPFJHMz4u Lg0KDQo8U25pcHBlZCBlbWFpbCB0byBmb2N1cyBvbiBvcGVuIGl0ZW1zPg0KDQoNCkZyb206IHpo YW5nLmZlaTNAenRlLmNvbS5jbjxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPiBbbWFpbHRv OnpoYW5nLmZlaTNAenRlLmNvbS5jbl08bWFpbHRvOlttYWlsdG86emhhbmcuZmVpM0B6dGUuY29t LmNuXT4NClNlbnQ6IE1vbmRheSwgSnVseSAzMCwgMjAxMiAxMDowNCBQTQ0KVG86IFJha2VzaCBH YW5kaGkgKHJnYW5kaGkpDQpDYzogRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7IGppYW5nLndlaWxp YW5AenRlLmNvbS5jbjxtYWlsdG86amlhbmcud2VpbGlhbkB6dGUuY29tLmNuPjsgamluZ3JxQGN0 YnJpLmNvbS5jbjxtYWlsdG86amluZ3JxQGN0YnJpLmNvbS5jbj47IFJvYmVydCBTYXdheWEgKHJz YXdheWEpOyBHZW9yZ2UgU3dhbGxvdyAoc3dhbGxvdyk7IHlhbmcuZmFuNUB6dGUuY29tLmNuPG1h aWx0bzp5YW5nLmZhbjVAenRlLmNvbS5jbj47IENDQU1QDQpTdWJqZWN0OiBSRTogQ29tbWVudHMg b24gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDMN Cg0KVGhhbmsgeW91IFJha2VzaCBmb3Igc2hhcmluZyB5b3VyIGlkZWEsIEkgdGhpbmsgd2UgYXJl IHJvdWdobHkgaW4gYWdyZWVtZW50IGFuZCBuZWVkIHRvIGhlYXIgbW9yZSB2b2ljZXMgZnJvbSB0 aGUgV0cuIDopDQoNClNlZSBpbmxpbmUgPGZlaT48L2ZlaT4NCg0KQmVzdA0KDQpGZWkNCg0KMikg RGVmaW5lIG9uZSBmbGFnIGZvciBjby1yb3V0ZWQgb3Igbm9uLWNvcm91dGVkLiBJZiB0aGUgY28t cm91dGVkIGJpZGlyIGlzIHRoZSBkZWZhdWx0IGJlaGF2aW9yLCB3aHkgbm90IHVzaW5nIHRoZSBw cm9jZWR1cmUgZGVmaW5lZCBpbiBSRkMzNDczPyBJIGFtIGFmcmFpZCBpdCBpcyBoYXJkDQp0byBw ZXJzdWFkZSB0aGUgV0cgdG8gZG8gc28uIE1heWJlIHRoZSBiZXR0ZXIgd2F5IGlzIHRoYXQgbm9u LWNvcm91dGVkIGJpZGlyIGlzIHRoZSBkZWZhdWx0LCBhbmQgdGhlIHNldCBvZiB0aGUgY28tcm91 dGVkIGZsYWcgb25seSBtZWFucyB0aGF0IGl0IGlzIHJlY29tbWVuZGVkLCBub3QgbWFuZGF0b3J5 LCB0aGUgY2hlY2tpbmcgd2hldGhlciB0aGUgTFNQIGlzIGNvLXJvdXRlZCBjYW4gYmUgZG9uZSBi eSBjb21wYXJpbmcgdGhlIFJSTyBvYmplY3RzLiBXaGF0IGlzIHlvdXIgb3Bpbmlvbj8NCjxSRzE+ IEl0IGlzIGZpbmUgdG8gaGF2ZSBub24gY28tcm91dGVkIGFzIGRlZmF1bHQuIFJGQyAzNDczIGlz IGEgR01QTFMgc2lnbmFsaW5nIHByb2NlZHVyZS4gSXQgbWF5IG5vdCBiZSBvcHRpbWFsICB0byBo YXZlIHR3byBkaWZmZXJlbnQgc2lnbmFsaW5nIHByb2NlZHVyZXMsIG9uZSBmb3Igbm9uIGNvLXJv dXRlZCAoZXh0IGFzc29jaWF0ZWQgb2JqZWN0KSBhbmQgb25lIGZvciBjby1yb3V0ZWQgKFJGQyAz NDczKSBwcm9jZWR1cmVzLiBCeSBhZGRpbmcgYSBmbGFnIGZvciBjby1yb3V0ZWQsIHNhbWUgc2ln bmFsaW5nIChleHQgYXNzb2NpYXRlZCBvYmplY3QpIGNhbiBiZSB1c2VkIGZvciBib3RoIHdoaWNo IGlzIG5pY2UuIFdlIGJlbGlldmUgY29tcGFyaW5nIG9mIFJSTyBjYW4gYmUgbWlzbGVhZGluZyBi ZWNhdXNlIHR3byBMU1BzIGNhbiBiZSBvbiB0aGUgc2FtZSBwYXRoIGV2ZW4gdGhvdWdoIHByb3Zp c2lvbmVkIHRvIGJlIG5vbiBjby1yb3V0ZWQuDQoNCjxmZWk+DQpTb3JyeSB0aGF0IHdoYXQgSSBz dWdnZXN0ZWQgbWF5YmUgbWlzbGVhZCB5b3UsIHRoZSBmb2xsb3dpbmcgZGVzY3JpcGl0b25zIGFy ZSBtb3JlIGFjY3VyYXRlLiA6KQ0KMSlUaGUgZGVmYXVsdCBiZWhhdmlvciAobm9uLWNvcm91dGVk KSBtZWFucyB0aGF0IGl0IGlzIG5vdCByZXF1aXJlZCB0byBiZSBjby1yb3V0ZWQuIEluIG90aGVy IHdvcmRzLCBpdCBpcyBhbHNvIE9LIHRoYXQgdGhlIHR3byBwYXRocyBhcmUgYWxvbmcgdGhlIHNh bWUgcGF0aA0KDQouDQo8UkczPiBBZ3JlZS4NCg0KMilUaGUgZmxhZyBzZXQgbWVhbnMgdGhhdCBj by1yb3V0ZWQgaXMgcmVjb21tZW5kZWQuIEluIG90aGVyIHdvcmRzLCB0aGUgcmV2ZXJzZSBMU1Ag U0hPVUxEIGJlIGVzdGFibGlzaGVkIGluIHRoZSBzYW1lIHBhdGggYXMgbXVjaCBhcyBwb3NzaWJs ZS4gSWYgdGhlIGZsYWcgc2V0IG1lYW5zDQp0aGF0IGNvLXJvdXRlZCBpcyBtYW5kYXRvcnksdGhl IHByb2NlZHVyZXMgd2lsbCBiZSB2ZXJ5IGNvbXBsZXggaW4gZG91YmxlIHNpZGVkIHByb3Zpc2lv bmluZyBtb2RlbC4NCjwvZmVpPg0KPFJHMz4gVGhlcmUgYXJlIGFwcGxpY2F0aW9ucyB0aGF0IHJl cXVpcmUgY28tcm91dGVkIExTUHMuIFNvIEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSBmbGFnIHRv IGluZGljYXRlIHRoYXQgTFNQcyBtdXN0IGJlIGNvLXJvdXRlZCwgZWxzZSBub2RlIHdpbGwgc2Vu ZCBhIHBhdGggZXJyb3IgZm9yIGV4YW1wbGUgaWYgcmVxdWVzdCBjYW5ub3QgYmUgbWV0LiAgSSBh Z3JlZSB3aXRoIHlvdSBhYm91dCBjb21wbGV4aXR5IHdpdGggZG91YmxlIHNpZGVkIHByb3Zpc2lv bmluZyBtb2RlbCB0aG91Z2guDQoNCg0KMylBcyB0byB0aGUgdHVwbGUgb2YgPGxvd2VyIGlwIGFk ZHJlc3MsIGhpZ2ggaXAgYWRkcmVzcywgYXNzb2NpYXRpb24gaWQ+LCB5ZWFoLCBpdCBpcyBvbmUg a2luZCBvZiBpbXBsZW1lbnRhdGlvbiwgYnV0IHRoZXJlIGFyZSBwb3RlbnRpYWwgc29tZSBvdGhl ciByZWFsaXphdGlvbnMsIGxpa2UgdXNpbmcgb25lIG9mIHRoZSByb3V0ZXIgaWQgcGx1cyB0aGUg dHVubmVsIGlkLiBJIHRoaW5rIHdlIGhhZCBiZXR0ZXIgbm90IHJlc3RyaWN0IHRoZSBleGVjdXRp b24gdG8gc3VjaCBhIG5hcnJvdyBzY29wZS4gV2hhdCBhYm91dCB0aGUgRUEgZm9ybWF0IGxpc3Rl ZCBiZWxvdz8NCg0KICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAg IDIgICAgICAgICAgICAgICAgICAgMw0KICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogIHwgICAgICAg ICAgICBMZW5ndGggICAgICAgICAgICAgfCBDbGFzcy1OdW0oMTk5KXwgIEMtVHlwZSAoVEJBKSB8 DQogICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQogIHwgICAgICAgQXNzb2NpYXRpb24gVHlwZSAgICAgICAgfCAgICAgICBB c3NvY2lhdGlvbiBJRCAgICAgICAgICB8DQogICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogIHwgICAgICAgICAgICAgICAg ICAgIElQdjQgQXNzb2NpYXRpb24gU291cmNlICAgICAgICAgICAgICAgICAgICB8DQogICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogIHwgICAgICAgICAgICAgICAgICAgR2xvYmFsIEFzc29jaWF0aW9uIFNvdXJjZSAgICAg ICAgICAgICAgICAgICB8DQogICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogIHxFeHRlbmRlZCBBc3NvY2lhdGlvbiBGbGFn cy4gICAgfEV4dGVuZGVkIEFzc29jaWF0aW9uIElEIC4uLiAgICB8DQogICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAg fC4uLi4oY29udGludWUpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDoNCiAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCg0KPFJHPiBEbyB5b3UgbWVhbiB0byBoYXZlIGV4dGVuZGVk IGFzc29jaWF0aW9uIElEIGFzIHR1bm5lbCBJRCAoMTYgYml0cykgKyBJUCBhZGRyZXNzICgzMiBi aXRzKSBpbiB0aGlzIG9iamVjdD8NClBsZWFzZSBzZWUgaW5saW5lIGJlbG93Li48UkcxPi4uDQoN CjxmZWk+DQpOby4gSSB3YW50IHRvIHNheSB0aGF0IHRoaXMgZm9ybWF0IG9mIEVBIG9iamVjdHMg Y2FuIGFjY29tb2RhdGUgbW9yZSBraW5kcyBvZiBpbXBsZW1lbnRhdGlvbnMuIExpa2UNCg0KMSlB c3NvY2lhdGlvbiBJRDogdXNlciBwcm92aXNpb25lZCBpZGVudGlhbCB2YWx1ZTsgQXNzb2NpYXRp b24gU291cmNlOiB0aGUgbG93ZSBpcCBhZGRyZXNzOyBFQSBJRDogdGhlIGhpZ2hlciBJUCBhZGRy ZXNzLiBBcyB5b3Ugc3VnZ2VzdGVkDQoNCjIpQXNzb2NpYXRpb24gSUQ6IHR1bm5lbCBJRCBvciB1 c2VyIHByb3Zpc2lvbmVkIHZhbHVlOyBBc3NvY2lhdGlvbiBTb3VyY2U6VHVubmVsIHNlbmRlciBh ZGRyZXNzIG9yIHVzZXIgcHJvdmlzaW9uZWQ7IEVBIElEOiBiZSBlbXB0eSBvciBMU1AgSUQgb3Ig YW55IG90aGVyIGluZm9ybWF0aW9uLg0KDQozKVRoZSBwb3RlbnRpYWwgb3RoZXIgaW1wbGVtZW50 YXRpb25zLi4uDQoNCklNSE8sIHRoZSBFQSBJRCBjYW4gYmUgSVAgYWRkcmVzcyBvciBhbnkgb3Ro ZXIgdmFsdWVzIGluIHRoZSBjb250ZXh0IG9mIEFzc29jaWF0aW9uIFNvdXJjZSBwbHVzIEFzc29j aWF0aW9uIElELCB3aGljaCBpcyBiYWNrd2FyZCBjb21wYXRpYmxlLg0KDQo8L2ZlaT4NCjxSRzM+ IE9rLCB3ZSBwcm9iYWJseSBzaG91bGQgYWRkIHVzZSBjYXNlcyBmb3IgdmFyaW91cyBtZXRob2Rz LiBJIGNhbiBzZWUgbWV0aG9kIDEgYmVpbmcgdXNlZCBmb3Igc2V0dGluZyB1cCBiaWRpcmVjdGlv bmFsIExTUHMgYnV0IEkgYW0gbm90IHN1cmUgYWJvdXQgbWV0aG9kIDIgZm9yIGV4YW1wbGUuIE9u ZSB3b3JyeSBpcyB0aGF0IGRpZmZlcmVudCBtZXRob2RzIGNhbiBsZWFkIHRvIGludGVyb3AgaXNz dWVzIGlmIG9uZSB2ZW5kb3IgaW1wbGVtZW50cyBtZXRob2QgMSBhbmQgc2Vjb25kIHZlbmRvciBt ZXRob2QgMi4NCkFzc29jaWF0aW9uIG9iamVjdCBpcyBiZWluZyB1c2VkIGZvciBkaWZmZXJlbnQg YXNzb2NpYXRpb24gdHlwZXMgKFJGQyA0ODcyOiB0eXBlIDE6IFJlY292ZXJ5KSwgKFJGQyA0ODcz LSB0eXBlIDI6IFJlc291cmNlIHNoYXJpbmcpLCBldGMuIGFuZCB0aGVzZSBSRkNzIGRlZmluZSBz cGVjaWZpYyBwcm9jZWR1cmVzIGZvciB0aGUgZ2l2ZW4gYXNzb2NpYXRpb24gdHlwZS4gU28gSU1I TywgaXQgbWF5IGJlIG9rIHRvIGRlZmluZSBhIHN0cmljdGVyIHByb2NlZHVyZSBmb3IgcG9wdWxh dGluZyBleHQgYXNzb2NpYXRpb24gb2JqZWN0IGZvciB0aGUgbmV3IEJpZGlyZWN0aW9uYWwgTFNQ cyBhc3NvY2lhdGlvbiB0eXBlLg0KDQpUaGFua3MsDQpSYWtlc2gNCg0KDQo= --_000_B7D2A316AA32B6469D9670B6A81B7C24066C8Fxmbalnx07ciscocom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Fei,=

 <= /p>

Thanks for your insight. = I understand what you are saying, please see inline..<RG5>=

 <= /p>

From: zhang.fe= i3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]
Sent: Wednesday, August 08, 2012 3:41 AM
To: Rakesh Gandhi (rgandhi)
Cc: CCAMP; Eric Osborne (eosborne); jiang.weilian@zte.com.cn; jingrq= @ctbri.com.cn; Robert Sawaya (rsawaya); George Swallow (swallow); yang.fan5= @zte.com.cn
Subject: RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associa= ted-lsp-03

 


Thank you Rakesh for your prompt response :)

Snipped the agreeable parts, see in line with <fei1>

<RG4> I agree that if both vendors impleme= nt say method 1 or both vendors implement say method 2 then they would inte= roperate, and  ext EA objects are the same. But method 1 and method 2 may not interoperate together.  Not sure if we want to have = a separate flag to indicate if ext association object is populated with met= hod 1 or 2 to cover this case?   It is fine to have more than one meth= od in the draft for flexibility and future use but good to elaborate on the possible use case if we know of any.

<fei1> IMHO, the only difference is the unique representat= ion of the association, using SA+association-id(ID is unique under SA )= or SA+DA+association-id (ID is unique under the combination of SA and DA) which is more stricter. I agree that we had better adopting one of= them because of the interop issue.

Let's consider the auto-mesh tunnels which you provided in the p= revious email.  "<RG> There i= s a use case for auto-mesh tunnels where source node may originate tunnels to many destinations using the same association source and association-id.= In this case, different values for extended association ID provide unique = extended association object."
Can you clarify what is the benefits of using the same associati= on-id (different association-id works well also), so that we can persuade t= he WG that this strict implementation is a better choice and add the usecase if necessary.

<RG5> For single sided provisioning, where remote end simply co= pies the received Ext Association Object, association-id can be unique for SA. But for double sided provisioning, where association-id is = used to glue the two LSPs =A8C forward and reverse direction LSPs, associat= ion-id is used to identify the matching LSPs and hence need to be unique pe= r SA+DA.

Similar to static tunnels, auto-tunnel mesh can also be provisioned u= sing identical association-ids on both sides. This way same method works for both.

Thanks,

Rakesh


Or any other usecases?

Please do not hesitate to let me know if I have a mistake

Best regards

Fei

"Rakesh Gandhi (rgandhi)" <= ;rgandhi@cisco.com><= span style=3D"font-size:7.5pt;font-family:"Arial","sans-seri= f"">

2012-08-03 20:11

=CA=D5=BC=FE=C8=CB<= /p>

"zhang.fei3@zte.com.cn" <zhang.fei3@zte.com.cn>

=B3=AD=CB=CD

CCAMP <ccamp@ietf.org>, "Eric Osborne (eosborne)" <eosborne@cisco.com>, "jiang.weilian@zte.com.cn" <jiang.weilian@zte.com.cn>, "jingrq@ctbri.com.cn" <jingrq@ctbri.com.cn&= gt;, "Robert Sawaya (rsawaya)" <rsawaya@cisco.com>, "George Swallow (swallow)" <swallow@cisco.com>, "yang.fan5@zte.com.cn" <yang.fan5@zte.com.cn>

=D6=F7=CC=E2

RE: Comments on draft-ietf-ccamp-mpls-tp-r= svpte-ext-associated-lsp-03

 




Thanks Fei. We are almost there. Please see inli= ne..<RG4>.
 
From: zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]
Sent: Friday, August 03, 2012 5:16 AM
To: Rakesh Gandhi (rgandhi)
Cc: CCAMP; Eric Osborne (eosborne); jiang.weilian@zte.com.cn; jingrq= @ctbri.com.cn; Robert Sawaya (rsawaya); George Swallow (swallow); yang.fan5@zte.com.cn
Subject: RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated= -lsp-03
 =

Hi Rakesh

Snipped the other parts for easy reading, sorry for the delayed response <= br>
<RG3> There are applications that require co-routed LSPs. So I think = we should have a flag to indicate that LSPs must be co-routed, else node wi= ll send a path error for example if request cannot be met.  I agree wi= th you about complexity with double sided provisioning model though.

<fei> Since you believe that a common mechanism used for the non-coro= uted and corouted cases is useful, we will add the texts in the next versio= n.
<RG4> This is great. Thanks.


<RG3> Ok, we probably should add use cases for various methods. I can= see method 1 being used for setting up bidirectional LSPs but I am not sur= e about method 2 for example. One worry is that different methods can lead = to interop issues if one vendor implements method 1 and second vendor method 2. =
Association object is being used for different association types (RFC 4872:= type 1: Recovery), (RFC 4873- type 2: Resource sharing), etc. and these RF= Cs define specific procedures for the given association type. So IMHO, it m= ay be ok to define a stricter procedure for populating ext association object for the new Bidirectional LSPs assoc= iation type.

<fei> Method 2 works well, and the only difference is t how to repres= ent the global unique identifier. For the association is based on the full = match of the EA objects, the EA object is just copied from the path message= into another path message in single sided provisioning model. As to the doubled sided provisioning model, the EA obj= ects is also the same. IMHO, there is no interop issues, or do I have some = misunderstanding?

Yeah, we can define a stricter prodedure, I am not sure this is a good way = in standard, need more feedback from the WG.
<RG4> I agree that if both vendors impleme= nt say method 1 or both vendors implement say method 2 then they would inte= roperate, and  ext EA objects are the same. But method 1 and method 2 may not interoperate together.  Not sure if we want to have = a separate flag to indicate if ext association object is populated with met= hod 1 or 2 to cover this case?   It is fine to have more than one meth= od in the draft for flexibility and future use but good to elaborate on the possible use case if we know of any.
Thanks,
Rakesh


Cheer

Fei

"Rakesh Gandhi (rgandhi)" <= ;rgandhi@cisco= .com>

2012-08-01 01:24

 

=CA=D5=BC=FE=C8=CB<= /p>

"zhang.fei3@zte.com.cn" <zhang.fei3@z= te.com.cn>

=B3=AD=CB=CD

"Eric Osborne (eosborne)" <eosborne@cisco.com>, "jiang.w= eilian@zte.com.cn" <jiang.weilian@zte.com.cn>, "jingrq@ctbri= .com.cn" <jingrq@ctbri.com.cn>, "Robert Sawaya (rsawaya)" <rsawaya@cisco.com>, "Georg= e Swallow (swallow)" <<= span style=3D"font-size:7.5pt;font-family:"Arial","sans-seri= f"">swallow@cisco.com>, "yang.fan5@z= te.com.cn" <yang.fan5@zte.com.cn>, CCAMP <ccamp@ietf.or= g>

=D6=F7=CC=E2

RE: Comments on draft-ietf-ccamp-mpls-tp-r= svpte-ext-associated-lsp-03


 =

 





Hi Fei,
 
Thanks for your kind reply. Please see inline..<RG3>..
 
<Snipped email to focus on open items>
 
 
From: zhang.fei3@zte.= com.cn [mailt= o:zhang.fei3@zte.com.cn]
Sent: Monday, July 30, 2012 10:04 PM
To: Rakesh Gandhi (rgandhi)
Cc: Eric Osborne (eosborne); jiang.weilian@zte.com.cn; jingrq@ctbri.com.= cn; Robert Sawaya (rsawaya); George Swallow (swallow= ); yang.fan5@zte.co= m.cn; CCAMP
Subject: RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated= -lsp-03

Thank you Rakesh for sharing your idea, I think we are roughly in agreement= and need to hear more voices from the WG. :)

See inline <fei></fei>

Best

Fei

2) Define one flag for co-routed or non-corouted. If the co-routed bidir is= the default behavior, why not using the procedure defined in RFC3473? I am= afraid it is hard
to persuade the WG to do so. Maybe the better way is that non-corouted bidi= r is the default, and the set of the co-routed flag only means that it is r= ecommended, not mandatory, the checking whether the LSP is co-routed can be= done by comparing the RRO objects. What is your opinion?
<RG1> It is fine to have non co-routed as default. RFC 3473 is a GMPL= S signaling procedure. It may not be optimal  to have two different si= gnaling procedures, one for non co-routed (ext associated object) and one f= or co-routed (RFC 3473) procedures. By adding a flag for co-routed, same signaling (ext associated object) can be used f= or both which is nice. We believe comparing of RRO can be misleading becaus= e two LSPs can be on the same path even though provisioned to be non co-rou= ted.

<fei>
Sorry that what I suggested maybe mislead you, the following descripitons a= re more accurate. :)
1)The default behavior (non-corouted) means that it is not required to be c= o-routed. In other words, it is also OK that the two paths are along the sa= me path
 
.
<RG3> Agree.

2)The flag set means that co-routed is recommended. In other words, the rev= erse LSP SHOULD be established in the same path as much as possible. If the= flag set means
that co-routed is mandatory,the procedures will be very complex in double s= ided provisioning model.
</fei>
<RG3> There are applications that require co-routed LSPs. So I think = we should have a flag to indicate that LSPs must be co-routed, else node wi= ll send a path error for example if request cannot be met.  I agree wi= th you about complexity with double sided provisioning model though.


3)As to the tuple of <lower ip address, high ip address, association id&= gt;, yeah, it is one kind of implementation, but there are potential some o= ther realizations, like using one of the router id plus the tunnel id. I th= ink we had better not restrict the execution to such a narrow scope. What about the EA format listed below?

      0               &nb= sp;   1                  = 2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
  +-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
  |            Length     &nbs= p;       | Class-Num(199)|  C-Type (TBA) |
  +-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
  |       Association Type        |=       Association ID          |   +-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
  |                   &nb= sp;IPv4 Association Source              =      |
  +-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
  |                   Glo= bal Association Source               &nb= sp;   |
  +-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
  |Extended Association Flags.    |Extended Association ID .= ..    |
   +-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |....(continue)             &nbs= p;                     &n= bsp;             :
  +-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+

<RG> Do you mean to have extended association ID as tunnel ID (16 bit= s) + IP address (32 bits) in this object?
Please see inline below..<RG1>..

<fei>
No. I want to say that this format of EA objects can accomodate more kinds = of implementations. Like

1)Association ID: user provisioned idential value; Association Source: the = lowe ip address; EA ID: the higher IP address. As you suggested

2)Association ID: tunnel ID or user provisioned value; Association Source:T= unnel sender address or user provisioned; EA ID: be empty or LSP ID or any = other information.

3)The potential other implementations...

IMHO, the EA ID can be IP address or any other values in the context of Ass= ociation Source plus Association ID, which is backward compatible.

</fei>
<RG3> Ok, we probably should add use cases for various methods. I can= see method 1 being used for setting up bidirectional LSPs but I am not sur= e about method 2 for example. One worry is that different methods can lead = to interop issues if one vendor implements method 1 and second vendor method 2. =
Association object is being used for different association types (RFC 4872:= type 1: Recovery), (RFC 4873- type 2: Resource sharing), etc. and these RF= Cs define specific procedures for the given association type. So IMHO, it m= ay be ok to define a stricter procedure for populating ext association object for the new Bidirectional LSPs assoc= iation type.
 
Thanks,
Rakesh

&nb= sp;

--_000_B7D2A316AA32B6469D9670B6A81B7C24066C8Fxmbalnx07ciscocom_-- From lberger@labn.net Wed Aug 8 06:29:46 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E162021F8550 for ; Wed, 8 Aug 2012 06:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.343 X-Spam-Level: X-Spam-Status: No, score=-98.343 tagged_above=-999 required=5 tests=[AWL=1.818, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4J9Edf87KQ+K for ; Wed, 8 Aug 2012 06:29:46 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 5AA2F21F8543 for ; Wed, 8 Aug 2012 06:29:46 -0700 (PDT) Received: (qmail 17339 invoked by uid 0); 8 Aug 2012 13:29:45 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 8 Aug 2012 13:29:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=rXMzPJebqICwyraHQxWd2NgU4myPhJ3GggxnNolWdbI=; b=1BNl3oCusvjGtvnqgmTi46vDUlsefijZrt5JygO/fx0E7qDXbrMPZkElbf6hOz3dDVIlF2hZQmEWH2u+zftwGj2FPdsT26t523p9Ih2Kptp4AwFi9UBXkTvQusrXk8wc; Received: from box313.bluehost.com ([69.89.31.113]:46594 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Sz6KX-00024G-EQ for ccamp@ietf.org; Wed, 08 Aug 2012 07:29:45 -0600 Message-ID: <502269C8.8020607@labn.net> Date: Wed, 08 Aug 2012 09:29:44 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] comment on compatibility sections of g709v3 drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 13:29:47 -0000 Authors/All, I mentioned in Vancouver, the current "compatibility" text in the G.709-related framework, routing, and signaling WG drafts place more complex requirements on new implementations than is typical for CCAMP/GMPLS. With chair hat off, I'd like to propose the following approach: For routing: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-02#section-6 1. Nodes supporting [ospf-g709v3] MAY support [RFC4328] 2. When nodes support both advertisement methods, implementations MUST support the configuration of which advertisement method is followed. The choice of which is used is based on policy and is out of scope of the document. 3. This enables nodes following each method to identify similar supporting nodes and compute paths using only the appropriate nodes. For signaling: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-03#section-9 4. Nodes supporting [signaling-g709v3] SHOULD support [ospf-g709v3]. 5. Nodes supporting [signaling-g709v3] MAY support [RFC4328] signaling. 6. A node supporting both sets of procedures is NOT REQUIRED to signal an LSP using both procedures, i.e., to act as a signaling version translator. 7. Ingress nodes that support both sets of procedures MAY select which set of procedures to follow based on routing information or local policy. 8. Include informative comment: Per [RFC3473], nodes that do don't support [signaling-g709v3] will generate a PathErr message, with a "Routing problem/Unsupported Encoding" indication. Also, the background narrative really belongs in the framework draft. The framework will need to be reflected to match both changes once agreed to . See http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-08#section-5.5 Comments? Also, I'm happy for the authors to wordsmith (once there is consensus) or can provide specific text proposals if needed. Lou (as WG participant) From lberger@labn.net Wed Aug 8 07:26:29 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62DA21F8653 for ; Wed, 8 Aug 2012 07:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.389 X-Spam-Level: X-Spam-Status: No, score=-98.389 tagged_above=-999 required=5 tests=[AWL=1.772, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I80UGk3cLJE for ; Wed, 8 Aug 2012 07:26:28 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 4B6FF21F8647 for ; Wed, 8 Aug 2012 07:26:28 -0700 (PDT) Received: (qmail 29152 invoked by uid 0); 8 Aug 2012 14:26:27 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 8 Aug 2012 14:26:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=W8pTnxV4nGVMfETUJkEiHWbXJoniUCsekD8maPpjoFs=; b=VKTGxI88c9PGAmlO4qzf9NAbTnS5AX7y26p+SZ+rHQz1M6FBwTbrxWPqNLXQPNy1SsvyjGDWS1+4lhBbhgnHA42+P8i4nRSccHAftDOSsdsR9xbG32r8eo9AMB2v178X; Received: from box313.bluehost.com ([69.89.31.113]:52500 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Sz7DP-0007v6-Ba; Wed, 08 Aug 2012 08:26:27 -0600 Message-ID: <50227712.4010203@labn.net> Date: Wed, 08 Aug 2012 10:26:26 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <021a01cd7536$2104aa10$630dfe30$@olddog.co.uk> In-Reply-To: <021a01cd7536$2104aa10$630dfe30$@olddog.co.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-ccamp-assoc-ext.all@tools.ietf.org, 'CCAMP' Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 14:26:29 -0000 Adrian, Thank you for the review. Please see below for in-line responses. Lou (as co-author) On 8/8/2012 3:19 AM, Adrian Farrel wrote: > Hi, > > I have done my usual AD review of this document prior to issuing IETF > last call. The purpose of my review is to catch any issues that might > come up in last call or IESG evaluation, and so smooth the path of the > document. > > This seems to be a well-written I-D, thanks. I have just a few small > points that are mainly stylistic. A quick respin should address them. > I start with one fundamental question that I hope can be answered by > email. > > Thanks, > Adrian > > === > > To start with, a key question: > > Why does the working group want to publish this as an RFC when there > is no immediate intention to implement for any of the many scenarios > described in the document? > > Will this become just another Standards Track RFC that gathers dust > and obfuscates the real protocol specs, or is there good reason to > publish it? > The document was motivated to support applications such as defined in draft-ietf-ccamp-rsvp-resource-sharing (whose authors say they intend to revive this work now that the foundation work has reach maturity.) > --- > > I can see how this updates 4872. > > I am not convinced about this being an update to 2205, 3209 and 3473. only as much as it provides additional capability to those RFCs, not that it modifies their basic behavior. The point of listing them was to make it clear that this draft's scope is beyond rfc4872 / recovery. Perhaps it's sufficient to put this in the narrative and not as part of the updates field. > > Let me ask the question as follows: Is this document needed in order to > produce a conformant implementation of RFC 2205 RSVP? No. > In other words: is > it your intention that all new implementations of RSVP MUST include an > implementation of this document? Absolutely not the intent. > > If the document does make the updates stated, it would be good if some > part of the document (maybe a new section, maybe just the Introduction) > contained text that described what has been updated. The relevant text is in section 3. If this isn't sufficient can you propose some alternate/additional language? The remainder of this section defines the general rules to be followed when processing ASSOCIATION objects. Object usage in both Path and Resv messages is discussed. The usage applies equally to GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205], [RFC2207], [RFC3175] and [RFC4860]. > > Does Section 6.2 imply an update to RFC 4873? Perhaps, it extends the definition provided in 4873 to non-recovery application. implementations of rfc4873 aren't impacted by 3.3/6.2. So for this reference, I don't think so. That said, 4873 does make use of the association object defined in 4872. 4873 implementations can certainly make use of the Extended ASSOCIATION Objects (section 4), but we didn't list an update to 4873 as 4873 references 4872 for the definition of ASSOCIATION Objects. So we thought the 4872 update indication was sufficient. > > --- > > Section 1 > > Some ambiguity, since it looks like the extension is to recovery > contexts other than GMPLS! > > OLD > This document expands the possible usage of the ASSOCIATION object to > non-GMPLS recovery contexts. > NEW > This document expands the possible usage of the ASSOCIATION object to > contexts other than GMPLS recovery. > END I agree -- looking at it again after all this time. How about (in multiple places) OLD non-GMPLS recovery NEW non-GMPLS and non-recovery > > --- > > Section 1 Voice Call Waiting > > However, > there is no way in RSVP today to share the resources between the > A->B and A->C subflows of the call since by definition the RSVP > reservations for these subflows must have different IP addresses > in the SESSION objects. > > Since you are defining such a mechanism, "there is no way today" is not > true. I suggest... > > Since, by definition, the RSVP reservations for the subflows A->B > and A->C of the call must have different IP addresses in the > SESSION objects, this document defines a new mechanism to > associate the subflows and allow them to share resources. looks good to me. (assuming my co-authors don't object.) > > Similarly... > > OLD > o Voice Shared Line: > A single number that rings multiple endpoints (which may be > geographically diverse), such as phone lines on a manager's desk > and their assistant. A VoIP system that models these calls as > multiple P2P unicast pre-ring reservations would result in > significantly over-counting bandwidth on shared links, since > today unicast reservations to different endpoints cannot share > bandwidth. > NEW > o Voice Shared Line: > A voice shared line is a single number that rings multiple > endpoints (which may be geographically diverse), such as phone > lines to a manager's desk and to their assistant. A VoIP system > that models these calls as multiple P2P unicast pre-ring > reservations would result in significantly over-counting > bandwidth on shared links, since RSVP unicast reservations to > different endpoints cannot share bandwidth. So a new mechanism > is defined in this document allowing separate unicast > reservations to be associated and share resources. > END okay (assuming my co-authors don't object.) > > And... > > OLD > o Symmetric NAT: > RSVP permits sharing of resources between multiple flows > addressed to the same destination D, even from different senders > S1 and S2. However, if D is behind a NAT operating in symmetric > mode [RFC5389], it is possible that the destination port of the > flows S1->D and S2->D may be different outside the NAT. In this > case, these flows cannot share resources using RSVP today, since > the SESSION objects for these two flows outside the NAT would > have different ports. > NEW > o Symmetric NAT: > RSVP permits sharing of resources between multiple flows > addressed to the same destination D, even from different senders > S1 and S2. However, if D is behind a NAT operating in symmetric > mode [RFC5389], it is possible that the destination port of the > flows S1->D and S2->D may be different outside the NAT. In this > case, these flows cannot share resources using RSVP, since the > SESSION objects for these two flows outside the NAT have > different ports. This document defines a new mechanisms to > associate these flows and allow them to share resources. > END okay (assuming my co-authors don't object.) > > --- > > Globally... > > s/extended ASSOCIATION/Extended ASSOCIATION/ sure > > --- > > Section 1 > > OLD > This document also defines the extended ASSOCIATION objects which can > be used in the context of Transport Profile of Multiprotocol Label > Switching (MPLS-TP). Although, the scope of the extended ASSOCIATION > objects is not limited to MPLS-TP. > NEW > This document also defines the Extended ASSOCIATION objects which can > be used in the context of the Transport Profile of Multiprotocol > Label Switching (MPLS-TP). The scope of the Extended ASSOCIATION > objects is not limited to MPLS-TP. > END > sure. > --- > > As with the previous ambiguity... > > OLD > 3. Non-GMPLS Recovery Usage > NEW > 3. Uses other Than GMPLS Recovery > END > propose same change as above: Non-GMPLS and Non-Recovery Usage > --- > > Section 3.1 > > s/defined generic/defines generic/ thanks. > > --- > > Section 3.1.2 > > A node that wishes to > allow downstream nodes to associate Path state across RSVP sessions > MUST include an ASSOCIATION object in the outgoing Path messages > corresponding to the RSVP sessions to be associated. > > Yuck! > > Are the sessions to be associated in the outgoing Path messages or the > Association object, or both. Actually, I don't think this needs a MUST, > but can be converted to descriptive text as follows. > Agreed. This sentence is clearly subject to misinterpretation and must be fixed! > A node that wishes to allow downstream nodes to associate Path state > across RSVP sessions sends a Path message corresponding to one RSVP > session and includes in that message an ASSOCIATION object that > indicates the associated RSVP sessions. I think this actually doesn't match our intent. See below for proposed wording as I think it's easier to parse the sentences changes/together. > > > Then you have... > > In the absence > of Association Type-specific rules for identifying association, the > included ASSOCIATION objects MUST be identical across all associated > sessions. > > I know what you mean, but what you have said would require that a Path > message must contain an Association object that refers to itself. I > think what you need has to be more verbose to be accurate. > > In the absence > of Association Type-specific rules for identifying association, each > Path message for a session in a set of associated sessions MUST > include an ASSOCIATION object that indicates all the other sessions > in the set. how about: To indicate association between multiple sessions, an appropriate ASSOCIATION object MUST be included in the outgoing Path messages corresponding to each of the associated sessions. In the absence of Association Type-specific rules for identifying association, the included ASSOCIATION object MUST be identical. > > --- > > 3.1.1 vs 3.2.1 > > In 3.1.1 you have... > Relative ordering of ASSOCIATION objects of the same > type SHOULD be preserved by transit nodes. > note this is path processing, > In 3.2.1 you have... > Relative ordering of ASSOCIATION objects of the same > type MUST be preserved by transit nodes. Association type specific > ordering requirements MAY be defined in the future. > Note this is resv processing. > 1. Why is 3.1.1 SHOULD and 3.1.2 MUST? I'm not sure, other than 3.1.2 is new so there's no chance of placing a new requirement on implementations of 4872&3 (which only use association objects in Path messages.) I'm fine with should for both. Co-authors? > 2. Why does 3.2.1 consider association type-specific rules, but these > are not in 3.1.1? 3.1.1 relates to path messages and we didn't want to impose new requirements on implementations of 4872&3. > 3. s/type specific/Type-specific/ sure. > 4. Why "MAY" not "may"? over zealousness. i.e., your right! > > --- > > 3.2.2 > > s/This section apply/This section applies/ Thanks. > > --- > > 3.3.1 > > Once an association is identified, resources SHOULD be shared across > the identified sessions. > > This use of "SHOULD" begs the question: under what circumstances MAY > resource sharing not be applied? actual resource allocation is really an implementation choice and different internal implementation choices. We didn't want to overly constrain an implementation. "is expected" is really what we mean, but how do you say this in 2119 language? > > --- > > Globally... > > Please be consistent with: > - Association ID > - association-id okay. > > --- > > Section 4.1 > > Global Association Source: 4 bytes > > This field contains a value that is a unique global identifier. > This field MAY contain the 2-octet or 4-octet value of the > provider's Autonomous System Number (ASN). It is expected that > the global identifier will be derived from the globally unique ASN > of the autonomous system hosting the Association Source. The > special value of zero (0) indicates that no global identifier is > present. Note that a Global Association Source of zero SHOULD be > limited to entities contained within a single operator. > > Given the statement that the content is globally unique, I don't think > there is room for you to pontificate about how this field might be > filled. You need to make a definitive statement. Otherwise the content > cannot be guaranteed to be globally unique (unless you envisage a > central registration system!). Humm this text is actually lifted from 6370 which says: Quoting from RFC 5003, Section 3.2: The global ID can contain the 2-octet or 4-octet value of the provider's Autonomous System Number (ASN). It is expected that the global ID will be derived from the globally unique ASN of the autonomous system hosting the PEs containing the actual AIIs. The presence of a global ID based on the operator's ASN ensures that the AII will be globally unique. How about: This field contains a value that is a unique global identifier. This field MAY contain the Global_ID as defined in [RFC6370]. The special value of zero (0) indicates that no global identifier is present. Note that a Global Association Source of zero SHOULD be limited to entities contained within a single operator. > > --- > > Section 4.1 > > Extended Association ID: variable, 4-byte aligned > > This field contains data that is additional information to support > unique identification. The length and contents of this field is > determined by the Association Source. This field MAY be omitted, > i.e., have a zero length. This field MUST be padded with zeros > (0s) to ensure 32-bit alignment. > > This is confusing. I think that the length of the field is chosen by the > Association source and determined by the Length field of the Association > object. > > But your text implies that the contents of the field may be different > from a four octet quantity. Since you have not included a separate > length indicator, this cannot be. The object length must always be a > multiple of 4 (says RFC 2205) and so there is no difference between a > zero padded field and a field where the zeros have meaning. > > You *could* say that the length of this field is Association Type- > specific, but that would be ugly. How about: Extended Association ID: variable, 4-byte aligned This field contains data that is additional information to support unique identification. The length and contents of this field is determined by the Association Source. The length of this field is derive from the object Length field and as such MUST have a zero length or be 4-byte aligned. A zero length indicates that this field is omitted. > > --- > > > While you're at it, please note that draft-ietf-ccamp-assoc-info has > been published as RFC 6689 Sure. Thanks for the comments. > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From flefauch@cisco.com Wed Aug 8 09:02:25 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5959121F86F0 for ; Wed, 8 Aug 2012 09:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.352 X-Spam-Level: X-Spam-Status: No, score=-10.352 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxfmuiBNxe+o for ; Wed, 8 Aug 2012 09:02:24 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E53C921F86EB for ; Wed, 8 Aug 2012 09:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20022; q=dns/txt; s=iport; t=1344441744; x=1345651344; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xCN/w47AJHb7q3XRaWG8zalntCmaa980XmYefGAjst4=; b=QX4TjcPV8z0qLlqvULAoVTsSTF4DT7uVkXF621zxtQGoFNLNSKrhIn+H KYxSyD4TRXyMmr7bziNq8LgGBLHwR/eFN0buyu592tL+xolNHSKdQmJ6x dgynp1+vrFVGU6Jy0ImmUYoGaOiJN28apYZ8JHsHwCLCw1JuCPzOXXR2p I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAD+NIlCtJV2a/2dsb2JhbABFuVyBB4IhAQEEEgEUUhACAQgOODIlAQEEDieHa5p8oD6REmADlUmOKYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,733,1336348800"; d="scan'208,217";a="106631874" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 08 Aug 2012 16:02:23 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q78G2NDf006885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 16:02:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Wed, 8 Aug 2012 11:02:23 -0500 From: "Francois Le Faucheur (flefauch)" To: Lou Berger Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext Thread-Index: Ac11NY6nevEXepS5RqKUu/wkiJbhHgAZiUcAAANRhIA= Date: Wed, 8 Aug 2012 16:02:21 +0000 Message-ID: <67596B46-B753-46DC-93B8-8297EFFAF5DD@cisco.com> References: <021a01cd7536$2104aa10$630dfe30$@olddog.co.uk> <50227712.4010203@labn.net> In-Reply-To: <50227712.4010203@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.197] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19092.004 x-tm-as-result: No--45.211800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_67596B46B75346DC93B88297EFFAF5DDciscocom_" MIME-Version: 1.0 Cc: CCAMP , "" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:02:25 -0000 --_000_67596B46B75346DC93B88297EFFAF5DDciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adrian, Lou, Additional thoughts below: =3D=3D=3D To start with, a key question: Why does the working group want to publish this as an RFC when there is no immediate intention to implement for any of the many scenarios described in the document? Implementation for some of the discussed scenarios is being considered. Thi= s RFC will allow such implementation to be open for interoperability. In other words: is it your intention that all new implementations of RSVP MUST include an implementation of this document? Absolutely not the intent. Agree with Lou. Not the intent. So in that sense, probably not an "update" = to 2205. --- Section 1 Voice Call Waiting However, there is no way in RSVP today to share the resources between the A->B and A->C subflows of the call since by definition the RSVP reservations for these subflows must have different IP addresses in the SESSION objects. Since you are defining such a mechanism, "there is no way today" is not true. I suggest... Since, by definition, the RSVP reservations for the subflows A->B and A->C of the call must have different IP addresses in the SESSION objects, this document defines a new mechanism to associate the subflows and allow them to share resources. looks good to me. (assuming my co-authors don't object.) Works for me. Similarly... OLD o Voice Shared Line: A single number that rings multiple endpoints (which may be geographically diverse), such as phone lines on a manager's desk and their assistant. A VoIP system that models these calls as multiple P2P unicast pre-ring reservations would result in significantly over-counting bandwidth on shared links, since today unicast reservations to different endpoints cannot share bandwidth. NEW o Voice Shared Line: A voice shared line is a single number that rings multiple endpoints (which may be geographically diverse), such as phone lines to a manager's desk and to their assistant. A VoIP system that models these calls as multiple P2P unicast pre-ring reservations would result in significantly over-counting bandwidth on shared links, since RSVP unicast reservations to different endpoints cannot share bandwidth. So a new mechanism is defined in this document allowing separate unicast reservations to be associated and share resources. END okay (assuming my co-authors don't object.) Works for me. And... OLD o Symmetric NAT: RSVP permits sharing of resources between multiple flows addressed to the same destination D, even from different senders S1 and S2. However, if D is behind a NAT operating in symmetric mode [RFC5389], it is possible that the destination port of the flows S1->D and S2->D may be different outside the NAT. In this case, these flows cannot share resources using RSVP today, since the SESSION objects for these two flows outside the NAT would have different ports. NEW o Symmetric NAT: RSVP permits sharing of resources between multiple flows addressed to the same destination D, even from different senders S1 and S2. However, if D is behind a NAT operating in symmetric mode [RFC5389], it is possible that the destination port of the flows S1->D and S2->D may be different outside the NAT. In this case, these flows cannot share resources using RSVP, since the SESSION objects for these two flows outside the NAT have different ports. This document defines a new mechanisms to associate these flows and allow them to share resources. END okay (assuming my co-authors don't object.) Works for me. 3.1.1 vs 3.2.1 In 3.1.1 you have... Relative ordering of ASSOCIATION objects of the same type SHOULD be preserved by transit nodes. note this is path processing, In 3.2.1 you have... Relative ordering of ASSOCIATION objects of the same type MUST be preserved by transit nodes. Association type specific ordering requirements MAY be defined in the future. Note this is resv processing. 1. Why is 3.1.1 SHOULD and 3.1.2 MUST? I'm not sure, other than 3.1.2 is new so there's no chance of placing a new requirement on implementations of 4872&3 (which only use association objects in Path messages.) I believe the idea is that while ordering is currently irrelevant, it might= be relevant in some future application so we may as well avoid re-ordering= when it is easy (i.e. new implementation). Hence the logic of SHOULD & MU= ST. I am happy either way SHOULD/MUST or SHOULD/SHOULD. I'm fine with should for both. Co-authors? 4. Why "MAY" not "may"? over zealousness. i.e., your right! or maybe something like : "Note that association type specific ordering requirements could be defined= in the future." --- 3.3.1 Once an association is identified, resources SHOULD be shared across the identified sessions. This use of "SHOULD" begs the question: under what circumstances MAY resource sharing not be applied? actual resource allocation is really an implementation choice and different internal implementation choices. We didn't want to overly constrain an implementation. "is expected" is really what we mean, but how do you say this in 2119 language? 2205 uses the term "Admission control", so would it work if we said: " Once an association is identified, resources MUST be considered as shared a= cross the identified sessions by the admission control function. " Francois --_000_67596B46B75346DC93B88297EFFAF5DDciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <06091B5897F93B4B973B360CF47EA881@cisco.com> Content-Transfer-Encoding: quoted-printable Adrian, Lou,

Additional thoughts below:

=3D=3D=3D

To start with, a key question:

Why does the working group want to publish this a= s an RFC when there
is no immediate intention to implement for any of= the many scenarios
described in the document?


Implementation for some of the discussed scenarios is being considered= . This RFC will allow such implementation to be open for interoperability.<= /div>


In other words: is
it your intention that all new implementations of= RSVP MUST include an
implementation of this document?

Absolutely not the intent.

Agree with Lou. Not the intent. So in that sense, probably not an &quo= t;update" to 2205.

---

Section 1 Voice Call Waiting

      However,
      there is no w= ay in RSVP today to share the resources between the
      A->B and A= ->C subflows of the call since by definition the RSVP
      reservations = for these subflows must have different IP addresses
      in the SESSIO= N objects.

Since you are defining such a mechanism, "th= ere is no way today" is not
true. I suggest...

      Since, by def= inition, the RSVP reservations for the subflows A->B
      and A->C o= f the call must have different IP addresses in the
      SESSION objec= ts, this document defines a new mechanism to
      associate the= subflows and allow them to share resources.

looks good to me. (assuming my co-authors don't object.)

Works for me.

Similarly...

OLD
    o Voice Shared Line:
      A single numb= er that rings multiple endpoints (which may be
      geographicall= y diverse), such as phone lines on a manager's desk
      and their ass= istant.  A VoIP system that models these calls as
      multiple P2P = unicast pre-ring reservations would result in
      significantly= over-counting bandwidth on shared links, since
      today unicast= reservations to different endpoints cannot share
      bandwidth.
NEW
    o Voice Shared Line:
      A voice share= d line is a single number that rings multiple
      endpoints (wh= ich may be geographically diverse), such as phone
      lines to a ma= nager's desk and to their assistant.  A VoIP system
      that models t= hese calls as multiple P2P unicast pre-ring
      reservations = would result in significantly over-counting
      bandwidth on = shared links, since RSVP unicast reservations to
      different end= points cannot share bandwidth.  So a new mechanism
      is defined in= this document allowing separate unicast
      reservations = to be associated and share resources.
END

okay (assuming my co-authors don't object.)

Works for me.



And...

OLD
    o Symmetric NAT:
      RSVP permits = sharing of resources between multiple flows
      addressed to = the same destination D, even from different senders
      S1 and S2. &n= bsp;However, if D is behind a NAT operating in symmetric
      mode [RFC5389= ], it is possible that the destination port of the
      flows S1->= D and S2->D may be different outside the NAT.  In this
      case, these f= lows cannot share resources using RSVP today, since
      the SESSION o= bjects for these two flows outside the NAT would
      have differen= t ports.
NEW
    o Symmetric NAT:
      RSVP permits = sharing of resources between multiple flows
      addressed to = the same destination D, even from different senders
      S1 and S2. &n= bsp;However, if D is behind a NAT operating in symmetric
      mode [RFC5389= ], it is possible that the destination port of the
      flows S1->= D and S2->D may be different outside the NAT.  In this
      case, these f= lows cannot share resources using RSVP, since the
      SESSION objec= ts for these two flows outside the NAT have
      different por= ts.  This document defines a new mechanisms to
      associate the= se flows and allow them to share resources.
END

okay (assuming my co-authors don't object.)

Works for me.



3.1.1 vs 3.2.1

In 3.1.1 you have...
  Relative ordering of ASSOCIATION obje= cts of the same
  type SHOULD be preserved by transit n= odes.


note this is path processing,

In 3.2.1 you have...
  Relative ordering of ASSOCIATION obje= cts of the same
  type MUST be preserved by transit nod= es.  Association type specific
  ordering requirements MAY be defined = in the future.

Note this is resv processing.

1. Why is 3.1.1 SHOULD and 3.1.2 MUST?

I'm not sure, other than 3.1.2 is new so there's no chance of placing a
new requirement on implementations of 4872&3 (which only use associatio= n
objects in Path messages.)

I believe the idea is that while ordering is currently irrelevant, it = might be relevant in some future application so we may as well avoid re-ord= ering when it is easy (i.e. new implementation).  Hence the logic of S= HOULD & MUST. I am happy either way SHOULD/MUST or SHOULD/SHOULD.




I'm fine with should for both.

Co-authors?


4. Why "MAY" not "may"?

over zealousness.  i.e., your right!

or maybe something like :
"Note that association type specific ordering requirements c= ould be defined in the future."


---

3.3.1

  Once an association is identified, re= sources SHOULD be shared across
  the identified sessions.

This use of "SHOULD" begs the question:= under what circumstances MAY
resource sharing not be applied?

actual resource allocation is really an implementation choice and
different internal implementation choices.  We didn't want to overly constrain an implementation. "is expected" is really what we mean= , but
how do you say this in 2119 language?

2205 uses the term "Admission control", so would it work if = we said:
"
Once an association is identified, resources MUST be considered as sha= red across
  the identified sessions by the admission control function.
"



Francois

--_000_67596B46B75346DC93B88297EFFAF5DDciscocom_-- From internet-drafts@ietf.org Wed Aug 8 09:22:21 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE7E21F86B5; Wed, 8 Aug 2012 09:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUb7d2EzSc1i; Wed, 8 Aug 2012 09:22:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C04C21F8670; Wed, 8 Aug 2012 09:22:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120808162218.7656.84411.idtracker@ietfa.amsl.com> Date: Wed, 08 Aug 2012 09:22:18 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-10.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:22:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : GMPLS OSPF Enhancement for Signal and Network Element Co= mpatibility for Wavelength Switched Optical Networks Author(s) : Young Lee Greg M. Bernstein Filename : draft-ietf-ccamp-wson-signal-compatibility-ospf-10.txt Pages : 13 Date : 2012-08-08 Abstract: This document provides GMPLS OSPF routing enhancements to support signal compatibility constraints associated with WSON network elements. These routing enhancements are required in common optical or hybrid electro-optical networks where not all of the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters since such systems can be limited to processing only certain types of WSON signals. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibility= -ospf There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-= 10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-wson-signal-compatibili= ty-ospf-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Aug 8 09:24:26 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF8421F8723; Wed, 8 Aug 2012 09:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMeb-yL+Vg3A; Wed, 8 Aug 2012 09:24:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA58D21F871C; Wed, 8 Aug 2012 09:24:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120808162424.16064.92873.idtracker@ietfa.amsl.com> Date: Wed, 08 Aug 2012 09:24:24 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-15.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:24:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Routing and Wavelength Assignment Information Encoding f= or Wavelength Switched Optical Networks Author(s) : Greg M. Bernstein Young Lee Dan Li Wataru Imajuku Filename : draft-ietf-ccamp-rwa-wson-encode-15.txt Pages : 33 Date : 2012-08-08 Abstract: A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are fairly specific to WSONs. This document provides efficient, protocol-agnostic encodings for the WSON specific information elements. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rwa-wson-encode-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Aug 8 09:25:44 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F5F21F8648; Wed, 8 Aug 2012 09:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQ7O8xlqLANi; Wed, 8 Aug 2012 09:25:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E5C21F8639; Wed, 8 Aug 2012 09:25:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120808162543.16066.5204.idtracker@ietfa.amsl.com> Date: Wed, 08 Aug 2012 09:25:43 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-15.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:25:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Routing and Wavelength Assignment Information Model for = Wavelength Switched Optical Networks Author(s) : Young Lee Greg M. Bernstein Dan Li Wataru Imajuku Filename : draft-ietf-ccamp-rwa-info-15.txt Pages : 27 Date : 2012-08-08 Abstract: This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-info There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rwa-info-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gregb@grotto-networking.com Wed Aug 8 10:04:33 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF0721F8762 for ; Wed, 8 Aug 2012 10:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.769, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixmFLYLo9bcd for ; Wed, 8 Aug 2012 10:04:19 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0F23721F8733 for ; Wed, 8 Aug 2012 10:04:18 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id B3221212E304 for ; Wed, 8 Aug 2012 12:04:17 -0500 (CDT) Message-ID: <50229C0B.5020509@grotto-networking.com> Date: Wed, 08 Aug 2012 10:04:11 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] WSON updates for Optical Interface Classes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 17:04:33 -0000 Hi CCAMPers, per working group consensus we have updated the following WSON drafts: http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-10 http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-15 http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-15. We have removed "modulation type", "FEC type", and "Bit rate range" and replace with the "Optical Interface Class". We have applied the changes suggested on the CCAMP list and in the OIC draft. There are some undefined references that need to be filled in by the authors of the OIC draft. Please furnish references or suitable text. Info draft: ..."Where the term is defined by [xyz]." Encoding draft: ..."The Optical Interface Class format is defined within [x-ref-tbd]." See updated drafts for further context. Also if an encoding example is desired for appendix A of the encoding draft please furnish. To ease and expedite further changes on the OIC issue MS Word versions of these documents can be found at: http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp-wson-signal-compatibility-ospf-10a.docx http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp-rwa-wson-encode-15a.docx http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp-rwa-info-15a.docx Best Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From lberger@labn.net Wed Aug 8 10:33:49 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DE721F8527 for ; Wed, 8 Aug 2012 10:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.473 X-Spam-Level: X-Spam-Status: No, score=-98.473 tagged_above=-999 required=5 tests=[AWL=1.688, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzclQknpnqD0 for ; Wed, 8 Aug 2012 10:33:48 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 429B221F8653 for ; Wed, 8 Aug 2012 10:33:48 -0700 (PDT) Received: (qmail 31588 invoked by uid 0); 8 Aug 2012 17:33:47 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 8 Aug 2012 17:33:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=kVjC2zy0kw9APT/m/Lbh3rTQPmNpENzPQ8Qt4Z5yVks=; b=rOnqvJ0iWw9dJN8+ZP6aCMWO5mjfBBFegtZIIXl5ZWxeLMvPlIIABY/3UGw/Diz6v1ij1ljg8/Z02n8La4QmoWkjO8wMzs1h/YzAdfRnaTc7F9WacSe9U4Og1rz5/Jq4; Received: from box313.bluehost.com ([69.89.31.113]:44778 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1SzA8h-0007EH-6Z for ccamp@ietf.org; Wed, 08 Aug 2012 11:33:47 -0600 Message-ID: <5022A2F9.8050008@labn.net> Date: Wed, 08 Aug 2012 13:33:45 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Fwd: comment on compatibility sections of g709v3 drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 17:33:49 -0000 All, It was pointed out to me, off list, that I had previously made a related comment: http://www.ietf.org/mail-archive/web/ccamp/current/msg13284.html I believe the (implied) question is why am I once again raising this topic. I though others may be interested in the answer. In the previous thread my objective was to clarify the intent of what was written and not change the technical solution, i.e., the comment was really editorial/process in nature and not technical. I think the revised text, which was published in May, is clear. Now that the text is clear and the full implications of the text are spelled out, I as a WG participant (not chair) am saying the documented *technical* approach is too complex and am proposing a simplification. In short, in this new thread I am proposing a new consensus technical position while the previous thread was only asking for clarification. Lou PS Please respond to the original message if you want to discuss the technical details of my proposal. -------- Original Message -------- Subject: [CCAMP] comment on compatibility sections of g709v3 drafts Date: Wed, 08 Aug 2012 09:29:44 -0400 From: Lou Berger To: CCAMP Authors/All, I mentioned in Vancouver, the current "compatibility" text in the G.709-related framework, routing, and signaling WG drafts place more complex requirements on new implementations than is typical for CCAMP/GMPLS. With chair hat off, I'd like to propose the following approach: For routing: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-02#section-6 1. Nodes supporting [ospf-g709v3] MAY support [RFC4328] 2. When nodes support both advertisement methods, implementations MUST support the configuration of which advertisement method is followed. The choice of which is used is based on policy and is out of scope of the document. 3. This enables nodes following each method to identify similar supporting nodes and compute paths using only the appropriate nodes. For signaling: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-03#section-9 4. Nodes supporting [signaling-g709v3] SHOULD support [ospf-g709v3]. 5. Nodes supporting [signaling-g709v3] MAY support [RFC4328] signaling. 6. A node supporting both sets of procedures is NOT REQUIRED to signal an LSP using both procedures, i.e., to act as a signaling version translator. 7. Ingress nodes that support both sets of procedures MAY select which set of procedures to follow based on routing information or local policy. 8. Include informative comment: Per [RFC3473], nodes that do don't support [signaling-g709v3] will generate a PathErr message, with a "Routing problem/Unsupported Encoding" indication. Also, the background narrative really belongs in the framework draft. The framework will need to be reflected to match both changes once agreed to . See http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-08#section-5.5 Comments? Also, I'm happy for the authors to wordsmith (once there is consensus) or can provide specific text proposals if needed. Lou (as WG participant) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From daniele.ceccarelli@ericsson.com Thu Aug 9 01:07:59 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5594121F8744 for ; Thu, 9 Aug 2012 01:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.353 X-Spam-Level: X-Spam-Status: No, score=-3.353 tagged_above=-999 required=5 tests=[AWL=2.896, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BatdFixxIhBn for ; Thu, 9 Aug 2012 01:07:58 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CED8421F873E for ; Thu, 9 Aug 2012 01:07:57 -0700 (PDT) X-AuditID: c1b4fb25-b7f236d000005cde-86-50236fdbb0ac Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 16.E4.23774.BDF63205; Thu, 9 Aug 2012 10:07:55 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.63]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 9 Aug 2012 10:07:55 +0200 From: Daniele Ceccarelli To: Lou Berger , CCAMP Date: Thu, 9 Aug 2012 10:07:52 +0200 Thread-Topic: [CCAMP] comment on compatibility sections of g709v3 drafts Thread-Index: Ac11aeMdeQPwqCVoSteYWvMfdnt6DAAluVhg Message-ID: References: <502269C8.8020607@labn.net> In-Reply-To: <502269C8.8020607@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvre7tfOUAgz075CyezLnBYtHR/JbF gcljyZKfTB4fNjWzBTBFcdmkpOZklqUW6dslcGWs/PmCseCbdkXL3zeMDYyXlLsYOTkkBEwk Pqw7xQhhi0lcuLeerYuRi0NI4BSjxPel91khnPmMEr+fPgWq4uBgE7CSeHLIB6RBRMBSYkpX OxOIzSKgIvHx4nU2EFtYwF1i94V+VogaD4lLz1oZIWwjiRm3frOA2LwC4RIzuieA1QgJqEt0 PW0FszkFNCT+HP3IDmIzCshKTNi9CKyXWUBc4taT+UwQhwpILNlznhnCFpV4+fgfK0S9jMSv Td9YIer1JG5MncIGYWtLLFv4mhlir6DEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilE4NzEz J73cSC+1KDO5uDg/T684dRMjMEYObvmtuoPxzjmRQ4zSHCxK4rzWW/f4CwmkJ5akZqemFqQW xReV5qQWH2Jk4uCUamCsnc4hZqfOKLO+9u3Uv3d+xrO90u24WRAQEBo75dncQyssVaY7zNVf Md2gLXbV4kPSXj+OKb59sOzlhVSR5EzmWf0FRvNVMoV2f6576B285byU5rHztk8l6pWPndv0 QeR57VWbva7f5UWj44wzU34E7vNViw5iczT1izHQU1kc+erArfNa12uVWIozEg21mIuKEwFs qFWJXwIAAA== Subject: Re: [CCAMP] comment on compatibility sections of g709v3 drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 08:07:59 -0000 OK for me! Just some comments: 1) What abbout adding a default behaviour for both of them? Like said in FW= K, the default routing behavior should be the new one.=20 2) Routing: what about a should (or even a may) instead of a must in the co= nfigurability of the advertisement method? >When nodes support both advertisement methods, > implementations SHOULD support the configuration of which > advertisement method is followed. The choice of which is used > is based on policy and is out of scope of the document. 3) What about this for section 5.5. of the FWK: 5.5. Implications for Control Plane Backward Compatibility [...] OLD From a routing perspective, the advertisement of LSAs carrying new Switching Capability type implies the support of new OTN control plane protocols. A new node must support both legacy routing (i.e., the procedures defined in [RFC4203] with the switching capabilities defined in [RFC4328]) and new routing (i.e., the procedures defined for [G709-V3]), and should use new routing by default. When detecting the presence of a legacy node in the administrative domain (i.e., receiving LSAs carrying legacy Switching Capability type), the new node should advertise its links information by both the new and legacy routing approach, so that the legacy node can obtain the link resource information advertised by the new node. On the other hand, from a signaling perspective, a new node must support both the legacy signaling procedures defined in [RFC4328] and the new procedures for control of [G709-V3]. Based on the routing information, a new node can determine whether its neighbor node is a legacy one or new one, so that it can determine which signaling procedure (new or legacy signaling procedure) needs to be performed. In case the new node has not enough information to know which signaling procedure its neighbor can support, it can use the new signaling procedure with the new Switching Capability type by default. NEW From a routing perspective, the advertisement of LSAs carrying new Switching Capability type implies the support of new OTN control plane protocols. A new node may support both legacy routing (i.e., the procedures defined in [RFC4203] with the switching capabilities defined in [RFC4328]) and new routing (i.e., the procedures defined for [G709-V3]), and should use new routing by default. When nodes=20 support both advertisement methods, implementations should support the configuration of which advertisement method is followed.=20 On the other hand, from a signaling perspective, a new node supporting n= ew signaling should support also new routing and may support [RFC4328] sign= aling. Ingress nodes that support both sets of procedures may select which set of procedures to follow based on routing information or local policy and is not required to use both of them. Per [RFC3473], nodes that do don't support new signaling will generate a PathErr message, with a "Routing problem/Unsupported Encoding" indication. BR Daniele >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 >On Behalf Of Lou Berger >Sent: mercoled=EC 8 agosto 2012 15.30 >To: CCAMP >Subject: [CCAMP] comment on compatibility sections of g709v3 drafts > >Authors/All, > I mentioned in Vancouver, the current "compatibility"=20 >text in the G.709-related framework, routing, and signaling WG=20 >drafts place more complex requirements on new implementations=20 >than is typical for CCAMP/GMPLS. > >With chair hat off, I'd like to propose the following approach: > >For routing: >http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-0 2#section-6 >1. Nodes supporting [ospf-g709v3] MAY support [RFC4328] 2.=20 >When nodes support both advertisement methods, > implementations MUST support the configuration of which > advertisement method is followed. The choice of which is used > is based on policy and is out of scope of the document. >3. This enables nodes following each method to identify similar > supporting nodes and compute paths using only the > appropriate nodes. > >For signaling: >http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g70 9v3-03#section-9 >4. Nodes supporting [signaling-g709v3] SHOULD support [ospf-g709v3]. >5. Nodes supporting [signaling-g709v3] MAY support [RFC4328] signaling. >6. A node supporting both sets of procedures is NOT REQUIRED to signal > an LSP using both procedures, i.e., to act as a signaling version > translator. >7. Ingress nodes that support both sets of procedures MAY select > which set of procedures to follow based on routing information or > local policy. >8. Include informative comment: Per [RFC3473], nodes that do don't > support [signaling-g709v3] will generate a PathErr > message, with a "Routing problem/Unsupported Encoding" indication. > > Also, the background narrative really belongs in the=20 >framework draft. > >The framework will need to be reflected to match both changes=20 >once agreed to . See >http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framewor k-08#section-5.5 > >Comments? > >Also, I'm happy for the authors to wordsmith (once there is=20 >consensus) or can provide specific text proposals if needed. > >Lou (as WG participant) >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp >= From lberger@labn.net Thu Aug 9 06:44:40 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C146921F8686 for ; Thu, 9 Aug 2012 06:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.512 X-Spam-Level: X-Spam-Status: No, score=-98.512 tagged_above=-999 required=5 tests=[AWL=1.649, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jSOzeXZADGL for ; Thu, 9 Aug 2012 06:44:39 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 8323021F8687 for ; Thu, 9 Aug 2012 06:44:32 -0700 (PDT) Received: (qmail 21307 invoked by uid 0); 9 Aug 2012 13:44:29 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 9 Aug 2012 13:44:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=9IHNK4T4ktFJ6TOcmqnBqB62Kkrr0aOkLQGtpWyJhnQ=; b=AT0piPMdQ3TME91yyZdQORsYWWW6MzmBT6VuZUcJcCFOAwsLFkRay+ur/TzHhfLf/Botx7qQy0AtyFHUpjEdfOxC+yBOLdNxfEEIQonLJ4hInJmw1hYR0VXZDIiG9rQk; Received: from box313.bluehost.com ([69.89.31.113]:47029 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1SzT2K-0005JI-Ld; Thu, 09 Aug 2012 07:44:28 -0600 Message-ID: <5023BEBA.6080305@labn.net> Date: Thu, 09 Aug 2012 09:44:26 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Francois Le Faucheur (flefauch)" References: <021a01cd7536$2104aa10$630dfe30$@olddog.co.uk> <50227712.4010203@labn.net> <67596B46-B753-46DC-93B8-8297EFFAF5DD@cisco.com> In-Reply-To: <67596B46-B753-46DC-93B8-8297EFFAF5DD@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "" , CCAMP Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 13:44:41 -0000 How about "MUST be" --> "is" Lou On 8/8/2012 12:02 PM, Francois Le Faucheur (flefauch) wrote: > 2205 uses the term "Admission control", so would it work if we said: > " > Once an association is identified, resources MUST be considered as > shared across > the identified sessions by the admission control function. > " > From lberger@labn.net Thu Aug 9 07:18:02 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B342521F86A0 for ; Thu, 9 Aug 2012 07:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.55 X-Spam-Level: X-Spam-Status: No, score=-98.55 tagged_above=-999 required=5 tests=[AWL=1.611, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE8sg6FCQzJ6 for ; Thu, 9 Aug 2012 07:18:01 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 96EFE21F8687 for ; Thu, 9 Aug 2012 07:18:01 -0700 (PDT) Received: (qmail 26839 invoked by uid 0); 9 Aug 2012 14:18:01 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 9 Aug 2012 14:18:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=wpJdiLhebyFeD4xUiLr195eLnGcB0RQkVYS79i8ptoU=; b=sJL9OR+m80Br3p/k6ayFdzpR03zALzig4CKdcJePk4CV/9Eodn/ZTPaKK0RpQEb0KwRn49K1Sno47ZzlYYGUBkEogzhqtU0bu+aczaFpROeQb1DPr+DqatiGGtQ2bST7; Received: from box313.bluehost.com ([69.89.31.113]:50670 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1SzTYn-0002PQ-07; Thu, 09 Aug 2012 08:18:01 -0600 Message-ID: <5023C697.2010506@labn.net> Date: Thu, 09 Aug 2012 10:17:59 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Daniele Ceccarelli References: <502269C8.8020607@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] comment on compatibility sections of g709v3 drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 14:18:02 -0000 Daniele, See responses below. On 8/9/2012 4:07 AM, Daniele Ceccarelli wrote: > OK for me! Just some comments: > > 1) What abbout adding a default behaviour for both of them? Like said > in FWK, the default routing behavior should be the new one. > I'm not sure that this adds value (as is covered by policy) but also don't think it causes any harm, so either way is fine with me. > 2) Routing: what about a should (or even a may) instead of a must in > the configurability of the advertisement method? > >> When nodes support both advertisement methods, >> implementations SHOULD support the configuration of which >> advertisement method is followed. The choice of which is used >> is based on policy and is out of scope of the document. > Under what conditions would *not* having a configuration knob make sense? > 3) What about this for section 5.5. of the FWK: > > 5.5. Implications for Control Plane Backward Compatibility > > [...] > OLD > From a routing perspective, the advertisement of LSAs carrying new > Switching Capability type implies the support of new OTN control > plane protocols. A new node must support both legacy routing (i.e., > the procedures defined in [RFC4203] with the switching capabilities > defined in [RFC4328]) and new routing (i.e., the procedures defined > for [G709-V3]), and should use new routing by default. When detecting > the presence of a legacy node in the administrative domain (i.e., > receiving LSAs carrying legacy Switching Capability type), the new > node should advertise its links information by both the new and > legacy routing approach, so that the legacy node can obtain the link > resource information advertised by the new node. > > On the other hand, from a signaling perspective, a new node must > support both the legacy signaling procedures defined in [RFC4328] and > the new procedures for control of [G709-V3]. Based on the routing > information, a new node can determine whether its neighbor node is a > legacy one or new one, so that it can determine which signaling > procedure (new or legacy signaling procedure) needs to be performed. > In case the new node has not enough information to know which > signaling procedure its neighbor can support, it can use the new > signaling procedure with the new Switching Capability type by default. > NEW > From a routing perspective, the advertisement of LSAs carrying new > Switching Capability type implies the support of new OTN control > plane protocols. A new node may support both legacy routing (i.e., > the procedures defined in [RFC4203] with the switching capabilities > defined in [RFC4328]) and new routing (i.e., the procedures defined > for [G709-V3]), and should use new routing by default. When nodes > support both advertisement methods, implementations should support > the configuration of which advertisement method is followed. > > On the other hand, from a signaling perspective, a new node supporting new > signaling should support also new routing and may support [RFC4328] signaling. > Ingress nodes that support both sets of procedures may select > which set of procedures to follow based on routing information or > local policy and is not required to use both of them. Per [RFC3473], > nodes that do don't support new signaling will generate a PathErr > message, with a "Routing problem/Unsupported Encoding" indication. This is getting into a bit of a style issue. To me this text is far too tied into the solutions. I'd leave the framework to identify the issues and the high level approach for the solutions and leave the details to the solutions draft. Perhaps something like: This section discusses the compatibility of nodes implementing the control plane procedures defined [RFC4328], in support of [G709-V1], and the control plane procedures defined to support [G709-V3], as outlined by this document. Compatibility needs to be considered only when controlling ODU1 or ODU2 or ODU3 connection, because [G709-V1] only support these three ODU signal types. In such cases, there are several possible options including: o a node supporting [G709-V3] could support only the [G709-V3] related control plane procedures. In which case both types of nodes would be unable to jointly control a LSP for an ODU type that both nodes support in the data plane. Note that this case is supported by the procedures defined in [RFC3473] as a different Switching Capability/Type value is used for the different control plane versions. o a node supporting [G709-V3] could support both the [G709-V3] related control plane and the the control plane defined [RFC4328]. o such a node could identify which set of procedure to follow when initiating an LSP based on the Switching Capability value advertised in routing. o such a node could follow the set of procedures based on the Switching Type received in signaling messages from an upstream node. o such a node, when processing a transit LSP, could select which signaling procedures to follow based on the Switching Capability value advertised in routing by the next hop node. Note that text has been adapted from the signaling draft. I'm not tied to the specific wording, I just (largely) revised what was already there. Feel free to edit/modify as you see fit. Lou > > > BR > Daniele > > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >> On Behalf Of Lou Berger >> Sent: mercoledì 8 agosto 2012 15.30 >> To: CCAMP >> Subject: [CCAMP] comment on compatibility sections of g709v3 drafts >> >> Authors/All, >> I mentioned in Vancouver, the current "compatibility" >> text in the G.709-related framework, routing, and signaling WG >> drafts place more complex requirements on new implementations >> than is typical for CCAMP/GMPLS. >> >> With chair hat off, I'd like to propose the following approach: >> >> For routing: >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-0 > 2#section-6 >> 1. Nodes supporting [ospf-g709v3] MAY support [RFC4328] 2. >> When nodes support both advertisement methods, >> implementations MUST support the configuration of which >> advertisement method is followed. The choice of which is used >> is based on policy and is out of scope of the document. >> 3. This enables nodes following each method to identify similar >> supporting nodes and compute paths using only the >> appropriate nodes. >> >> For signaling: >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g70 > 9v3-03#section-9 >> 4. Nodes supporting [signaling-g709v3] SHOULD support [ospf-g709v3]. >> 5. Nodes supporting [signaling-g709v3] MAY support [RFC4328] signaling. >> 6. A node supporting both sets of procedures is NOT REQUIRED to signal >> an LSP using both procedures, i.e., to act as a signaling version >> translator. >> 7. Ingress nodes that support both sets of procedures MAY select >> which set of procedures to follow based on routing information or >> local policy. >> 8. Include informative comment: Per [RFC3473], nodes that do don't >> support [signaling-g709v3] will generate a PathErr >> message, with a "Routing problem/Unsupported Encoding" indication. >> >> Also, the background narrative really belongs in the >> framework draft. >> >> The framework will need to be reflected to match both changes >> once agreed to . See >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framewor > k-08#section-5.5 >> >> Comments? >> >> Also, I'm happy for the authors to wordsmith (once there is >> consensus) or can provide specific text proposals if needed. >> >> Lou (as WG participant) >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > > > From leeyoung@huawei.com Thu Aug 9 15:46:22 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BE821F85C7 for ; Thu, 9 Aug 2012 15:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4cR5e8LrMkZ for ; Thu, 9 Aug 2012 15:46:21 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1B12921F85C6 for ; Thu, 9 Aug 2012 15:46:21 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJB88132; Thu, 09 Aug 2012 14:46:20 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 9 Aug 2012 15:44:45 -0700 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.49]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 9 Aug 2012 15:44:41 -0700 From: Leeyoung To: Rajan Rao , "Giovanni Martinelli (giomarti)" Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority Thread-Index: AQHNcAyuJFh0KZM0PEuR5rvzvXz1+5dFha9ggAB9XQD//4xN4IABmgCA//+RYuCAAIYUgIAK0m1A Date: Thu, 9 Aug 2012 22:44:41 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172905FCB0@dfweml511-mbs.china.huawei.com> References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED70@dfweml511-mbs.china.huawei.com> <48F63A76-53E9-4C38-A266-8B8BAB9F7838@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905EEC1@dfweml511-mbs.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D347EE54E@SV-EXDB-PROD2.infinera.com> In-Reply-To: <650AA355E323C34D9D4AAEED952E053D347EE54E@SV-EXDB-PROD2.infinera.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 22:46:22 -0000 Hi Rajan and Giovanni,=20 Per your request, the following two changes can be made to Generic Constrai= nt Encode draft. 1. Priority Flags are changed to 3 bits=20 2. Illustrative Examples are given in Appendix.=20 Check if this makes sense and give me your comments. Once we would agree on= this, all the pending issues will be closed and we can update the draft re= ady for WG LC. Best Regards, Young ---------------------------------------------------------------------------= ------------------------------------ 1. The following is a new encoding for Available/Shared Backup Labels Sub-T= LV: 2.3 (2.4) Available (Shared Backup) Labels sub-TLV=20 The Available (Shared Backup) Labels sub-TLV link consists of an availabili= ty flag, priority flags, and a single variable length label set field as fo= llows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| PRI | Reserve | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where A (Availability bit) =3D 1 or 0 indicates that the labels listed in the fol= lowing label set field are available or not available, respectively, for us= e at a given priority level as indicated by the Priority Flags. PRI (Priority Flags, 3 bits): Indicates priority level applied to Label Set= Field.=20 000: Priority Level 0 001: Priority Level 1 010: Priority Level 2 011: Priority Level 3 100: Priority Level 4 101: Priority Level 5 110: Priority Level 6 111: Priority Level 7 If A bit is set then the labels in the label set field are available or not= available as indicated by the A bit for use at that particular priority le= vel. 2. Illustrative Examples A.5. Priority Flags in Available/Shared Backup Labels sub-TLV=20 If one wants to make a set of labels (indicated by Label Set Field #1) avai= lable for all priority levels (level 0 to 7) while allowing a set of labels= (indicated by Label Set Field #2) only to available to the highest priorit= y (Priority Level 7), the following encoding will express such need.=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0 0 0| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #1 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1 1 1| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #2 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Alternatively, the following encoding expresses the same need by using A bi= t (A=3D0) as a mechanism to make unavailable a certain set of labels for al= l priority levels except the highest priority Level 7.=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1 1 0| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #2 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that when a set of labels (indicated by Label Set Field #2) is unavail= able for Priority Level 6 (indicated by Priority Flag 110), this implies th= at these labels are not also available for lower Priority levels, 0-5. The = above encoding also implies that all other labels except those defined unde= r Label Set Field #2 are available for all priority levels. -----Original Message----- From: Rajan Rao [mailto:rrao@infinera.com]=20 Sent: Thursday, August 02, 2012 12:40 PM To: Leeyoung; Giovanni Martinelli (giomarti) Cc: CCAMP Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Giovanni, My comment few months ago was to cover bandwidth advertisement at all 8 pr= iority levels as in PSC, TDM & TDM-OTN switching cases. The priority bas= ed advertisement in WSON/LSC is no different from other cases. What might be useful is to add couple of examples to show how this is used = along with other flags. Hope this helps. Thanks Rajan -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= eeyoung Sent: Thursday, August 02, 2012 9:57 AM To: Giovanni Martinelli (giomarti) Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Giovanni, Please see in-line for my responses. Thanks.=20 -----Original Message----- From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] Sent: Thursday, August 02, 2012 11:16 AM To: Leeyoung Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Young, btw first just a naming issue (I guess a question for the wg in general) th= e object label_set here has the same name name as the label_set form rfc347= 1 but it has actually a different encoding, so just asking if worth figurin= g out a little different name. If no one complain I'm fine too. YOUNG>> We are expanding the label set concept from 3471. I am not sure if = there is a new name needed here. I defer this to WG chairs.=20 please see inline On Aug 2, 2012, at 1:18 , Leeyoung wrote: > > On Aug 2, 2012, at 24:25 , Leeyoung wrote: >=20 >> Hi Giovanni, >>=20 >> The wavelength priority you propose seems different from the what we enc= oded per Rao Rajan's suggestion. What we encoded in section 2.3 of gen enco= de is not giving wavelength a priority level, among which I believe your wa= velength property specifies. >>=20 >> What we are proposing is what labels are available/not available for eac= h priority level (similar to LSP reservation or holding priority) as the fo= llowing encoding dictates:=20 >>=20 >=20 >=20 > GM> So at the end is a "Label Priority" ? With the Label_Set granularity = instead of the single Label? =20 >=20 > YOUNG>> No, this is not "label priority". Label is not "assigned" a prior= ity. Label is neutral. Say, you have five wavelengths available for grab an= d you have two priorities you are aware of which is service level (e.g., LS= P). For higher priority service, you may want to all your five wavelengths = (w1-w5) available for grab while for lower priority, you may restrict to le= ss number of wavelengths, say three wavelengths only (e.g., w1-w3). GM> Well I'm not sure I'm following you, you say that labels are not assign= ed to a priority but then there is a priority associated to a label set. Fo= r sure label is neutral but "someone" decide if it goes in a label set with= a certain priority, or in another (or in both label_set ). So, to me this = means associate (is this term better than assign?) a priority to a label. YOUNG>> I think I explained enough what the current encoding is. This is ab= out what labels are available for LSP priority. Some labels may be availabl= e for more than one LSP priority. There is no 1:1 "association" between lab= el and priority per se.=20 > Here you can see individual wavelength is not assigned a priority. GM> the granularity is the label_set so you can easily see that's equivalen= t to individual label, anyway single label or label-set its not a substanti= al difference to me. > This is analogous to how much BW availability for each priority in MPLS n= etwork, except that we need to express in wavelength level. =20 >=20 >=20 >=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |A| Reserved | Priority Flags| Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Label Set Field | >> : : >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Where >>=20 >> A (Availability bit) =3D 1 or 0 indicates that the labels listed in =20 >> the following label set field are available or not available, =20 >> respectively, for use at a given priority level as indicated by the =20 >> Priority Flags. >=20 >=20 > GM> The reading here suggest me that there could be multiple objects (I b= et up to 8) packed up somewere (e.g. something like sub-tlvs in the link ad= vertisement). Is my interpretation correct? >=20 > YOUNG>> Yes.=20 >=20 GM> two encoding question here: GM> 1/ why using flags instead of classical three bits?=20 GM> 2/ What the usage of A? I mean you have an Available_label object and t= hen you set A=3D0 which means that labels are not available... could you pl= ease clarify better? =20 YOUNG>> Yes, three bits can do that. We put A=3D0 (not available) --just to= give more flexibility. That's all. If you want to restrict some ranges of = labels to lower LSP, using A bit (A=3D0) would be more efficient to express= such need.=20 Cheers G > Cheers > G >=20 >=20 >>=20 >> Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 =20 >> corresponds to priority level 7. If a bit is set then the labels in =20 >> the label set field are available or not available as indicated by =20 >> the A bit for use at that particular priority level. >>=20 >> Let's begin if we are in agreement with this point.=20 >>=20 >> Thanks. >> Young >>=20 >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >> Behalf Of Giovanni Martinelli (giomarti) >> Sent: Wednesday, August 01, 2012 12:40 PM >> To: Giovanni Martinelli (giomarti) >> Cc: CCAMP >> Subject: Re: [CCAMP] Comment on=20 >> draft-ietf-ccamp-general-constraint-encode-08: priority >>=20 >> Here my latest mail with comments on wavelength priority...=20 >>=20 >> Here my memory on past discussion (please correct if wrong) >> - last short thread was during ieft83 (around 26/28 march), last mail wa= s from me and did not get answers. The content here below cover that mail a= s well. >> - discussions about wl priority happens among authors not on ccamp maili= ng list. On the mailing list you announce draft update around dec 2011. =20 >>=20 >> Well, I'm not complaining about how discussion happen, simply I saw a n= ot-trivial addition to wg document, hence my comments. >>=20 >> Cheers >> G >>=20 >>=20 >>=20 >> On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: >>=20 >>> Dear authors / ccamp, >>>=20 >>> here a few comments related to the priority field added to draft-ietf-c= camp-general-constraint-encode: >>>=20 >>> A couple of editorial comments >>> 1) "wavelenght priority" appears in a draft that claim to be general. = In fact is available in "Available Labels Sub-TLV" and "Shared Backup Label= s Sub-TLV". So is a wavelength or label-like priority? >>> 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0= .. 7]? >>>=20 >>>=20 >>> Then few other comments >>> 3) How the priority is used versus the A flag . Draft text report " >>> A (Availability bit) =3D 1 or 0 indicates that the labels listed in=20 >>> the following label set field are available or not available,=20 >>> respectively, for use at a given priority level as indicated by the=20 >>> Priority Flags. >>>=20 >>> " >>> So does it means that there could be different "available labels sub-TL= Vs" advertised?=20 >>>=20 >>> 4) Still unclear to me how this priority is different from the one=20 >>> reported in http://tools.ietf.org/html/draft-kattan-wson-property-01=20 >>> and eventually if this "priority" could fit the LSP priority already=20 >>> available (as one of the comment we received at that time) >>>=20 >>> Cheers >>> G >>>=20 >>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From rrao@infinera.com Thu Aug 9 17:18:28 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8C011E80A6 for ; Thu, 9 Aug 2012 17:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlB5OGz3XEyE for ; Thu, 9 Aug 2012 17:18:27 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 019CE11E808A for ; Thu, 9 Aug 2012 17:18:26 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0283.003; Thu, 9 Aug 2012 17:18:26 -0700 From: Rajan Rao To: Leeyoung , "Giovanni Martinelli (giomarti)" Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority Thread-Index: AQHNcAy0UkTqZeG4LEua7hBAeom47ZdF/mQAgAAEqACAAAosgIABHCGAgAALcQD//5T7sIALzJqA//+U4UA= Date: Fri, 10 Aug 2012 00:18:25 +0000 Message-ID: <650AA355E323C34D9D4AAEED952E053D34807E2F@SV-EXDB-PROD2.infinera.com> References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED70@dfweml511-mbs.china.huawei.com> <48F63A76-53E9-4C38-A266-8B8BAB9F7838@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905EEC1@dfweml511-mbs.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D347EE54E@SV-EXDB-PROD2.infinera.com> <7AEB3D6833318045B4AE71C2C87E8E172905FCB0@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172905FCB0@dfweml511-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP , Mohit Misra , Ashok Kunjidhapatham , Subhendu Chattopadhyay Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 00:18:28 -0000 Young, et al The confusion is mainly about which fields are applicable where. We need to= clarify usage for routing and signaling cases for the following fields: - Action field in Label set - A-bit in Available Labels - Priority field in Available labels Let us agree on what is required for routing and signaling: 1) Routing: cares about what lambda is available at what priorities. S= o, =20 a) Action =3D inclusive List | Inclusive Range | BitMap are useful. =20 Action =3D Exclusive List | Exclusive Range is not of much use =20 My preference would be to go with one option (bit-map) and don't expo= se Action field at all in BW advertisements. Like to hear from others. b) A-bit is not useful/redundant we can take it out. c) Priority field is useful/required. Regarding 3bit field Vs. 8bit fiel= d, I would go with 8-bit field to be consistent with usage in PSC, TDM en= codings. They use 8-bit priority field. 2) Signaling: cares about what lambda to use or not use for an LSP. So, a) Action field - all values are applicable b) A-bit is not required c) Priority field is not required as Action field identifies resources @ = priority-p for the LSP being setup @ priority-p. Would like to hear comments from others as well. Thanks Rajan -----Original Message----- From: Leeyoung [mailto:leeyoung@huawei.com]=20 Sent: Thursday, August 09, 2012 3:45 PM To: Rajan Rao; Giovanni Martinelli (giomarti) Cc: CCAMP Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Rajan and Giovanni,=20 Per your request, the following two changes can be made to Generic Constrai= nt Encode draft. 1. Priority Flags are changed to 3 bits=20 2. Illustrative Examples are given in Appendix.=20 Check if this makes sense and give me your comments. Once we would agree on= this, all the pending issues will be closed and we can update the draft re= ady for WG LC. Best Regards, Young ---------------------------------------------------------------------------= ------------------------------------ 1. The following is a new encoding for Available/Shared Backup Labels Sub-T= LV: 2.3 (2.4) Available (Shared Backup) Labels sub-TLV=20 The Available (Shared Backup) Labels sub-TLV link consists of an availabili= ty flag, priority flags, and a single variable length label set field as fo= llows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| PRI | Reserve | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where A (Availability bit) =3D 1 or 0 indicates that the labels listed in the fol= lowing label set field are available or not available, respectively, for us= e at a given priority level as indicated by the Priority Flags. PRI (Priority Flags, 3 bits): Indicates priority level applied to Label Set= Field.=20 000: Priority Level 0 001: Priority Level 1 010: Priority Level 2 011: Priority Level 3 100: Priority Level 4 101: Priority Level 5 110: Priority Level 6 111: Priority Level 7 If A bit is set then the labels in the label set field are available or not= available as indicated by the A bit for use at that particular priority le= vel. 2. Illustrative Examples A.5. Priority Flags in Available/Shared Backup Labels sub-TLV=20 If one wants to make a set of labels (indicated by Label Set Field #1) avai= lable for all priority levels (level 0 to 7) while allowing a set of labels= (indicated by Label Set Field #2) only to available to the highest priorit= y (Priority Level 7), the following encoding will express such need.=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0 0 0| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #1 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1 1 1| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #2 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Alternatively, the following encoding expresses the same need by using A bi= t (A=3D0) as a mechanism to make unavailable a certain set of labels for al= l priority levels except the highest priority Level 7.=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1 1 0| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #2 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that when a set of labels (indicated by Label Set Field #2) is unavail= able for Priority Level 6 (indicated by Priority Flag 110), this implies th= at these labels are not also available for lower Priority levels, 0-5. The = above encoding also implies that all other labels except those defined unde= r Label Set Field #2 are available for all priority levels. -----Original Message----- From: Rajan Rao [mailto:rrao@infinera.com] Sent: Thursday, August 02, 2012 12:40 PM To: Leeyoung; Giovanni Martinelli (giomarti) Cc: CCAMP Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Giovanni, My comment few months ago was to cover bandwidth advertisement at all 8 pr= iority levels as in PSC, TDM & TDM-OTN switching cases. The priority bas= ed advertisement in WSON/LSC is no different from other cases. What might be useful is to add couple of examples to show how this is used = along with other flags. Hope this helps. Thanks Rajan -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= eeyoung Sent: Thursday, August 02, 2012 9:57 AM To: Giovanni Martinelli (giomarti) Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Giovanni, Please see in-line for my responses. Thanks.=20 -----Original Message----- From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] Sent: Thursday, August 02, 2012 11:16 AM To: Leeyoung Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Young, btw first just a naming issue (I guess a question for the wg in general) th= e object label_set here has the same name name as the label_set form rfc347= 1 but it has actually a different encoding, so just asking if worth figurin= g out a little different name. If no one complain I'm fine too. YOUNG>> We are expanding the label set concept from 3471. I am not sure if = there is a new name needed here. I defer this to WG chairs.=20 please see inline On Aug 2, 2012, at 1:18 , Leeyoung wrote: > > On Aug 2, 2012, at 24:25 , Leeyoung wrote: >=20 >> Hi Giovanni, >>=20 >> The wavelength priority you propose seems different from the what we enc= oded per Rao Rajan's suggestion. What we encoded in section 2.3 of gen enco= de is not giving wavelength a priority level, among which I believe your wa= velength property specifies. >>=20 >> What we are proposing is what labels are available/not available for eac= h priority level (similar to LSP reservation or holding priority) as the fo= llowing encoding dictates:=20 >>=20 >=20 >=20 > GM> So at the end is a "Label Priority" ? With the Label_Set granularity = instead of the single Label? =20 >=20 > YOUNG>> No, this is not "label priority". Label is not "assigned" a prior= ity. Label is neutral. Say, you have five wavelengths available for grab an= d you have two priorities you are aware of which is service level (e.g., LS= P). For higher priority service, you may want to all your five wavelengths = (w1-w5) available for grab while for lower priority, you may restrict to le= ss number of wavelengths, say three wavelengths only (e.g., w1-w3). GM> Well I'm not sure I'm following you, you say that labels are not assign= ed to a priority but then there is a priority associated to a label set. Fo= r sure label is neutral but "someone" decide if it goes in a label set with= a certain priority, or in another (or in both label_set ). So, to me this = means associate (is this term better than assign?) a priority to a label. YOUNG>> I think I explained enough what the current encoding is. This is ab= out what labels are available for LSP priority. Some labels may be availabl= e for more than one LSP priority. There is no 1:1 "association" between lab= el and priority per se.=20 > Here you can see individual wavelength is not assigned a priority. GM> the granularity is the label_set so you can easily see that's equivalen= t to individual label, anyway single label or label-set its not a substanti= al difference to me. > This is analogous to how much BW availability for each priority in MPLS n= etwork, except that we need to express in wavelength level. =20 >=20 >=20 >=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |A| Reserved | Priority Flags| Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Label Set Field | >> : : >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Where >>=20 >> A (Availability bit) =3D 1 or 0 indicates that the labels listed in=20 >> the following label set field are available or not available,=20 >> respectively, for use at a given priority level as indicated by the=20 >> Priority Flags. >=20 >=20 > GM> The reading here suggest me that there could be multiple objects (I b= et up to 8) packed up somewere (e.g. something like sub-tlvs in the link ad= vertisement). Is my interpretation correct? >=20 > YOUNG>> Yes.=20 >=20 GM> two encoding question here: GM> 1/ why using flags instead of classical three bits?=20 GM> 2/ What the usage of A? I mean you have an Available_label object and t= hen you set A=3D0 which means that labels are not available... could you pl= ease clarify better? =20 YOUNG>> Yes, three bits can do that. We put A=3D0 (not available) --just to= give more flexibility. That's all. If you want to restrict some ranges of = labels to lower LSP, using A bit (A=3D0) would be more efficient to express= such need.=20 Cheers G > Cheers > G >=20 >=20 >>=20 >> Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 =20 >> corresponds to priority level 7. If a bit is set then the labels in =20 >> the label set field are available or not available as indicated by =20 >> the A bit for use at that particular priority level. >>=20 >> Let's begin if we are in agreement with this point.=20 >>=20 >> Thanks. >> Young >>=20 >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >> Behalf Of Giovanni Martinelli (giomarti) >> Sent: Wednesday, August 01, 2012 12:40 PM >> To: Giovanni Martinelli (giomarti) >> Cc: CCAMP >> Subject: Re: [CCAMP] Comment on=20 >> draft-ietf-ccamp-general-constraint-encode-08: priority >>=20 >> Here my latest mail with comments on wavelength priority...=20 >>=20 >> Here my memory on past discussion (please correct if wrong) >> - last short thread was during ieft83 (around 26/28 march), last mail wa= s from me and did not get answers. The content here below cover that mail a= s well. >> - discussions about wl priority happens among authors not on ccamp maili= ng list. On the mailing list you announce draft update around dec 2011. =20 >>=20 >> Well, I'm not complaining about how discussion happen, simply I saw a n= ot-trivial addition to wg document, hence my comments. >>=20 >> Cheers >> G >>=20 >>=20 >>=20 >> On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: >>=20 >>> Dear authors / ccamp, >>>=20 >>> here a few comments related to the priority field added to draft-ietf-c= camp-general-constraint-encode: >>>=20 >>> A couple of editorial comments >>> 1) "wavelenght priority" appears in a draft that claim to be general. = In fact is available in "Available Labels Sub-TLV" and "Shared Backup Label= s Sub-TLV". So is a wavelength or label-like priority? >>> 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0= .. 7]? >>>=20 >>>=20 >>> Then few other comments >>> 3) How the priority is used versus the A flag . Draft text report " >>> A (Availability bit) =3D 1 or 0 indicates that the labels listed in=20 >>> the following label set field are available or not available,=20 >>> respectively, for use at a given priority level as indicated by the=20 >>> Priority Flags. >>>=20 >>> " >>> So does it means that there could be different "available labels sub-TL= Vs" advertised?=20 >>>=20 >>> 4) Still unclear to me how this priority is different from the one=20 >>> reported in http://tools.ietf.org/html/draft-kattan-wson-property-01=20 >>> and eventually if this "priority" could fit the LSP priority already=20 >>> available (as one of the comment we received at that time) >>>=20 >>> Cheers >>> G >>>=20 >>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From adrian@olddog.co.uk Thu Aug 9 18:46:17 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0F721F861F for ; Thu, 9 Aug 2012 18:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RWQvsuuvMIf for ; Thu, 9 Aug 2012 18:46:16 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id B78C621F8624 for ; Thu, 9 Aug 2012 18:46:15 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7A1kEv1019264; Fri, 10 Aug 2012 02:46:14 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7A1kChE019256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Aug 2012 02:46:13 +0100 From: "Adrian Farrel" To: "'Lou Berger'" , References: <021a01cd7536$2104aa10$630dfe30$@olddog.co.uk> <50227712.4010203@labn.net> In-Reply-To: <50227712.4010203@labn.net> Date: Fri, 10 Aug 2012 02:46:10 +0100 Message-ID: <056001cd7699$eb953330$c2bf9990$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH2xGWI71ErEuAv2SBWNzwa8SIWFAJTXtInlu0K0eA= Content-Language: en-gb Cc: draft-ietf-ccamp-assoc-ext.all@tools.ietf.org, 'CCAMP' Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 01:46:17 -0000 Hi, Nearly there. See in line. Thanks or the work. Adrian > > To start with, a key question: > > > > Why does the working group want to publish this as an RFC when there > > is no immediate intention to implement for any of the many scenarios > > described in the document? > > > > Will this become just another Standards Track RFC that gathers dust > > and obfuscates the real protocol specs, or is there good reason to > > publish it? > > > > The document was motivated to support applications such as defined in > draft-ietf-ccamp-rsvp-resource-sharing (whose authors say they intend to > revive this work now that the foundation work has reach maturity.) OK. I think that this and the other responses probably tip it towards publication. It feels a little premature, but not overly. > > I can see how this updates 4872. > > > > I am not convinced about this being an update to 2205, 3209 and 3473. [snip] The bottom line here appears to be: - leave updates 4872 - remove updates 2205, 3209, 3473 - retain text in Section 3 - don't add updates 4873 > > Section 1 > > > > Some ambiguity, since it looks like the extension is to recovery > > contexts other than GMPLS! > > > > OLD > > This document expands the possible usage of the ASSOCIATION object to > > non-GMPLS recovery contexts. > > NEW > > This document expands the possible usage of the ASSOCIATION object to > > contexts other than GMPLS recovery. > > END > > I agree -- looking at it again after all this time. > > How about (in multiple places) > OLD > non-GMPLS recovery > NEW > non-GMPLS and non-recovery wfm > > Section 1 Voice Call Waiting > > > > However, > > there is no way in RSVP today to share the resources between the > > A->B and A->C subflows of the call since by definition the RSVP > > reservations for these subflows must have different IP addresses > > in the SESSION objects. > > > > Since you are defining such a mechanism, "there is no way today" is not > > true. I suggest... > > > > Since, by definition, the RSVP reservations for the subflows A->B > > and A->C of the call must have different IP addresses in the > > SESSION objects, this document defines a new mechanism to > > associate the subflows and allow them to share resources. > > looks good to me. (assuming my co-authors don't object.) You have acks > > Similarly... > > > > OLD > > o Voice Shared Line: > > A single number that rings multiple endpoints (which may be > > geographically diverse), such as phone lines on a manager's desk > > and their assistant. A VoIP system that models these calls as > > multiple P2P unicast pre-ring reservations would result in > > significantly over-counting bandwidth on shared links, since > > today unicast reservations to different endpoints cannot share > > bandwidth. > > NEW > > o Voice Shared Line: > > A voice shared line is a single number that rings multiple > > endpoints (which may be geographically diverse), such as phone > > lines to a manager's desk and to their assistant. A VoIP system > > that models these calls as multiple P2P unicast pre-ring > > reservations would result in significantly over-counting > > bandwidth on shared links, since RSVP unicast reservations to > > different endpoints cannot share bandwidth. So a new mechanism > > is defined in this document allowing separate unicast > > reservations to be associated and share resources. > > END > > okay (assuming my co-authors don't object.) You have acks > > And... > > > > OLD > > o Symmetric NAT: > > RSVP permits sharing of resources between multiple flows > > addressed to the same destination D, even from different senders > > S1 and S2. However, if D is behind a NAT operating in symmetric > > mode [RFC5389], it is possible that the destination port of the > > flows S1->D and S2->D may be different outside the NAT. In this > > case, these flows cannot share resources using RSVP today, since > > the SESSION objects for these two flows outside the NAT would > > have different ports. > > NEW > > o Symmetric NAT: > > RSVP permits sharing of resources between multiple flows > > addressed to the same destination D, even from different senders > > S1 and S2. However, if D is behind a NAT operating in symmetric > > mode [RFC5389], it is possible that the destination port of the > > flows S1->D and S2->D may be different outside the NAT. In this > > case, these flows cannot share resources using RSVP, since the > > SESSION objects for these two flows outside the NAT have > > different ports. This document defines a new mechanisms to > > associate these flows and allow them to share resources. > > END > > okay (assuming my co-authors don't object.) You have acks > > Globally... > > > > s/extended ASSOCIATION/Extended ASSOCIATION/ > > sure > > > Section 1 > > > > OLD > > This document also defines the extended ASSOCIATION objects which can > > be used in the context of Transport Profile of Multiprotocol Label > > Switching (MPLS-TP). Although, the scope of the extended ASSOCIATION > > objects is not limited to MPLS-TP. > > NEW > > This document also defines the Extended ASSOCIATION objects which can > > be used in the context of the Transport Profile of Multiprotocol > > Label Switching (MPLS-TP). The scope of the Extended ASSOCIATION > > objects is not limited to MPLS-TP. > > END > > sure. > > > --- > > > > As with the previous ambiguity... > > > > OLD > > 3. Non-GMPLS Recovery Usage > > NEW > > 3. Uses other Than GMPLS Recovery > > END > > propose same change as above: Non-GMPLS and Non-Recovery Usage OK > > Section 3.1 > > > > s/defined generic/defines generic/ > > thanks. > > > Section 3.1.2 > > > > A node that wishes to > > allow downstream nodes to associate Path state across RSVP sessions > > MUST include an ASSOCIATION object in the outgoing Path messages > > corresponding to the RSVP sessions to be associated. > > > > Yuck! > > > > Are the sessions to be associated in the outgoing Path messages or the > > Association object, or both. Actually, I don't think this needs a MUST, > > but can be converted to descriptive text as follows. > > Agreed. This sentence is clearly subject to misinterpretation and must > be fixed! > > > A node that wishes to allow downstream nodes to associate Path state > > across RSVP sessions sends a Path message corresponding to one RSVP > > session and includes in that message an ASSOCIATION object that > > indicates the associated RSVP sessions. > > I think this actually doesn't match our intent. > > See below for proposed wording as I think it's easier to parse the > sentences changes/together. > > > Then you have... > > > > In the absence > > of Association Type-specific rules for identifying association, the > > included ASSOCIATION objects MUST be identical across all associated > > sessions. > > > > I know what you mean, but what you have said would require that a Path > > message must contain an Association object that refers to itself. I > > think what you need has to be more verbose to be accurate. > > > > In the absence > > of Association Type-specific rules for identifying association, each > > Path message for a session in a set of associated sessions MUST > > include an ASSOCIATION object that indicates all the other sessions > > in the set. > > how about: > To indicate association between multiple sessions, an appropriate > ASSOCIATION object MUST be included in the outgoing > Path messages corresponding to each of the associated sessions. > In the absence of Association Type-specific rules for identifying > association, the included ASSOCIATION object MUST be identical. OK > > 3.1.1 vs 3.2.1 > > > > In 3.1.1 you have... > > Relative ordering of ASSOCIATION objects of the same > > type SHOULD be preserved by transit nodes. > > note this is path processing, > > > In 3.2.1 you have... > > Relative ordering of ASSOCIATION objects of the same > > type MUST be preserved by transit nodes. Association type specific > > ordering requirements MAY be defined in the future. > > Note this is resv processing. > > > 1. Why is 3.1.1 SHOULD and 3.1.2 MUST? > > I'm not sure, other than 3.1.2 is new so there's no chance of placing a > new requirement on implementations of 4872&3 (which only use association > objects in Path messages.) > > I'm fine with should for both. > > Co-authors? Francois seems to indicate SHOULD and SHOULD is OK. > > 2. Why does 3.2.1 consider association type-specific rules, but these > > are not in 3.1.1? > > 3.1.1 relates to path messages and we didn't want to impose new > requirements on implementations of 4872&3. > > > 3. s/type specific/Type-specific/ > > sure. > > > 4. Why "MAY" not "may"? > > over zealousness. i.e., your right! > > > 3.2.2 > > > > s/This section apply/This section applies/ > > Thanks. > > > 3.3.1 > > > > Once an association is identified, resources SHOULD be shared across > > the identified sessions. > > > > This use of "SHOULD" begs the question: under what circumstances MAY > > resource sharing not be applied? > > actual resource allocation is really an implementation choice and > different internal implementation choices. We didn't want to overly > constrain an implementation. "is expected" is really what we mean, but > how do you say this in 2119 language? I think you are fine using SHOULD in this case. But you need to add ...although implementations MAY vary this according to local policy and resource-sharing capabilities. (Note that Francois proposed to promote this to a MUST, which would be OK, but doesn't seem to be the original intent.) > > Globally... > > > > Please be consistent with: > > - Association ID > > - association-id > > okay. > > > Section 4.1 > > > > Global Association Source: 4 bytes > > > > This field contains a value that is a unique global identifier. > > This field MAY contain the 2-octet or 4-octet value of the > > provider's Autonomous System Number (ASN). It is expected that > > the global identifier will be derived from the globally unique ASN > > of the autonomous system hosting the Association Source. The > > special value of zero (0) indicates that no global identifier is > > present. Note that a Global Association Source of zero SHOULD be > > limited to entities contained within a single operator. > > > > Given the statement that the content is globally unique, I don't think > > there is room for you to pontificate about how this field might be > > filled. You need to make a definitive statement. Otherwise the content > > cannot be guaranteed to be globally unique (unless you envisage a > > central registration system!). > > Humm this text is actually lifted from 6370 which says: > > Quoting from RFC 5003, Section 3.2: > The global ID can contain the 2-octet or 4-octet value of the > provider's Autonomous System Number (ASN). It is expected that > the global ID will be derived from the globally unique ASN of the > autonomous system hosting the PEs containing the actual AIIs. The > presence of a global ID based on the operator's ASN ensures that > the AII will be globally unique. > > How about: > > This field contains a value that is a unique global identifier. > This field MAY contain the Global_ID as defined in [RFC6370]. > The special value of zero (0) indicates that no global identifier > is present. Note that a Global Association Source of zero SHOULD be > limited to entities contained within a single operator. Notwithstanding the problems of ambiguity introduced in RFC 5003 (the text you quote is poor, but section 3.2 is clearer about the actual content of the identifier) *this* document must not be ambiguous. Noting also that RFC 5003 allows a provider to decide to not bother with global uniqueness. So, I would prefer you to write... This field contains a value that is a unique global identifier using the Global_ID as defined in [RFC6370] or the value zero (0). The special value of zero indicates that no global identifier is present. Note that a Global Association Source of zero SHOULD be limited to entities contained within a single operator. > > Section 4.1 > > > > Extended Association ID: variable, 4-byte aligned > > > > This field contains data that is additional information to support > > unique identification. The length and contents of this field is > > determined by the Association Source. This field MAY be omitted, > > i.e., have a zero length. This field MUST be padded with zeros > > (0s) to ensure 32-bit alignment. > > > > This is confusing. I think that the length of the field is chosen by the > > Association source and determined by the Length field of the Association > > object. > > > > But your text implies that the contents of the field may be different > > from a four octet quantity. Since you have not included a separate > > length indicator, this cannot be. The object length must always be a > > multiple of 4 (says RFC 2205) and so there is no difference between a > > zero padded field and a field where the zeros have meaning. > > > > You *could* say that the length of this field is Association Type- > > specific, but that would be ugly. > > How about: > Extended Association ID: variable, 4-byte aligned > > This field contains data that is additional information to support > unique identification. The length and contents of this field is > determined by the Association Source. The length of this field > is derive from the object Length field and as such MUST have a > zero length or be 4-byte aligned. A zero length indicates that > this field is omitted. Still having trouble with "determined by". Try "dependent on". s/derive/derived/ > > While you're at it, please note that draft-ietf-ccamp-assoc-info has > > been published as RFC 6689 > > Sure. From leeyoung@huawei.com Thu Aug 9 22:11:21 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FF411E80DE for ; Thu, 9 Aug 2012 22:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2Op5WOhTVQh for ; Thu, 9 Aug 2012 22:11:19 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDB511E8087 for ; Thu, 9 Aug 2012 22:11:19 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIS22811; Thu, 09 Aug 2012 21:11:18 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 9 Aug 2012 22:10:27 -0700 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.49]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Thu, 9 Aug 2012 22:10:25 -0700 From: Leeyoung To: Rajan Rao , "Giovanni Martinelli (giomarti)" Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority Thread-Index: AQHNcAyuJFh0KZM0PEuR5rvzvXz1+5dFha9ggAB9XQD//4xN4IABmgCA//+RYuCAAIYUgIAK0m1AgACdVID//9B+8A== Date: Fri, 10 Aug 2012 05:10:24 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172906059C@dfweml511-mbs.china.huawei.com> References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED70@dfweml511-mbs.china.huawei.com> <48F63A76-53E9-4C38-A266-8B8BAB9F7838@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905EEC1@dfweml511-mbs.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D347EE54E@SV-EXDB-PROD2.infinera.com> <7AEB3D6833318045B4AE71C2C87E8E172905FCB0@dfweml511-mbs.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D34807E2F@SV-EXDB-PROD2.infinera.com> In-Reply-To: <650AA355E323C34D9D4AAEED952E053D34807E2F@SV-EXDB-PROD2.infinera.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , Mohit Misra , Ashok Kunjidhapatham , Subhendu Chattopadhyay Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 05:11:21 -0000 Hi Rajan, I think what you are suggesting is all agreeable with me. Please see in-lin= e for my comment. Regards, Young -----Original Message----- From: Rajan Rao [mailto:rrao@infinera.com]=20 Sent: Thursday, August 09, 2012 7:18 PM To: Leeyoung; Giovanni Martinelli (giomarti) Cc: CCAMP; Subhendu Chattopadhyay; Ashok Kunjidhapatham; Khuzema Pithewan; = Biao Lu; Mohit Misra Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Young, et al The confusion is mainly about which fields are applicable where. We need to= clarify usage for routing and signaling cases for the following fields: - Action field in Label set - A-bit in Available Labels - Priority field in Available labels Let us agree on what is required for routing and signaling: 1) Routing: cares about what lambda is available at what priorities. S= o, =20 a) Action =3D inclusive List | Inclusive Range | BitMap are useful. =20 Action =3D Exclusive List | Exclusive Range is not of much use =20 My preference would be to go with one option (bit-map) and don't expo= se Action field at all in BW advertisements. Like to hear from others. YOUNG>> Bit-map is most basic representation of Action Field. If you prefer= Bit-map set representation, then Action Field in Label Set TLV would be Ac= tion =3D=3D 4, which is Bit Map set. We can make this value (=3D=3D4) as on= ly valid option, if you prefer. Inclusive List/ Inclusive Range might be st= ill useful for compact encoding for some cases.=20 b) A-bit is not useful/redundant we can take it out. YOUNG>> It can be done that way. Not a problem.=20 c) Priority field is useful/required. Regarding 3bit field Vs. 8bit fiel= d, I would go with 8-bit field to be consistent with usage in PSC, TDM en= codings. They use 8-bit priority field. YOUNG>> 8 bit vs 3 bit is not an important issue. As you said, if PSC, TDM= use 8-bit, we can put 8-bit flag back to encoding.=20 2) Signaling: cares about what lambda to use or not use for an LSP. So, a) Action field - all values are applicable b) A-bit is not required YOUNG>> Agreed.=20 c) Priority field is not required as Action field identifies resources @ = priority-p for the LSP being setup @ priority-p. YOUNG>> Yes. Since LSP has its priority so we do not need to make use of pr= iority field. ---- is this your logic?=20 Would like to hear comments from others as well. YOUNG>> So the only changed in this draft would be: (i) delete A bit, (ii) = make priority bit =3D=3D 8 (if others agree). Routing draft will refer to = this draft and will need to specify valid Action Fields for its use. (We ag= reed not to use Exclusive Range/List while use of Bit Map is agreed. Inclus= ive Range/List may need to be further debated.)=20 YOUNG>> Signaling draft will do the similar thing.=20 Thanks Rajan -----Original Message----- From: Leeyoung [mailto:leeyoung@huawei.com]=20 Sent: Thursday, August 09, 2012 3:45 PM To: Rajan Rao; Giovanni Martinelli (giomarti) Cc: CCAMP Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Rajan and Giovanni,=20 Per your request, the following two changes can be made to Generic Constrai= nt Encode draft. 1. Priority Flags are changed to 3 bits=20 2. Illustrative Examples are given in Appendix.=20 Check if this makes sense and give me your comments. Once we would agree on= this, all the pending issues will be closed and we can update the draft re= ady for WG LC. Best Regards, Young ---------------------------------------------------------------------------= ------------------------------------ 1. The following is a new encoding for Available/Shared Backup Labels Sub-T= LV: 2.3 (2.4) Available (Shared Backup) Labels sub-TLV=20 The Available (Shared Backup) Labels sub-TLV link consists of an availabili= ty flag, priority flags, and a single variable length label set field as fo= llows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| PRI | Reserve | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where A (Availability bit) =3D 1 or 0 indicates that the labels listed in the fol= lowing label set field are available or not available, respectively, for us= e at a given priority level as indicated by the Priority Flags. PRI (Priority Flags, 3 bits): Indicates priority level applied to Label Set= Field.=20 000: Priority Level 0 001: Priority Level 1 010: Priority Level 2 011: Priority Level 3 100: Priority Level 4 101: Priority Level 5 110: Priority Level 6 111: Priority Level 7 If A bit is set then the labels in the label set field are available or not= available as indicated by the A bit for use at that particular priority le= vel. 2. Illustrative Examples A.5. Priority Flags in Available/Shared Backup Labels sub-TLV=20 If one wants to make a set of labels (indicated by Label Set Field #1) avai= lable for all priority levels (level 0 to 7) while allowing a set of labels= (indicated by Label Set Field #2) only to available to the highest priorit= y (Priority Level 7), the following encoding will express such need.=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0 0 0| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #1 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1 1 1| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #2 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Alternatively, the following encoding expresses the same need by using A bi= t (A=3D0) as a mechanism to make unavailable a certain set of labels for al= l priority levels except the highest priority Level 7.=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1 1 0| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set Field #2 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that when a set of labels (indicated by Label Set Field #2) is unavail= able for Priority Level 6 (indicated by Priority Flag 110), this implies th= at these labels are not also available for lower Priority levels, 0-5. The = above encoding also implies that all other labels except those defined unde= r Label Set Field #2 are available for all priority levels. -----Original Message----- From: Rajan Rao [mailto:rrao@infinera.com] Sent: Thursday, August 02, 2012 12:40 PM To: Leeyoung; Giovanni Martinelli (giomarti) Cc: CCAMP Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Giovanni, My comment few months ago was to cover bandwidth advertisement at all 8 pr= iority levels as in PSC, TDM & TDM-OTN switching cases. The priority bas= ed advertisement in WSON/LSC is no different from other cases. What might be useful is to add couple of examples to show how this is used = along with other flags. Hope this helps. Thanks Rajan -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= eeyoung Sent: Thursday, August 02, 2012 9:57 AM To: Giovanni Martinelli (giomarti) Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Giovanni, Please see in-line for my responses. Thanks.=20 -----Original Message----- From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] Sent: Thursday, August 02, 2012 11:16 AM To: Leeyoung Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Young, btw first just a naming issue (I guess a question for the wg in general) th= e object label_set here has the same name name as the label_set form rfc347= 1 but it has actually a different encoding, so just asking if worth figurin= g out a little different name. If no one complain I'm fine too. YOUNG>> We are expanding the label set concept from 3471. I am not sure if = there is a new name needed here. I defer this to WG chairs.=20 please see inline On Aug 2, 2012, at 1:18 , Leeyoung wrote: > > On Aug 2, 2012, at 24:25 , Leeyoung wrote: >=20 >> Hi Giovanni, >>=20 >> The wavelength priority you propose seems different from the what we enc= oded per Rao Rajan's suggestion. What we encoded in section 2.3 of gen enco= de is not giving wavelength a priority level, among which I believe your wa= velength property specifies. >>=20 >> What we are proposing is what labels are available/not available for eac= h priority level (similar to LSP reservation or holding priority) as the fo= llowing encoding dictates:=20 >>=20 >=20 >=20 > GM> So at the end is a "Label Priority" ? With the Label_Set granularity = instead of the single Label? =20 >=20 > YOUNG>> No, this is not "label priority". Label is not "assigned" a prior= ity. Label is neutral. Say, you have five wavelengths available for grab an= d you have two priorities you are aware of which is service level (e.g., LS= P). For higher priority service, you may want to all your five wavelengths = (w1-w5) available for grab while for lower priority, you may restrict to le= ss number of wavelengths, say three wavelengths only (e.g., w1-w3). GM> Well I'm not sure I'm following you, you say that labels are not assign= ed to a priority but then there is a priority associated to a label set. Fo= r sure label is neutral but "someone" decide if it goes in a label set with= a certain priority, or in another (or in both label_set ). So, to me this = means associate (is this term better than assign?) a priority to a label. YOUNG>> I think I explained enough what the current encoding is. This is ab= out what labels are available for LSP priority. Some labels may be availabl= e for more than one LSP priority. There is no 1:1 "association" between lab= el and priority per se.=20 > Here you can see individual wavelength is not assigned a priority. GM> the granularity is the label_set so you can easily see that's equivalen= t to individual label, anyway single label or label-set its not a substanti= al difference to me. > This is analogous to how much BW availability for each priority in MPLS n= etwork, except that we need to express in wavelength level. =20 >=20 >=20 >=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |A| Reserved | Priority Flags| Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Label Set Field | >> : : >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Where >>=20 >> A (Availability bit) =3D 1 or 0 indicates that the labels listed in=20 >> the following label set field are available or not available,=20 >> respectively, for use at a given priority level as indicated by the=20 >> Priority Flags. >=20 >=20 > GM> The reading here suggest me that there could be multiple objects (I b= et up to 8) packed up somewere (e.g. something like sub-tlvs in the link ad= vertisement). Is my interpretation correct? >=20 > YOUNG>> Yes.=20 >=20 GM> two encoding question here: GM> 1/ why using flags instead of classical three bits?=20 GM> 2/ What the usage of A? I mean you have an Available_label object and t= hen you set A=3D0 which means that labels are not available... could you pl= ease clarify better? =20 YOUNG>> Yes, three bits can do that. We put A=3D0 (not available) --just to= give more flexibility. That's all. If you want to restrict some ranges of = labels to lower LSP, using A bit (A=3D0) would be more efficient to express= such need.=20 Cheers G > Cheers > G >=20 >=20 >>=20 >> Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 =20 >> corresponds to priority level 7. If a bit is set then the labels in =20 >> the label set field are available or not available as indicated by =20 >> the A bit for use at that particular priority level. >>=20 >> Let's begin if we are in agreement with this point.=20 >>=20 >> Thanks. >> Young >>=20 >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >> Behalf Of Giovanni Martinelli (giomarti) >> Sent: Wednesday, August 01, 2012 12:40 PM >> To: Giovanni Martinelli (giomarti) >> Cc: CCAMP >> Subject: Re: [CCAMP] Comment on=20 >> draft-ietf-ccamp-general-constraint-encode-08: priority >>=20 >> Here my latest mail with comments on wavelength priority...=20 >>=20 >> Here my memory on past discussion (please correct if wrong) >> - last short thread was during ieft83 (around 26/28 march), last mail wa= s from me and did not get answers. The content here below cover that mail a= s well. >> - discussions about wl priority happens among authors not on ccamp maili= ng list. On the mailing list you announce draft update around dec 2011. =20 >>=20 >> Well, I'm not complaining about how discussion happen, simply I saw a n= ot-trivial addition to wg document, hence my comments. >>=20 >> Cheers >> G >>=20 >>=20 >>=20 >> On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: >>=20 >>> Dear authors / ccamp, >>>=20 >>> here a few comments related to the priority field added to draft-ietf-c= camp-general-constraint-encode: >>>=20 >>> A couple of editorial comments >>> 1) "wavelenght priority" appears in a draft that claim to be general. = In fact is available in "Available Labels Sub-TLV" and "Shared Backup Label= s Sub-TLV". So is a wavelength or label-like priority? >>> 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0= .. 7]? >>>=20 >>>=20 >>> Then few other comments >>> 3) How the priority is used versus the A flag . Draft text report " >>> A (Availability bit) =3D 1 or 0 indicates that the labels listed in=20 >>> the following label set field are available or not available,=20 >>> respectively, for use at a given priority level as indicated by the=20 >>> Priority Flags. >>>=20 >>> " >>> So does it means that there could be different "available labels sub-TL= Vs" advertised?=20 >>>=20 >>> 4) Still unclear to me how this priority is different from the one=20 >>> reported in http://tools.ietf.org/html/draft-kattan-wson-property-01=20 >>> and eventually if this "priority" could fit the LSP priority already=20 >>> available (as one of the comment we received at that time) >>>=20 >>> Cheers >>> G >>>=20 >>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From flefauch@cisco.com Fri Aug 10 05:07:29 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0087D21F84F7 for ; Fri, 10 Aug 2012 05:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-rJJOGNvnch for ; Fri, 10 Aug 2012 05:07:28 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5C77521F84C8 for ; Fri, 10 Aug 2012 05:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=2445; q=dns/txt; s=iport; t=1344600448; x=1345810048; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tQJQDV3olVMOaQUEsBygDWuFH9Zn39Yk6sgi+cpsks0=; b=J34qYryoW76ZtiYn4ITj/TYmO2UQOsDo3XMiUjKZycMmpBoB/e7IKPCt x+wdYLmDhEDVX94PehRlgSRCZR9l0njUUmHR+Pi4xX94yY4Gy++M4Kmrs DQ/8ff7xRnMD/GOSUhTBCNlRZ/ylzY6YzM1RcD01I+S+x/cHzOhSF34QE Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAIzgI1CtJXHA/2dsb2JhbABFtjuDJ4EHgiABAQEDARIBFFIFCwIBCA4KFRkyJQEBBA4nh2UGmwagbYsPgzyCSGADiBmNMI4pgWaCXw X-IronPort-AV: E=Sophos;i="4.77,745,1336348800"; d="scan'208";a="110293999" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 10 Aug 2012 12:07:28 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7AC7RcZ032572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Aug 2012 12:07:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Fri, 10 Aug 2012 07:07:27 -0500 From: "Francois Le Faucheur (flefauch)" To: Lou Berger Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext Thread-Index: Ac11NY6nevEXepS5RqKUu/wkiJbhHgAZiUcAAANRhIAALYGUAAAu33WA Date: Fri, 10 Aug 2012 12:07:26 +0000 Message-ID: <36F8D8AE-C474-49A7-9347-671B572FFD32@cisco.com> References: <021a01cd7536$2104aa10$630dfe30$@olddog.co.uk> <50227712.4010203@labn.net> <67596B46-B753-46DC-93B8-8297EFFAF5DD@cisco.com> <5023BEBA.6080305@labn.net> In-Reply-To: <5023BEBA.6080305@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.127] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19098.003 x-tm-as-result: No--36.416500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP , "" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 12:07:29 -0000 Lou, On 9 Aug 2012, at 15:44, Lou Berger wrote: > How about "MUST be" --> "is" >=20 I think the situation is that: * we want to define a Resource Sharing Association whose semantics is clea= rly that resources ought to be shared * at the same time, all things related to admission control, bandwidth acc= ounting etc are out of scope, so the exact meaning of "sharing resources" i= s somewhat implementation specific. Do you agree? My personal preference is that : * we have a strong statement about semantics (i.e. "MUST" or a "SHOULD") * we clarify that the realization of this is somewhat implementation speci= fic (to that end, I like Adrian's suggestion below to add an explicit state= ment clarifying that it may mean different things to different implementati= ons) This is as opposed to an alternative approach which has a weak statement ("= is") on semantics of the Association. So I'd suggest something like: " Once an association is identified, resources MUST be considered as shared a= cross the identified sessions by the admission control function. Since the = admission control function is outside the scope of RSVP, we observe that ho= w resource sharing is actually reflected may vary according to specific imp= lementations (e.g. depending on the specific admission control and resource= management algorithm, or on how local policy is taken into account). " A SHOULD instead of a MUST can work for me to. Would that be acceptable? Francois > Lou >=20 > On 8/8/2012 12:02 PM, Francois Le Faucheur (flefauch) wrote: >> 2205 uses the term "Admission control", so would it work if we said: >> " >> Once an association is identified, resources MUST be considered as >> shared across >> the identified sessions by the admission control function. >> " >>=20 Adrian Farrell wrote: >> actual resource allocation is really an implementation choice and >> different internal implementation choices. We didn't want to overly >> constrain an implementation. "is expected" is really what we mean, but >> how do you say this in 2119 language? >=20 > I think you are fine using SHOULD in this case. But you need to add > ...although implementations MAY vary this according to local policy and > resource-sharing capabilities. >=20 > (Note that Francois proposed to promote this to a MUST, which would be OK= , but > doesn't seem to be the original intent.) From lberger@labn.net Fri Aug 10 07:19:10 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9030F21F85F0 for ; Fri, 10 Aug 2012 07:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.695 X-Spam-Level: X-Spam-Status: No, score=-99.695 tagged_above=-999 required=5 tests=[AWL=2.570, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Sk0A7mRoh5T for ; Fri, 10 Aug 2012 07:19:10 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id E86D221F85C3 for ; Fri, 10 Aug 2012 07:19:09 -0700 (PDT) Received: (qmail 2424 invoked by uid 0); 10 Aug 2012 14:18:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 10 Aug 2012 14:18:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=c+7rnExp4PESwBWX8xsoNzv7d9FUfVax0+o4bybmQgw=; b=xv+4zm36xwmtQWY6CSuz72IOcinRaB+mbBtrLHwvK0Xxa64pWxu9ytvsssvvRU2jqNi259UogPC+/TZ8xorcQkpNMJDKWa+iY7hAZQDRVzvRb+6nsZ9NhO12StjGIhrJ; Received: from box313.bluehost.com ([69.89.31.113]:36305 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Szq36-0003Ru-Cj; Fri, 10 Aug 2012 08:18:48 -0600 Message-ID: <50251847.2010700@labn.net> Date: Fri, 10 Aug 2012 10:18:47 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Francois Le Faucheur (flefauch)" , "" References: <021a01cd7536$2104aa10$630dfe30$@olddog.co.uk> <50227712.4010203@labn.net> <67596B46-B753-46DC-93B8-8297EFFAF5DD@cisco.com> <5023BEBA.6080305@labn.net> <36F8D8AE-C474-49A7-9347-671B572FFD32@cisco.com> In-Reply-To: <36F8D8AE-C474-49A7-9347-671B572FFD32@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "" , CCAMP Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:19:10 -0000 Francois, On 8/10/2012 8:07 AM, Francois Le Faucheur (flefauch) wrote: > Lou, > > On 9 Aug 2012, at 15:44, Lou Berger wrote: > >> How about "MUST be" --> "is" >> > > I think the situation is that: > * we want to define a Resource Sharing Association whose semantics is clearly that resources ought to be shared > * at the same time, all things related to admission control, bandwidth accounting etc are out of scope, so the exact meaning of "sharing resources" is somewhat implementation specific. > Do you agree? precisely. > > My personal preference is that : > * we have a strong statement about semantics (i.e. "MUST" or a "SHOULD") > * we clarify that the realization of this is somewhat implementation specific (to that end, I like Adrian's suggestion below to add an explicit statement clarifying that it may mean different things to different implementations) > This is as opposed to an alternative approach which has a weak statement ("is") on semantics of the Association. > > So I'd suggest something like: > "Once an association is identified, resources MUST be considered as > shared across the identified sessions by the admission control > function. Since the admission control function is outside the scope > of RSVP, we observe that how resource sharing is actually reflected > may vary according to specific implementations (e.g. depending on the > specific admission control and resource management algorithm, or on > how local policy is taken into account). " > > A SHOULD instead of a MUST can work for me to. > > Would that be acceptable? WFM Adrian are okay with this language? Lou > > Francois > > >> Lou >> >> On 8/8/2012 12:02 PM, Francois Le Faucheur (flefauch) wrote: >>> 2205 uses the term "Admission control", so would it work if we said: >>> " >>> Once an association is identified, resources MUST be considered as >>> shared across >>> the identified sessions by the admission control function. >>> " >>> > > > Adrian Farrell wrote: >>> actual resource allocation is really an implementation choice and >>> different internal implementation choices. We didn't want to overly >>> constrain an implementation. "is expected" is really what we mean, but >>> how do you say this in 2119 language? >> >> I think you are fine using SHOULD in this case. But you need to add >> ...although implementations MAY vary this according to local policy and >> resource-sharing capabilities. >> >> (Note that Francois proposed to promote this to a MUST, which would be OK, but >> doesn't seem to be the original intent.) > > > > > > From adrian@olddog.co.uk Fri Aug 10 07:47:11 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244E021F8613 for ; Fri, 10 Aug 2012 07:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aObhm-SRZ36Q for ; Fri, 10 Aug 2012 07:47:10 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6973C21F85FF for ; Fri, 10 Aug 2012 07:47:10 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7AEl6CC024850; Fri, 10 Aug 2012 15:47:06 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7AEl4Ue024838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Aug 2012 15:47:05 +0100 From: "Adrian Farrel" To: "'Lou Berger'" , "'Francois Le Faucheur \(flefauch\)'" References: <021a01cd7536$2104aa10$630dfe30$@olddog.co.uk> <50227712.4010203@labn.net> <67596B46-B753-46DC-93B8-8297EFFAF5DD@cisco.com> <5023BEBA.6080305@labn.net> <36F8D8AE-C474-49A7-9347-671B572FFD32@cisco.com> <50251847.2010700@labn.net> In-Reply-To: <50251847.2010700@labn.net> Date: Fri, 10 Aug 2012 15:47:02 +0100 Message-ID: <064001cd7707$01747c20$045d7460$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH2xGWI71ErEuAv2SBWNzwa8SIWFAJTXtInAfO9JOcCFYPjuAMdo8TRAfaCjL6WpP5PwA== Content-Language: en-gb Cc: draft-ietf-ccamp-assoc-ext.all@tools.ietf.org, 'CCAMP' Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:47:11 -0000 > > So I'd suggest something like: > > "Once an association is identified, resources MUST be considered as > > shared across the identified sessions by the admission control > > function. Since the admission control function is outside the scope > > of RSVP, we observe that how resource sharing is actually reflected > > may vary according to specific implementations (e.g. depending on the > > specific admission control and resource management algorithm, or on > > how local policy is taken into account). " > > > > A SHOULD instead of a MUST can work for me to. > > > > Would that be acceptable? > > WFM > > Adrian are okay with this language? I can live with it. It is fabulously woolly :-) "MUST be considered as shared, but might not actually be shared" I think that you are actually saying "MUST be made available to be shared across the identified sessions, but admission control..." Anyway, pick some words and go for it. A From rrao@infinera.com Fri Aug 10 10:49:38 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85ED21F8731 for ; Fri, 10 Aug 2012 10:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6bC9d3zuAvF for ; Fri, 10 Aug 2012 10:49:36 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 54AC721F8726 for ; Fri, 10 Aug 2012 10:49:36 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0283.003; Fri, 10 Aug 2012 10:49:35 -0700 From: Rajan Rao To: Leeyoung , "Giovanni Martinelli (giomarti)" Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority Thread-Index: AQHNcAy0UkTqZeG4LEua7hBAeom47ZdF/mQAgAAEqACAAAosgIABHCGAgAALcQD//5T7sIALzJqA//+U4UCAANbkAIAAWyqQ Date: Fri, 10 Aug 2012 17:49:34 +0000 Message-ID: <650AA355E323C34D9D4AAEED952E053D3480A337@SV-EXDB-PROD2.infinera.com> References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED70@dfweml511-mbs.china.huawei.com> <48F63A76-53E9-4C38-A266-8B8BAB9F7838@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905EEC1@dfweml511-mbs.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D347EE54E@SV-EXDB-PROD2.infinera.com> <7AEB3D6833318045B4AE71C2C87E8E172905FCB0@dfweml511-mbs.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D34807E2F@SV-EXDB-PROD2.infinera.com> <7AEB3D6833318045B4AE71C2C87E8E172906059C@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172906059C@dfweml511-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_650AA355E323C34D9D4AAEED952E053D3480A337SVEXDBPROD2infi_" MIME-Version: 1.0 Cc: CCAMP , Mohit Misra , Ashok Kunjidhapatham , Subhendu Chattopadhyay Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 17:49:38 -0000 --_000_650AA355E323C34D9D4AAEED952E053D3480A337SVEXDBPROD2infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Young, Pl see inline Thanks Rajan -----Original Message----- From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, August 09, 2012 10:10 PM To: Rajan Rao; Giovanni Martinelli (giomarti) Cc: CCAMP; Subhendu Chattopadhyay; Ashok Kunjidhapatham; Khuzema Pithewan; = Biao Lu; Mohit Misra Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Rajan, I think what you are suggesting is all agreeable with me. Please see in-lin= e for my comment. Regards, Young -----Original Message----- From: Rajan Rao [mailto:rrao@infinera.com] Sent: Thursday, August 09, 2012 7:18 PM To: Leeyoung; Giovanni Martinelli (giomarti) Cc: CCAMP; Subhendu Chattopadhyay; Ashok Kunjidhapatham; Khuzema Pithewan; = Biao Lu; Mohit Misra Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Young, et al The confusion is mainly about which fields are applicable where. We need to= clarify usage for routing and signaling cases for the following fields: - Action field in Label set - A-bit in Available Labels - Priority field in Available labels Let us agree on what is required for routing and signaling: 1) Routing: cares about what lambda is available at what priorities. S= o, a) Action =3D inclusive List | Inclusive Range | BitMap are useful. Action =3D Exclusive List | Exclusive Range is not of much use My preference would be to go with one option (bit-map) and don't expo= se Action field at all in BW advertisements. Like to hear from others. YOUNG>> Bit-map is most basic representation of Action Field. If you prefer= Bit-map set representation, then Action Field in Label Set TLV would be Ac= tion =3D=3D 4, which is Bit Map set. We can make this value (=3D=3D4) as on= ly valid option, if you prefer. Inclusive List/ Inclusive Range might be st= ill useful for compact encoding for some cases. b) A-bit is not useful/redundant we can take it out. YOUNG>> It can be done that way. Not a problem. c) Priority field is useful/required. Regarding 3bit field Vs. 8bit field= , I would go with 8-bit field to be consistent with usage in PSC, TDM enc= odings. They use 8-bit priority field. YOUNG>> 8 bit vs 3 bit is not an important issue. As you said, if PSC, TDM= use 8-bit, we can put 8-bit flag back to encoding. 2) Signaling: cares about what lambda to use or not use for an LSP. So, a) Action field - all values are applicable b) A-bit is not required YOUNG>> Agreed. c) Priority field is not required as Action field identifies resources @ p= riority-p for the LSP being setup @ priority-p. YOUNG>> Yes. Since LSP has its priority so we do not need to make use of pr= iority field. ---- is this your logic? Rajan>> during LSP setup the LSP priority is already known (setup/holding)= . I do not see any value in providing a label set that contains labels fo= r priorities other that what is being requested. I think it is sufficient= for upstream to provide label set for the priority for which LSP is being= setup. Would like to hear comments from others as well. YOUNG>> So the only changed in this draft would be: (i) delete A bit, YOUNG>> (ii) make priority bit =3D=3D 8 (if others agree). Routing draft YOUNG>> will refer to this draft and will need to specify valid Action YOUNG>> Fields for its use. (We agreed not to use Exclusive Range/List YOUNG>> while use of Bit Map is agreed. Inclusive Range/List may need to YOUNG>> be further debated.) YOUNG>> Signaling draft will do the similar thing. Rajan>> it is perhaps cleaner to define a new TLV without priority field = for use in signaling. This will avoid confusion. Thanks Rajan -----Original Message----- From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, August 09, 2012 3:45 PM To: Rajan Rao; Giovanni Martinelli (giomarti) Cc: CCAMP Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Rajan and Giovanni, Per your request, the following two changes can be made to Generic Constrai= nt Encode draft. 1. Priority Flags are changed to 3 bits 2. Illustrative Examples are given in Appendix. Check if this makes sense and give me your comments. Once we would agree on= this, all the pending issues will be closed and we can update the draft re= ady for WG LC. Best Regards, Young ---------------------------------------------------------------------------= ------------------------------------ 1. The following is a new encoding for Available/Shared Backup Labels Sub-T= LV: 2.3 (2.4) Available (Shared Backup) Labels sub-TLV The Available (Shared Backup) Labels sub-TLV link consists of an availabili= ty flag, priority flags, and a single variable length label set field as fo= llows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| PRI | Reserve | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Se= t Field | : = : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where A (Availability bit) =3D 1 or 0 indicates that the labels listed in the fol= lowing label set field are available or not available, respectively, for us= e at a given priority level as indicated by the Priority Flags. PRI (Priority Flags, 3 bits): Indicates priority level applied to Label Set= Field. 000: Priority Level 0 001: Priority Level 1 010: Priority Level 2 011: Priority Level 3 100: Priority Level 4 101: Priority Level 5 110: Priority Level 6 111: Priority Level 7 If A bit is set then the labels in the label set field are available or not= available as indicated by the A bit for use at that particular priority le= vel. 2. Illustrative Examples A.5. Priority Flags in Available/Shared Backup Labels sub-TLV If one wants to make a set of labels (indicated by Label Set Field #1) avai= lable for all priority levels (level 0 to 7) while allowing a set of labels= (indicated by Label Set Field #2) only to available to the highest priorit= y (Priority Level 7), the following encoding will express such need. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0 0 0| Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = Label Set Field #1 | : = = : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1 1 1| Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = Label Set Field #2 | : = = : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Alternatively, the following encoding expresses the same need by using A bi= t (A=3D0) as a mechanism to make unavailable a certain set of labels for al= l priority levels except the highest priority Level 7. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1 1 0| Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = Label Set Field #2 | : = : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that when a set of labels (indicated by Label Set Field #2) is unavail= able for Priority Level 6 (indicated by Priority Flag 110), this implies th= at these labels are not also available for lower Priority levels, 0-5. The = above encoding also implies that all other labels except those defined unde= r Label Set Field #2 are available for all priority levels. -----Original Message----- From: Rajan Rao [mailto:rrao@infinera.com] Sent: Thursday, August 02, 2012 12:40 PM To: Leeyoung; Giovanni Martinelli (giomarti) Cc: CCAMP Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Giovanni, My comment few months ago was to cover bandwidth advertisement at all 8 pr= iority levels as in PSC, TDM & TDM-OTN switching cases. The priority bas= ed advertisement in WSON/LSC is no different from other cases. What might be useful is to add couple of examples to show how this is used = along with other flags. Hope this helps. Thanks Rajan -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Leeyo= ung Sent: Thursday, August 02, 2012 9:57 AM To: Giovanni Martinelli (giomarti) Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Giovanni, Please see in-line for my responses. Thanks. -----Original Message----- From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] Sent: Thursday, August 02, 2012 11:16 AM To: Leeyoung Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Young, btw first just a naming issue (I guess a question for the wg in general) th= e object label_set here has the same name name as the label_set form rfc347= 1 but it has actually a different encoding, so just asking if worth figurin= g out a little different name. If no one complain I'm fine too. YOUNG>> We are expanding the label set concept from 3471. I am not sure if = there is a new name needed here. I defer this to WG chairs. please see inline On Aug 2, 2012, at 1:18 , Leeyoung wrote: > > On Aug 2, 2012, at 24:25 , Leeyoung wrote: > >> Hi Giovanni, >> >> The wavelength priority you propose seems different from the what we enc= oded per Rao Rajan's suggestion. What we encoded in section 2.3 of gen enco= de is not giving wavelength a priority level, among which I believe your wa= velength property specifies. >> >> What we are proposing is what labels are available/not available for eac= h priority level (similar to LSP reservation or holding priority) as the fo= llowing encoding dictates: >> > > > GM> So at the end is a "Label Priority" ? With the Label_Set granularity = instead of the single Label? > > YOUNG>> No, this is not "label priority". Label is not "assigned" a prior= ity. Label is neutral. Say, you have five wavelengths available for grab an= d you have two priorities you are aware of which is service level (e.g., LS= P). For higher priority service, you may want to all your five wavelengths = (w1-w5) available for grab while for lower priority, you may restrict to le= ss number of wavelengths, say three wavelengths only (e.g., w1-w3). GM> Well I'm not sure I'm following you, you say that labels are not assign= ed to a priority but then there is a priority associated to a label set. Fo= r sure label is neutral but "someone" decide if it goes in a label set with= a certain priority, or in another (or in both label_set ). So, to me this = means associate (is this term better than assign?) a priority to a label. YOUNG>> I think I explained enough what the current encoding is. This is ab= out what labels are available for LSP priority. Some labels may be availabl= e for more than one LSP priority. There is no 1:1 "association" between lab= el and priority per se. > Here you can see individual wavelength is not assigned a priority. GM> the granularity is the label_set so you can easily see that's equivalen= t to individual label, anyway single label or label-set its not a substanti= al difference to me. > This is analogous to how much BW availability for each priority in MPLS n= etwork, except that we need to express in wavelength level. > > > >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |A| Reserved | Priority Flags| Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Label Set Field | >> : : >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Where >> >> A (Availability bit) =3D 1 or 0 indicates that the labels listed in >> the following label set field are available or not available, >> respectively, for use at a given priority level as indicated by the >> Priority Flags. > > > GM> The reading here suggest me that there could be multiple objects (I b= et up to 8) packed up somewere (e.g. something like sub-tlvs in the link ad= vertisement). Is my interpretation correct? > > YOUNG>> Yes. > GM> two encoding question here: GM> 1/ why using flags instead of classical three bits? GM> 2/ What the usage of A? I mean you have an Available_label object and t= hen you set A=3D0 which means that labels are not available... could you pl= ease clarify better? YOUNG>> Yes, three bits can do that. We put A=3D0 (not available) --just to= give more flexibility. That's all. If you want to restrict some ranges of = labels to lower LSP, using A bit (A=3D0) would be more efficient to express= such need. Cheers G > Cheers > G > > >> >> Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 >> corresponds to priority level 7. If a bit is set then the labels in >> the label set field are available or not available as indicated by >> the A bit for use at that particular priority level. >> >> Let's begin if we are in agreement with this point. >> >> Thanks. >> Young >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccam= p-bounces@ietf.org] On >> Behalf Of Giovanni Martinelli (giomarti) >> Sent: Wednesday, August 01, 2012 12:40 PM >> To: Giovanni Martinelli (giomarti) >> Cc: CCAMP >> Subject: Re: [CCAMP] Comment on >> draft-ietf-ccamp-general-constraint-encode-08: priority >> >> Here my latest mail with comments on wavelength priority... >> >> Here my memory on past discussion (please correct if wrong) >> - last short thread was during ieft83 (around 26/28 march), last mail wa= s from me and did not get answers. The content here below cover that mail a= s well. >> - discussions about wl priority happens among authors not on ccamp maili= ng list. On the mailing list you announce draft update around dec 2011. >> >> Well, I'm not complaining about how discussion happen, simply I saw a n= ot-trivial addition to wg document, hence my comments. >> >> Cheers >> G >> >> >> >> On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: >> >>> Dear authors / ccamp, >>> >>> here a few comments related to the priority field added to draft-ietf-c= camp-general-constraint-encode: >>> >>> A couple of editorial comments >>> 1) "wavelenght priority" appears in a draft that claim to be general. = In fact is available in "Available Labels Sub-TLV" and "Shared Backup Label= s Sub-TLV". So is a wavelength or label-like priority? >>> 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0= .. 7]? >>> >>> >>> Then few other comments >>> 3) How the priority is used versus the A flag . Draft text report " >>> A (Availability bit) =3D 1 or 0 indicates that the labels listed in >>> the following label set field are available or not available, >>> respectively, for use at a given priority level as indicated by the >>> Priority Flags. >>> >>> " >>> So does it means that there could be different "available labels sub-TL= Vs" advertised? >>> >>> 4) Still unclear to me how this priority is different from the one >>> reported in http://tools.ietf.org/html/draft-kattan-wson-property-01 >>> and eventually if this "priority" could fit the LSP priority already >>> available (as one of the comment we received at that time) >>> >>> Cheers >>> G >>> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_650AA355E323C34D9D4AAEED952E053D3480A337SVEXDBPROD2infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Young,

 

Pl see inline<= /o:p>

 

Thanks

Rajan

 

-----Original Message-----
From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, August 09, 2012 10:10 PM
To: Rajan Rao; Giovanni Martinelli (giomarti)
Cc: CCAMP; Subhendu Chattopadhyay; Ashok Kunjidhapatham; Khuzema Pithewan; = Biao Lu; Mohit Misra
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority

 

Hi Rajan,

 

I think what you are suggesting is all agreeable = with me. Please see in-line for my comment.

 

Regards,

Young

 

-----Original Message-----

From: Rajan Rao [mailto:rrao@infinera= .com]

Sent: Thursday, August 09, 2012 7:18 PM

To: Leeyoung; Giovanni Martinelli (giomarti)=

Cc: CCAMP; Subhendu Chattopadhyay; Ashok Kunjidha= patham; Khuzema Pithewan; Biao Lu; Mohit Misra

Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-= general-constraint-encode-08: priority

 

Young, et al

 

The confusion is mainly about which fields are ap= plicable where. We need to clarify usage for routing and signaling cases fo= r the following fields:

 

- Action field  in Label set

- A-bit  in Available Labels

- Priority field in Available labels

 

Let us agree on what is required for routing and = signaling:

 

1) Routing:   cares about what lambda i= s available at what priorities.    So, 

 a)  Action =3D  inclusive List |&= nbsp; Inclusive Range | BitMap  are useful. 

      Action =3D&nb= sp; Exclusive List | Exclusive Range   is not of much use &n= bsp;

      My preference= would be to go with one option (bit-map) and don't expose Action field at = all in  BW advertisements. Like to hear from others.

 

YOUNG>> Bit-map is most basic representatio= n of Action Field. If you prefer Bit-map set representation, then Action Fi= eld in Label Set TLV would be Action =3D=3D 4, which is Bit Map set. We can= make this value (=3D=3D4) as only valid option, if you prefer. Inclusive List/ Inclusive Range might be still useful for c= ompact encoding for some cases.

 

 

b)  A-bit is  not useful/redundant = ; we can take it out.

 

YOUNG>> It can be done that way. Not a prob= lem.

 

c) Priority field is useful/required.  = Regarding 3bit field Vs. 8bit field,   I would go with 8-bit fie= ld to be consistent with usage in PSC, TDM encodings. They use 8-bit priori= ty field.

 

YOUNG>>  8 bit vs 3 bit is not an impo= rtant issue. As you said, if PSC, TDM use 8-bit, we can put 8-bit flag back= to encoding.

 

 

2) Signaling:  cares about what lambda to us= e or not use for an LSP.  So,

a) Action field  -  all values are appl= icable

b) A-bit  is not required

 

YOUNG>> Agreed.

 

c) Priority  field is not required as Action= field identifies resources @ priority-p for the LSP being setup @ priority= -p.

 

YOUNG>> Yes. Since LSP has its priority so = we do not need to make use of priority field. ---- is this your logic?

Rajan>>  = ;during LSP setup the LSP priority is already known (setup/holding).  =  I do not see any value in providing a label set that contains labels = for priorities other that what is being requested.   I think it is sufficient for upstream to provide label set for the priority  = for which LSP is being setup.

 

Would like to hear comments from others as well.<= o:p>

 

YOUNG>> So the only changed in this draft w= ould be: (i) delete A bit,

YOUNG>> (ii) make priority bit =3D=3D 8 (if= others agree).  Routing draft

YOUNG>> will refer to this draft and will n= eed to specify valid Action

YOUNG>> Fields for its use. (We agreed not = to use Exclusive Range/List

YOUNG>> while use of Bit Map is agreed. Inc= lusive Range/List may need to

YOUNG>> be further debated.)

 

YOUNG>> Signaling draft will do the similar= thing.

 

Rajan>>  = ;it is perhaps cleaner to define a new TLV without  priority field for= use in signaling.   This will avoid confusion.

 

Thanks

Rajan

 

-----Original Message-----

From: Leeyoung [mailto:leeyoung@huaw= ei.com]

Sent: Thursday, August 09, 2012 3:45 PM

To: Rajan Rao; Giovanni Martinelli (giomarti)

Cc: CCAMP

Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-= general-constraint-encode-08: priority

 

Hi Rajan and Giovanni,

 

Per your request, the following two changes can b= e made to Generic Constraint Encode draft.

 

1. Priority Flags are changed to 3 bits

 

2. Illustrative Examples are given in Appendix. <= o:p>

 

Check if this makes sense and give me your commen= ts. Once we would agree on this, all the pending issues will be closed and = we can update the draft ready for WG LC.

 

Best Regards,

Young

 

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

 

1. The following is a new encoding for Available/= Shared Backup Labels Sub-TLV:

 

2.3 (2.4) Available (Shared Backup) Labels sub-TL= V

 

The Available (Shared Backup) Labels sub-TLV link= consists of an availability flag, priority flags, and a single variable le= ngth label set field as follows:

   0      = ;             1=             &nb= sp;      2      &nbs= p;            3=

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |A| PRI |     &nb= sp;            =       Reserve      &= nbsp;           &nbs= p;     |

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |       = ;            &n= bsp;            = ;             &= nbsp;           &nbs= p;      Label Set Field     &n= bsp;            = ;            &n= bsp;            = ;         |

  :       = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             &= nbsp;           &nbs= p;            &= nbsp; :

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

 

Where

A (Availability bit) =3D 1 or 0 indicates that th= e labels listed in the following label set field are available or not avail= able, respectively, for use at a given priority level as indicated by the P= riority Flags.

 

PRI (Priority Flags, 3 bits): Indicates priority = level applied to Label Set Field.

        &= nbsp;       000: Priority Level 0<= /p>

        &= nbsp;       001: Priority Level 1<= /p>

      010: Priority Leve= l 2

        &= nbsp;       011: Priority Level 3<= /p>

        &= nbsp;       100: Priority Level 4<= /p>

        &= nbsp;       101: Priority Level 5<= /p>

        &= nbsp;       110: Priority Level 6<= /p>

        &= nbsp;       111: Priority Level 7<= /p>

 

If A bit is set then the labels in the label set = field are available or not available as indicated by the A bit for use at t= hat particular priority level.

 

 

2. Illustrative Examples

 

 

A.5. Priority Flags in Available/Shared Backup La= bels sub-TLV

 

If one wants to make a set of labels (indicated b= y Label Set Field #1) available for all priority levels (level 0 to 7) whil= e allowing a set of labels (indicated by Label Set Field #2) only to availa= ble to the highest priority (Priority Level 7), the following encoding will express such need.

 

   0      = ;             1=             &nb= sp;      2      &nbs= p;            3=

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |1|0 0 0|     &nb= sp;            =       Reserved      =              &n= bsp;            = ; |

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |       = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Label Set Field #1     &n= bsp;            = ;             &= nbsp;  |

  :       = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            &nbs= p;   :

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |1|1 1 1|     &nb= sp;            =       Reserved      =              &n= bsp;            = ; |

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |       = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      Label Set Field #2   &nbs= p;             = |

  :       = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            &nbs= p;    :

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

 

Alternatively, the following encoding expresses t= he same need by using A bit (A=3D0) as a mechanism to make unavailable a ce= rtain set of labels for all priority levels except the highest priority Lev= el 7.

   0     =             &nb= sp; 1           &nbs= p;       2      = ;             3=

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |0|1 1 0|     &nb= sp;            =       Reserved      =              &n= bsp;            = ; |

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |       = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      Label Set Field #2   &nbs= p;            &= nbsp; |

  :       = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;             &nb= sp;            =             &nb= sp;            =             &nb= sp;            :

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

 

Note that when a set of labels (indicated by Labe= l Set Field #2) is unavailable for Priority Level 6 (indicated by Priority = Flag 110), this implies that these labels are not also available for lower = Priority levels, 0-5. The above encoding also implies that all other labels except those defined under Label Set Fi= eld #2 are available for all priority levels.

 

-----Original Message-----

From: Rajan Rao [mailto:rrao@infinera= .com]

Sent: Thursday, August 02, 2012 12:40 PM

To: Leeyoung; Giovanni Martinelli (giomarti)=

Cc: CCAMP

Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-= general-constraint-encode-08: priority

 

Giovanni,

 

My comment  few months ago was to cover band= width advertisement at all 8 priority levels  as in PSC, TDM & TDM= -OTN switching cases.   The priority based advertisement in WSON/= LSC  is no different from other cases.

 

What might be useful is to add couple of examples= to show how this is used along with other flags.

 

Hope this helps.

Thanks

Rajan

 

-----Original Message-----

From: <= span style=3D"color:windowtext;text-decoration:none">ccamp-bounces@ietf.org= [mailto:ccamp-bounces@ietf.org] On= Behalf Of Leeyoung

Sent: Thursday, August 02, 2012 9:57 AM

To: Giovanni Martinelli (giomarti)

Cc: CCAMP

Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-= general-constraint-encode-08: priority

 

Hi Giovanni,

 

Please see in-line for my responses.

 

Thanks.

 

-----Original Message-----

From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisc= o.com]

Sent: Thursday, August 02, 2012 11:16 AM

To: Leeyoung

Cc: CCAMP

Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-= general-constraint-encode-08: priority

 

Hi Young,

 

btw first just a naming issue (I guess a question= for the wg in general) the object label_set here has the same name name as= the label_set form rfc3471 but it has actually a different encoding, so ju= st asking if worth figuring out a little different name. If no one complain I'm fine too.

 

YOUNG>> We are expanding the label set conc= ept from 3471. I am not sure if there is a new name needed here. I defer th= is to WG chairs.

 

please see inline

 

On Aug 2, 2012, at 1:18 , Leeyoung wrote:

 

> <snip>

> On Aug 2, 2012, at 24:25 , Leeyoung wrote:

>

>> Hi Giovanni,

>>

>> The wavelength priority you propose seem= s different from the what we encoded per Rao Rajan's suggestion. What we en= coded in section 2.3 of gen encode is not giving wavelength a priority leve= l, among which I believe your wavelength property specifies.

>>

>> What we are proposing is what labels are= available/not available for each priority level (similar to LSP reservatio= n or holding priority) as the following encoding dictates:

>>

>

>

> GM> So at the end is a "Label Priori= ty" ? With the Label_Set granularity instead of the single Label? = ;

>

> YOUNG>> No, this is not "label pr= iority". Label is not "assigned" a priority. Label is neutra= l. Say, you have five wavelengths available for grab and you have two prior= ities you are aware of which is service level (e.g., LSP). For higher priority service, you may want to all your five wavelengths (w1-w5)= available for grab while for lower priority, you may restrict to less numb= er of wavelengths, say three wavelengths only (e.g., w1-w3).

 

 

GM> Well I'm not sure I'm following you, you s= ay that labels are not assigned to a priority but then there is a priority = associated to a label set. For sure label is neutral but "someone"= ; decide if it goes in a label set with a certain priority, or in another (or in both label_set ). So, to me this means asso= ciate (is this term better than assign?) a priority to a label.<= /p>

 

YOUNG>> I think I explained enough what the= current encoding is. This is about what labels are available for LSP prior= ity. Some labels may be available for more than one LSP priority. There is = no 1:1 "association" between label and priority per se.

 

> Here you can see individual wavelength is no= t assigned a priority.

 

 

GM> the granularity is the label_set so you ca= n easily see that's equivalent to individual label, anyway single label or = label-set its not a substantial difference to me.

 

 

 

> This is analogous to how much BW availabilit= y for each priority in MPLS network, except that we need to express in wave= length level. 

>

>

>

>>   0    &nb= sp;            =   1           &= nbsp;       2     &n= bsp;            = ; 3

>>     0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

>>    +-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+

>>    |A| Reserved &nbs= p;  | Priority Flags|        Reserv= ed            &= nbsp;  |

>>    +-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+

>>    |   &nb= sp;            =            Label Set Fiel= d            &n= bsp;        |

>>    :   &nb= sp;            =             &nb= sp;            =             &nb= sp;         :

>>    +-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+

>>  Where

>>

>>  A (Availability bit) =3D 1 or 0 in= dicates that the labels listed in

>> the following label set field are availa= ble or not available,

>> respectively, for use at a given priorit= y level as indicated by the

>> Priority Flags.

>

>

> GM> The reading here suggest me that ther= e could be multiple objects (I bet up to 8) packed up somewere (e.g. someth= ing like sub-tlvs in the link advertisement). Is my interpretation correct?=

>

> YOUNG>> Yes.

>

 

GM> two encoding question here:

GM>  1/ why using flags instead of classi= cal three bits?

GM> 2/ What the usage of A? I mean you have an= Available_label object and then you set A=3D0 which means that labels are = not available... could you please clarify better?

YOUNG>> Yes, three bits can do that. We put= A=3D0 (not available) --just to give more flexibility. That's all. If you = want to restrict some ranges of labels to lower LSP, using A bit (A=3D0) wo= uld be more efficient to express such need.

 

Cheers

G

 

 

 

> Cheers

> G

>

>

>>

>>  Priority Flags: Bit 8 corresponds = to priority level 0 and bit 15

>> corresponds to priority level 7. If a bi= t is set then the labels in

>> the label set field are available or not= available as indicated by

>> the A bit for use at that particular pri= ority level.

>>

>> Let's begin if we are in agreement with = this point.

>>

>> Thanks.

>> Young

>>

>> -----Original Message-----

>> From: ccamp-bounces= @ietf.org [mailto:ccamp-bounces@ietf.org] On

>> Behalf Of Giovanni Martinelli (giomarti)=

>> Sent: Wednesday, August 01, 2012 12:40 P= M

>> To: Giovanni Martinelli (giomarti)<= /o:p>

>> Cc: CCAMP

>> Subject: Re: [CCAMP] Comment on

>> draft-ietf-ccamp-general-constraint-enco= de-08: priority

>>

>> Here my latest mail  with comments = on wavelength priority...

>>

>> Here my memory on past discussion (pleas= e correct if wrong)

>> - last short thread was during ieft83 (a= round 26/28 march), last mail was from me and did not get answers. The cont= ent here below cover that mail as well.

>> - discussions about wl priority happens = among authors not on ccamp mailing list. On the mailing list you announce d= raft update around dec 2011. 

>>

>> Well, I'm not complaining about how disc= ussion happen, simply I saw  a not-trivial addition to wg document, he= nce my comments.

>>

>> Cheers

>> G

>>

>>

>>

>> On Jul 31, 2012, at 24:34 , Giovanni Mar= tinelli (giomarti) wrote:

>>

>>> Dear authors / ccamp,

>>>

>>> here a few comments related to the p= riority field added to draft-ietf-ccamp-general-constraint-encode:

>>>

>>> A couple of editorial comments<= /o:p>

>>> 1)  "wavelenght priority&q= uot; appears in a draft that claim to be general. In fact is available in &= quot;Available Labels Sub-TLV" and "Shared Backup Labels Sub-TLV&= quot;. So is a wavelength or label-like priority?

>>> 2)  why an 8 bits (bit field) i= nstead of the classic 3 bits (integer [0 .. 7]?

>>>

>>>

>>> Then few other comments

>>> 3)  How the priority is used ve= rsus the A flag . Draft text report "

>>> A (Availability bit) =3D 1 or 0 indi= cates that the labels listed in

>>> the following label set field are av= ailable or not available,

>>> respectively, for use at a given pri= ority level as indicated by the

>>> Priority Flags.

>>>

>>> "

>>> So does it means that there could be= different "available labels sub-TLVs" advertised?

>>>

>>> 4) Still unclear to me how this prio= rity is different from the one

>>> reported in http://tools.ietf.org= /html/draft-kattan-wson-property-01

>>> and eventually if this "priorit= y" could fit the LSP priority already

>>> available (as one of the comment we = received at that time)

>>>

>>> Cheers

>>> G

>>>

>>

>> ________________________________________= _______

>> CCAMP mailing list

>> CCAMP@ietf.org

>> https://www.ietf.org/= mailman/listinfo/ccamp

>

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org=

https://www.ie= tf.org/mailman/listinfo/ccamp

--_000_650AA355E323C34D9D4AAEED952E053D3480A337SVEXDBPROD2infi_-- From lberger@labn.net Fri Aug 10 13:38:13 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B78811E808E for ; Fri, 10 Aug 2012 13:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.749 X-Spam-Level: X-Spam-Status: No, score=-99.749 tagged_above=-999 required=5 tests=[AWL=2.516, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cskx27B1WfqQ for ; Fri, 10 Aug 2012 13:38:12 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 4B6DC21F8682 for ; Fri, 10 Aug 2012 13:38:12 -0700 (PDT) Received: (qmail 29949 invoked by uid 0); 10 Aug 2012 20:37:43 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 10 Aug 2012 20:37:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=MCKD4qCOjtuNXpjcz+UHzqIfBcWRcynDka0Dukp3KZs=; b=tTNqMvthMQ0EkK5lG4JjkvgZUsEmMyyE0C1CaEkF/4k2pypKxNUvQBjbijs7lpGNizS3YrFFp79WVlxbMLhQF7qbsJJQ8f5JmSWpPZQjf1fYb95mpOktogO1CFnneQQF; Received: from box313.bluehost.com ([69.89.31.113]:45502 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Szvxn-0000ER-1D; Fri, 10 Aug 2012 14:37:43 -0600 Message-ID: <50257116.5030201@labn.net> Date: Fri, 10 Aug 2012 16:37:42 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <021a01cd7536$2104aa10$630dfe30$@olddog.co.uk> <50227712.4010203@labn.net> <056001cd7699$eb953330$c2bf9990$@olddog.co.uk> In-Reply-To: <056001cd7699$eb953330$c2bf9990$@olddog.co.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-ccamp-assoc-ext.all@tools.ietf.org, 'CCAMP' Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 20:38:13 -0000 Adrian, See below. On 8/9/2012 9:46 PM, Adrian Farrel wrote: > Hi, > > Nearly there. See in line. > > Thanks or the work. > > Adrian > >>> To start with, a key question: >>> >>> Why does the working group want to publish this as an RFC when there >>> is no immediate intention to implement for any of the many scenarios >>> described in the document? >>> >>> Will this become just another Standards Track RFC that gathers dust >>> and obfuscates the real protocol specs, or is there good reason to >>> publish it? >>> >> >> The document was motivated to support applications such as defined in >> draft-ietf-ccamp-rsvp-resource-sharing (whose authors say they intend to >> revive this work now that the foundation work has reach maturity.) > > OK. I think that this and the other responses probably tip it towards > publication. It feels a little premature, but not overly. > >>> I can see how this updates 4872. >>> >>> I am not convinced about this being an update to 2205, 3209 and 3473. > > [snip] > > The bottom line here appears to be: > - leave updates 4872 > - remove updates 2205, 3209, 3473 Are you sure about this? Other RFCs that provide incremental functions that are not required by all implementations identify the base protocol in the Updates field. For example, take a look at rfc5151 it says both 3209 and 3473 are updated. > - retain text in Section 3 > - don't add updates 4873 > ... > >>> 3.1.1 vs 3.2.1 >>> >>> In 3.1.1 you have... >>> Relative ordering of ASSOCIATION objects of the same >>> type SHOULD be preserved by transit nodes. >> >> note this is path processing, >> >>> In 3.2.1 you have... >>> Relative ordering of ASSOCIATION objects of the same >>> type MUST be preserved by transit nodes. Association type specific >>> ordering requirements MAY be defined in the future. >> >> Note this is resv processing. >> >>> 1. Why is 3.1.1 SHOULD and 3.1.2 MUST? >> >> I'm not sure, other than 3.1.2 is new so there's no chance of placing a >> new requirement on implementations of 4872&3 (which only use association >> objects in Path messages.) >> >> I'm fine with should for both. >> >> Co-authors? > > Francois seems to indicate SHOULD and SHOULD is OK. done, although this means that we have to drop the following sentence. > >>> 2. Why does 3.2.1 consider association type-specific rules, but these >>> are not in 3.1.1? >> >> 3.1.1 relates to path messages and we didn't want to impose new >> requirements on implementations of 4872&3. >> >>> 3. s/type specific/Type-specific/ >> >> sure. >> >>> 4. Why "MAY" not "may"? >> >> over zealousness. i.e., your right! >> >>> 3.2.2 >>> >>> s/This section apply/This section applies/ >> >> Thanks. >> >>> 3.3.1 >>> >>> Once an association is identified, resources SHOULD be shared across >>> the identified sessions. >>> >>> This use of "SHOULD" begs the question: under what circumstances MAY >>> resource sharing not be applied? >> >> actual resource allocation is really an implementation choice and >> different internal implementation choices. We didn't want to overly >> constrain an implementation. "is expected" is really what we mean, but >> how do you say this in 2119 language? > > I think you are fine using SHOULD in this case. But you need to add > ...although implementations MAY vary this according to local policy and > resource-sharing capabilities. > > (Note that Francois proposed to promote this to a MUST, which would be OK, but > doesn't seem to be the original intent.) > >>> Globally... >>> >>> Please be consistent with: >>> - Association ID >>> - association-id >> >> okay. >> >>> Section 4.1 >>> >>> Global Association Source: 4 bytes >>> >>> This field contains a value that is a unique global identifier. >>> This field MAY contain the 2-octet or 4-octet value of the >>> provider's Autonomous System Number (ASN). It is expected that >>> the global identifier will be derived from the globally unique ASN >>> of the autonomous system hosting the Association Source. The >>> special value of zero (0) indicates that no global identifier is >>> present. Note that a Global Association Source of zero SHOULD be >>> limited to entities contained within a single operator. >>> >>> Given the statement that the content is globally unique, I don't think >>> there is room for you to pontificate about how this field might be >>> filled. You need to make a definitive statement. Otherwise the content >>> cannot be guaranteed to be globally unique (unless you envisage a >>> central registration system!). >> >> Humm this text is actually lifted from 6370 which says: >> >> Quoting from RFC 5003, Section 3.2: >> The global ID can contain the 2-octet or 4-octet value of the >> provider's Autonomous System Number (ASN). It is expected that >> the global ID will be derived from the globally unique ASN of the >> autonomous system hosting the PEs containing the actual AIIs. The >> presence of a global ID based on the operator's ASN ensures that >> the AII will be globally unique. >> >> How about: >> >> This field contains a value that is a unique global identifier. >> This field MAY contain the Global_ID as defined in [RFC6370]. >> The special value of zero (0) indicates that no global identifier >> is present. Note that a Global Association Source of zero SHOULD be >> limited to entities contained within a single operator. > > Notwithstanding the problems of ambiguity introduced in RFC 5003 (the text you > quote is poor, but section 3.2 is clearer about the actual content of the > identifier) *this* document must not be ambiguous. Noting also that RFC 5003 > allows a provider to decide to not bother with global uniqueness. > > So, I would prefer you to write... > > This field contains a value that is a unique global identifier > using the Global_ID as defined in [RFC6370] or the value zero (0). > The special value of zero indicates that no global identifier is > present. Note that a Global Association Source of zero SHOULD be > limited to entities contained within a single operator. The old text allowed for TP Global_ID while you are now requiring it's use. How about: This field contains a value that is a unique global identifier or the special value zero (0). When non-zero and not overridden by local policy, the Global_ID as defined in [RFC6370] SHALL be used. The special value of zero indicates that no global identifier is present. Note that a Global Association Source of zero SHOULD be limited to entities contained within a single operator. > >>> Section 4.1 >>> >>> Extended Association ID: variable, 4-byte aligned >>> >>> This field contains data that is additional information to support >>> unique identification. The length and contents of this field is >>> determined by the Association Source. This field MAY be omitted, >>> i.e., have a zero length. This field MUST be padded with zeros >>> (0s) to ensure 32-bit alignment. >>> >>> This is confusing. I think that the length of the field is chosen by the >>> Association source and determined by the Length field of the Association >>> object. >>> >>> But your text implies that the contents of the field may be different >>> from a four octet quantity. Since you have not included a separate >>> length indicator, this cannot be. The object length must always be a >>> multiple of 4 (says RFC 2205) and so there is no difference between a >>> zero padded field and a field where the zeros have meaning. >>> >>> You *could* say that the length of this field is Association Type- >>> specific, but that would be ugly. >> >> How about: >> Extended Association ID: variable, 4-byte aligned >> >> This field contains data that is additional information to support >> unique identification. The length and contents of this field is >> determined by the Association Source. The length of this field >> is derive from the object Length field and as such MUST have a >> zero length or be 4-byte aligned. A zero length indicates that >> this field is omitted. > > Still having trouble with "determined by". Try "dependent on". how about "scoped by" > s/derive/derived/ k ... Thanks, Lou From leeyoung@huawei.com Fri Aug 10 15:42:45 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C052711E80BA for ; Fri, 10 Aug 2012 15:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D3rsKS+3qQX for ; Fri, 10 Aug 2012 15:42:43 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E82E411E80AD for ; Fri, 10 Aug 2012 15:42:42 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp03-ep.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJC61444; Fri, 10 Aug 2012 14:42:42 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 10 Aug 2012 15:41:59 -0700 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.49]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Fri, 10 Aug 2012 15:41:56 -0700 From: Leeyoung To: Rajan Rao , "Giovanni Martinelli (giomarti)" Thread-Topic: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority Thread-Index: AQHNcAyuJFh0KZM0PEuR5rvzvXz1+5dFha9ggAB9XQD//4xN4IABmgCA//+RYuCAAIYUgIAK0m1AgACdVID//9B+8AAqpkQAAASSEuA= Date: Fri, 10 Aug 2012 22:41:55 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172906081A@dfweml511-mbs.china.huawei.com> References: <98310D9B-8BF2-4C16-ABEF-F96D1DE1675C@cisco.com> <63F9D750-59E0-487B-B590-DCC2D3EBC344@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED40@dfweml511-mbs.china.huawei.com> <47594FF6-97E2-401A-8703-FAD081F28635@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905ED70@dfweml511-mbs.china.huawei.com> <48F63A76-53E9-4C38-A266-8B8BAB9F7838@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E172905EEC1@dfweml511-mbs.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D347EE54E@SV-EXDB-PROD2.infinera.com> <7AEB3D6833318045B4AE71C2C87E8E172905FCB0@dfweml511-mbs.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D34807E2F@SV-EXDB-PROD2.infinera.com> <7AEB3D6833318045B4AE71C2C87E8E172906059C@dfweml511-mbs.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D3480A337@SV-EXDB-PROD2.infinera.com> In-Reply-To: <650AA355E323C34D9D4AAEED952E053D3480A337@SV-EXDB-PROD2.infinera.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.112] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172906081Adfweml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , Ashok Kunjidhapatham , Subhendu Chattopadhyay , Mohit Misra Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-08: priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 22:42:46 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172906081Adfweml511mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rajan, I think we are in agreement in all the issues on priority encoding for Avai= lable/Shared backup Label Set sub-TLV. CCAMP WG, please send your comments on this discussion if you have other th= oughts or differing opinions. Thanks, Young From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= ajan Rao Sent: Friday, August 10, 2012 12:50 PM To: Leeyoung; Giovanni Martinelli (giomarti) Cc: CCAMP; Mohit Misra; Ashok Kunjidhapatham; Subhendu Chattopadhyay Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Young, Pl see inline Thanks Rajan -----Original Message----- From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, August 09, 2012 10:10 PM To: Rajan Rao; Giovanni Martinelli (giomarti) Cc: CCAMP; Subhendu Chattopadhyay; Ashok Kunjidhapatham; Khuzema Pithewan; = Biao Lu; Mohit Misra Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Rajan, I think what you are suggesting is all agreeable with me. Please see in-lin= e for my comment. Regards, Young -----Original Message----- From: Rajan Rao [mailto:rrao@infinera.com] Sent: Thursday, August 09, 2012 7:18 PM To: Leeyoung; Giovanni Martinelli (giomarti) Cc: CCAMP; Subhendu Chattopadhyay; Ashok Kunjidhapatham; Khuzema Pithewan; = Biao Lu; Mohit Misra Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Young, et al The confusion is mainly about which fields are applicable where. We need to= clarify usage for routing and signaling cases for the following fields: - Action field in Label set - A-bit in Available Labels - Priority field in Available labels Let us agree on what is required for routing and signaling: 1) Routing: cares about what lambda is available at what priorities. S= o, a) Action =3D inclusive List | Inclusive Range | BitMap are useful. Action =3D Exclusive List | Exclusive Range is not of much use My preference would be to go with one option (bit-map) and don't expo= se Action field at all in BW advertisements. Like to hear from others. YOUNG>> Bit-map is most basic representation of Action Field. If you prefer= Bit-map set representation, then Action Field in Label Set TLV would be Ac= tion =3D=3D 4, which is Bit Map set. We can make this value (=3D=3D4) as on= ly valid option, if you prefer. Inclusive List/ Inclusive Range might be st= ill useful for compact encoding for some cases. b) A-bit is not useful/redundant we can take it out. YOUNG>> It can be done that way. Not a problem. c) Priority field is useful/required. Regarding 3bit field Vs. 8bit field= , I would go with 8-bit field to be consistent with usage in PSC, TDM enc= odings. They use 8-bit priority field. YOUNG>> 8 bit vs 3 bit is not an important issue. As you said, if PSC, TDM= use 8-bit, we can put 8-bit flag back to encoding. 2) Signaling: cares about what lambda to use or not use for an LSP. So, a) Action field - all values are applicable b) A-bit is not required YOUNG>> Agreed. c) Priority field is not required as Action field identifies resources @ p= riority-p for the LSP being setup @ priority-p. YOUNG>> Yes. Since LSP has its priority so we do not need to make use of pr= iority field. ---- is this your logic? Rajan>> during LSP setup the LSP priority is already known (setup/holding)= . I do not see any value in providing a label set that contains labels fo= r priorities other that what is being requested. I think it is sufficient= for upstream to provide label set for the priority for which LSP is being= setup. Would like to hear comments from others as well. YOUNG>> So the only changed in this draft would be: (i) delete A bit, YOUNG>> (ii) make priority bit =3D=3D 8 (if others agree). Routing draft YOUNG>> will refer to this draft and will need to specify valid Action YOUNG>> Fields for its use. (We agreed not to use Exclusive Range/List YOUNG>> while use of Bit Map is agreed. Inclusive Range/List may need to YOUNG>> be further debated.) YOUNG>> Signaling draft will do the similar thing. Rajan>> it is perhaps cleaner to define a new TLV without priority field = for use in signaling. This will avoid confusion. Thanks Rajan -----Original Message----- From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, August 09, 2012 3:45 PM To: Rajan Rao; Giovanni Martinelli (giomarti) Cc: CCAMP Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Rajan and Giovanni, Per your request, the following two changes can be made to Generic Constrai= nt Encode draft. 1. Priority Flags are changed to 3 bits 2. Illustrative Examples are given in Appendix. Check if this makes sense and give me your comments. Once we would agree on= this, all the pending issues will be closed and we can update the draft re= ady for WG LC. Best Regards, Young ---------------------------------------------------------------------------= ------------------------------------ 1. The following is a new encoding for Available/Shared Backup Labels Sub-T= LV: 2.3 (2.4) Available (Shared Backup) Labels sub-TLV The Available (Shared Backup) Labels sub-TLV link consists of an availabili= ty flag, priority flags, and a single variable length label set field as fo= llows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| PRI | Reserve | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Se= t Field | : = : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where A (Availability bit) =3D 1 or 0 indicates that the labels listed in the fol= lowing label set field are available or not available, respectively, for us= e at a given priority level as indicated by the Priority Flags. PRI (Priority Flags, 3 bits): Indicates priority level applied to Label Set= Field. 000: Priority Level 0 001: Priority Level 1 010: Priority Level 2 011: Priority Level 3 100: Priority Level 4 101: Priority Level 5 110: Priority Level 6 111: Priority Level 7 If A bit is set then the labels in the label set field are available or not= available as indicated by the A bit for use at that particular priority le= vel. 2. Illustrative Examples A.5. Priority Flags in Available/Shared Backup Labels sub-TLV If one wants to make a set of labels (indicated by Label Set Field #1) avai= lable for all priority levels (level 0 to 7) while allowing a set of labels= (indicated by Label Set Field #2) only to available to the highest priorit= y (Priority Level 7), the following encoding will express such need. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0 0 0| Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = Label Set Field #1 | : = = : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1 1 1| Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = Label Set Field #2 | : = = : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Alternatively, the following encoding expresses the same need by using A bi= t (A=3D0) as a mechanism to make unavailable a certain set of labels for al= l priority levels except the highest priority Level 7. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1 1 0| Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = Label Set Field #2 | : = : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that when a set of labels (indicated by Label Set Field #2) is unavail= able for Priority Level 6 (indicated by Priority Flag 110), this implies th= at these labels are not also available for lower Priority levels, 0-5. The = above encoding also implies that all other labels except those defined unde= r Label Set Field #2 are available for all priority levels. -----Original Message----- From: Rajan Rao [mailto:rrao@infinera.com] Sent: Thursday, August 02, 2012 12:40 PM To: Leeyoung; Giovanni Martinelli (giomarti) Cc: CCAMP Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Giovanni, My comment few months ago was to cover bandwidth advertisement at all 8 pr= iority levels as in PSC, TDM & TDM-OTN switching cases. The priority bas= ed advertisement in WSON/LSC is no different from other cases. What might be useful is to add couple of examples to show how this is used = along with other flags. Hope this helps. Thanks Rajan -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Leeyo= ung Sent: Thursday, August 02, 2012 9:57 AM To: Giovanni Martinelli (giomarti) Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Giovanni, Please see in-line for my responses. Thanks. -----Original Message----- From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] Sent: Thursday, August 02, 2012 11:16 AM To: Leeyoung Cc: CCAMP Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority Hi Young, btw first just a naming issue (I guess a question for the wg in general) th= e object label_set here has the same name name as the label_set form rfc347= 1 but it has actually a different encoding, so just asking if worth figurin= g out a little different name. If no one complain I'm fine too. YOUNG>> We are expanding the label set concept from 3471. I am not sure if = there is a new name needed here. I defer this to WG chairs. please see inline On Aug 2, 2012, at 1:18 , Leeyoung wrote: > > On Aug 2, 2012, at 24:25 , Leeyoung wrote: > >> Hi Giovanni, >> >> The wavelength priority you propose seems different from the what we enc= oded per Rao Rajan's suggestion. What we encoded in section 2.3 of gen enco= de is not giving wavelength a priority level, among which I believe your wa= velength property specifies. >> >> What we are proposing is what labels are available/not available for eac= h priority level (similar to LSP reservation or holding priority) as the fo= llowing encoding dictates: >> > > > GM> So at the end is a "Label Priority" ? With the Label_Set granularity = instead of the single Label? > > YOUNG>> No, this is not "label priority". Label is not "assigned" a prior= ity. Label is neutral. Say, you have five wavelengths available for grab an= d you have two priorities you are aware of which is service level (e.g., LS= P). For higher priority service, you may want to all your five wavelengths = (w1-w5) available for grab while for lower priority, you may restrict to le= ss number of wavelengths, say three wavelengths only (e.g., w1-w3). GM> Well I'm not sure I'm following you, you say that labels are not assign= ed to a priority but then there is a priority associated to a label set. Fo= r sure label is neutral but "someone" decide if it goes in a label set with= a certain priority, or in another (or in both label_set ). So, to me this = means associate (is this term better than assign?) a priority to a label. YOUNG>> I think I explained enough what the current encoding is. This is ab= out what labels are available for LSP priority. Some labels may be availabl= e for more than one LSP priority. There is no 1:1 "association" between lab= el and priority per se. > Here you can see individual wavelength is not assigned a priority. GM> the granularity is the label_set so you can easily see that's equivalen= t to individual label, anyway single label or label-set its not a substanti= al difference to me. > This is analogous to how much BW availability for each priority in MPLS n= etwork, except that we need to express in wavelength level. > > > >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |A| Reserved | Priority Flags| Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Label Set Field | >> : : >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Where >> >> A (Availability bit) =3D 1 or 0 indicates that the labels listed in >> the following label set field are available or not available, >> respectively, for use at a given priority level as indicated by the >> Priority Flags. > > > GM> The reading here suggest me that there could be multiple objects (I b= et up to 8) packed up somewere (e.g. something like sub-tlvs in the link ad= vertisement). Is my interpretation correct? > > YOUNG>> Yes. > GM> two encoding question here: GM> 1/ why using flags instead of classical three bits? GM> 2/ What the usage of A? I mean you have an Available_label object and t= hen you set A=3D0 which means that labels are not available... could you pl= ease clarify better? YOUNG>> Yes, three bits can do that. We put A=3D0 (not available) --just to= give more flexibility. That's all. If you want to restrict some ranges of = labels to lower LSP, using A bit (A=3D0) would be more efficient to express= such need. Cheers G > Cheers > G > > >> >> Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 >> corresponds to priority level 7. If a bit is set then the labels in >> the label set field are available or not available as indicated by >> the A bit for use at that particular priority level. >> >> Let's begin if we are in agreement with this point. >> >> Thanks. >> Young >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccam= p-bounces@ietf.org] On >> Behalf Of Giovanni Martinelli (giomarti) >> Sent: Wednesday, August 01, 2012 12:40 PM >> To: Giovanni Martinelli (giomarti) >> Cc: CCAMP >> Subject: Re: [CCAMP] Comment on >> draft-ietf-ccamp-general-constraint-encode-08: priority >> >> Here my latest mail with comments on wavelength priority... >> >> Here my memory on past discussion (please correct if wrong) >> - last short thread was during ieft83 (around 26/28 march), last mail wa= s from me and did not get answers. The content here below cover that mail a= s well. >> - discussions about wl priority happens among authors not on ccamp maili= ng list. On the mailing list you announce draft update around dec 2011. >> >> Well, I'm not complaining about how discussion happen, simply I saw a n= ot-trivial addition to wg document, hence my comments. >> >> Cheers >> G >> >> >> >> On Jul 31, 2012, at 24:34 , Giovanni Martinelli (giomarti) wrote: >> >>> Dear authors / ccamp, >>> >>> here a few comments related to the priority field added to draft-ietf-c= camp-general-constraint-encode: >>> >>> A couple of editorial comments >>> 1) "wavelenght priority" appears in a draft that claim to be general. = In fact is available in "Available Labels Sub-TLV" and "Shared Backup Label= s Sub-TLV". So is a wavelength or label-like priority? >>> 2) why an 8 bits (bit field) instead of the classic 3 bits (integer [0= .. 7]? >>> >>> >>> Then few other comments >>> 3) How the priority is used versus the A flag . Draft text report " >>> A (Availability bit) =3D 1 or 0 indicates that the labels listed in >>> the following label set field are available or not available, >>> respectively, for use at a given priority level as indicated by the >>> Priority Flags. >>> >>> " >>> So does it means that there could be different "available labels sub-TL= Vs" advertised? >>> >>> 4) Still unclear to me how this priority is different from the one >>> reported in http://tools.ietf.org/html/draft-kattan-wson-property-01 >>> and eventually if this "priority" could fit the LSP priority already >>> available (as one of the comment we received at that time) >>> >>> Cheers >>> G >>> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_7AEB3D6833318045B4AE71C2C87E8E172906081Adfweml511mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rajan,

 

I think we are in agre= ement in all the issues on priority encoding for Available/Shared backup La= bel Set sub-TLV.

 

CCAMP WG, please send = your comments on this discussion if you have other thoughts or differing op= inions.

 

Thanks,

Young

 

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao
Sent: Friday, August 10, 2012 12:50 PM
To: Leeyoung; Giovanni Martinelli (giomarti)
Cc: CCAMP; Mohit Misra; Ashok Kunjidhapatham; Subhendu Chattopadhyay=
Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-= encode-08: priority

 

Young,

 

Pl see inline<= /o:p>

 

Thanks

Rajan

 

-----Original Message-----
From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, August 09, 2012 10:10 PM
To: Rajan Rao; Giovanni Martinelli (giomarti)
Cc: CCAMP; Subhendu Chattopadhyay; Ashok Kunjidhapatham; Khuzema Pithewan; = Biao Lu; Mohit Misra
Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-general-constraint-encode-= 08: priority

 

Hi Rajan,

 

I think what you are suggesting is all agreeable = with me. Please see in-line for my comment.

 

Regards,

Young

 

-----Original Message-----

From: Rajan Rao [mailto:rrao@infinera= .com]

Sent: Thursday, August 09, 2012 7:18 PM

To: Leeyoung; Giovanni Martinelli (giomarti)=

Cc: CCAMP; Subhendu Chattopadhyay; Ashok Kunjidha= patham; Khuzema Pithewan; Biao Lu; Mohit Misra

Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-= general-constraint-encode-08: priority

 

Young, et al

 

The confusion is mainly about which fields are ap= plicable where. We need to clarify usage for routing and signaling cases fo= r the following fields:

 

- Action field  in Label set

- A-bit  in Available Labels

- Priority field in Available labels

 

Let us agree on what is required for routing and = signaling:

 

1) Routing:   cares about what lambda i= s available at what priorities.    So, 

 a)  Action =3D  inclusive List |&= nbsp; Inclusive Range | BitMap  are useful. 

      Action =3D&nb= sp; Exclusive List | Exclusive Range   is not of much use &n= bsp;

      My preference= would be to go with one option (bit-map) and don't expose Action field at = all in  BW advertisements. Like to hear from others.

 

YOUNG>> Bit-map is most basic representatio= n of Action Field. If you prefer Bit-map set representation, then Action Fi= eld in Label Set TLV would be Action =3D=3D 4, which is Bit Map set. We can= make this value (=3D=3D4) as only valid option, if you prefer. Inclusive List/ Inclusive Range might be still useful for c= ompact encoding for some cases.

 

 

b)  A-bit is  not useful/redundant = ; we can take it out.

 

YOUNG>> It can be done that way. Not a prob= lem.

 

c) Priority field is useful/required.  = Regarding 3bit field Vs. 8bit field,   I would go with 8-bit fie= ld to be consistent with usage in PSC, TDM encodings. They use 8-bit priori= ty field.

 

YOUNG>>  8 bit vs 3 bit is not an impo= rtant issue. As you said, if PSC, TDM use 8-bit, we can put 8-bit flag back= to encoding.

 

 

2) Signaling:  cares about what lambda to us= e or not use for an LSP.  So,

a) Action field  -  all values are appl= icable

b) A-bit  is not required

 

YOUNG>> Agreed.

 

c) Priority  field is not required as Action= field identifies resources @ priority-p for the LSP being setup @ priority= -p.

 

YOUNG>> Yes. Since LSP has its priority so = we do not need to make use of priority field. ---- is this your logic?

Rajan>>  = ;during LSP setup the LSP priority is already known (setup/holding).  =  I do not see any value in providing a label set that contains labels = for priorities other that what is being requested.   I think it is sufficient for upstream to provide label set for the priority  = for which LSP is being setup.

 

Would like to hear comments from others as well.<= o:p>

 

YOUNG>> So the only changed in this draft w= ould be: (i) delete A bit,

YOUNG>> (ii) make priority bit =3D=3D 8 (if= others agree).  Routing draft

YOUNG>> will refer to this draft and will n= eed to specify valid Action

YOUNG>> Fields for its use. (We agreed not = to use Exclusive Range/List

YOUNG>> while use of Bit Map is agreed. Inc= lusive Range/List may need to

YOUNG>> be further debated.)

 

YOUNG>> Signaling draft will do the similar= thing.

 

Rajan>>  = ;it is perhaps cleaner to define a new TLV without  priority field for= use in signaling.   This will avoid confusion.

 

Thanks

Rajan

 

-----Original Message-----

From: Leeyoung [mailto:leeyoung@huaw= ei.com]

Sent: Thursday, August 09, 2012 3:45 PM

To: Rajan Rao; Giovanni Martinelli (giomarti)

Cc: CCAMP

Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-= general-constraint-encode-08: priority

 

Hi Rajan and Giovanni,

 

Per your request, the following two changes can b= e made to Generic Constraint Encode draft.

 

1. Priority Flags are changed to 3 bits

 

2. Illustrative Examples are given in Appendix. <= o:p>

 

Check if this makes sense and give me your commen= ts. Once we would agree on this, all the pending issues will be closed and = we can update the draft ready for WG LC.

 

Best Regards,

Young

 

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

 

1. The following is a new encoding for Available/= Shared Backup Labels Sub-TLV:

 

2.3 (2.4) Available (Shared Backup) Labels sub-TL= V

 

The Available (Shared Backup) Labels sub-TLV link= consists of an availability flag, priority flags, and a single variable le= ngth label set field as follows:

   0      = ;             1=             &nb= sp;      2      &nbs= p;            3=

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |A| PRI |     &nb= sp;            =       Reserve      &= nbsp;           &nbs= p;     |

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |       = ;            &n= bsp;            = ;             &= nbsp;           &nbs= p;      Label Set Field     &n= bsp;            = ;            &n= bsp;            = ;         |

  :       = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             &= nbsp;           &nbs= p;            &= nbsp; :

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

 

Where

A (Availability bit) =3D 1 or 0 indicates that th= e labels listed in the following label set field are available or not avail= able, respectively, for use at a given priority level as indicated by the P= riority Flags.

 

PRI (Priority Flags, 3 bits): Indicates priority = level applied to Label Set Field.

        &= nbsp;       000: Priority Level 0<= /p>

        &= nbsp;       001: Priority Level 1<= /p>

      010: Priority Leve= l 2

        &= nbsp;       011: Priority Level 3<= /p>

        &= nbsp;       100: Priority Level 4<= /p>

        &= nbsp;       101: Priority Level 5<= /p>

        &= nbsp;       110: Priority Level 6<= /p>

        &= nbsp;       111: Priority Level 7<= /p>

 

If A bit is set then the labels in the label set = field are available or not available as indicated by the A bit for use at t= hat particular priority level.

 

 

2. Illustrative Examples

 

 

A.5. Priority Flags in Available/Shared Backup La= bels sub-TLV

 

If one wants to make a set of labels (indicated b= y Label Set Field #1) available for all priority levels (level 0 to 7) whil= e allowing a set of labels (indicated by Label Set Field #2) only to availa= ble to the highest priority (Priority Level 7), the following encoding will express such need.

 

   0      = ;             1=             &nb= sp;      2      &nbs= p;            3=

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |1|0 0 0|     &nb= sp;            =       Reserved      =              &n= bsp;            = ; |

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |       = ;            &n= bsp;            &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Label Set Field #1     &n= bsp;            = ;             &= nbsp;  |

  :       = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            &nbs= p;   :

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |1|1 1 1|     &nb= sp;            =       Reserved      =              &n= bsp;            = ; |

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |       = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      Label Set Field #2   &nbs= p;             = |

  :       = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            &nbs= p;    :

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

 

Alternatively, the following encoding expresses t= he same need by using A bit (A=3D0) as a mechanism to make unavailable a ce= rtain set of labels for all priority levels except the highest priority Lev= el 7.

   0     =             &nb= sp; 1           &nbs= p;       2      = ;             3=

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |0|1 1 0|     &nb= sp;            =       Reserved      =              &n= bsp;            = ; |

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

  |       = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      Label Set Field #2   &nbs= p;            &= nbsp; |

  :       = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;             &nb= sp;            =             &nb= sp;            =             &nb= sp;            :

  +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +

 

Note that when a set of labels (indicated by Labe= l Set Field #2) is unavailable for Priority Level 6 (indicated by Priority = Flag 110), this implies that these labels are not also available for lower = Priority levels, 0-5. The above encoding also implies that all other labels except those defined under Label Set Fi= eld #2 are available for all priority levels.

 

-----Original Message-----

From: Rajan Rao [mailto:rrao@infinera= .com]

Sent: Thursday, August 02, 2012 12:40 PM

To: Leeyoung; Giovanni Martinelli (giomarti)=

Cc: CCAMP

Subject: RE: [CCAMP] Comment on draft-ietf-ccamp-= general-constraint-encode-08: priority

 

Giovanni,

 

My comment  few months ago was to cover band= width advertisement at all 8 priority levels  as in PSC, TDM & TDM= -OTN switching cases.   The priority based advertisement in WSON/= LSC  is no different from other cases.

 

What might be useful is to add couple of examples= to show how this is used along with other flags.

 

Hope this helps.

Thanks

Rajan

 

-----Original Message-----

From: <= span style=3D"color:windowtext;text-decoration:none">ccamp-bounces@ietf.org= [mailto:ccamp-bounces@ietf.org] On= Behalf Of Leeyoung

Sent: Thursday, August 02, 2012 9:57 AM

To: Giovanni Martinelli (giomarti)

Cc: CCAMP

Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-= general-constraint-encode-08: priority

 

Hi Giovanni,

 

Please see in-line for my responses.

 

Thanks.

 

-----Original Message-----

From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisc= o.com]

Sent: Thursday, August 02, 2012 11:16 AM

To: Leeyoung

Cc: CCAMP

Subject: Re: [CCAMP] Comment on draft-ietf-ccamp-= general-constraint-encode-08: priority

 

Hi Young,

 

btw first just a naming issue (I guess a question= for the wg in general) the object label_set here has the same name name as= the label_set form rfc3471 but it has actually a different encoding, so ju= st asking if worth figuring out a little different name. If no one complain I'm fine too.

 

YOUNG>> We are expanding the label set conc= ept from 3471. I am not sure if there is a new name needed here. I defer th= is to WG chairs.

 

please see inline

 

On Aug 2, 2012, at 1:18 , Leeyoung wrote:

 

> <snip>

> On Aug 2, 2012, at 24:25 , Leeyoung wrote:

>

>> Hi Giovanni,

>>

>> The wavelength priority you propose seem= s different from the what we encoded per Rao Rajan's suggestion. What we en= coded in section 2.3 of gen encode is not giving wavelength a priority leve= l, among which I believe your wavelength property specifies.

>>

>> What we are proposing is what labels are= available/not available for each priority level (similar to LSP reservatio= n or holding priority) as the following encoding dictates:

>>

>

>

> GM> So at the end is a "Label Priori= ty" ? With the Label_Set granularity instead of the single Label? = ;

>

> YOUNG>> No, this is not "label pr= iority". Label is not "assigned" a priority. Label is neutra= l. Say, you have five wavelengths available for grab and you have two prior= ities you are aware of which is service level (e.g., LSP). For higher priority service, you may want to all your five wavelengths (w1-w5)= available for grab while for lower priority, you may restrict to less numb= er of wavelengths, say three wavelengths only (e.g., w1-w3).

 

 

GM> Well I'm not sure I'm following you, you s= ay that labels are not assigned to a priority but then there is a priority = associated to a label set. For sure label is neutral but "someone"= ; decide if it goes in a label set with a certain priority, or in another (or in both label_set ). So, to me this means asso= ciate (is this term better than assign?) a priority to a label.<= /p>

 

YOUNG>> I think I explained enough what the= current encoding is. This is about what labels are available for LSP prior= ity. Some labels may be available for more than one LSP priority. There is = no 1:1 "association" between label and priority per se.

 

> Here you can see individual wavelength is no= t assigned a priority.

 

 

GM> the granularity is the label_set so you ca= n easily see that's equivalent to individual label, anyway single label or = label-set its not a substantial difference to me.

 

 

 

> This is analogous to how much BW availabilit= y for each priority in MPLS network, except that we need to express in wave= length level. 

>

>

>

>>   0    &nb= sp;            =   1           &= nbsp;       2     &n= bsp;            = ; 3

>>     0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

>>    +-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+

>>    |A| Reserved &nbs= p;  | Priority Flags|        Reserv= ed            &= nbsp;  |

>>    +-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+

>>    |   &nb= sp;            =            Label Set Fiel= d            &n= bsp;        |

>>    :   &nb= sp;            =             &nb= sp;            =             &nb= sp;         :

>>    +-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+

>>  Where

>>

>>  A (Availability bit) =3D 1 or 0 in= dicates that the labels listed in

>> the following label set field are availa= ble or not available,

>> respectively, for use at a given priorit= y level as indicated by the

>> Priority Flags.

>

>

> GM> The reading here suggest me that ther= e could be multiple objects (I bet up to 8) packed up somewere (e.g. someth= ing like sub-tlvs in the link advertisement). Is my interpretation correct?=

>

> YOUNG>> Yes.

>

 

GM> two encoding question here:

GM>  1/ why using flags instead of classi= cal three bits?

GM> 2/ What the usage of A? I mean you have an= Available_label object and then you set A=3D0 which means that labels are = not available... could you please clarify better?

 

YOUNG>> Yes, three bits can do that. We put= A=3D0 (not available) --just to give more flexibility. That's all. If you = want to restrict some ranges of labels to lower LSP, using A bit (A=3D0) wo= uld be more efficient to express such need.

 

Cheers

G

 

 

 

> Cheers

> G

>

>

>>

>>  Priority Flags: Bit 8 corresponds = to priority level 0 and bit 15

>> corresponds to priority level 7. If a bi= t is set then the labels in

>> the label set field are available or not= available as indicated by

>> the A bit for use at that particular pri= ority level.

>>

>> Let's begin if we are in agreement with = this point.

>>

>> Thanks.

>> Young

>>

>> -----Original Message-----

>> From: ccamp-bounces= @ietf.org [mailto:ccamp-bounces@ietf.org] On

>> Behalf Of Giovanni Martinelli (giomarti)=

>> Sent: Wednesday, August 01, 2012 12:40 P= M

>> To: Giovanni Martinelli (giomarti)<= /o:p>

>> Cc: CCAMP

>> Subject: Re: [CCAMP] Comment on

>> draft-ietf-ccamp-general-constraint-enco= de-08: priority

>>

>> Here my latest mail  with comments = on wavelength priority...

>>

>> Here my memory on past discussion (pleas= e correct if wrong)

>> - last short thread was during ieft83 (a= round 26/28 march), last mail was from me and did not get answers. The cont= ent here below cover that mail as well.

>> - discussions about wl priority happens = among authors not on ccamp mailing list. On the mailing list you announce d= raft update around dec 2011. 

>>

>> Well, I'm not complaining about how disc= ussion happen, simply I saw  a not-trivial addition to wg document, he= nce my comments.

>>

>> Cheers

>> G

>>

>>

>>

>> On Jul 31, 2012, at 24:34 , Giovanni Mar= tinelli (giomarti) wrote:

>>

>>> Dear authors / ccamp,

>>>

>>> here a few comments related to the p= riority field added to draft-ietf-ccamp-general-constraint-encode:

>>>

>>> A couple of editorial comments<= /o:p>

>>> 1)  "wavelenght priority&q= uot; appears in a draft that claim to be general. In fact is available in &= quot;Available Labels Sub-TLV" and "Shared Backup Labels Sub-TLV&= quot;. So is a wavelength or label-like priority?

>>> 2)  why an 8 bits (bit field) i= nstead of the classic 3 bits (integer [0 .. 7]?

>>>

>>>

>>> Then few other comments

>>> 3)  How the priority is used ve= rsus the A flag . Draft text report "

>>> A (Availability bit) =3D 1 or 0 indi= cates that the labels listed in

>>> the following label set field are av= ailable or not available,

>>> respectively, for use at a given pri= ority level as indicated by the

>>> Priority Flags.

>>>

>>> "

>>> So does it means that there could be= different "available labels sub-TLVs" advertised?

>>>

>>> 4) Still unclear to me how this prio= rity is different from the one

>>> reported in http://tools.ietf.org= /html/draft-kattan-wson-property-01

>>> and eventually if this "priorit= y" could fit the LSP priority already

>>> available (as one of the comment we = received at that time)

>>>

>>> Cheers

>>> G

>>>

>>

>> ________________________________________= _______

>> CCAMP mailing list

>> CCAMP@ietf.org

>> https://www.ietf.org/= mailman/listinfo/ccamp

>

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org=

https://www.ie= tf.org/mailman/listinfo/ccamp

--_000_7AEB3D6833318045B4AE71C2C87E8E172906081Adfweml511mbschi_-- From adrian@olddog.co.uk Mon Aug 13 02:19:59 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0187C21F8701 for ; Mon, 13 Aug 2012 02:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwSutmXSWDNx for ; Mon, 13 Aug 2012 02:19:58 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3993D21F8578 for ; Mon, 13 Aug 2012 02:19:58 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7D9Je7j013703; Mon, 13 Aug 2012 10:19:49 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7D9JdQW013671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Aug 2012 10:19:40 +0100 From: "Adrian Farrel" To: "'Lou Berger'" References: <021a01cd7536$2104aa10$630dfe30$@olddog.co.uk> <50227712.4010203@labn.net> <056001cd7699$eb953330$c2bf9990$@olddog.co.uk> <50257116.5030201@labn.net> In-Reply-To: <50257116.5030201@labn.net> Date: Mon, 13 Aug 2012 10:19:36 +0100 Message-ID: <086a01cd7934$c30753b0$4915fb10$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH2xGWI71ErEuAv2SBWNzwa8SIWFAJTXtInAdtGSo8DAyZS85bLTnRQ Content-Language: en-gb Cc: draft-ietf-ccamp-assoc-ext.all@tools.ietf.org, 'CCAMP' Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 09:19:59 -0000 Hi Lou, > > The bottom line here appears to be: > > - leave updates 4872 > > > - remove updates 2205, 3209, 3473 > > Are you sure about this? Other RFCs that provide incremental functions > that are not required by all implementations identify the base protocol > in the Updates field. For example, take a look at rfc5151 it says both > 3209 and 3473 are updated. Are you sure the authors of 5151 did not intend that all new implementations of 3209 and 3473 should include full support for 5151? But I can see that there may have been confusion in the WG consensus on this point if there is lack of clarity about what "updates" means in the header. My view is that "updates" means "this becomes part of the protocol spec originally stated by the updated RFC". It is quite possible that this has not been applied/enforced in the past, and I am currently hunting for a definitive reference (if I can't find one, I will have to run some IETF process to create a clear definition of "updates" for future use). > >>> Section 4.1 [snip] > How about: > > This field contains a value that is a unique global identifier or the > special value zero (0). When non-zero and not overridden by local > policy, the Global_ID as defined in [RFC6370] SHALL be used. > The special value of zero indicates that no global identifier is > present. Note that a Global Association Source of zero SHOULD be > limited to entities contained within a single operator. Yes. Thanks. > >>> Section 4.1 [snip] > >> How about: > >> Extended Association ID: variable, 4-byte aligned > >> > >> This field contains data that is additional information to support > >> unique identification. The length and contents of this field is > >> determined by the Association Source. The length of this field > >> is derive from the object Length field and as such MUST have a > >> zero length or be 4-byte aligned. A zero length indicates that > >> this field is omitted. > > > > Still having trouble with "determined by". Try "dependent on". > > how about "scoped by" Yes. Many thanks, Adrian From lberger@labn.net Mon Aug 13 05:55:46 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C4621F85C5 for ; Mon, 13 Aug 2012 05:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.969 X-Spam-Level: X-Spam-Status: No, score=-99.969 tagged_above=-999 required=5 tests=[AWL=2.630, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzXUU3Fbzowd for ; Mon, 13 Aug 2012 05:55:46 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 0D69321F84FC for ; Mon, 13 Aug 2012 05:55:45 -0700 (PDT) Received: (qmail 8858 invoked by uid 0); 13 Aug 2012 12:55:24 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 13 Aug 2012 12:55:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=TL5rosMV/9mDyMsmFt5jaaVlzfaItNoOx+HAGOsvTL0=; b=hlzwrMIl3v1SohGNvs9rusnT5q0VHgpDxTpdInu8hRWxOxdpW54rtquh06F4vBSA/BuD0SMe1re2/KU2DpRUtc8APzqH7cRye1THGn8dd2wx2soNeeFOPednfGB4wza1; Received: from box313.bluehost.com ([69.89.31.113]:36372 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T0uB2-0000Eg-D7; Mon, 13 Aug 2012 06:55:24 -0600 Message-ID: <5028F939.4020807@labn.net> Date: Mon, 13 Aug 2012 08:55:21 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <021a01cd7536$2104aa10$630dfe30$@olddog.co.uk> <50227712.4010203@labn.net> <056001cd7699$eb953330$c2bf9990$@olddog.co.uk> <50257116.5030201@labn.net> <086a01cd7934$c30753b0$4915fb10$@olddog.co.uk> In-Reply-To: <086a01cd7934$c30753b0$4915fb10$@olddog.co.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-ccamp-assoc-ext.all@tools.ietf.org, 'CCAMP' Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 12:55:46 -0000 Adrian, On 8/13/2012 5:19 AM, Adrian Farrel wrote: > Hi Lou, > >>> The bottom line here appears to be: >>> - leave updates 4872 >> >>> - remove updates 2205, 3209, 3473 >> >> Are you sure about this? Other RFCs that provide incremental functions >> that are not required by all implementations identify the base protocol >> in the Updates field. For example, take a look at rfc5151 it says both >> 3209 and 3473 are updated. > > Are you sure the authors of 5151 did not intend that all new implementations of > 3209 and 3473 should include full support for 5151? > humm have to check with the authors;-) Either way, I don't think that was the WG's intent. I think keeping the updates reference is consistent with precedent and http://www.rfc-editor.org/rfc-editor/instructions2authors.txt, so would prefer to keep it. > [snip] Lou From internet-drafts@ietf.org Tue Aug 14 06:45:19 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5FC21F86F9; Tue, 14 Aug 2012 06:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQDXHhNAO7sR; Tue, 14 Aug 2012 06:45:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BAE21F86C8; Tue, 14 Aug 2012 06:45:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120814134519.2596.12258.idtracker@ietfa.amsl.com> Date: Tue, 14 Aug 2012 06:45:19 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 13:45:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : RSVP Association Object Extensions Author(s) : Lou Berger Francois Le Faucheur Ashok Narayanan Filename : draft-ietf-ccamp-assoc-ext-04.txt Pages : 16 Date : 2012-08-14 Abstract: The RSVP ASSOCIATION object was defined in the context of GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state, and this document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects which, in particular, can be used in the context of the Transport Profile of Multiprotocol Label Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also modifies the definition of the Association ID field defined in RFC 4872. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-assoc-ext There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-assoc-ext-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lberger@labn.net Tue Aug 14 07:10:45 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A655521F8548 for ; Tue, 14 Aug 2012 07:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.855 X-Spam-Level: X-Spam-Status: No, score=-99.855 tagged_above=-999 required=5 tests=[AWL=2.410, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyMyT24HoVW8 for ; Tue, 14 Aug 2012 07:10:40 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 2555421F8504 for ; Tue, 14 Aug 2012 07:10:40 -0700 (PDT) Received: (qmail 16194 invoked by uid 0); 14 Aug 2012 14:10:18 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 14 Aug 2012 14:10:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=sC471fTTQfT7nE64lW6P8Q+P7xZwXQWr8ejcc1l5H5k=; b=XO1uVQ/8y4ekE5cTa7FiJULjPUE92vpKzmEZh4DpALCuJilpJ1WAguN9WEMFhEUKZ8MIwyVnuHo7TyC6plynPqP3bGNZmE/m2hN5vFeT24aWvOW0+dXZLWCVreKcBmEo; Received: from box313.bluehost.com ([69.89.31.113]:39043 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T1Hp4-0005q1-EB for ccamp@ietf.org; Tue, 14 Aug 2012 08:10:18 -0600 Message-ID: <502A5C48.1080301@labn.net> Date: Tue, 14 Aug 2012 10:10:16 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: ccamp@ietf.org References: <20120814134519.2596.12258.idtracker@ietfa.amsl.com> In-Reply-To: <20120814134519.2596.12258.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 14:10:45 -0000 The authors believe that this revision addresses the comments raised by Adrian and discussed on the list. (It also includes few other editorial nits identified by the authors.) Please note, as discussed, there has been one substantive technical change (MUST --> SHOULD): 3.2.1. Resv Message Format OLD Relative ordering of ASSOCIATION objects of the same type MUST be preserved by transit nodes. NEW Relative ordering of ASSOCIATION objects of the same type *SHOULD* be preserved by transit nodes. Lou (and co-authors) On 8/14/2012 9:45 AM, internet-drafts@ietf.org wrote: > > 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 Association Object Extensions > Author(s) : Lou Berger > Francois Le Faucheur > Ashok Narayanan > Filename : draft-ietf-ccamp-assoc-ext-04.txt > Pages : 16 > Date : 2012-08-14 > > Abstract: > The RSVP ASSOCIATION object was defined in the context of GMPLS > (Generalized Multi-Protocol Label Switching) controlled label > switched paths (LSPs). In this context, the object is used to > associate recovery LSPs with the LSP they are protecting. This > object also has broader applicability as a mechanism to associate > RSVP state, and this document defines how the ASSOCIATION object > can be more generally applied. This document also defines > Extended ASSOCIATION objects which, in particular, can be used in > the context of the Transport Profile of Multiprotocol Label > Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, > and RFC 3473. It also modifies the definition of the Association > ID field defined in RFC 4872. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-assoc-ext > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-assoc-ext-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From zhang.fei3@zte.com.cn Tue Aug 14 20:11:20 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690BE21F84EC; Tue, 14 Aug 2012 20:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.156 X-Spam-Level: X-Spam-Status: No, score=-96.156 tagged_above=-999 required=5 tests=[AWL=1.479, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gWQ--Mftk5c; Tue, 14 Aug 2012 20:11:19 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8267F21F84E4; Tue, 14 Aug 2012 20:11:18 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 232551461793122; Wed, 15 Aug 2012 11:05:51 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 33084.1973556129; Wed, 15 Aug 2012 11:10:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7F3Ab5n028860; Wed, 15 Aug 2012 11:10:37 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <502A5C48.1080301@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: 12A119AC:205999F8-48257A5B:000F1A4E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Wed, 15 Aug 2012 11:10:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-15 11:10:21, Serialize complete at 2012-08-15 11:10:21 Content-Type: multipart/alternative; boundary="=_alternative 0011645248257A5B_=" X-MAIL: mse02.zte.com.cn q7F3Ab5n028860 Cc: ccamp@ietf.org, ccamp-bounces@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 03:11:20 -0000 This is a multipart message in MIME format. --=_alternative 0011645248257A5B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTG91DQoNCkkgY2FuIHNlZSB0aGVyZSBhcmUgc29tZSBtaW5vciBjaGFuZ2VzIHdoZW4gdGFr aW5nIGEgbG9vayBhdCB0aGUgdXBkYXRlZCANCm5ldyB2ZXJzaW9uLCBhbmQgd2FudCB0byBjaGVj ayB3aXRoIHlvdSB0aGUgaW50ZW50aW9uIG9mIGxpc3RlZCB0d28gDQpyZXZpc2lvbnMuDQoNCjEu IFNlY3Rpb24gMyBOby1HTVBMUyBSZWNvdmVyeSBVc2FnZQ0KDQpUaGUgc2VudGVuY2UgIk5vdGUg dGhhdCB0aGVyZSBhcmUgdGltZXMgd2hlbiBubyBtYXRjaGluZyBzdGF0ZSBpcyBmb3VuZCwgDQpl LmcuLCB3aGVuIHByb2Nlc3NpbmcgYW4gaW5pdGlhbCBMU1Agb3Igd2hlbiB0aGUgQVNTT0NJQVRJ T04gb2JqZWN0IA0KY29udGFpbnMNCm90aGVyd2lzZSB1c2VmdWwgaW5mb3JtYXRpb24sIGFuZCBz dWNoIGNhc2VzIGRvIG5vdCBhbHRlciB0aGUgcHJvY2Vzc2luZyANCmRlZmluZWQgYmVsb3cuIiBp cyBkZWxldGVkIGluIHRoZSB2ZXJzaW9uIDA0LCB3aGljaCBpbmRpY2F0ZXMgdGhhdCB0aGUgDQpB U1NPQ0lBVElPTiBvYmplY3QNCmNhbiBub3QgYmUgdXNlZCBpbiBhIHNpbmdsZSBzZXNzaW9uIHdo aXRoIGFueSBraW5kcyBvZiBBc3NvY2lhdGlvbiBUeXBlcyANCm9yIHRoZSB1c2FnZSBpbiBhIHNp bmdsZSBzZXNzaW9uIGNhbiBiZSBkZWZpbmVkIGFzIGFuIGFzc29jaWF0aW9uIHR5cGUgDQpzcGVj aWZpYyBydWxlcz8NCg0KMi4gVGhlIGRlc2NyaXB0aW9ucyBhYm91dCBHbG9iYWwgQXNzb2NpYXRp b24gU291cmNlIGluIFNlY3Rpb24gNC4xLiAgSVB2NCANCmFuZCBJUHY2IEV4dGVuZGVkIEFTU09D SUFUSU9OIE9iamVjdCBGb3JtYXQNCg0KU2ltaWxhcmx5LCB0aGUgc2VudGVuY2UgIkl0IGlzIGV4 cGVjdGVkIHRoYXQgdGhlIGdsb2JhbCBpZGVudGlmaWVyIHdpbGwgYmUgDQpkZXJpdmVkIGZyb20g dGhlIGdsb2JhbGx5IHVuaXF1ZSBBU04gb2YgdGhlIGF1dG9ub21vdXMgc3lzdGVtIGhvc3Rpbmcg dGhlIA0KQXNzb2NpYXRpb24gU291cmNlLiIgZG9lcyBub3QgYXBwZWFyIGluIHRoZSBuZXcgdmVy c2lvbi4gVGhlIHF1ZXN0aW9uIGhlcmUgDQppcyB3aGV0aGVyIHRoZSBHbG9iYWwgQXNzb2NpYXRp b24gU291cmNlIFNIT1VMRCBob3N0IHRoZSBBc3NvY2lhdGlvbiANClNvdXJjZSBvciBub3Q/ICBJ ZiB5ZWFoLCBpdCBoYWQgYmV0dGVyIGJlaW5nIGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQuDQoN Cg0KQmVzdCByZWdhcmRzDQoNCkZlaQ0KDQoNCg0KTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5l dD4gDQq3orz+yMs6ICBjY2FtcC1ib3VuY2VzQGlldGYub3JnDQoyMDEyLTA4LTE0IDIyOjEwDQoN CsrVvP7Iyw0KY2NhbXBAaWV0Zi5vcmcNCrOty80NCg0K1vfM4g0KUmU6IFtDQ0FNUF0gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDQudHh0DQoNCg0KDQoNCg0KDQoNClRo ZSBhdXRob3JzIGJlbGlldmUgdGhhdCB0aGlzIHJldmlzaW9uIGFkZHJlc3NlcyB0aGUgY29tbWVu dHMgcmFpc2VkIGJ5DQpBZHJpYW4gYW5kIGRpc2N1c3NlZCBvbiB0aGUgbGlzdC4gKEl0IGFsc28g aW5jbHVkZXMgZmV3IG90aGVyIGVkaXRvcmlhbA0Kbml0cyBpZGVudGlmaWVkIGJ5IHRoZSBhdXRo b3JzLikNCg0KUGxlYXNlIG5vdGUsIGFzIGRpc2N1c3NlZCwgdGhlcmUgaGFzIGJlZW4gb25lIHN1 YnN0YW50aXZlIHRlY2huaWNhbA0KY2hhbmdlIChNVVNUIC0tPiBTSE9VTEQpOg0KDQogIDMuMi4x LiBSZXN2IE1lc3NhZ2UgRm9ybWF0DQpPTEQNCiAgUmVsYXRpdmUgb3JkZXJpbmcgb2YgQVNTT0NJ QVRJT04gb2JqZWN0cyBvZiB0aGUgc2FtZSB0eXBlDQogIE1VU1QgYmUgcHJlc2VydmVkIGJ5IHRy YW5zaXQgbm9kZXMuDQpORVcNCiAgUmVsYXRpdmUgb3JkZXJpbmcgb2YgQVNTT0NJQVRJT04gb2Jq ZWN0cyBvZiB0aGUgc2FtZSB0eXBlDQogICpTSE9VTEQqIGJlIHByZXNlcnZlZCBieSB0cmFuc2l0 IG5vZGVzLg0KDQpMb3UgKGFuZCBjby1hdXRob3JzKQ0KDQpPbiA4LzE0LzIwMTIgOTo0NSBBTSwg aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJh ZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KZGlyZWN0 b3JpZXMuDQo+ICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb21tb24gQ29udHJv bCBhbmQgTWVhc3VyZW1lbnQgUGxhbmUgDQpXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPiAN Cj4gICAgICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogUlNWUCBBc3NvY2lhdGlvbiBPYmpl Y3QgRXh0ZW5zaW9ucw0KPiAgICAgICAgICAgICAgICBBdXRob3IocykgICAgICAgOiBMb3UgQmVy Z2VyDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJhbmNvaXMgTGUgRmF1Y2hldXINCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICBBc2hvayBOYXJheWFuYW4NCj4gICAgICAgICAgICAg ICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDQudHh0DQo+ ICAgICAgICAgICAgICAgIFBhZ2VzICAgICAgICAgICA6IDE2DQo+ICAgICAgICAgICAgICAgIERh dGUgICAgICAgICAgICA6IDIwMTItMDgtMTQNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGUgUlNW UCBBU1NPQ0lBVElPTiBvYmplY3Qgd2FzIGRlZmluZWQgaW4gdGhlIGNvbnRleHQgb2YgR01QTFMN Cj4gICAgKEdlbmVyYWxpemVkIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZykgY29udHJv bGxlZCBsYWJlbA0KPiAgICBzd2l0Y2hlZCBwYXRocyAoTFNQcykuICBJbiB0aGlzIGNvbnRleHQs IHRoZSBvYmplY3QgaXMgdXNlZCB0bw0KPiAgICBhc3NvY2lhdGUgcmVjb3ZlcnkgTFNQcyB3aXRo IHRoZSBMU1AgdGhleSBhcmUgcHJvdGVjdGluZy4gIFRoaXMNCj4gICAgb2JqZWN0IGFsc28gaGFz IGJyb2FkZXIgYXBwbGljYWJpbGl0eSBhcyBhIG1lY2hhbmlzbSB0byBhc3NvY2lhdGUNCj4gICAg UlNWUCBzdGF0ZSwgYW5kIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyBob3cgdGhlIEFTU09DSUFUSU9O IG9iamVjdA0KPiAgICBjYW4gYmUgbW9yZSBnZW5lcmFsbHkgYXBwbGllZC4gIFRoaXMgZG9jdW1l bnQgYWxzbyBkZWZpbmVzDQo+ICAgIEV4dGVuZGVkIEFTU09DSUFUSU9OIG9iamVjdHMgd2hpY2gs IGluIHBhcnRpY3VsYXIsIGNhbiBiZSB1c2VkIGluDQo+ICAgIHRoZSBjb250ZXh0IG9mIHRoZSBU cmFuc3BvcnQgUHJvZmlsZSBvZiBNdWx0aXByb3RvY29sIExhYmVsDQo+ICAgIFN3aXRjaGluZyAo TVBMUy1UUCkuICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDIDIyMDUsIFJGQyAzMjA5LA0KPiAg ICBhbmQgUkZDIDM0NzMuIEl0IGFsc28gbW9kaWZpZXMgdGhlIGRlZmluaXRpb24gb2YgdGhlIEFz c29jaWF0aW9uDQo+ICAgIElEIGZpZWxkIGRlZmluZWQgaW4gUkZDIDQ4NzIuDQo+IA0KPiANCj4g VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0 DQo+IA0KPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDQN Cj4gDQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoN Cj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jY2FtcC1hc3Nv Yy1leHQtMDQNCj4gDQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gQ0NBTVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiANCj4gDQo+IA0KPiANCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QN CkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nj YW1wDQoNCg0KDQo= --=_alternative 0011645248257A5B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIExvdTwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBjYW4gc2VlIHRoZXJlIGFyZSBz b21lIG1pbm9yIGNoYW5nZXMNCndoZW4gdGFraW5nIGEgbG9vayBhdCB0aGUgdXBkYXRlZCBuZXcg dmVyc2lvbiwgYW5kIHdhbnQgdG8gY2hlY2sgd2l0aCB5b3UNCnRoZSBpbnRlbnRpb24gb2YgbGlz dGVkIHR3byByZXZpc2lvbnMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4xLiBTZWN0aW9uIDMgTm8tR01QTFMgUmVjb3ZlcnkgVXNhZ2U8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBzZW50ZW5jZSAmcXVv dDtOb3RlIHRoYXQgdGhlcmUgYXJlDQp0aW1lcyB3aGVuIG5vIG1hdGNoaW5nIHN0YXRlIGlzIGZv dW5kLCBlLmcuLCB3aGVuIHByb2Nlc3NpbmcgYW4gaW5pdGlhbA0KTFNQIG9yIHdoZW4gdGhlIEFT U09DSUFUSU9OIG9iamVjdCBjb250YWluczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+b3RoZXJ3aXNlIHVzZWZ1bCBpbmZvcm1hdGlvbiwgYW5kIHN1Y2gNCmNhc2Vz IGRvIG5vdCBhbHRlciB0aGUgcHJvY2Vzc2luZyBkZWZpbmVkIGJlbG93LiZxdW90OyBpcyBkZWxl dGVkIGluIHRoZQ0KdmVyc2lvbiAwNCwgd2hpY2ggaW5kaWNhdGVzIHRoYXQgdGhlIEFTU09DSUFU SU9OIG9iamVjdDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Y2Fu IG5vdCBiZSB1c2VkIGluIGEgc2luZ2xlIHNlc3Npb24NCndoaXRoIGFueSBraW5kcyBvZiBBc3Nv Y2lhdGlvbiBUeXBlcyBvciB0aGUgdXNhZ2UgaW4gYSBzaW5nbGUgc2Vzc2lvbiBjYW4NCmJlIGRl ZmluZWQgYXMgYW4gYXNzb2NpYXRpb24gdHlwZSBzcGVjaWZpYyBydWxlcz88L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIuIFRoZSBkZXNjcmlwdGlvbnMg YWJvdXQgR2xvYmFsIEFzc29jaWF0aW9uDQpTb3VyY2UgaW4gU2VjdGlvbiA0LjEuICZuYnNwO0lQ djQgYW5kIElQdjYgRXh0ZW5kZWQgQVNTT0NJQVRJT04gT2JqZWN0DQpGb3JtYXQ8YnI+DQo8YnI+ DQpTaW1pbGFybHksIHRoZSBzZW50ZW5jZSAmcXVvdDtJdCBpcyBleHBlY3RlZCB0aGF0IHRoZSBn bG9iYWwgaWRlbnRpZmllcg0Kd2lsbCBiZSBkZXJpdmVkIGZyb20gdGhlIGdsb2JhbGx5IHVuaXF1 ZSBBU04gb2YgdGhlIGF1dG9ub21vdXMgc3lzdGVtIGhvc3RpbmcNCnRoZSBBc3NvY2lhdGlvbiBT b3VyY2UuJnF1b3Q7IGRvZXMgbm90IGFwcGVhciBpbiB0aGUgbmV3IHZlcnNpb24uIFRoZSBxdWVz dGlvbg0KaGVyZSBpcyB3aGV0aGVyIHRoZSBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlIFNIT1VM RCBob3N0IHRoZSBBc3NvY2lhdGlvbg0KU291cmNlIG9yIG5vdD8gJm5ic3A7SWYgeWVhaCwgaXQg aGFkIGJldHRlciBiZWluZyBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50LjwvZm9udD4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCByZWdhcmRzPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GZWk8L2ZvbnQ+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+TG91IEJlcmdl ciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTA4LTE0IDIyOjEw PC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PmNjYW1wQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0K PHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5SZTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1w LWFzc29jLWV4dC0wNC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NClRoZSBhdXRob3JzIGJlbGlldmUgdGhhdCB0aGlzIHJl dmlzaW9uIGFkZHJlc3NlcyB0aGUgY29tbWVudHMgcmFpc2VkIGJ5PGJyPg0KQWRyaWFuIGFuZCBk aXNjdXNzZWQgb24gdGhlIGxpc3QuIChJdCBhbHNvIGluY2x1ZGVzIGZldyBvdGhlciBlZGl0b3Jp YWw8YnI+DQpuaXRzIGlkZW50aWZpZWQgYnkgdGhlIGF1dGhvcnMuKTxicj4NCjxicj4NClBsZWFz ZSBub3RlLCBhcyBkaXNjdXNzZWQsIHRoZXJlIGhhcyBiZWVuIG9uZSBzdWJzdGFudGl2ZSB0ZWNo bmljYWw8YnI+DQpjaGFuZ2UgKE1VU1QgLS0mZ3Q7IFNIT1VMRCk6PGJyPg0KPGJyPg0KICZuYnNw OzMuMi4xLiBSZXN2IE1lc3NhZ2UgRm9ybWF0PGJyPg0KT0xEPGJyPg0KICZuYnNwO1JlbGF0aXZl IG9yZGVyaW5nIG9mIEFTU09DSUFUSU9OIG9iamVjdHMgb2YgdGhlIHNhbWUgdHlwZTxicj4NCiAm bmJzcDtNVVNUIGJlIHByZXNlcnZlZCBieSB0cmFuc2l0IG5vZGVzLjxicj4NCk5FVzxicj4NCiAm bmJzcDtSZWxhdGl2ZSBvcmRlcmluZyBvZiBBU1NPQ0lBVElPTiBvYmplY3RzIG9mIHRoZSBzYW1l IHR5cGU8YnI+DQogJm5ic3A7KlNIT1VMRCogYmUgcHJlc2VydmVkIGJ5IHRyYW5zaXQgbm9kZXMu PGJyPg0KPGJyPg0KTG91IChhbmQgY28tYXV0aG9ycyk8YnI+DQo8YnI+DQpPbiA4LzE0LzIwMTIg OTo0NSBBTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOjxicj4NCiZndDsgPGJyPg0K Jmd0OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMNCmRpcmVjdG9yaWVzLjxicj4NCiZndDsgJm5ic3A7VGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRyb2wgYW5kIE1lYXN1cmVtZW50DQpQbGFu ZSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Rp dGxlDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogUlNWUCBBc3NvY2lhdGlv biBPYmplY3QgRXh0ZW5zaW9uczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBdXRob3IocykNCiZuYnNwOyAmbmJz cDsgJm5ic3A7IDogTG91IEJlcmdlcjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyBGcmFuY29pcyBMZSBGYXVjaGV1cjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7ICZuYnNwOyBBc2hvayBOYXJheWFuYW48YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RmlsZW5h bWUNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1l eHQtMDQudHh0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BhZ2VzDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDogMTY8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGF0ZQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs6IDIwMTItMDgtMTQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWJz dHJhY3Q6PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7VGhlIFJTVlAgQVNTT0NJQVRJT04gb2JqZWN0 IHdhcyBkZWZpbmVkIGluIHRoZSBjb250ZXh0DQpvZiBHTVBMUzxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyhHZW5lcmFsaXplZCBNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcpIGNvbnRyb2xs ZWQNCmxhYmVsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7c3dpdGNoZWQgcGF0aHMgKExTUHMpLiAm bmJzcDtJbiB0aGlzIGNvbnRleHQsIHRoZSBvYmplY3QNCmlzIHVzZWQgdG88YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDthc3NvY2lhdGUgcmVjb3ZlcnkgTFNQcyB3aXRoIHRoZSBMU1AgdGhleSBhcmUg cHJvdGVjdGluZy4NCiZuYnNwO1RoaXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtvYmplY3QgYWxz byBoYXMgYnJvYWRlciBhcHBsaWNhYmlsaXR5IGFzIGEgbWVjaGFuaXNtDQp0byBhc3NvY2lhdGU8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtSU1ZQIHN0YXRlLCBhbmQgdGhpcyBkb2N1bWVudCBkZWZp bmVzIGhvdyB0aGUgQVNTT0NJQVRJT04NCm9iamVjdDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2Nh biBiZSBtb3JlIGdlbmVyYWxseSBhcHBsaWVkLiAmbmJzcDtUaGlzIGRvY3VtZW50IGFsc28NCmRl ZmluZXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtFeHRlbmRlZCBBU1NPQ0lBVElPTiBvYmplY3Rz IHdoaWNoLCBpbiBwYXJ0aWN1bGFyLCBjYW4NCmJlIHVzZWQgaW48YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDt0aGUgY29udGV4dCBvZiB0aGUgVHJhbnNwb3J0IFByb2ZpbGUgb2YgTXVsdGlwcm90b2Nv bA0KTGFiZWw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtTd2l0Y2hpbmcgKE1QTFMtVFApLiAmbmJz cDtUaGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDDQoyMjA1LCBSRkMgMzIwOSw8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDthbmQgUkZDIDM0NzMuIEl0IGFsc28gbW9kaWZpZXMgdGhlIGRlZmluaXRpb24g b2YgdGhlDQpBc3NvY2lhdGlvbjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0lEIGZpZWxkIGRlZmlu ZWQgaW4gUkZDIDQ4NzIuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KJmd0OyBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dDxi cj4NCiZndDsgPGJyPg0KJmd0OyBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWls YWJsZSBhdDo8YnI+DQomZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt Y2NhbXAtYXNzb2MtZXh0LTA0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0LTA0PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCiZndDsgZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy88YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IENDQU1QIG1haWxpbmcgbGlzdDxicj4N CiZndDsgQ0NBTVBAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY2NhbXA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IDxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KQ0NBTVBAaWV0Zi5vcmc8YnI+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wPGJyPg0KPGJyPg0KPC9mb250Pjwv dHQ+DQo8YnI+DQo= --=_alternative 0011645248257A5B_=-- From iesg-secretary@ietf.org Wed Aug 15 05:16:44 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C65621F86C6; Wed, 15 Aug 2012 05:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKUKtHEwTpBV; Wed, 15 Aug 2012 05:16:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E3421F856D; Wed, 15 Aug 2012 05:16:43 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120815121643.11114.33683.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2012 05:16:43 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: (RSVP Association Object Extensions) to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 12:16:44 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'RSVP Association Object Extensions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-08-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The RSVP ASSOCIATION object was defined in the context of GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state, and this document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects which, in particular, can be used in the context of the Transport Profile of Multiprotocol Label Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also modifies the definition of the Association ID field defined in RFC 4872. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ccamp-assoc-ext/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ccamp-assoc-ext/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1720/ http://datatracker.ietf.org/ipr/1169/ From internet-drafts@ietf.org Wed Aug 15 07:53:24 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F5D21F87D8; Wed, 15 Aug 2012 07:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPtQkdmIk6QU; Wed, 15 Aug 2012 07:53:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2013821F8742; Wed, 15 Aug 2012 07:53:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2012 07:53:24 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 14:53:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : RSVP-TE Extensions for Associated Bidirectional LSPs Author(s) : Fei Zhang Ruiquan Jing Rakesh Gandhi Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Pages : 17 Date : 2012-08-15 Abstract: The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], describes that MPLS-TP MUST support associated bidirectional point- to-point LSPs. This document provides a method to bind two unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining the new Association Type in the Extended ASSOCIATION object. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-l= sp-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lberger@labn.net Wed Aug 15 09:23:17 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9979921F85AA for ; Wed, 15 Aug 2012 09:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.846 X-Spam-Level: X-Spam-Status: No, score=-98.846 tagged_above=-999 required=5 tests=[AWL=1.303, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJYoYgtDBFtA for ; Wed, 15 Aug 2012 09:23:15 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 59F2D21F87FA for ; Wed, 15 Aug 2012 09:23:15 -0700 (PDT) Received: (qmail 21501 invoked by uid 0); 15 Aug 2012 16:22:52 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 15 Aug 2012 16:22:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=f435s+Ie+Jb78CyifB5MF//f8X3155uRYkRiIX6fyms=; b=Vy1rMWL3ubTRYaHmlT0ji62NMSvbVwD/gQNVwbe5smwZZQPAX9hK4V1Lm/uF09fCI+AAMbnJ4Plcq3TbvRZgfab/5i+xIeEGE002O49xGtQeM341+qup+Zk9Yjv17tdY; Received: from box313.bluehost.com ([69.89.31.113]:58428 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T1gMt-000341-Ru; Wed, 15 Aug 2012 10:22:52 -0600 Message-ID: <502BCCD7.9000402@labn.net> Date: Wed, 15 Aug 2012 12:22:47 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 16:23:17 -0000 Fei, See below. On 8/14/2012 11:10 PM, zhang.fei3@zte.com.cn wrote: > > Hi Lou > > I can see there are some minor changes when taking a look at the updated > new version, and want to check with you the intention of listed two > revisions. > > 1. Section 3 No-GMPLS Recovery Usage > > The sentence "Note that there are times when no matching state is found, > e.g., when processing an initial LSP or when the ASSOCIATION object > contains > otherwise useful information, and such cases do not alter the processing > defined below." is deleted in the version 04, which indicates that the > ASSOCIATION object > can not be used in a single session whith any kinds of Association Types > or the usage in a single session can be defined as an association type > specific rules? Not sure exactly what you're asking, but this change was editorial in nature only, as processing behavior continues to be specified (see the 2nd to last paragraph in Section 3.1.2 and 3.2.2.) > > 2. The descriptions about Global Association Source in Section 4.1. > IPv4 and IPv6 Extended ASSOCIATION Object Format > > Similarly, the sentence "It is expected that the global identifier will > be derived from the globally unique ASN of the autonomous system hosting > the Association Source." does not appear in the new version. The > question here is whether the Global Association Source SHOULD host the > Association Source or not? If yeah, it had better being described in > the document. So the old text was informative only (and was taken from RFC6370). The new text is normative and says use definition from [RFC6370]. So I'm not sure what is ambiguous in the new text. What specific change would you like to see? Lou > > > Best regards > > Fei > > > *Lou Berger * > ·¢¼þÈË: ccamp-bounces@ietf.org > > 2012-08-14 22:10 > > > ÊÕ¼þÈË > ccamp@ietf.org > ³­ËÍ > > Ö÷Ìâ > Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt > > > > > > > > > > The authors believe that this revision addresses the comments raised by > Adrian and discussed on the list. (It also includes few other editorial > nits identified by the authors.) > > Please note, as discussed, there has been one substantive technical > change (MUST --> SHOULD): > > 3.2.1. Resv Message Format > OLD > Relative ordering of ASSOCIATION objects of the same type > MUST be preserved by transit nodes. > NEW > Relative ordering of ASSOCIATION objects of the same type > *SHOULD* be preserved by transit nodes. > > Lou (and co-authors) > > On 8/14/2012 9:45 AM, internet-drafts@ietf.org wrote: >> >> 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 Association Object Extensions >> Author(s) : Lou Berger >> Francois Le Faucheur >> Ashok Narayanan >> Filename : draft-ietf-ccamp-assoc-ext-04.txt >> Pages : 16 >> Date : 2012-08-14 >> >> Abstract: >> The RSVP ASSOCIATION object was defined in the context of GMPLS >> (Generalized Multi-Protocol Label Switching) controlled label >> switched paths (LSPs). In this context, the object is used to >> associate recovery LSPs with the LSP they are protecting. This >> object also has broader applicability as a mechanism to associate >> RSVP state, and this document defines how the ASSOCIATION object >> can be more generally applied. This document also defines >> Extended ASSOCIATION objects which, in particular, can be used in >> the context of the Transport Profile of Multiprotocol Label >> Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, >> and RFC 3473. It also modifies the definition of the Association >> ID field defined in RFC 4872. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ccamp-assoc-ext >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-assoc-ext-04 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > From lberger@labn.net Wed Aug 15 09:34:40 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772E321F8817 for ; Wed, 15 Aug 2012 09:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.929 X-Spam-Level: X-Spam-Status: No, score=-99.929 tagged_above=-999 required=5 tests=[AWL=2.336, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+Qsq6Orkqgi for ; Wed, 15 Aug 2012 09:34:39 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id B425321F8815 for ; Wed, 15 Aug 2012 09:34:38 -0700 (PDT) Received: (qmail 8651 invoked by uid 0); 15 Aug 2012 16:34:17 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 15 Aug 2012 16:34:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=a2tqKYF8ZAEAztlPSEfEoePdaMjoTuRudr35EA3jZHw=; b=FKWeV6/M2rHAfQ4WWMcvBPWMdST7KlyL8WZ/8PGhzO0CI4NyX0SxiyuHQd2rTdCaXrtK8SOkhTQweWjGhnWtpi310sfHKAYYSxZ++xZ9rqbfqzAtu9cysB9e5MLs7ZOs; Received: from box313.bluehost.com ([69.89.31.113]:59634 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T1gXx-000744-4d; Wed, 15 Aug 2012 10:34:17 -0600 Message-ID: <502BCF84.6090307@labn.net> Date: Wed, 15 Aug 2012 12:34:12 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "jingrq@ctbri.com.cn" , "Robert Sawaya \(rsawaya\)" , "yang.fan5@zte.com.cn" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 16:34:40 -0000 Fei/Rakeash, Co-routed associated is already supported in 3473 using bidirectional LSPs. So, to signal co-routed all that needs to be done is use the existing procedures. What issue is being addressed (i.e., function being added) by adding the proposed co-routed related mechanisms? Keep in mind, it's generally a *very* bad idea to define 2 mechanisms in the same protocol for the same function. Lou On 8/3/2012 5:16 AM, zhang.fei3@zte.com.cn wrote: > Snipped the other parts for easy reading, sorry for the delayed response > > There are applications that require co-routed LSPs. So I think we > should have a flag to indicate that LSPs must be co-routed, else node > will send a path error for example if request cannot be met. I agree > with you about complexity with double sided provisioning model though. > > Since you believe that a common mechanism used for the > non-corouted and corouted cases is useful, we will add the texts in the > next version. From lberger@labn.net Wed Aug 15 10:00:36 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE5321F85AE for ; Wed, 15 Aug 2012 10:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.27 X-Spam-Level: X-Spam-Status: No, score=-97.27 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_66=0.6, J_CHICKENPOX_93=0.6, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsIV7vcvpQRq for ; Wed, 15 Aug 2012 10:00:35 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 514DC21F85AC for ; Wed, 15 Aug 2012 10:00:35 -0700 (PDT) Received: (qmail 23081 invoked by uid 0); 15 Aug 2012 17:00:14 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 15 Aug 2012 17:00:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=p7o1HSo06PWB4OPqMviuoUVAFT61EveT5KzejkyUKw8=; b=BDE68IBaNdGO5kWlCZIs/mQqKzava/pDDnz+OYw/Ltg5RPqmXW91gXTXdRzCrDr8KjJeWC4h1M8eBj8iWveVrkCZEwi8gy+br8F55ifHWMOfDSDVOI/iZlB3MSCXG2DT; Received: from box313.bluehost.com ([69.89.31.113]:34065 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T1gx3-0008Cz-MZ; Wed, 15 Aug 2012 11:00:14 -0600 Message-ID: <502BD599.30905@labn.net> Date: Wed, 15 Aug 2012 13:00:09 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn, "Rakesh Gandhi (rgandhi)" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "jingrq@ctbri.com.cn" , "Robert Sawaya \(rsawaya\)" , "yang.fan5@zte.com.cn" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:00:36 -0000 Fei/Rakesh, I'd like to take a step back on this thread. This mail seems to be bringing the WG into the middle of a private discussion. I personally think the *right* way to have brought this *private* discussion to the attention of the WG would be to either: (a) start the discussion anew, this time including the WG or (b) use the meeting time in Vancouver to raise the discussion (Fei, I know you weren't there, but Rakesh or someone else could have presented.) So where do we go from here? I'd like to ask that someone (Rakesh, Fei, etc.) review each of the proposed changeand the rational for each change (in one or in separate e-mails). The WG discussion can then really begin on the proposed changes. (Which are quite substantial both in scope and implication.) Lou (as co-chair) On 7/30/2012 10:03 PM, zhang.fei3@zte.com.cn wrote: > > Thank you Rakesh for sharing your idea, I think we are roughly in > agreement and need to hear more voices from the WG. :) > > See inline > > Best > > Fei > > > *"Rakesh Gandhi (rgandhi)" * > > 2012-07-30 23:59 > > > ÊÕ¼þÈË > "zhang.fei3@zte.com.cn" > ³­ËÍ > "Eric Osborne (eosborne)" , > "jiang.weilian@zte.com.cn" , > "jingrq@ctbri.com.cn" , "Robert Sawaya (rsawaya)" > , "George Swallow (swallow)" , > "yang.fan5@zte.com.cn" > Ö÷Ìâ > RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 > > > > > > > > > Thanks Fei for your kind reply. Sorry for the delay (as I was away). > > Please see inline.... > > *From:* zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn] * > Sent:* Wednesday, July 25, 2012 11:42 AM* > To:* Rakesh Gandhi (rgandhi)* > Cc:* Eric Osborne (eosborne); jiang.weilian@zte.com.cn; > jingrq@ctbri.com.cn; Robert Sawaya (rsawaya); George Swallow (swallow); > yang.fan5@zte.com.cn* > Subject:* RE: Comments on > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 > > > Rakesh > > Thanks for your nice interpretation, and I can see there are at least > three parts that need to be revised in the next version > > 1) Define only one association type, and the single sided and double > sided provisioning models are represented by 1 flag. Agree > Great, thanks. > > 2) Define one flag for co-routed or non-corouted. If the co-routed bidir > is the default behavior, why not using the procedure defined in RFC3473? > I am afraid it is hard > to persuade the WG to do so. Maybe the better way is that non-corouted > bidir is the default, and the set of the co-routed flag only means that > it is recommended, not mandatory, the checking whether the LSP is > co-routed can be done by comparing the RRO objects. What is your opinion? > It is fine to have non co-routed as default. RFC 3473 is a GMPLS > signaling procedure. It may not be optimal to have two different > signaling procedures, one for non co-routed (ext associated object) and > one for co-routed (RFC 3473) procedures. By adding a flag for co-routed, > same signaling (ext associated object) can be used for both which is > nice. We believe comparing of RRO can be misleading because two LSPs can > be on the same path even though provisioned to be non co-routed. > > > Sorry that what I suggested maybe mislead you, the following > descripitons are more accurate. :) > 1)The default behavior (non-corouted) means that it is not required to > be co-routed. In other words, it is also OK that the two paths are along > the same path. > 2)The flag set means that co-routed is recommended. In other words, the > reverse LSP SHOULD be established in the same path as much as possible. > If the flag set means > that co-routed is mandatory,the procedures will be very complex in > double sided provisioning model. > > > 3)As to the tuple of id>, yeah, it is one kind of implementation, but there are potential > some other realizations, like using one of the router id plus the tunnel > id. I think we had better not restrict the execution to such a narrow > scope. What about the EA format listed below? > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Class-Num(199)| C-Type (TBA) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Association Type | Association ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 Association Source | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Global Association Source | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Extended Association Flags. |Extended Association ID ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |....(continue) : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Do you mean to have extended association ID as tunnel ID (16 bits) > + IP address (32 bits) in this object? > Please see inline below.... > > > No. I want to say that this format of EA objects can accomodate more > kinds of implementations. Like > > 1)Association ID: user provisioned idential value; Association Source: > the lowe ip address; EA ID: the higher IP address. As you suggested > > 2)Association ID: tunnel ID or user provisioned value; Association > Source:Tunnel sender address or user provisioned; EA ID: be empty or LSP > ID or any other information. > > 3)The potential other implementations... > > IMHO, the EA ID can be IP address or any other values in the context of > Association Source plus Association ID, which is backward compatible. > > > > > The other comments are lined with in the former email > > Best > > Fei > > *"Rakesh Gandhi (rgandhi)" <* * rgandhi@cisco.com * > *>* > > 2012-07-25 05:49 > > > ÊÕ¼þÈË > " zhang.fei3@zte.com.cn " < > zhang.fei3@zte.com.cn > > ³­ËÍ > "Eric Osborne (eosborne)" < eosborne@cisco.com > >, " jiang.weilian@zte.com.cn > " < jiang.weilian@zte.com.cn > >, " jingrq@ctbri.com.cn > " < jingrq@ctbri.com.cn > >, "Robert Sawaya (rsawaya)" < > rsawaya@cisco.com >, "George Swallow > (swallow)" < swallow@cisco.com >, " > yang.fan5@zte.com.cn " < > yang.fan5@zte.com.cn > > Ö÷Ìâ > RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 > > > > > > > > > > > > > Thank you Fei for detailed comments. > > Please see inline.... > * > From:* zhang.fei3@zte.com.cn > [mailto:zhang.fei3@zte.com.cn] * > Sent:* Tuesday, July 24, 2012 10:44 AM* > To:* Rakesh Gandhi (rgandhi)* > Cc:* Eric Osborne (eosborne); jiang.weilian@zte.com.cn > ; jingrq@ctbri.com.cn > ; Robert Sawaya (rsawaya); George Swallow > (swallow); yang.fan5@zte.com.cn * > Subject:* RE: Comments on > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 > > > Rakesh > > Thanks for your constructive inputs, it is really a pity that we can not > talk with each other face to face. > Yeap, that would make it much easier J > In order to reflect your idea correctly, I need to double check with you > before incorporating them into the draft. :) > > Slide 3: > > The EA Object defined in the draft > http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-03 > has an > variable "Extended Association ID" field, > > which is restricted to be IP address and FLAGS in your proposal and the > length is fixed, right? > Right. It will be fixed length, explicitly defined. > Slide 4: > > IPv4 Association source: > > In the double sided provisioning model, what if the lower IP address > that the two end points see is different? IMHO, the sender address can > be any interface address or router id of this node (for example A see > the interface address, but Z see the router id of node A) > > It is up to the user and implementation. One option is that similar > to the association ID, user provisions association source on the router > and ensures same value is configured on two ends of the bi-directional > LSP. That way interop issues can be avoided. > > If the association source is user provisions, it can be diffferent > from the lower ip address, which is the same way as we described in the > current version of the draft. And I think it is a better choice since > the signaling procedure is much simpler. > User provisioned values can override the default behavior. It is > nice to have a default behavior in the draft as it can minimize number > of configurations on a router and potential provisioning errors. > > See inline above, we need to find a better way to descirbe the > Association Source field so that the implementations can be more > flexible and let's hear about other voices from the WG. :) > > > > In the paragraph of Extended association ID- IP address > > Since your proposal is to put *the higher IP address *in this field, I > do not understand why extended association id received is different than > sent > . Can you interpret it more clearly? > It should not be different. This is in-line with your comment above > for the association source, i.e. what if two end points choose different > values. In that case value received from the association source wins. > This part can be optional. > > If it is different, I still do not understand the tie-breaker rule > here. Even it really works, the signaling procedure is much more > complicated > Ext association IDs should not be different if draft defines a > rule with lower and higher IP address. So you are right, we can remove > this point. > > Got it. > > Thanks, > Rakesh > > > Slide 6: > Sentence 1, do you mean the backup tunnel is co-routed (one signaling) > or associated (two signaling, but the path is the same)? > Some applications may require co-routed LSPs. In that case, backup > tunnels may also need to be co-routed as a requirement. > > Sentence 2 and 3, technically right, but I do not understand why > corouted must be used here, for the same latency of the two directions? > Application may have this as a requirement. Signaling should > support both co-routed or non-co-routed LSPs. > Sentence 4, why non-routed LSP can not be used here for OAM purpose? > It can be. But OAM could potentially have different handling. > IMHO, it is the same handling since the OAM packet follows the > data packet path, and the forwarding table (non-co or corout ) looks > the same when the binding is successful > > Slide 8; > I do not think the draft preclude the usage of Protection Object in the > current verion, and the usecase can be added in the next version if you > like. > Yes, that would be good. This way less interop issues to worry > about J > Your proposal is excellent and easy to implement, but I am not totally > convinced because of the listed reason blow > > (1) According to my understanding, the association can work without the > field of Extended Association ID (IP address), and what is the benefits > of the interoperability for > using two IP address? > There is a use case for auto-mesh tunnels where source node may > originate tunnels to many destinations using the same association source > and association-id. In this case, different values for extended > association ID provide unique extended association object. > Got it ,thanks > (2)The suggestion of using flags is very good, but we need to list the > motivation why corouted and non-corouted should be distinct. > This is on page 6 of the file I had sent. Inter-domain LSP with > loose-hop ERO is one example. > Thanks Fei, > Rakesh > > Hope you shed some light on me, and we can have agreement quickly. > > Best regards > > Fei > > *"Rakesh Gandhi (rgandhi)" <* * rgandhi@cisco.com * > *>* > > 2012-07-21 23:33 > > > > > ÊÕ¼þÈË > " zhang.fei3@zte.com.cn " < > zhang.fei3@zte.com.cn > > ³­ËÍ > "Eric Osborne (eosborne)" < eosborne@cisco.com > >, " jiang.weilian@zte.com.cn > " < jiang.weilian@zte.com.cn > >, " jingrq@ctbri.com.cn > " < jingrq@ctbri.com.cn > >, "Robert Sawaya (rsawaya)" < > rsawaya@cisco.com >, "George Swallow > (swallow)" < swallow@cisco.com >, " > yang.fan5@zte.com.cn " < > yang.fan5@zte.com.cn > > Ö÷Ìâ > RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 > > > > > > > > > > > > > > > > Thanks Fei for your kind reply. > > Please see the attached document that describes the set of rules that > can be standardized to populate the extended association object for > bi-directional LSP setup. This will greatly help with the > interoperability for tunnel setup. > > Thanks for accommodating these inputs in the draft. > > Regards, > Rakesh > * > From:* zhang.fei3@zte.com.cn > [mailto:zhang.fei3@zte.com.cn] * > Sent:* Wednesday, July 04, 2012 10:57 PM* > To:* Rakesh Gandhi (rgandhi)* > Cc:* Eric Osborne (eosborne); jiang.weilian@zte.com.cn > ; jingrq@ctbri.com.cn > ; Robert Sawaya (rsawaya); George Swallow > (swallow); yang.fan5@zte.com.cn * > Subject:* Re: Comments on > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 > > > Hi Rakesh > > Be glad that you are also interested in this draft and your opinions are > important to us. > > As to the plan, I am afraid I can not attend the IETF meeting in > Vancouver for the limited budget, but I would like to upload a new > version reflecting the comments collected > on and off the mailinglist recently, then ask for last call. > > Any thinking coming from you are welcome ^-^ > > Best regards > > Fei > > *"Rakesh Gandhi (rgandhi)" <* * rgandhi@cisco.com * > *>* > > 2012-07-04 20:46 > > > > > > > ÊÕ¼þÈË > " zhang.fei3@zte.com.cn " < > zhang.fei3@zte.com.cn >, " > jingrq@ctbri.com.cn " < jingrq@ctbri.com.cn > >, " yang.fan5@zte.com.cn > " < yang.fan5@zte.com.cn > >, " jiang.weilian@zte.com.cn > " < jiang.weilian@zte.com.cn > > > ³­ËÍ > "Eric Osborne (eosborne)" < eosborne@cisco.com > >, "George Swallow (swallow)" < > swallow@cisco.com >, rsawaya < > rsawaya@cisco.com > > Ö÷Ìâ > Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 > > > > > > > > > > > > > > > > > > Hello Authors of the draft, > > We have taken a close look at the > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03. > > We have some comments on this draft that we like to share with you. > There is an IETF meeting end of this Month in Vancouver, not sure if you > are planing to attend. > > Can you please advise your plans and next steps for this draft? If you > are planning to publish updated draft, may be we should sync up on our > thinking before that? > > Thanks a lot, > Rakesh Gandhi > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From rgandhi@cisco.com Wed Aug 15 10:06:50 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A51E21F86EB for ; Wed, 15 Aug 2012 10:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUrGVPJpH4Tr for ; Wed, 15 Aug 2012 10:06:49 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AD03B21F86E3 for ; Wed, 15 Aug 2012 10:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=1568; q=dns/txt; s=iport; t=1345050409; x=1346260009; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NkN+CjbXTW09H5wZs1iAsKwvmIJiFfb3veGdkYeczi8=; b=MXKcW1yJbnqrs5C0wPxUoGqfPYJg0oYsG7NuA2PBarvmLXPWqFAYnFFl YF8HPXpsJGbra8qUhmVrKe7wGhCiBO9xYt2AYwd3n9FQ87Ew0Sx73WUdH k08gyCDXQ7Byi8CUHQ3qU9Kgd0JwphwwIxIiM8C6NSm2qvblr6PjPPs0n g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHHWK1CtJXG8/2dsb2JhbABFuheBB4IgAQEBBBIBJz8MBAIBCA4DBAEBAQoUCQcyFAkIAgQBDQUIGodrmgKgTYsIhXdgA6N7gWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,774,1336348800"; d="scan'208";a="111860993" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 15 Aug 2012 17:06:49 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7FH6mWv012047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Aug 2012 17:06:49 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Wed, 15 Aug 2012 12:06:46 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger , "zhang.fei3@zte.com.cn" Thread-Topic: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 Thread-Index: AQHNewPVoTZ9sT2vpUytRTkwLtZW95dbGblA Date: Wed, 15 Aug 2012 17:06:45 +0000 Message-ID: References: <502BCF84.6090307@labn.net> In-Reply-To: <502BCF84.6090307@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.249.119] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19114.006 x-tm-as-result: No--42.725200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP , "jingrq@ctbri.com.cn" , "Robert Sawaya \(rsawaya\)" , "yang.fan5@zte.com.cn" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:06:50 -0000 Hi Lou, Thank you for your comments. As you indicated in another email, it will be easier to start with a new e= mail thread or perhaps a presentation. Thanks, Rakesh -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Wednesday, August 15, 2012 12:34 PM To: zhang.fei3@zte.com.cn Cc: Rakesh Gandhi (rgandhi); Robert Sawaya (rsawaya); yang.fan5@zte.com.cn;= CCAMP; jingrq@ctbri.com.cn Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-03 Fei/Rakeash, Co-routed associated is already supported in 3473 using bidirectional LSPs= . So, to signal co-routed all that needs to be done is use the existing pro= cedures. What issue is being addressed (i.e., function being added) by add= ing the proposed co-routed related mechanisms? Keep in mind, it's generally a *very* bad idea to define 2 mechanisms in th= e same protocol for the same function. Lou On 8/3/2012 5:16 AM, zhang.fei3@zte.com.cn wrote: > Snipped the other parts for easy reading, sorry for the delayed=20 > response >=20 > There are applications that require co-routed LSPs. So I think=20 > we should have a flag to indicate that LSPs must be co-routed, else=20 > node will send a path error for example if request cannot be met. I=20 > agree with you about complexity with double sided provisioning model thou= gh. >=20 > Since you believe that a common mechanism used for the=20 > non-corouted and corouted cases is useful, we will add the texts in=20 > the next version. From lberger@labn.net Wed Aug 15 10:10:19 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BAA21F8740 for ; Wed, 15 Aug 2012 10:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.133 X-Spam-Level: X-Spam-Status: No, score=-100.133 tagged_above=-999 required=5 tests=[AWL=2.466, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFYWxVT6SSyO for ; Wed, 15 Aug 2012 10:10:19 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 1601B21F8733 for ; Wed, 15 Aug 2012 10:10:19 -0700 (PDT) Received: (qmail 13978 invoked by uid 0); 15 Aug 2012 17:09:54 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 15 Aug 2012 17:09:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=VUK8UoNK6WhgrMoQ2rDGmLpwEOVgXkRZo66kLzW1T/w=; b=docwGBdMX8zUmD+GzzUWPl2uXiclsWePv/cgOjrMc0DvEP6rZ+anbeXhl0yCdl4APl+RVVb4WeLv28U+v6XSl0cXSpGMAcK9ZrYEDWlNxrIoVeE0hVW7uD2T+14INTcb; Received: from box313.bluehost.com ([69.89.31.113]:35082 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T1h6Q-0003W9-H6; Wed, 15 Aug 2012 11:09:54 -0600 Message-ID: <502BD7DE.2020100@labn.net> Date: Wed, 15 Aug 2012 13:09:50 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Rakesh Gandhi (rgandhi)" References: <502BCF84.6090307@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "jingrq@ctbri.com.cn" , "Robert Sawaya \(rsawaya\)" , "yang.fan5@zte.com.cn" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:10:19 -0000 Rakesh, Agreed. I sent this mail before realizing the full scope of the discussion/proposed changes. I'll look to your (the) new thread to resolve this comment. Thanks, Lou On 8/15/2012 1:06 PM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, > > Thank you for your comments. > > As you indicated in another email, it will be easier to start with a new email thread or perhaps a presentation. > > Thanks, > Rakesh > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, August 15, 2012 12:34 PM > To: zhang.fei3@zte.com.cn > Cc: Rakesh Gandhi (rgandhi); Robert Sawaya (rsawaya); yang.fan5@zte.com.cn; CCAMP; jingrq@ctbri.com.cn > Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 > > Fei/Rakeash, > Co-routed associated is already supported in 3473 using bidirectional LSPs. So, to signal co-routed all that needs to be done is use the existing procedures. What issue is being addressed (i.e., function being added) by adding the proposed co-routed related mechanisms? > > Keep in mind, it's generally a *very* bad idea to define 2 mechanisms in the same protocol for the same function. > > Lou > > On 8/3/2012 5:16 AM, zhang.fei3@zte.com.cn wrote: >> Snipped the other parts for easy reading, sorry for the delayed >> response >> >> There are applications that require co-routed LSPs. So I think >> we should have a flag to indicate that LSPs must be co-routed, else >> node will send a path error for example if request cannot be met. I >> agree with you about complexity with double sided provisioning model though. >> >> Since you believe that a common mechanism used for the >> non-corouted and corouted cases is useful, we will add the texts in >> the next version. > > > > From jdrake@juniper.net Wed Aug 15 10:10:22 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458CD21F8753 for ; Wed, 15 Aug 2012 10:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.558 X-Spam-Level: X-Spam-Status: No, score=-5.558 tagged_above=-999 required=5 tests=[AWL=1.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCwMFB7Wice9 for ; Wed, 15 Aug 2012 10:10:21 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id AAF5321F870F for ; Wed, 15 Aug 2012 10:10:10 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUCvX7zmH/y1UxWYzqY054y3CivRxP7ka@postini.com; Wed, 15 Aug 2012 10:10:21 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 15 Aug 2012 10:08:14 -0700 From: John E Drake To: Lou Berger , "zhang.fei3@zte.com.cn" Date: Wed, 15 Aug 2012 10:07:44 -0700 Thread-Topic: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 Thread-Index: Ac17A+JEF3kCDYvrQc6nS6q3Xk1u/gABEjWA Message-ID: <5E893DB832F57341992548CDBB333163A5A9B467F0@EMBX01-HQ.jnpr.net> References: <502BCF84.6090307@labn.net> In-Reply-To: <502BCF84.6090307@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP , "jingrq@ctbri.com.cn" , "Robert Sawaya \(rsawaya\)" , "yang.fan5@zte.com.cn" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:10:22 -0000 Lou, This sounds like a textbook definition of 'feature creep' and is a really b= ad idea. Thanks, John Sent from my iPhone > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Wednesday, August 15, 2012 9:34 AM > To: zhang.fei3@zte.com.cn > Cc: CCAMP; jingrq@ctbri.com.cn; Robert Sawaya (rsawaya); > yang.fan5@zte.com.cn > Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext- > associated-lsp-03 >=20 > Fei/Rakeash, > Co-routed associated is already supported in 3473 using > bidirectional LSPs. So, to signal co-routed all that needs to be done > is use the existing procedures. What issue is being addressed (i.e., > function being added) by adding the proposed co-routed related > mechanisms? >=20 > Keep in mind, it's generally a *very* bad idea to define 2 mechanisms > in the same protocol for the same function. >=20 > Lou >=20 > On 8/3/2012 5:16 AM, zhang.fei3@zte.com.cn wrote: > > Snipped the other parts for easy reading, sorry for the delayed > > response > > > > There are applications that require co-routed LSPs. So I think > > we should have a flag to indicate that LSPs must be co-routed, else > > node will send a path error for example if request cannot be met. I > > agree with you about complexity with double sided provisioning model > though. > > > > Since you believe that a common mechanism used for the > > non-corouted and corouted cases is useful, we will add the texts in > > the next version. > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From rgandhi@cisco.com Wed Aug 15 10:10:40 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EE121F8772 for ; Wed, 15 Aug 2012 10:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, J_CHICKENPOX_66=0.6, J_CHICKENPOX_93=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-MAGMXcsMVF for ; Wed, 15 Aug 2012 10:10:39 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1A70F21F8733 for ; Wed, 15 Aug 2012 10:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=24432; q=dns/txt; s=iport; t=1345050639; x=1346260239; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=s651ECGFgEz2xC6VCY3ri94vzjTWqthN5vtW3+QIv8Y=; b=iMDSLweSai/aGl1sPjKouA3U6dUHNZKYKexjzsGGiX12Y6eiaNsQbOnS NshWYf6Mcgf6JsT51aXRA6lgTe/D0izqrBkG8nNF6GV3v72N1OZSSNBoA WJXRemdBzkNbRUsjmBbG2DdiFqnS0rj8KnvdsqHk3vFPvXVniJVBgUCKf c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAILXK1CtJV2d/2dsb2JhbABFhgGzL2eBB4IgAQEBBAEBAQ8BIToLDAQCAQYCDgMEAQEBBAYdBQICJQsUCQgCBAENBQgah2sLmXiNEwiTMoEdiWsCEgaFJzZgA5ZjjRiBZoJfgVYJ X-IronPort-AV: E=Sophos;i="4.77,774,1336348800"; d="scan'208";a="111889919" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 15 Aug 2012 17:10:38 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7FHAbNO026022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Aug 2012 17:10:37 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Wed, 15 Aug 2012 12:10:37 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger , "zhang.fei3@zte.com.cn" Thread-Topic: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 Thread-Index: AQHNewd0+HddaTB6UUmSKbjiOPaACJdbGulQ Date: Wed, 15 Aug 2012 17:10:37 +0000 Message-ID: References: <502BD599.30905@labn.net> In-Reply-To: <502BD599.30905@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.249.119] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19114.004 x-tm-as-result: No--56.538800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: CCAMP , "jingrq@ctbri.com.cn" , "Robert Sawaya \(rsawaya\)" , "yang.fan5@zte.com.cn" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:10:40 -0000 SGkgTG91LA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgZmVlZGJhY2tzLg0KDQpGZWkgYW5kIEkgYXJl IGRpc2N1c3NlZCB0aGUgcG9zc2liaWxpdHkgYnV0IGNvdWxkIG5vdCBhdHRlbmQgdGhlIG1lZXRp bmcgaW4gVmFuY291dmVyLg0KDQpXZSB3aWxsIHN0YXJ0IGEgbmV3IGVtYWlsIHRocmVhZCBvbiB0 aGUgY2hhbmdlcy4NCg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSANClNlbnQ6 IFdlZG5lc2RheSwgQXVndXN0IDE1LCAyMDEyIDE6MDAgUE0NClRvOiB6aGFuZy5mZWkzQHp0ZS5j b20uY247IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQpDYzogUm9iZXJ0IFNhd2F5YSAocnNhd2F5 YSk7IHlhbmcuZmFuNUB6dGUuY29tLmNuOyBDQ0FNUDsgamluZ3JxQGN0YnJpLmNvbS5jbg0KU3Vi amVjdDogUmU6IFtDQ0FNUF0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJz dnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDMNCg0KRmVpL1Jha2VzaCwNCg0KCUknZCBsaWtlIHRv IHRha2UgYSBzdGVwIGJhY2sgb24gdGhpcyB0aHJlYWQuIFRoaXMgbWFpbCBzZWVtcyB0byBiZSBi cmluZ2luZyB0aGUgV0cgaW50byB0aGUgbWlkZGxlIG9mIGEgcHJpdmF0ZSBkaXNjdXNzaW9uLiBJ IHBlcnNvbmFsbHkgdGhpbmsgdGhlICpyaWdodCogd2F5IHRvIGhhdmUgYnJvdWdodCB0aGlzICAq cHJpdmF0ZSogZGlzY3Vzc2lvbiB0byB0aGUgYXR0ZW50aW9uIG9mIHRoZSBXRyB3b3VsZCBiZSB0 byBlaXRoZXI6DQooYSkgc3RhcnQgdGhlIGRpc2N1c3Npb24gYW5ldywgdGhpcyB0aW1lIGluY2x1 ZGluZyB0aGUgV0cgb3INCihiKSB1c2UgdGhlIG1lZXRpbmcgdGltZSBpbiBWYW5jb3V2ZXIgdG8g cmFpc2UgdGhlIGRpc2N1c3Npb24gKEZlaSwNCiAgICBJIGtub3cgeW91IHdlcmVuJ3QgdGhlcmUs IGJ1dCBSYWtlc2ggb3Igc29tZW9uZSBlbHNlIGNvdWxkIGhhdmUNCiAgICBwcmVzZW50ZWQuKQ0K DQpTbyB3aGVyZSBkbyB3ZSBnbyBmcm9tIGhlcmU/DQoNCkknZCBsaWtlIHRvIGFzayB0aGF0IHNv bWVvbmUgKFJha2VzaCwgRmVpLCBldGMuKSByZXZpZXcgZWFjaCBvZiB0aGUgcHJvcG9zZWQgY2hh bmdlYW5kIHRoZSByYXRpb25hbCBmb3IgZWFjaCBjaGFuZ2UgKGluIG9uZSBvciBpbiBzZXBhcmF0 ZSBlLW1haWxzKS4gVGhlIFdHIGRpc2N1c3Npb24gY2FuIHRoZW4gcmVhbGx5IGJlZ2luIG9uIHRo ZSBwcm9wb3NlZCBjaGFuZ2VzLiAoV2hpY2ggYXJlIHF1aXRlIHN1YnN0YW50aWFsIGJvdGggaW4g c2NvcGUgYW5kIGltcGxpY2F0aW9uLikNCg0KTG91IChhcyBjby1jaGFpcikNCg0KT24gNy8zMC8y MDEyIDEwOjAzIFBNLCB6aGFuZy5mZWkzQHp0ZS5jb20uY24gd3JvdGU6DQo+IA0KPiBUaGFuayB5 b3UgUmFrZXNoIGZvciBzaGFyaW5nIHlvdXIgaWRlYSwgSSB0aGluayB3ZSBhcmUgcm91Z2hseSBp biANCj4gYWdyZWVtZW50IGFuZCBuZWVkIHRvIGhlYXIgbW9yZSB2b2ljZXMgZnJvbSB0aGUgV0cu IDopDQo+IA0KPiBTZWUgaW5saW5lIDxmZWk+PC9mZWk+DQo+IA0KPiBCZXN0DQo+IA0KPiBGZWkN Cj4gDQo+IA0KPiAqIlJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIiA8cmdhbmRoaUBjaXNjby5jb20+ Kg0KPiANCj4gMjAxMi0wNy0zMCAyMzo1OQ0KPiANCj4gCQ0KPiDK1bz+yMsNCj4gCSJ6aGFuZy5m ZWkzQHp0ZS5jb20uY24iIDx6aGFuZy5mZWkzQHp0ZS5jb20uY24+DQo+ILOty80NCj4gCSJFcmlj IE9zYm9ybmUgKGVvc2Jvcm5lKSIgPGVvc2Jvcm5lQGNpc2NvLmNvbT4sIA0KPiAiamlhbmcud2Vp bGlhbkB6dGUuY29tLmNuIiA8amlhbmcud2VpbGlhbkB6dGUuY29tLmNuPiwgDQo+ICJqaW5ncnFA Y3RicmkuY29tLmNuIiA8amluZ3JxQGN0YnJpLmNvbS5jbj4sICJSb2JlcnQgU2F3YXlhIChyc2F3 YXlhKSINCj4gPHJzYXdheWFAY2lzY28uY29tPiwgIkdlb3JnZSBTd2FsbG93IChzd2FsbG93KSIg PHN3YWxsb3dAY2lzY28uY29tPiwgDQo+ICJ5YW5nLmZhbjVAenRlLmNvbS5jbiIgPHlhbmcuZmFu NUB6dGUuY29tLmNuPg0KPiDW98ziDQo+IAlSRTogQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2Ft cC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDMNCj4gDQo+IA0KPiAJDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gVGhhbmtzIEZlaSBmb3IgeW91ciBraW5kIHJlcGx5LiBTb3JyeSBm b3IgdGhlIGRlbGF5IChhcyBJIHdhcyBhd2F5KS4NCj4gIA0KPiBQbGVhc2Ugc2VlIGlubGluZS4u PFJHMT4uLg0KPiAgDQo+ICpGcm9tOiogemhhbmcuZmVpM0B6dGUuY29tLmNuIFttYWlsdG86emhh bmcuZmVpM0B6dGUuY29tLmNuXSAqDQo+IFNlbnQ6KiBXZWRuZXNkYXksIEp1bHkgMjUsIDIwMTIg MTE6NDIgQU0qDQo+IFRvOiogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkqDQo+IENjOiogRXJpYyBP c2Jvcm5lIChlb3Nib3JuZSk7IGppYW5nLndlaWxpYW5AenRlLmNvbS5jbjsgDQo+IGppbmdycUBj dGJyaS5jb20uY247IFJvYmVydCBTYXdheWEgKHJzYXdheWEpOyBHZW9yZ2UgU3dhbGxvdyANCj4g KHN3YWxsb3cpOw0KPiB5YW5nLmZhbjVAenRlLmNvbS5jbioNCj4gU3ViamVjdDoqIFJFOiBDb21t ZW50cyBvbg0KPiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVk LWxzcC0wMw0KPiAgDQo+IA0KPiBSYWtlc2gNCj4gDQo+IFRoYW5rcyBmb3IgeW91ciBuaWNlIGlu dGVycHJldGF0aW9uLCBhbmQgSSBjYW4gc2VlIHRoZXJlIGFyZSBhdCBsZWFzdCANCj4gdGhyZWUg cGFydHMgdGhhdCBuZWVkIHRvIGJlIHJldmlzZWQgaW4gdGhlIG5leHQgdmVyc2lvbg0KPiANCj4g MSkgRGVmaW5lIG9ubHkgb25lIGFzc29jaWF0aW9uIHR5cGUsIGFuZCB0aGUgc2luZ2xlIHNpZGVk IGFuZCBkb3VibGUgDQo+IHNpZGVkIHByb3Zpc2lvbmluZyBtb2RlbHMgYXJlIHJlcHJlc2VudGVk IGJ5IDEgZmxhZy4gIEFncmVlIDxSRzE+IA0KPiBHcmVhdCwgdGhhbmtzLg0KPiANCj4gMikgRGVm aW5lIG9uZSBmbGFnIGZvciBjby1yb3V0ZWQgb3Igbm9uLWNvcm91dGVkLiBJZiB0aGUgY28tcm91 dGVkIA0KPiBiaWRpciBpcyB0aGUgZGVmYXVsdCBiZWhhdmlvciwgd2h5IG5vdCB1c2luZyB0aGUg cHJvY2VkdXJlIGRlZmluZWQgaW4gUkZDMzQ3Mz8NCj4gSSBhbSBhZnJhaWQgaXQgaXMgaGFyZA0K PiB0byBwZXJzdWFkZSB0aGUgV0cgdG8gZG8gc28uIE1heWJlIHRoZSBiZXR0ZXIgd2F5IGlzIHRo YXQgbm9uLWNvcm91dGVkIA0KPiBiaWRpciBpcyB0aGUgZGVmYXVsdCwgYW5kIHRoZSBzZXQgb2Yg dGhlIGNvLXJvdXRlZCBmbGFnIG9ubHkgbWVhbnMgDQo+IHRoYXQgaXQgaXMgcmVjb21tZW5kZWQs IG5vdCBtYW5kYXRvcnksIHRoZSBjaGVja2luZyB3aGV0aGVyIHRoZSBMU1AgaXMgDQo+IGNvLXJv dXRlZCBjYW4gYmUgZG9uZSBieSBjb21wYXJpbmcgdGhlIFJSTyBvYmplY3RzLiBXaGF0IGlzIHlv dXIgb3Bpbmlvbj8NCj4gPFJHMT4gSXQgaXMgZmluZSB0byBoYXZlIG5vbiBjby1yb3V0ZWQgYXMg ZGVmYXVsdC4gUkZDIDM0NzMgaXMgYSBHTVBMUyANCj4gc2lnbmFsaW5nIHByb2NlZHVyZS4gSXQg bWF5IG5vdCBiZSBvcHRpbWFsICB0byBoYXZlIHR3byBkaWZmZXJlbnQgDQo+IHNpZ25hbGluZyBw cm9jZWR1cmVzLCBvbmUgZm9yIG5vbiBjby1yb3V0ZWQgKGV4dCBhc3NvY2lhdGVkIG9iamVjdCkg DQo+IGFuZCBvbmUgZm9yIGNvLXJvdXRlZCAoUkZDIDM0NzMpIHByb2NlZHVyZXMuIEJ5IGFkZGlu ZyBhIGZsYWcgZm9yIA0KPiBjby1yb3V0ZWQsIHNhbWUgc2lnbmFsaW5nIChleHQgYXNzb2NpYXRl ZCBvYmplY3QpIGNhbiBiZSB1c2VkIGZvciBib3RoIA0KPiB3aGljaCBpcyBuaWNlLiBXZSBiZWxp ZXZlIGNvbXBhcmluZyBvZiBSUk8gY2FuIGJlIG1pc2xlYWRpbmcgYmVjYXVzZSANCj4gdHdvIExT UHMgY2FuIGJlIG9uIHRoZSBzYW1lIHBhdGggZXZlbiB0aG91Z2ggcHJvdmlzaW9uZWQgdG8gYmUg bm9uIGNvLXJvdXRlZC4NCj4gDQo+IDxmZWk+DQo+IFNvcnJ5IHRoYXQgd2hhdCBJIHN1Z2dlc3Rl ZCBtYXliZSBtaXNsZWFkIHlvdSwgdGhlIGZvbGxvd2luZyANCj4gZGVzY3JpcGl0b25zIGFyZSBt b3JlIGFjY3VyYXRlLiA6KSAgMSlUaGUgZGVmYXVsdCBiZWhhdmlvciANCj4gKG5vbi1jb3JvdXRl ZCkgbWVhbnMgdGhhdCBpdCBpcyBub3QgcmVxdWlyZWQgdG8gYmUgY28tcm91dGVkLiBJbiBvdGhl ciANCj4gd29yZHMsIGl0IGlzIGFsc28gT0sgdGhhdCB0aGUgdHdvIHBhdGhzIGFyZSBhbG9uZyB0 aGUgc2FtZSBwYXRoLg0KPiAgMilUaGUgZmxhZyBzZXQgbWVhbnMgdGhhdCBjby1yb3V0ZWQgaXMg cmVjb21tZW5kZWQuIEluIG90aGVyIHdvcmRzLCANCj4gdGhlIHJldmVyc2UgTFNQIFNIT1VMRCBi ZSBlc3RhYmxpc2hlZCBpbiB0aGUgc2FtZSBwYXRoIGFzIG11Y2ggYXMgcG9zc2libGUuDQo+IElm IHRoZSBmbGFnIHNldCBtZWFucw0KPiB0aGF0IGNvLXJvdXRlZCBpcyBtYW5kYXRvcnksdGhlIHBy b2NlZHVyZXMgd2lsbCBiZSB2ZXJ5IGNvbXBsZXggaW4gDQo+IGRvdWJsZSBzaWRlZCBwcm92aXNp b25pbmcgbW9kZWwuDQo+IDwvZmVpPg0KPiANCj4gMylBcyB0byB0aGUgdHVwbGUgb2YgPGxvd2Vy IGlwIGFkZHJlc3MsIGhpZ2ggaXAgYWRkcmVzcywgYXNzb2NpYXRpb24NCj4gaWQ+LCB5ZWFoLCBp dCBpcyBvbmUga2luZCBvZiBpbXBsZW1lbnRhdGlvbiwgYnV0IHRoZXJlIGFyZSBwb3RlbnRpYWwN Cj4gc29tZSBvdGhlciByZWFsaXphdGlvbnMsIGxpa2UgdXNpbmcgb25lIG9mIHRoZSByb3V0ZXIg aWQgcGx1cyB0aGUgDQo+IHR1bm5lbCBpZC4gSSB0aGluayB3ZSBoYWQgYmV0dGVyIG5vdCByZXN0 cmljdCB0aGUgZXhlY3V0aW9uIHRvIHN1Y2ggYSANCj4gbmFycm93IHNjb3BlLiBXaGF0IGFib3V0 IHRoZSBFQSBmb3JtYXQgbGlzdGVkIGJlbG93Pw0KPiANCj4gICAgICAgICAwICAgICAgICAgICAg ICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQo+ICAgICAg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxDQo+ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgfCAgICAgICAgICAgIExlbmd0aCAgICAgICAg ICAgICB8IENsYXNzLU51bSgxOTkpfCAgQy1UeXBlIChUQkEpIHwNCj4gICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ ICAgICB8ICAgICAgIEFzc29jaWF0aW9uIFR5cGUgICAgICAgIHwgICAgICAgQXNzb2NpYXRpb24g SUQgICAgICAgICAgfA0KPiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgIHwgICAgICAgICAgICAgICAgICAg IElQdjQgQXNzb2NpYXRpb24gU291cmNlICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KPiAgICAgfCAgICAgICAgICAgICAgICAgICBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNl ICAgICAgICAgICAgICAgICAgIHwNCj4gICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ICAgICB8RXh0ZW5kZWQgQXNz b2NpYXRpb24gRmxhZ3MuICAgIHxFeHRlbmRlZCBBc3NvY2lhdGlvbiBJRCAuLi4gICAgfA0KPiAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQo+ICAgICAgfC4uLi4oY29udGludWUpICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDoNCj4gICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IA0KPiA8Ukc+ IERvIHlvdSBtZWFuIHRvIGhhdmUgZXh0ZW5kZWQgYXNzb2NpYXRpb24gSUQgYXMgdHVubmVsIElE ICgxNiANCj4gYml0cykNCj4gKyBJUCBhZGRyZXNzICgzMiBiaXRzKSBpbiB0aGlzIG9iamVjdD8N Cj4gUGxlYXNlIHNlZSBpbmxpbmUgYmVsb3cuLjxSRzE+Li4NCj4gDQo+IDxmZWk+DQo+IE5vLiBJ IHdhbnQgdG8gc2F5IHRoYXQgdGhpcyBmb3JtYXQgb2YgRUEgb2JqZWN0cyBjYW4gYWNjb21vZGF0 ZSBtb3JlIA0KPiBraW5kcyBvZiBpbXBsZW1lbnRhdGlvbnMuIExpa2UNCj4gDQo+IDEpQXNzb2Np YXRpb24gSUQ6IHVzZXIgcHJvdmlzaW9uZWQgaWRlbnRpYWwgdmFsdWU7IEFzc29jaWF0aW9uIFNv dXJjZToNCj4gdGhlIGxvd2UgaXAgYWRkcmVzczsgRUEgSUQ6IHRoZSBoaWdoZXIgSVAgYWRkcmVz cy4gQXMgeW91IHN1Z2dlc3RlZA0KPiANCj4gMilBc3NvY2lhdGlvbiBJRDogdHVubmVsIElEIG9y IHVzZXIgcHJvdmlzaW9uZWQgdmFsdWU7IEFzc29jaWF0aW9uIA0KPiBTb3VyY2U6VHVubmVsIHNl bmRlciBhZGRyZXNzIG9yIHVzZXIgcHJvdmlzaW9uZWQ7IEVBIElEOiBiZSBlbXB0eSBvciANCj4g TFNQIElEIG9yIGFueSBvdGhlciBpbmZvcm1hdGlvbi4NCj4gDQo+IDMpVGhlIHBvdGVudGlhbCBv dGhlciBpbXBsZW1lbnRhdGlvbnMuLi4NCj4gDQo+IElNSE8sIHRoZSBFQSBJRCBjYW4gYmUgSVAg YWRkcmVzcyBvciBhbnkgb3RoZXIgdmFsdWVzIGluIHRoZSBjb250ZXh0IA0KPiBvZiBBc3NvY2lh dGlvbiBTb3VyY2UgcGx1cyBBc3NvY2lhdGlvbiBJRCwgd2hpY2ggaXMgYmFja3dhcmQgY29tcGF0 aWJsZS4NCj4gDQo+IDwvZmVpPg0KPiANCj4gDQo+IFRoZSBvdGhlciBjb21tZW50cyBhcmUgbGlu ZWQgd2l0aCA8ZmVpPiBpbiB0aGUgZm9ybWVyIGVtYWlsDQo+IA0KPiBCZXN0DQo+IA0KPiBGZWkN Cj4gDQo+ICoiUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkiIDwqICogcmdhbmRoaUBjaXNjby5jb20g KiANCj4gPG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNvbT4gKj4qDQo+IA0KPiAyMDEyLTA3LTI1IDA1 OjQ5DQo+IA0KPiAJDQo+IMrVvP7Iyw0KPiAJIiB6aGFuZy5mZWkzQHp0ZS5jb20uY24gPG1haWx0 bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+ICIgPCANCj4gemhhbmcuZmVpM0B6dGUuY29tLmNuIDxt YWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPiA+DQo+ILOty80NCj4gCSJFcmljIE9zYm9ybmUg KGVvc2Jvcm5lKSIgPCBlb3Nib3JuZUBjaXNjby5jb20gDQo+IDxtYWlsdG86ZW9zYm9ybmVAY2lz Y28uY29tPiA+LCAiIGppYW5nLndlaWxpYW5AenRlLmNvbS5jbiANCj4gPG1haWx0bzpqaWFuZy53 ZWlsaWFuQHp0ZS5jb20uY24+ICIgPCBqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY24gDQo+IDxtYWls dG86amlhbmcud2VpbGlhbkB6dGUuY29tLmNuPiA+LCAiIGppbmdycUBjdGJyaS5jb20uY24gDQo+ IDxtYWlsdG86amluZ3JxQGN0YnJpLmNvbS5jbj4gIiA8IGppbmdycUBjdGJyaS5jb20uY24gDQo+ IDxtYWlsdG86amluZ3JxQGN0YnJpLmNvbS5jbj4gPiwgIlJvYmVydCBTYXdheWEgKHJzYXdheWEp IiA8IA0KPiByc2F3YXlhQGNpc2NvLmNvbSA8bWFpbHRvOnJzYXdheWFAY2lzY28uY29tPiA+LCAi R2VvcmdlIFN3YWxsb3cgDQo+IChzd2FsbG93KSIgPCBzd2FsbG93QGNpc2NvLmNvbSA8bWFpbHRv OnN3YWxsb3dAY2lzY28uY29tPiA+LCAiDQo+IHlhbmcuZmFuNUB6dGUuY29tLmNuIDxtYWlsdG86 eWFuZy5mYW41QHp0ZS5jb20uY24+ICIgPCANCj4geWFuZy5mYW41QHp0ZS5jb20uY24gPG1haWx0 bzp5YW5nLmZhbjVAenRlLmNvbS5jbj4gPg0KPiDW98ziDQo+IAlSRTogQ29tbWVudHMgb24gZHJh ZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDMNCj4gDQo+ IA0KPiAgDQo+IA0KPiANCj4gCQ0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBUaGFuayB5b3Ug RmVpICBmb3IgZGV0YWlsZWQgY29tbWVudHMuDQo+ICANCj4gUGxlYXNlIHNlZSBpbmxpbmUuLjxS Rz4uLg0KPiAgICoNCj4gRnJvbToqIHpoYW5nLmZlaTNAenRlLmNvbS5jbiA8bWFpbHRvOnpoYW5n LmZlaTNAenRlLmNvbS5jbj4gDQo+IFttYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuXSA8bWFp bHRvOlttYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuXT4gDQo+ICoNCj4gU2VudDoqIFR1ZXNk YXksIEp1bHkgMjQsIDIwMTIgMTA6NDQgQU0qDQo+IFRvOiogUmFrZXNoIEdhbmRoaSAocmdhbmRo aSkqDQo+IENjOiogRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7IGppYW5nLndlaWxpYW5AenRlLmNv bS5jbiANCj4gPG1haWx0bzpqaWFuZy53ZWlsaWFuQHp0ZS5jb20uY24+IDsgamluZ3JxQGN0YnJp LmNvbS5jbiANCj4gPG1haWx0bzpqaW5ncnFAY3RicmkuY29tLmNuPiA7IFJvYmVydCBTYXdheWEg KHJzYXdheWEpOyBHZW9yZ2UgU3dhbGxvdyANCj4gKHN3YWxsb3cpOyB5YW5nLmZhbjVAenRlLmNv bS5jbiA8bWFpbHRvOnlhbmcuZmFuNUB6dGUuY29tLmNuPiAqDQo+IFN1YmplY3Q6KiBSRTogQ29t bWVudHMgb24NCj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRl ZC1sc3AtMDMNCj4gIA0KPiANCj4gUmFrZXNoDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgY29uc3Ry dWN0aXZlIGlucHV0cywgaXQgaXMgcmVhbGx5IGEgcGl0eSB0aGF0IHdlIGNhbiANCj4gbm90IHRh bGsgd2l0aCBlYWNoIG90aGVyIGZhY2UgdG8gZmFjZS4NCj4gPFJHPiBZZWFwLCB0aGF0IHdvdWxk IG1ha2UgaXQgbXVjaCBlYXNpZXIgSiBJbiBvcmRlciB0byByZWZsZWN0IHlvdXIgDQo+IGlkZWEg Y29ycmVjdGx5LCBJIG5lZWQgdG8gZG91YmxlIGNoZWNrIHdpdGggeW91IGJlZm9yZSBpbmNvcnBv cmF0aW5nIA0KPiB0aGVtIGludG8gdGhlIGRyYWZ0LiA6KQ0KPiANCj4gU2xpZGUgMzoNCj4gDQo+ IFRoZSBFQSBPYmplY3QgZGVmaW5lZCBpbiB0aGUgZHJhZnQNCj4gaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDMNCj4gPGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0LTAzPiBoYXMgYW4gDQo+IHZh cmlhYmxlICJFeHRlbmRlZCBBc3NvY2lhdGlvbiBJRCIgZmllbGQsDQo+IA0KPiB3aGljaCBpcyBy ZXN0cmljdGVkIHRvIGJlIElQIGFkZHJlc3MgYW5kIEZMQUdTIGluIHlvdXIgcHJvcG9zYWwgYW5k IA0KPiB0aGUgbGVuZ3RoIGlzIGZpeGVkLCByaWdodD8NCj4gPFJHPiBSaWdodC4gSXQgd2lsbCBi ZSBmaXhlZCBsZW5ndGgsIGV4cGxpY2l0bHkgZGVmaW5lZC4NCj4gU2xpZGUgNDoNCj4gDQo+IElQ djQgQXNzb2NpYXRpb24gc291cmNlOg0KPiANCj4gSW4gdGhlIGRvdWJsZSBzaWRlZCBwcm92aXNp b25pbmcgbW9kZWwsIHdoYXQgaWYgdGhlIGxvd2VyIElQIGFkZHJlc3MgDQo+IHRoYXQgdGhlIHR3 byBlbmQgcG9pbnRzIHNlZSBpcyBkaWZmZXJlbnQ/IElNSE8sIHRoZSBzZW5kZXIgYWRkcmVzcyBj YW4gDQo+IGJlIGFueSBpbnRlcmZhY2UgYWRkcmVzcyBvciByb3V0ZXIgaWQgb2YgdGhpcyBub2Rl IChmb3IgZXhhbXBsZSBBIHNlZSANCj4gdGhlIGludGVyZmFjZSBhZGRyZXNzLCBidXQgWiBzZWUg dGhlIHJvdXRlciBpZCBvZiBub2RlIEEpDQo+IA0KPiA8Ukc+IEl0IGlzIHVwIHRvIHRoZSB1c2Vy IGFuZCBpbXBsZW1lbnRhdGlvbi4gT25lIG9wdGlvbiBpcyB0aGF0IA0KPiBzaW1pbGFyIHRvIHRo ZSBhc3NvY2lhdGlvbiBJRCwgdXNlciBwcm92aXNpb25zIGFzc29jaWF0aW9uIHNvdXJjZSBvbiAN Cj4gdGhlIHJvdXRlciBhbmQgZW5zdXJlcyBzYW1lIHZhbHVlIGlzIGNvbmZpZ3VyZWQgb24gdHdv IGVuZHMgb2YgdGhlIA0KPiBiaS1kaXJlY3Rpb25hbCBMU1AuIFRoYXQgd2F5IGludGVyb3AgaXNz dWVzIGNhbiBiZSBhdm9pZGVkLg0KPiANCj4gPGZlaT5JZiB0aGUgYXNzb2NpYXRpb24gc291cmNl IGlzIHVzZXIgcHJvdmlzaW9ucywgaXQgY2FuIGJlIA0KPiBkaWZmZmVyZW50IGZyb20gdGhlIGxv d2VyIGlwIGFkZHJlc3MsIHdoaWNoIGlzIHRoZSBzYW1lIHdheSBhcyB3ZSANCj4gZGVzY3JpYmVk IGluIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRyYWZ0LiBBbmQgSSB0aGluayBpdCBpcyBh IA0KPiBiZXR0ZXIgY2hvaWNlIHNpbmNlIHRoZSBzaWduYWxpbmcgcHJvY2VkdXJlIGlzIG11Y2gg c2ltcGxlci4NCj4gPFJHMT4gVXNlciBwcm92aXNpb25lZCB2YWx1ZXMgIGNhbiBvdmVycmlkZSB0 aGUgZGVmYXVsdCBiZWhhdmlvci4gSXQgDQo+IGlzIG5pY2UgdG8gaGF2ZSBhIGRlZmF1bHQgYmVo YXZpb3IgaW4gdGhlIGRyYWZ0IGFzIGl0IGNhbiBtaW5pbWl6ZSANCj4gbnVtYmVyIG9mIGNvbmZp Z3VyYXRpb25zIG9uIGEgcm91dGVyIGFuZCBwb3RlbnRpYWwgcHJvdmlzaW9uaW5nIGVycm9ycy4N Cj4gPGZlaT4NCj4gU2VlIGlubGluZSBhYm92ZSwgd2UgbmVlZCB0byBmaW5kIGEgYmV0dGVyIHdh eSB0byBkZXNjaXJiZSB0aGUgDQo+IEFzc29jaWF0aW9uIFNvdXJjZSBmaWVsZCBzbyB0aGF0IHRo ZSBpbXBsZW1lbnRhdGlvbnMgY2FuIGJlIG1vcmUgDQo+IGZsZXhpYmxlIGFuZCBsZXQncyBoZWFy IGFib3V0IG90aGVyIHZvaWNlcyBmcm9tIHRoZSBXRy4gOikgPC9mZWk+DQo+IA0KPiANCj4gSW4g dGhlIHBhcmFncmFwaCBvZiBFeHRlbmRlZCBhc3NvY2lhdGlvbiBJRC0gSVAgYWRkcmVzcw0KPiAN Cj4gU2luY2UgeW91ciBwcm9wb3NhbCBpcyB0byBwdXQgKnRoZSBoaWdoZXIgSVAgYWRkcmVzcyAq aW4gdGhpcyBmaWVsZCwgSSANCj4gZG8gbm90IHVuZGVyc3RhbmQgd2h5IGV4dGVuZGVkIGFzc29j aWF0aW9uIGlkIHJlY2VpdmVkIGlzIGRpZmZlcmVudCANCj4gdGhhbiBzZW50IC4gQ2FuIHlvdSBp bnRlcnByZXQgaXQgbW9yZSBjbGVhcmx5Pw0KPiA8Ukc+IEl0IHNob3VsZCBub3QgYmUgZGlmZmVy ZW50LiBUaGlzIGlzIGluLWxpbmUgd2l0aCB5b3VyIGNvbW1lbnQgDQo+IGFib3ZlIGZvciB0aGUg YXNzb2NpYXRpb24gc291cmNlLCBpLmUuIHdoYXQgaWYgdHdvIGVuZCBwb2ludHMgY2hvb3NlIA0K PiBkaWZmZXJlbnQgdmFsdWVzLiBJbiB0aGF0IGNhc2UgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUg YXNzb2NpYXRpb24gc291cmNlIHdpbnMuDQo+IFRoaXMgcGFydCBjYW4gYmUgIG9wdGlvbmFsLg0K PiANCj4gPGZlaT5JZiBpdCBpcyBkaWZmZXJlbnQsIEkgc3RpbGwgZG8gbm90IHVuZGVyc3RhbmQg dGhlIHRpZS1icmVha2VyIA0KPiBydWxlIGhlcmUuIEV2ZW4gaXQgcmVhbGx5IHdvcmtzLCB0aGUg c2lnbmFsaW5nIHByb2NlZHVyZSBpcyBtdWNoIG1vcmUgDQo+IGNvbXBsaWNhdGVkIDxSRzE+IEV4 dCBhc3NvY2lhdGlvbiBJRHMgc2hvdWxkIG5vdCBiZSBkaWZmZXJlbnQgaWYgZHJhZnQgDQo+IGRl ZmluZXMgYSBydWxlIHdpdGggbG93ZXIgYW5kIGhpZ2hlciBJUCBhZGRyZXNzLiBTbyB5b3UgYXJl IHJpZ2h0LCB3ZSANCj4gY2FuIHJlbW92ZSB0aGlzIHBvaW50Lg0KPiA8ZmVpPg0KPiBHb3QgaXQu DQo+IDwvZmVpPg0KPiBUaGFua3MsDQo+IFJha2VzaA0KPiANCj4gDQo+IFNsaWRlIDY6DQo+IFNl bnRlbmNlIDEsIGRvIHlvdSBtZWFuIHRoZSBiYWNrdXAgdHVubmVsIGlzIGNvLXJvdXRlZCAob25l IHNpZ25hbGluZykgDQo+IG9yIGFzc29jaWF0ZWQgKHR3byBzaWduYWxpbmcsIGJ1dCB0aGUgcGF0 aCBpcyB0aGUgc2FtZSk/DQo+IDxSRz4gU29tZSBhcHBsaWNhdGlvbnMgbWF5IHJlcXVpcmUgY28t cm91dGVkIExTUHMuIEluIHRoYXQgY2FzZSwgDQo+IGJhY2t1cCB0dW5uZWxzIG1heSBhbHNvIG5l ZWQgdG8gYmUgY28tcm91dGVkIGFzIGEgcmVxdWlyZW1lbnQuDQo+IA0KPiBTZW50ZW5jZSAyIGFu ZCAzLCB0ZWNobmljYWxseSByaWdodCwgYnV0IEkgZG8gbm90IHVuZGVyc3RhbmQgd2h5IA0KPiBj b3JvdXRlZCBtdXN0IGJlIHVzZWQgaGVyZSwgZm9yIHRoZSBzYW1lIGxhdGVuY3kgb2YgdGhlIHR3 byBkaXJlY3Rpb25zPw0KPiA8Ukc+IEFwcGxpY2F0aW9uIG1heSBoYXZlIHRoaXMgYXMgYSByZXF1 aXJlbWVudC4gU2lnbmFsaW5nIHNob3VsZCANCj4gc3VwcG9ydCBib3RoIGNvLXJvdXRlZCBvciBu b24tY28tcm91dGVkIExTUHMuDQo+IFNlbnRlbmNlIDQsIHdoeSBub24tcm91dGVkIExTUCBjYW4g bm90IGJlIHVzZWQgaGVyZSBmb3IgT0FNIHB1cnBvc2U/DQo+IDxSRz4gSXQgY2FuIGJlLiBCdXQg T0FNIGNvdWxkIHBvdGVudGlhbGx5IGhhdmUgZGlmZmVyZW50IGhhbmRsaW5nLg0KPiA8ZmVpPiBJ TUhPLCBpdCBpcyB0aGUgc2FtZSBoYW5kbGluZyBzaW5jZSB0aGUgT0FNIHBhY2tldCBmb2xsb3dz IHRoZSANCj4gZGF0YSBwYWNrZXQgIHBhdGgsIGFuZCB0aGUgZm9yd2FyZGluZyB0YWJsZSAgKG5v bi1jbyBvciBjb3JvdXQgKSAgDQo+IGxvb2tzIHRoZSBzYW1lIHdoZW4gdGhlIGJpbmRpbmcgaXMg c3VjY2Vzc2Z1bA0KPiANCj4gU2xpZGUgODsNCj4gSSBkbyBub3QgdGhpbmsgdGhlIGRyYWZ0IHBy ZWNsdWRlIHRoZSB1c2FnZSBvZiBQcm90ZWN0aW9uIE9iamVjdCBpbiANCj4gdGhlIGN1cnJlbnQg dmVyaW9uLCBhbmQgdGhlIHVzZWNhc2UgY2FuIGJlIGFkZGVkIGluIHRoZSBuZXh0IHZlcnNpb24g DQo+IGlmIHlvdSBsaWtlLg0KPiA8Ukc+IFllcywgdGhhdCB3b3VsZCBiZSBnb29kLiAgVGhpcyB3 YXkgbGVzcyBpbnRlcm9wIGlzc3VlcyB0byB3b3JyeSANCj4gYWJvdXQgSiBZb3VyIHByb3Bvc2Fs IGlzIGV4Y2VsbGVudCBhbmQgZWFzeSB0byBpbXBsZW1lbnQsIGJ1dCBJIGFtIG5vdCANCj4gdG90 YWxseSBjb252aW5jZWQgYmVjYXVzZSBvZiB0aGUgbGlzdGVkIHJlYXNvbiBibG93DQo+IA0KPiAo MSkgQWNjb3JkaW5nIHRvIG15IHVuZGVyc3RhbmRpbmcsIHRoZSBhc3NvY2lhdGlvbiBjYW4gd29y ayB3aXRob3V0IA0KPiB0aGUgZmllbGQgb2YgRXh0ZW5kZWQgQXNzb2NpYXRpb24gSUQgKElQIGFk ZHJlc3MpLCBhbmQgd2hhdCBpcyB0aGUgDQo+IGJlbmVmaXRzIG9mIHRoZSBpbnRlcm9wZXJhYmls aXR5IGZvciB1c2luZyB0d28gSVAgYWRkcmVzcz8NCj4gPFJHPiBUaGVyZSBpcyAgYSB1c2UgY2Fz ZSBmb3IgYXV0by1tZXNoIHR1bm5lbHMgd2hlcmUgc291cmNlIG5vZGUgbWF5IA0KPiBvcmlnaW5h dGUgdHVubmVscyB0byBtYW55IGRlc3RpbmF0aW9ucyB1c2luZyB0aGUgc2FtZSBhc3NvY2lhdGlv biANCj4gc291cmNlIGFuZCBhc3NvY2lhdGlvbi1pZC4gSW4gdGhpcyBjYXNlLCBkaWZmZXJlbnQg dmFsdWVzIGZvciBleHRlbmRlZCANCj4gYXNzb2NpYXRpb24gSUQgcHJvdmlkZSB1bmlxdWUgZXh0 ZW5kZWQgYXNzb2NpYXRpb24gb2JqZWN0Lg0KPiA8RmVpPiBHb3QgaXQgLHRoYW5rcw0KPiAoMilU aGUgc3VnZ2VzdGlvbiBvZiB1c2luZyBmbGFncyBpcyB2ZXJ5IGdvb2QsIGJ1dCB3ZSBuZWVkIHRv IGxpc3QgdGhlIA0KPiBtb3RpdmF0aW9uIHdoeSBjb3JvdXRlZCBhbmQgbm9uLWNvcm91dGVkIHNo b3VsZCBiZSBkaXN0aW5jdC4NCj4gPFJHPiBUaGlzIGlzIG9uIHBhZ2UgNiBvZiB0aGUgZmlsZSBJ IGhhZCBzZW50LiBJbnRlci1kb21haW4gTFNQIHdpdGggDQo+IGxvb3NlLWhvcCBFUk8gaXMgb25l IGV4YW1wbGUuDQo+IFRoYW5rcyBGZWksDQo+IFJha2VzaA0KPiANCj4gSG9wZSB5b3Ugc2hlZCBz b21lIGxpZ2h0IG9uIG1lLCBhbmQgd2UgY2FuIGhhdmUgYWdyZWVtZW50IHF1aWNrbHkuDQo+IA0K PiBCZXN0IHJlZ2FyZHMNCj4gDQo+IEZlaQ0KPiANCj4gKiJSYWtlc2ggR2FuZGhpIChyZ2FuZGhp KSIgPCogKiByZ2FuZGhpQGNpc2NvLmNvbSAqIA0KPiA8bWFpbHRvOnJnYW5kaGlAY2lzY28uY29t PiAqPioNCj4gDQo+IDIwMTItMDctMjEgMjM6MzMNCj4gDQo+IAkgDQo+IA0KPiANCj4gytW8/sjL DQo+IAkiIHpoYW5nLmZlaTNAenRlLmNvbS5jbiA8bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5j bj4gIiA8IA0KPiB6aGFuZy5mZWkzQHp0ZS5jb20uY24gPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5j b20uY24+ID4NCj4gs63LzQ0KPiAJIkVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpIiA8IGVvc2Jvcm5l QGNpc2NvLmNvbSANCj4gPG1haWx0bzplb3Nib3JuZUBjaXNjby5jb20+ID4sICIgamlhbmcud2Vp bGlhbkB6dGUuY29tLmNuIA0KPiA8bWFpbHRvOmppYW5nLndlaWxpYW5AenRlLmNvbS5jbj4gIiA8 IGppYW5nLndlaWxpYW5AenRlLmNvbS5jbiANCj4gPG1haWx0bzpqaWFuZy53ZWlsaWFuQHp0ZS5j b20uY24+ID4sICIgamluZ3JxQGN0YnJpLmNvbS5jbiANCj4gPG1haWx0bzpqaW5ncnFAY3Ricmku Y29tLmNuPiAiIDwgamluZ3JxQGN0YnJpLmNvbS5jbiANCj4gPG1haWx0bzpqaW5ncnFAY3Ricmku Y29tLmNuPiA+LCAiUm9iZXJ0IFNhd2F5YSAocnNhd2F5YSkiIDwgDQo+IHJzYXdheWFAY2lzY28u Y29tIDxtYWlsdG86cnNhd2F5YUBjaXNjby5jb20+ID4sICJHZW9yZ2UgU3dhbGxvdyANCj4gKHN3 YWxsb3cpIiA8IHN3YWxsb3dAY2lzY28uY29tIDxtYWlsdG86c3dhbGxvd0BjaXNjby5jb20+ID4s ICINCj4geWFuZy5mYW41QHp0ZS5jb20uY24gPG1haWx0bzp5YW5nLmZhbjVAenRlLmNvbS5jbj4g IiA8IA0KPiB5YW5nLmZhbjVAenRlLmNvbS5jbiA8bWFpbHRvOnlhbmcuZmFuNUB6dGUuY29tLmNu PiA+DQo+INb3zOINCj4gCVJFOiBDb21tZW50cyBvbiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAt cnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wMw0KPiANCj4gDQo+IA0KPiAgDQo+IA0KPiAgDQo+ IA0KPiANCj4gCQ0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBUaGFua3MgRmVpIGZvciB5b3Vy IGtpbmQgcmVwbHkuDQo+IA0KPiBQbGVhc2Ugc2VlIHRoZSBhdHRhY2hlZCBkb2N1bWVudCB0aGF0 IGRlc2NyaWJlcyB0aGUgc2V0IG9mIHJ1bGVzIHRoYXQgDQo+IGNhbiBiZSBzdGFuZGFyZGl6ZWQg dG8gcG9wdWxhdGUgdGhlIGV4dGVuZGVkIGFzc29jaWF0aW9uIG9iamVjdCBmb3IgDQo+IGJpLWRp cmVjdGlvbmFsIExTUCBzZXR1cC4gVGhpcyB3aWxsIGdyZWF0bHkgaGVscCB3aXRoIHRoZSANCj4g aW50ZXJvcGVyYWJpbGl0eSBmb3IgdHVubmVsIHNldHVwLg0KPiANCj4gVGhhbmtzIGZvciBhY2Nv bW1vZGF0aW5nIHRoZXNlIGlucHV0cyBpbiB0aGUgZHJhZnQuDQo+IA0KPiBSZWdhcmRzLA0KPiBS YWtlc2gNCj4gKg0KPiBGcm9tOiogemhhbmcuZmVpM0B6dGUuY29tLmNuIDxtYWlsdG86emhhbmcu ZmVpM0B6dGUuY29tLmNuPiANCj4gW21haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY25dIDxtYWls dG86W21haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY25dPiANCj4gKg0KPiBTZW50OiogV2VkbmVz ZGF5LCBKdWx5IDA0LCAyMDEyIDEwOjU3IFBNKg0KPiBUbzoqIFJha2VzaCBHYW5kaGkgKHJnYW5k aGkpKg0KPiBDYzoqIEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpOyBqaWFuZy53ZWlsaWFuQHp0ZS5j b20uY24gDQo+IDxtYWlsdG86amlhbmcud2VpbGlhbkB6dGUuY29tLmNuPiA7IGppbmdycUBjdGJy aS5jb20uY24gDQo+IDxtYWlsdG86amluZ3JxQGN0YnJpLmNvbS5jbj4gOyBSb2JlcnQgU2F3YXlh IChyc2F3YXlhKTsgR2VvcmdlIFN3YWxsb3cgDQo+IChzd2FsbG93KTsgeWFuZy5mYW41QHp0ZS5j b20uY24gPG1haWx0bzp5YW5nLmZhbjVAenRlLmNvbS5jbj4gKg0KPiBTdWJqZWN0OiogUmU6IENv bW1lbnRzIG9uDQo+IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0 ZWQtbHNwLTAzDQo+IA0KPiANCj4gSGkgUmFrZXNoDQo+IA0KPiBCZSBnbGFkIHRoYXQgeW91IGFy ZSBhbHNvIGludGVyZXN0ZWQgaW4gdGhpcyBkcmFmdCBhbmQgeW91ciBvcGluaW9ucyANCj4gYXJl IGltcG9ydGFudCB0byB1cy4NCj4gDQo+IEFzIHRvIHRoZSBwbGFuLCBJIGFtIGFmcmFpZCBJIGNh biBub3QgYXR0ZW5kIHRoZSBJRVRGIG1lZXRpbmcgaW4gDQo+IFZhbmNvdXZlciBmb3IgdGhlIGxp bWl0ZWQgYnVkZ2V0LCBidXQgSSB3b3VsZCBsaWtlIHRvIHVwbG9hZCBhIG5ldyANCj4gdmVyc2lv biByZWZsZWN0aW5nIHRoZSBjb21tZW50cyBjb2xsZWN0ZWQgb24gYW5kIG9mZiB0aGUgbWFpbGlu Z2xpc3QgDQo+IHJlY2VudGx5LCB0aGVuIGFzayBmb3IgbGFzdCBjYWxsLg0KPiANCj4gQW55IHRo aW5raW5nIGNvbWluZyBmcm9tIHlvdSBhcmUgd2VsY29tZSAgXi1eDQo+IA0KPiBCZXN0IHJlZ2Fy ZHMNCj4gDQo+IEZlaQ0KPiANCj4gKiJSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSIgPCogKiByZ2Fu ZGhpQGNpc2NvLmNvbSAqIA0KPiA8bWFpbHRvOnJnYW5kaGlAY2lzY28uY29tPiAqPioNCj4gDQo+ IDIwMTItMDctMDQgMjA6NDYNCj4gDQo+IAkgDQo+IA0KPiAgDQo+IA0KPiANCj4gytW8/sjLDQo+ IAkiIHpoYW5nLmZlaTNAenRlLmNvbS5jbiA8bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj4g IiA8IA0KPiB6aGFuZy5mZWkzQHp0ZS5jb20uY24gPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20u Y24+ID4sICINCj4gamluZ3JxQGN0YnJpLmNvbS5jbiA8bWFpbHRvOmppbmdycUBjdGJyaS5jb20u Y24+ICIgPCANCj4gamluZ3JxQGN0YnJpLmNvbS5jbiA8bWFpbHRvOmppbmdycUBjdGJyaS5jb20u Y24+ID4sICIgDQo+IHlhbmcuZmFuNUB6dGUuY29tLmNuIDxtYWlsdG86eWFuZy5mYW41QHp0ZS5j b20uY24+ICIgPCANCj4geWFuZy5mYW41QHp0ZS5jb20uY24gPG1haWx0bzp5YW5nLmZhbjVAenRl LmNvbS5jbj4gPiwgIiANCj4gamlhbmcud2VpbGlhbkB6dGUuY29tLmNuIDxtYWlsdG86amlhbmcu d2VpbGlhbkB6dGUuY29tLmNuPiAiIDwgDQo+IGppYW5nLndlaWxpYW5AenRlLmNvbS5jbiA8bWFp bHRvOmppYW5nLndlaWxpYW5AenRlLmNvbS5jbj4gPg0KPiCzrcvNDQo+IAkiRXJpYyBPc2Jvcm5l IChlb3Nib3JuZSkiIDwgZW9zYm9ybmVAY2lzY28uY29tIA0KPiA8bWFpbHRvOmVvc2Jvcm5lQGNp c2NvLmNvbT4gPiwgIkdlb3JnZSBTd2FsbG93IChzd2FsbG93KSIgPCANCj4gc3dhbGxvd0BjaXNj by5jb20gPG1haWx0bzpzd2FsbG93QGNpc2NvLmNvbT4gPiwgcnNhd2F5YSA8IA0KPiByc2F3YXlh QGNpc2NvLmNvbSA8bWFpbHRvOnJzYXdheWFAY2lzY28uY29tPiA+DQo+INb3zOINCj4gCUNvbW1l bnRzIG9uIGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNw LTAzDQo+IA0KPiANCj4gDQo+ICANCj4gDQo+ICANCj4gDQo+ICANCj4gDQo+IA0KPiAJDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IEhlbGxvIEF1dGhvcnMgb2YgdGhlIGRyYWZ0LA0KPiANCj4g V2UgaGF2ZSB0YWtlbiBhIGNsb3NlIGxvb2sgYXQgdGhlDQo+IGRyYWZ0LWlldGYtY2NhbXAtbXBs cy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTAzLg0KPiANCj4gV2UgaGF2ZSBzb21lIGNv bW1lbnRzIG9uIHRoaXMgZHJhZnQgdGhhdCB3ZSBsaWtlIHRvIHNoYXJlIHdpdGggeW91Lg0KPiBU aGVyZSBpcyBhbiBJRVRGIG1lZXRpbmcgZW5kIG9mIHRoaXMgTW9udGggaW4gVmFuY291dmVyLCBu b3Qgc3VyZSBpZiANCj4geW91IGFyZSBwbGFuaW5nIHRvIGF0dGVuZC4NCj4gDQo+IENhbiB5b3Ug cGxlYXNlIGFkdmlzZSB5b3VyIHBsYW5zIGFuZCBuZXh0IHN0ZXBzIGZvciB0aGlzIGRyYWZ0PyBJ ZiB5b3UgDQo+IGFyZSBwbGFubmluZyB0byBwdWJsaXNoIHVwZGF0ZWQgZHJhZnQsIG1heSBiZSB3 ZSBzaG91bGQgc3luYyB1cCBvbiBvdXIgDQo+IHRoaW5raW5nIGJlZm9yZSB0aGF0Pw0KPiANCj4g VGhhbmtzIGEgbG90LA0KPiBSYWtlc2ggR2FuZGhpDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENDQU1QIG1haWxpbmcgbGlz dA0KPiBDQ0FNUEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NjYW1wDQo= From lberger@labn.net Wed Aug 15 14:40:48 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E9A11E809B for ; Wed, 15 Aug 2012 14:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.179 X-Spam-Level: X-Spam-Status: No, score=-100.179 tagged_above=-999 required=5 tests=[AWL=2.420, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cz4ilZAQYR1e for ; Wed, 15 Aug 2012 14:40:47 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 8285211E808A for ; Wed, 15 Aug 2012 14:40:37 -0700 (PDT) Received: (qmail 28462 invoked by uid 0); 15 Aug 2012 21:40:16 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 15 Aug 2012 21:40:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=bHi+eGgT4gFzbhJwAH39nbU3igJTxyJJy4yZsYXvhSM=; b=e4YX9BMZFhqe5Fg6Xncj/vP0IbRbFctHWdbbSFmyHnotAt8m3pk2gjtBpTPSP7+z/ItHvximnARrjhXMRS8ymIrZjXyUmoskpMyoFwlsXhNgWbjEjIi7cFUUMYNuZZto; Received: from box313.bluehost.com ([69.89.31.113]:37738 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T1lK3-0000ri-Vi; Wed, 15 Aug 2012 15:40:16 -0600 Message-ID: <502C173C.7040700@labn.net> Date: Wed, 15 Aug 2012 17:40:12 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Greg Bernstein , draft-ietf-ccamp-wson-signaling@tools.ietf.org References: <50229C0B.5020509@grotto-networking.com> In-Reply-To: <50229C0B.5020509@grotto-networking.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] WSON updates for Optical Interface Classes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 21:40:48 -0000 Greg/Authors, When do you expect to have a rev of the signaling draft to match the recent updates (including the previous addition of WSON-LSC type)? Thanks, Lou On 8/8/2012 1:04 PM, Greg Bernstein wrote: > Hi CCAMPers, per working group consensus we have updated the following > WSON drafts: > > http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-10 > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-15 > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-15. > > We have removed "modulation type", "FEC type", and "Bit rate range" and replace with the "Optical Interface Class". > We have applied the changes suggested on the CCAMP list and in the OIC draft. > There are some undefined references that need to be filled in by the authors of the OIC draft. > Please furnish references or suitable text. > Info draft: > ..."Where the term is defined by [xyz]." > > Encoding draft: > ..."The Optical Interface Class format is defined within [x-ref-tbd]." > > See updated drafts for further context. Also if an encoding example is desired for > appendix A of the encoding draft please furnish. > > To ease and expedite further changes on the OIC issue > MS Word versions of these documents can be found at: > http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp-wson-signal-compatibility-ospf-10a.docx > http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp-rwa-wson-encode-15a.docx > http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp-rwa-info-15a.docx > > Best Regards > Greg B. > > > From internet-drafts@ietf.org Wed Aug 15 22:14:08 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7290A21F8611; Wed, 15 Aug 2012 22:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqVbaALOqIu3; Wed, 15 Aug 2012 22:14:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75AA21F8610; Wed, 15 Aug 2012 22:14:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120816051407.12397.26655.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2012 22:14:07 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 05:14:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : RSVP-TE Extensions to Exchange MPLS-TP LSP Tunnel Numbers Author(s) : Fei Zhang Venkatesan Mahalingam Yunbin Xu Rakesh Gandhi Filename : draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-04.txt Pages : 7 Date : 2012-08-15 Abstract: The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370] specifies an initial set of identifiers, including the local assigned Z9-Tunnel_Num, which can be used to form Maintenance Entity Point Identifier (MEP_ID). As to some Operation, Administration and Maintenance (OAM) functions, such as Connectivity Verification (CV) [RFC6428], source MEP_ID must be inserted in the OAM packets, so that the peer endpoint can compare the received and expected MEP_IDs to judge whether there is a mis-connectivity defect [RFC6371], which means that the two MEP nodes need to pre-store each other's MEP_IDs. This document defines the signaling extensions to communicate the local assigned Z9-Tunnel_Num to the ingress LSR (Label Switching Router) of a co-routed bidirectional LSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunne= l-num There's also a htmlized version available at: http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-= 04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-zhang-ccamp-mpls-tp-rsvpte-ext-tun= nel-num-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhang.fei3@zte.com.cn Wed Aug 15 23:07:30 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AD521F85F4 for ; Wed, 15 Aug 2012 23:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.895 X-Spam-Level: X-Spam-Status: No, score=-96.895 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiQQ7Ftf0JQE for ; Wed, 15 Aug 2012 23:07:29 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6537121F8517 for ; Wed, 15 Aug 2012 23:07:28 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 23255473195744; Thu, 16 Aug 2012 14:01:34 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 92587.984958751; Thu, 16 Aug 2012 14:07:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q7G66olD002975; Thu, 16 Aug 2012 14:06:50 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <502BCCD7.9000402@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: 2075C88A:4B5F911C-48257A5C:001ED3E3; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Thu, 16 Aug 2012 14:06:45 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-16 14:06:32, Serialize complete at 2012-08-16 14:06:32 Content-Type: multipart/alternative; boundary="=_alternative 0021858048257A5C_=" X-MAIL: mse01.zte.com.cn q7G66olD002975 Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 06:07:30 -0000 This is a multipart message in MIME format. --=_alternative 0021858048257A5C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TG91DQoNClRoYW5rIHlvdSBmb3IgeW91ciBjbGFyaWZpY2F0aW9uLCBzZWUgcmVzcG9uc2UgaW4g bGluZSB3aXRoIDxmZWk+DQoNClJlZ2FyZHMNCg0KRmVpDQoNCg0KDQpMb3UgQmVyZ2VyIDxsYmVy Z2VyQGxhYm4ubmV0PiANCjIwMTItMDgtMTYgMDA6MjINCg0KytW8/sjLDQp6aGFuZy5mZWkzQHp0 ZS5jb20uY24NCrOty80NCmNjYW1wQGlldGYub3JnDQrW98ziDQpSZTogW0NDQU1QXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC0wNC50eHQNCg0KDQoNCg0KDQoNCg0KRmVp LA0KICAgICAgICAgICAgICAgICBTZWUgYmVsb3cuDQoNCk9uIDgvMTQvMjAxMiAxMToxMCBQTSwg emhhbmcuZmVpM0B6dGUuY29tLmNuIHdyb3RlOg0KPiANCj4gSGkgTG91DQo+IA0KPiBJIGNhbiBz ZWUgdGhlcmUgYXJlIHNvbWUgbWlub3IgY2hhbmdlcyB3aGVuIHRha2luZyBhIGxvb2sgYXQgdGhl IHVwZGF0ZWQNCj4gbmV3IHZlcnNpb24sIGFuZCB3YW50IHRvIGNoZWNrIHdpdGggeW91IHRoZSBp bnRlbnRpb24gb2YgbGlzdGVkIHR3bw0KPiByZXZpc2lvbnMuDQo+IA0KPiAxLiBTZWN0aW9uIDMg Tm8tR01QTFMgUmVjb3ZlcnkgVXNhZ2UNCj4gDQo+IFRoZSBzZW50ZW5jZSAiTm90ZSB0aGF0IHRo ZXJlIGFyZSB0aW1lcyB3aGVuIG5vIG1hdGNoaW5nIHN0YXRlIGlzIGZvdW5kLA0KPiBlLmcuLCB3 aGVuIHByb2Nlc3NpbmcgYW4gaW5pdGlhbCBMU1Agb3Igd2hlbiB0aGUgQVNTT0NJQVRJT04gb2Jq ZWN0DQo+IGNvbnRhaW5zDQo+IG90aGVyd2lzZSB1c2VmdWwgaW5mb3JtYXRpb24sIGFuZCBzdWNo IGNhc2VzIGRvIG5vdCBhbHRlciB0aGUgcHJvY2Vzc2luZw0KPiBkZWZpbmVkIGJlbG93LiIgaXMg ZGVsZXRlZCBpbiB0aGUgdmVyc2lvbiAwNCwgd2hpY2ggaW5kaWNhdGVzIHRoYXQgdGhlDQo+IEFT U09DSUFUSU9OIG9iamVjdA0KPiBjYW4gbm90IGJlIHVzZWQgaW4gYSBzaW5nbGUgc2Vzc2lvbiB3 aGl0aCBhbnkga2luZHMgb2YgQXNzb2NpYXRpb24gVHlwZXMNCj4gb3IgdGhlIHVzYWdlIGluIGEg c2luZ2xlIHNlc3Npb24gY2FuIGJlIGRlZmluZWQgYXMgYW4gYXNzb2NpYXRpb24gdHlwZQ0KPiBz cGVjaWZpYyBydWxlcz8NCg0KTm90IHN1cmUgZXhhY3RseSB3aGF0IHlvdSdyZSBhc2tpbmcsIGJ1 dCB0aGlzIGNoYW5nZSB3YXMgZWRpdG9yaWFsIGluDQpuYXR1cmUgb25seSwgYXMgcHJvY2Vzc2lu ZyBiZWhhdmlvciBjb250aW51ZXMgdG8gYmUgc3BlY2lmaWVkIChzZWUgdGhlDQoybmQgdG8gbGFz dCBwYXJhZ3JhcGggaW4gU2VjdGlvbiAzLjEuMiBhbmQgMy4yLjIuKQ0KDQo8ZmVpPiBJIHdhbnQg dG8gY2hlY2sgd2hldGhlciB0aGUgQVNTT0NJQVRJT04gb2JqZWN0IGlzIGFsbG93ZWQgdG8gYmUg dXNlZCANCmluIGEgc2lnbmFsIHNlc3Npb24sDQphbmQgZmluZCB0aGUgY29ycmVzcG9uZGluZyBk ZXNjcmlwdGlvbiBpbiBzZWN0aW9uIDMuMSBhbmQgMy4yIA0KIlRoZSB1c2Ugb2YgYW4gQVNTT0NJ QVRJT04gb2JqZWN0IGluIGEgc2luZ2xlIHNlc3Npb24gaXMgbm90IHByZWNsdWRlZCINCiIgTm90 ZSwgdGhlIHVzZSBvZiBhbiBBU1NPQ0lBVElPTiBvYmplY3QgaW4gYSBzaW5nbGUgc2Vzc2lvbiBp cyBub3QgDQpwcmVjbHVkZWQiDQpObyBwcm9ibGVtIG5vdywgdGhhbmtzLg0KDQoNCj4gDQo+IDIu IFRoZSBkZXNjcmlwdGlvbnMgYWJvdXQgR2xvYmFsIEFzc29jaWF0aW9uIFNvdXJjZSBpbiBTZWN0 aW9uIDQuMS4NCj4gIElQdjQgYW5kIElQdjYgRXh0ZW5kZWQgQVNTT0NJQVRJT04gT2JqZWN0IEZv cm1hdA0KPiANCj4gU2ltaWxhcmx5LCB0aGUgc2VudGVuY2UgIkl0IGlzIGV4cGVjdGVkIHRoYXQg dGhlIGdsb2JhbCBpZGVudGlmaWVyIHdpbGwNCj4gYmUgZGVyaXZlZCBmcm9tIHRoZSBnbG9iYWxs eSB1bmlxdWUgQVNOIG9mIHRoZSBhdXRvbm9tb3VzIHN5c3RlbSBob3N0aW5nDQo+IHRoZSBBc3Nv Y2lhdGlvbiBTb3VyY2UuIiBkb2VzIG5vdCBhcHBlYXIgaW4gdGhlIG5ldyB2ZXJzaW9uLiBUaGUN Cj4gcXVlc3Rpb24gaGVyZSBpcyB3aGV0aGVyIHRoZSBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNl IFNIT1VMRCBob3N0IHRoZQ0KPiBBc3NvY2lhdGlvbiBTb3VyY2Ugb3Igbm90PyAgSWYgeWVhaCwg aXQgaGFkIGJldHRlciBiZWluZyBkZXNjcmliZWQgaW4NCj4gdGhlIGRvY3VtZW50Lg0KDQpTbyB0 aGUgb2xkIHRleHQgd2FzIGluZm9ybWF0aXZlIG9ubHkgKGFuZCB3YXMgdGFrZW4gZnJvbSBSRkM2 MzcwKS4gIFRoZQ0KbmV3IHRleHQgaXMgbm9ybWF0aXZlIGFuZCBzYXlzIHVzZSBkZWZpbml0aW9u IGZyb20gW1JGQzYzNzBdLiBTbyBJJ20gbm90DQpzdXJlIHdoYXQgaXMgYW1iaWd1b3VzIGluIHRo ZSBuZXcgdGV4dC4gIFdoYXQgc3BlY2lmaWMgY2hhbmdlIHdvdWxkIHlvdQ0KbGlrZSB0byBzZWU/ DQoNCjxmZWk+IElNSE8sIHRoZSBHbG9iYWwgQXNzb2NpYWl0b24gU291cmNlIHNob3VsZCBiZSB0 aGUgR2xvYmFsX0lEIHRoYXQgDQpob3N0aW5nDQpBc3NvY2lhdGlvbiBTb3VyY2UsIGhvdyBhYm91 dCAidGhlIEdsb2JhbF9JRCBhcyBkZWZpbmVkIGluIFtSRkM2MzcwXXRoYXQgDQpob3N0aW5nDQp0 aGUgQXNzb2NpYXRpb24gU291cmNlIFNIQUxMIGJlIHVzZWQiPyBPZiBjb3Vyc2UsIHRoZSBjdXJy ZW50IGRlc2NyaXB0aW9uIA0KaXMgDQpjb3JyZWN0IGFuZCBpbmNsdWRlcyB0aGlzIHBvc3NpYmls aXR5Lg0KDQoNCkxvdQ0KDQo+IA0KPiANCj4gQmVzdCByZWdhcmRzDQo+IA0KPiBGZWkNCj4gDQo+ IA0KPiAqTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4qDQo+ILeivP7IyzogIGNjYW1wLWJv dW5jZXNAaWV0Zi5vcmcNCj4gDQo+IDIwMTItMDgtMTQgMjI6MTANCj4gDQo+IA0KPiDK1bz+yMsN Cj4gICAgICAgICAgICAgICAgY2NhbXBAaWV0Zi5vcmcNCj4gs63LzQ0KPiANCj4g1vfM4g0KPiAg ICAgICAgICAgICAgICBSZTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWFz c29jLWV4dC0wNC50eHQNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gVGhl IGF1dGhvcnMgYmVsaWV2ZSB0aGF0IHRoaXMgcmV2aXNpb24gYWRkcmVzc2VzIHRoZSBjb21tZW50 cyByYWlzZWQgYnkNCj4gQWRyaWFuIGFuZCBkaXNjdXNzZWQgb24gdGhlIGxpc3QuIChJdCBhbHNv IGluY2x1ZGVzIGZldyBvdGhlciBlZGl0b3JpYWwNCj4gbml0cyBpZGVudGlmaWVkIGJ5IHRoZSBh dXRob3JzLikNCj4gDQo+IFBsZWFzZSBub3RlLCBhcyBkaXNjdXNzZWQsIHRoZXJlIGhhcyBiZWVu IG9uZSBzdWJzdGFudGl2ZSB0ZWNobmljYWwNCj4gY2hhbmdlIChNVVNUIC0tPiBTSE9VTEQpOg0K PiANCj4gIDMuMi4xLiBSZXN2IE1lc3NhZ2UgRm9ybWF0DQo+IE9MRA0KPiAgUmVsYXRpdmUgb3Jk ZXJpbmcgb2YgQVNTT0NJQVRJT04gb2JqZWN0cyBvZiB0aGUgc2FtZSB0eXBlDQo+ICBNVVNUIGJl IHByZXNlcnZlZCBieSB0cmFuc2l0IG5vZGVzLg0KPiBORVcNCj4gIFJlbGF0aXZlIG9yZGVyaW5n IG9mIEFTU09DSUFUSU9OIG9iamVjdHMgb2YgdGhlIHNhbWUgdHlwZQ0KPiAgKlNIT1VMRCogYmUg cHJlc2VydmVkIGJ5IHRyYW5zaXQgbm9kZXMuDQo+IA0KPiBMb3UgKGFuZCBjby1hdXRob3JzKQ0K PiANCj4gT24gOC8xNC8yMDEyIDk6NDUgQU0sIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90 ZToNCj4+DQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMuDQo+PiAgVGhpcyBkcmFmdCBpcyBh IHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRyb2wgYW5kIE1lYXN1cmVtZW50IFBsYW5lDQo+ IFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+Pg0KPj4gICAgICAgICAgICAgICAgICBUaXRs ZSAgICAgICAgICAgOiBSU1ZQIEFzc29jaWF0aW9uIE9iamVjdCBFeHRlbnNpb25zDQo+PiAgICAg ICAgICAgICAgICAgIEF1dGhvcihzKSAgICAgICA6IExvdSBCZXJnZXINCj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgRnJhbmNvaXMgTGUgRmF1Y2hldXINCj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgQXNob2sgTmFyYXlhbmFuDQo+PiAgICAgICAgICAgICAgICAgIEZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0LTA0LnR4dA0KPj4gICAgICAgICAgICAg ICAgICBQYWdlcyAgICAgICAgICAgOiAxNg0KPj4gICAgICAgICAgICAgICAgICBEYXRlICAgICAg ICAgICAgOiAyMDEyLTA4LTE0DQo+Pg0KPj4gQWJzdHJhY3Q6DQo+PiAgICBUaGUgUlNWUCBBU1NP Q0lBVElPTiBvYmplY3Qgd2FzIGRlZmluZWQgaW4gdGhlIGNvbnRleHQgb2YgR01QTFMNCj4+ICAg IChHZW5lcmFsaXplZCBNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcpIGNvbnRyb2xsZWQg bGFiZWwNCj4+ICAgIHN3aXRjaGVkIHBhdGhzIChMU1BzKS4gIEluIHRoaXMgY29udGV4dCwgdGhl IG9iamVjdCBpcyB1c2VkIHRvDQo+PiAgICBhc3NvY2lhdGUgcmVjb3ZlcnkgTFNQcyB3aXRoIHRo ZSBMU1AgdGhleSBhcmUgcHJvdGVjdGluZy4gIFRoaXMNCj4+ICAgIG9iamVjdCBhbHNvIGhhcyBi cm9hZGVyIGFwcGxpY2FiaWxpdHkgYXMgYSBtZWNoYW5pc20gdG8gYXNzb2NpYXRlDQo+PiAgICBS U1ZQIHN0YXRlLCBhbmQgdGhpcyBkb2N1bWVudCBkZWZpbmVzIGhvdyB0aGUgQVNTT0NJQVRJT04g b2JqZWN0DQo+PiAgICBjYW4gYmUgbW9yZSBnZW5lcmFsbHkgYXBwbGllZC4gIFRoaXMgZG9jdW1l bnQgYWxzbyBkZWZpbmVzDQo+PiAgICBFeHRlbmRlZCBBU1NPQ0lBVElPTiBvYmplY3RzIHdoaWNo LCBpbiBwYXJ0aWN1bGFyLCBjYW4gYmUgdXNlZCBpbg0KPj4gICAgdGhlIGNvbnRleHQgb2YgdGhl IFRyYW5zcG9ydCBQcm9maWxlIG9mIE11bHRpcHJvdG9jb2wgTGFiZWwNCj4+ICAgIFN3aXRjaGlu ZyAoTVBMUy1UUCkuICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDIDIyMDUsIFJGQyAzMjA5LA0K Pj4gICAgYW5kIFJGQyAzNDczLiBJdCBhbHNvIG1vZGlmaWVzIHRoZSBkZWZpbml0aW9uIG9mIHRo ZSBBc3NvY2lhdGlvbg0KPj4gICAgSUQgZmllbGQgZGVmaW5lZCBpbiBSRkMgNDg3Mi4NCj4+DQo+ Pg0KPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLWFz c29jLWV4dA0KPj4NCj4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxl IGF0Og0KPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1hc3Nv Yy1leHQtMDQNCj4+DQo+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFp bGFibGUgYXQ6DQo+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LWNjYW1wLWFzc29jLWV4dC0wNA0KPj4NCj4+DQo+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+IENDQU1QQGlldGYub3JnDQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+Pg0KPj4NCj4+ DQo+Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gQ0NBTVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiANCj4gDQoNCg0KDQo= --=_alternative 0021858048257A5C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxvdTwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmsgeW91IGZvciB5b3VyIGNsYXJp ZmljYXRpb24sIHNlZQ0KcmVzcG9uc2UgaW4gbGluZSB3aXRoIDwvZm9udD48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7ZmVpJmd0OzwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UmVnYXJkczwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RmVpPC9mb250Pg0KPGJyPg0KPGJyPg0K PGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkxvdSBCZXJnZXIgJmx0O2xiZXJnZXJA bGFibi5uZXQmZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjIwMTItMDgtMTYgMDA6MjI8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+emhhbmcuZmVpM0B6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5jY2FtcEBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtDQ0FNUF0gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDQudHh0PC9mb250PjwvdGFibGU+DQo8 YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwv dGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpGZWksPGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN ClNlZSBiZWxvdy48YnI+DQo8YnI+DQpPbiA4LzE0LzIwMTIgMTE6MTAgUE0sIHpoYW5nLmZlaTNA enRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgTG91PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEkgY2FuIHNlZSB0aGVyZSBhcmUgc29tZSBtaW5vciBjaGFuZ2VzIHdoZW4gdGFr aW5nIGEgbG9vayBhdCB0aGUgdXBkYXRlZDxicj4NCiZndDsgbmV3IHZlcnNpb24sIGFuZCB3YW50 IHRvIGNoZWNrIHdpdGggeW91IHRoZSBpbnRlbnRpb24gb2YgbGlzdGVkIHR3bzxicj4NCiZndDsg cmV2aXNpb25zLjxicj4NCiZndDsgPGJyPg0KJmd0OyAxLiBTZWN0aW9uIDMgTm8tR01QTFMgUmVj b3ZlcnkgVXNhZ2U8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIHNlbnRlbmNlICZxdW90O05vdGUg dGhhdCB0aGVyZSBhcmUgdGltZXMgd2hlbiBubyBtYXRjaGluZyBzdGF0ZQ0KaXMgZm91bmQsPGJy Pg0KJmd0OyBlLmcuLCB3aGVuIHByb2Nlc3NpbmcgYW4gaW5pdGlhbCBMU1Agb3Igd2hlbiB0aGUg QVNTT0NJQVRJT04gb2JqZWN0PGJyPg0KJmd0OyBjb250YWluczxicj4NCiZndDsgb3RoZXJ3aXNl IHVzZWZ1bCBpbmZvcm1hdGlvbiwgYW5kIHN1Y2ggY2FzZXMgZG8gbm90IGFsdGVyIHRoZSBwcm9j ZXNzaW5nPGJyPg0KJmd0OyBkZWZpbmVkIGJlbG93LiZxdW90OyBpcyBkZWxldGVkIGluIHRoZSB2 ZXJzaW9uIDA0LCB3aGljaCBpbmRpY2F0ZXMNCnRoYXQgdGhlPGJyPg0KJmd0OyBBU1NPQ0lBVElP TiBvYmplY3Q8YnI+DQomZ3Q7IGNhbiBub3QgYmUgdXNlZCBpbiBhIHNpbmdsZSBzZXNzaW9uIHdo aXRoIGFueSBraW5kcyBvZiBBc3NvY2lhdGlvbg0KVHlwZXM8YnI+DQomZ3Q7IG9yIHRoZSB1c2Fn ZSBpbiBhIHNpbmdsZSBzZXNzaW9uIGNhbiBiZSBkZWZpbmVkIGFzIGFuIGFzc29jaWF0aW9uDQp0 eXBlPGJyPg0KJmd0OyBzcGVjaWZpYyBydWxlcz88YnI+DQo8YnI+DQpOb3Qgc3VyZSBleGFjdGx5 IHdoYXQgeW91J3JlIGFza2luZywgYnV0IHRoaXMgY2hhbmdlIHdhcyBlZGl0b3JpYWwgaW48YnI+ DQpuYXR1cmUgb25seSwgYXMgcHJvY2Vzc2luZyBiZWhhdmlvciBjb250aW51ZXMgdG8gYmUgc3Bl Y2lmaWVkIChzZWUgdGhlPGJyPg0KMm5kIHRvIGxhc3QgcGFyYWdyYXBoIGluIFNlY3Rpb24gMy4x LjIgYW5kIDMuMi4yLik8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7ZmVpJmd0OyBJIHdhbnQgdG8gY2hlY2sNCndoZXRo ZXIgdGhlIEFTU09DSUFUSU9OIG9iamVjdCBpcyBhbGxvd2VkIHRvIGJlIHVzZWQgaW4gYSBzaWdu YWwgc2Vzc2lvbiw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fu cy1zZXJpZiI+YW5kIGZpbmQgdGhlIGNvcnJlc3BvbmRpbmcNCmRlc2NyaXB0aW9uIGluIHNlY3Rp b24gMy4xIGFuZCAzLjIgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 InNhbnMtc2VyaWYiPiZxdW90O1RoZSB1c2Ugb2YgYW4gQVNTT0NJQVRJT04NCm9iamVjdCBpbiBh IHNpbmdsZSBzZXNzaW9uIGlzIG5vdCBwcmVjbHVkZWQmcXVvdDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7IE5vdGUsIHRoZSB1c2Ug b2YgYW4NCkFTU09DSUFUSU9OIG9iamVjdCBpbiBhIHNpbmdsZSBzZXNzaW9uIGlzIG5vdCBwcmVj bHVkZWQmcXVvdDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fu cy1zZXJpZiI+Tm8gcHJvYmxlbSBub3csIHRoYW5rcy48L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj48YnI+DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgMi4gVGhlIGRlc2NyaXB0aW9ucyBhYm91 dCBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlIGluIFNlY3Rpb24gNC4xLjxicj4NCiZndDsgJm5i c3A7SVB2NCBhbmQgSVB2NiBFeHRlbmRlZCBBU1NPQ0lBVElPTiBPYmplY3QgRm9ybWF0PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFNpbWlsYXJseSwgdGhlIHNlbnRlbmNlICZxdW90O0l0IGlzIGV4cGVj dGVkIHRoYXQgdGhlIGdsb2JhbCBpZGVudGlmaWVyDQp3aWxsPGJyPg0KJmd0OyBiZSBkZXJpdmVk IGZyb20gdGhlIGdsb2JhbGx5IHVuaXF1ZSBBU04gb2YgdGhlIGF1dG9ub21vdXMgc3lzdGVtIGhv c3Rpbmc8YnI+DQomZ3Q7IHRoZSBBc3NvY2lhdGlvbiBTb3VyY2UuJnF1b3Q7IGRvZXMgbm90IGFw cGVhciBpbiB0aGUgbmV3IHZlcnNpb24uDQpUaGU8YnI+DQomZ3Q7IHF1ZXN0aW9uIGhlcmUgaXMg d2hldGhlciB0aGUgR2xvYmFsIEFzc29jaWF0aW9uIFNvdXJjZSBTSE9VTEQgaG9zdA0KdGhlPGJy Pg0KJmd0OyBBc3NvY2lhdGlvbiBTb3VyY2Ugb3Igbm90PyAmbmJzcDtJZiB5ZWFoLCBpdCBoYWQg YmV0dGVyIGJlaW5nIGRlc2NyaWJlZA0KaW48YnI+DQomZ3Q7IHRoZSBkb2N1bWVudC48YnI+DQo8 YnI+DQpTbyB0aGUgb2xkIHRleHQgd2FzIGluZm9ybWF0aXZlIG9ubHkgKGFuZCB3YXMgdGFrZW4g ZnJvbSBSRkM2MzcwKS4gJm5ic3A7VGhlPGJyPg0KbmV3IHRleHQgaXMgbm9ybWF0aXZlIGFuZCBz YXlzIHVzZSBkZWZpbml0aW9uIGZyb20gW1JGQzYzNzBdLiBTbyBJJ20gbm90PGJyPg0Kc3VyZSB3 aGF0IGlzIGFtYmlndW91cyBpbiB0aGUgbmV3IHRleHQuICZuYnNwO1doYXQgc3BlY2lmaWMgY2hh bmdlIHdvdWxkDQp5b3U8YnI+DQpsaWtlIHRvIHNlZT88YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7ZmVpJmd0OyBJTUhP LCB0aGUgR2xvYmFsDQpBc3NvY2lhaXRvbiBTb3VyY2Ugc2hvdWxkIGJlIHRoZSBHbG9iYWxfSUQg dGhhdCBob3N0aW5nPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNh bnMtc2VyaWYiPkFzc29jaWF0aW9uIFNvdXJjZSwgaG93IGFib3V0DQomcXVvdDt0aGUgR2xvYmFs X0lEIGFzIGRlZmluZWQgaW4gW1JGQzYzNzBddGhhdCBob3N0aW5nPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPnRoZSBBc3NvY2lhdGlvbiBTb3Vy Y2UgU0hBTEwNCmJlIHVzZWQmcXVvdDs/IE9mIGNvdXJzZSwgdGhlIGN1cnJlbnQgZGVzY3JpcHRp b24gaXMgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPmNvcnJlY3QgYW5kIGluY2x1ZGVzIHRoaXMNCnBvc3NpYmlsaXR5LjwvZm9udD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCkxvdTxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEJlc3QgcmVnYXJkczxicj4NCiZndDsgPGJyPg0KJmd0OyBGZWk8YnI+DQom Z3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAqTG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5l dCZndDsqPGJyPg0KJmd0OyC3orz+yMs6ICZuYnNwO2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8YnI+ DQomZ3Q7IDxicj4NCiZndDsgMjAxMi0wOC0xNCAyMjoxMDxicj4NCiZndDsgPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzxicj4NCiZndDsgytW8/sjLPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NjYW1wQGlldGYub3JnPGJyPg0K Jmd0OyCzrcvNPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsg1vfM4jxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtS ZToNCltDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDQudHh0 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFRoZSBhdXRob3JzIGJlbGlldmUgdGhhdCB0aGlzIHJldmlzaW9uIGFkZHJlc3NlcyB0aGUgY29t bWVudHMgcmFpc2VkDQpieTxicj4NCiZndDsgQWRyaWFuIGFuZCBkaXNjdXNzZWQgb24gdGhlIGxp c3QuIChJdCBhbHNvIGluY2x1ZGVzIGZldyBvdGhlciBlZGl0b3JpYWw8YnI+DQomZ3Q7IG5pdHMg aWRlbnRpZmllZCBieSB0aGUgYXV0aG9ycy4pPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFBsZWFzZSBu b3RlLCBhcyBkaXNjdXNzZWQsIHRoZXJlIGhhcyBiZWVuIG9uZSBzdWJzdGFudGl2ZSB0ZWNobmlj YWw8YnI+DQomZ3Q7IGNoYW5nZSAoTVVTVCAtLSZndDsgU0hPVUxEKTo8YnI+DQomZ3Q7IDxicj4N CiZndDsgJm5ic3A7My4yLjEuIFJlc3YgTWVzc2FnZSBGb3JtYXQ8YnI+DQomZ3Q7IE9MRDxicj4N CiZndDsgJm5ic3A7UmVsYXRpdmUgb3JkZXJpbmcgb2YgQVNTT0NJQVRJT04gb2JqZWN0cyBvZiB0 aGUgc2FtZSB0eXBlPGJyPg0KJmd0OyAmbmJzcDtNVVNUIGJlIHByZXNlcnZlZCBieSB0cmFuc2l0 IG5vZGVzLjxicj4NCiZndDsgTkVXPGJyPg0KJmd0OyAmbmJzcDtSZWxhdGl2ZSBvcmRlcmluZyBv ZiBBU1NPQ0lBVElPTiBvYmplY3RzIG9mIHRoZSBzYW1lIHR5cGU8YnI+DQomZ3Q7ICZuYnNwOypT SE9VTEQqIGJlIHByZXNlcnZlZCBieSB0cmFuc2l0IG5vZGVzLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBMb3UgKGFuZCBjby1hdXRob3JzKTxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiA4LzE0LzIwMTIg OTo0NSBBTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u LWxpbmUgSW50ZXJuZXQtRHJhZnRzPGJyPg0KJmd0OyBkaXJlY3Rvcmllcy48YnI+DQomZ3Q7Jmd0 OyAmbmJzcDtUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb21tb24gQ29udHJvbCBh bmQgTWVhc3VyZW1lbnQNClBsYW5lPGJyPg0KJmd0OyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRG Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaXRsZQ0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA6IFJTVlAgQXNzb2NpYXRpb24gT2JqZWN0IEV4dGVuc2lvbnM8 YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0F1dGhvcihzKQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBMb3Ug QmVyZ2VyPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBG cmFuY29pcyBMZSBGYXVjaGV1cjxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgQXNob2sgTmFyYXlhbmFuPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWxlbmFtZQ0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBkcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC0w NC50eHQ8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BhZ2VzDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDogMTY8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0RhdGUNCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAyMDEyLTA4LTE0PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7VGhlIFJTVlAgQVNT T0NJQVRJT04gb2JqZWN0IHdhcyBkZWZpbmVkIGluIHRoZSBjb250ZXh0DQpvZiBHTVBMUzxicj4N CiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsoR2VuZXJhbGl6ZWQgTXVsdGktUHJvdG9jb2wgTGFiZWwg U3dpdGNoaW5nKSBjb250cm9sbGVkDQpsYWJlbDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtz d2l0Y2hlZCBwYXRocyAoTFNQcykuICZuYnNwO0luIHRoaXMgY29udGV4dCwgdGhlDQpvYmplY3Qg aXMgdXNlZCB0bzxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDthc3NvY2lhdGUgcmVjb3Zlcnkg TFNQcyB3aXRoIHRoZSBMU1AgdGhleSBhcmUgcHJvdGVjdGluZy4NCiZuYnNwO1RoaXM8YnI+DQom Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7b2JqZWN0IGFsc28gaGFzIGJyb2FkZXIgYXBwbGljYWJpbGl0 eSBhcyBhIG1lY2hhbmlzbQ0KdG8gYXNzb2NpYXRlPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNw O1JTVlAgc3RhdGUsIGFuZCB0aGlzIGRvY3VtZW50IGRlZmluZXMgaG93IHRoZSBBU1NPQ0lBVElP Tg0Kb2JqZWN0PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO2NhbiBiZSBtb3JlIGdlbmVyYWxs eSBhcHBsaWVkLiAmbmJzcDtUaGlzIGRvY3VtZW50DQphbHNvIGRlZmluZXM8YnI+DQomZ3Q7Jmd0 OyAmbmJzcDsgJm5ic3A7RXh0ZW5kZWQgQVNTT0NJQVRJT04gb2JqZWN0cyB3aGljaCwgaW4gcGFy dGljdWxhciwNCmNhbiBiZSB1c2VkIGluPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO3RoZSBj b250ZXh0IG9mIHRoZSBUcmFuc3BvcnQgUHJvZmlsZSBvZiBNdWx0aXByb3RvY29sDQpMYWJlbDxi cj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtTd2l0Y2hpbmcgKE1QTFMtVFApLiAmbmJzcDtUaGlz IGRvY3VtZW50IHVwZGF0ZXMNClJGQyAyMjA1LCBSRkMgMzIwOSw8YnI+DQomZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7YW5kIFJGQyAzNDczLiBJdCBhbHNvIG1vZGlmaWVzIHRoZSBkZWZpbml0aW9uIG9m DQp0aGUgQXNzb2NpYXRpb248YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7SUQgZmllbGQgZGVm aW5lZCBpbiBSRkMgNDg3Mi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJy Pg0KJmd0OyZndDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1j Y2FtcC1hc3NvYy1leHQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZXJlJ3MgYWxzbyBh IGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsmZ3Q7IGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0LTA0PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFp bGFibGUgYXQ6PGJyPg0KJmd0OyZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Ojxicj4NCiZndDsmZ3Q7IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IENDQU1QIG1haWxpbmcgbGlz dDxicj4NCiZndDsmZ3Q7IENDQU1QQGlldGYub3JnPGJyPg0KJmd0OyZndDsgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgQ0NBTVAgbWFpbGluZyBs aXN0PGJyPg0KJmd0OyBDQ0FNUEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQo8YnI+ DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 0021858048257A5C_=-- From zhang.fei3@zte.com.cn Wed Aug 15 23:58:56 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157D921F8630 for ; Wed, 15 Aug 2012 23:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.142 X-Spam-Level: X-Spam-Status: No, score=-97.142 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiuLHiSNaNJQ for ; Wed, 15 Aug 2012 23:58:55 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id A36C521F8621 for ; Wed, 15 Aug 2012 23:58:54 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 23255473195744; Thu, 16 Aug 2012 14:53:21 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 92587.473195744; Thu, 16 Aug 2012 14:58:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q7G6wQvv080888 for ; Thu, 16 Aug 2012 14:58:32 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <20120816051407.12397.26655.idtracker@ietfa.amsl.com> To: ccamp@ietf.org MIME-Version: 1.0 X-KeepSent: E5F10A6F:5997DC96-48257A5C:0024E7C2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Thu, 16 Aug 2012 14:58:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-16 14:58:14, Serialize complete at 2012-08-16 14:58:14 Content-Type: multipart/alternative; boundary="=_alternative 0026409548257A5C_=" X-MAIL: mse01.zte.com.cn q7G6wQvv080888 Subject: Re: [CCAMP] I-D Action: draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 06:58:56 -0000 This is a multipart message in MIME format. --=_alternative 0026409548257A5C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsDQoNCldlIGhhdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0LCB0 aGUgY2hhbmdlcyBhcmUgbGlzdGVkIGFzIA0KYmVsb3c6DQoNCjEuIEFkZCBvbmUgcGFyYWdyYXBo IGluIHNlY3Rpb24gMyB0byBhZGRyZXNzIHRoZSBleGNoYW5nZSBvZiBHbG9iYWxfSUQgaWYgDQpj b3JvdXRlZCBiaWRpcmVjdGlvbmFsIExTUHMgYXJlIGFjcm9zcyBkaWZmZXJlbnQgZG9tYWlucy4N Cg0KMi4gQWRkIG9uZSBzZWN0aW9uIDQuMiB0byBkZXNjcmliZSB0aGUgcHJvY2Vzc2luZyBvZiBB U1NPQ0lBVElPTiBvYmplY3RzIA0Kd2l0aCBBc3NvY2lhdGlvbiBUeXBlICJMU1AgSWRlbnRpZmll cnMiIGluIG1vcmUgZGV0YWlscy4NCg0KMy4gQWRkICBSZWtlc2ggYXMgYSBjb2F1dGhvciBmb3Ig aGlzIHJldmlldyBhbmQgY29udHJpYnV0aW9ucy4NCg0KNC4gRWRpdG9yaWFsIGNoYW5nZXMuDQoN ClRoZSBhdXRob3JzIGJlbGlldmUgdGhhdCB0aGUgbW90aXZhdGlvbiBhbmQgc29sdXRpb24gaXMg c3RhYmxlIGFuZCB0aGUgDQpyZWxhdGlvbnNoaXAgYmV0d2VlbiBkcmFmdCANCmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29j aWF0ZWQtbHNwLTA0IA0KYW5kIHRoaXMgZHJhZnQgaXMgYWxzbyBjbGVhciBub3csIHdvdWxkIGxp a2UgdGhlIFdHIHRvIGNvbnNpZGVyIGl0DQphcyBhIFdHIGRvY3VtZW50IGFmdGVyIHRoZSByZXZp ZXcuDQoNCkFueSBjb21tZW50cyBhcmUgd2VsY29tZQ0KDQpCZXN0IA0KDQpGZWkNCg0KDQoNCmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyANCreivP7IyzogIGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcN CjIwMTItMDgtMTYgMTM6MTQNCg0KytW8/sjLDQppLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCrOty80N CmNjYW1wQGlldGYub3JnDQrW98ziDQpbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LXpoYW5nLWNj YW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTA0LnR4dA0KDQoNCg0KDQoNCg0KDQpB IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMgDQpkaXJlY3Rvcmllcy4NCiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo ZSBDb21tb24gQ29udHJvbCBhbmQgTWVhc3VyZW1lbnQgUGxhbmUgDQpXb3JraW5nIEdyb3VwIG9m IHRoZSBJRVRGLg0KDQogICAgICAgICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFJTVlAtVEUg RXh0ZW5zaW9ucyB0byBFeGNoYW5nZSBNUExTLVRQIA0KTFNQIFR1bm5lbCBOdW1iZXJzDQogICAg ICAgICAgICAgICAgIEF1dGhvcihzKSAgICAgICA6IEZlaSBaaGFuZw0KICAgICAgICAgICAgICAg ICAgICAgICAgICBWZW5rYXRlc2FuIE1haGFsaW5nYW0NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgWXVuYmluIFh1DQogICAgICAgICAgICAgICAgICAgICAgICAgIFJha2VzaCBHYW5kaGkNCiAg ICAgICAgICAgICAgICAgRmlsZW5hbWUgICAgICAgIDogDQpkcmFmdC16aGFuZy1jY2FtcC1tcGxz LXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS0wNC50eHQNCiAgICAgICAgICAgICAgICAgUGFnZXMg ICAgICAgICAgIDogNw0KICAgICAgICAgICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDEyLTA4 LTE1DQoNCkFic3RyYWN0Og0KICAgVGhlIE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUgKE1QTFMtVFAp IGlkZW50aWZpZXJzIGRvY3VtZW50IFtSRkM2MzcwXQ0KICAgc3BlY2lmaWVzIGFuIGluaXRpYWwg c2V0IG9mIGlkZW50aWZpZXJzLCBpbmNsdWRpbmcgdGhlIGxvY2FsIGFzc2lnbmVkDQogICBaOS1U dW5uZWxfTnVtLCB3aGljaCBjYW4gYmUgdXNlZCB0byBmb3JtIE1haW50ZW5hbmNlIEVudGl0eSBQ b2ludA0KICAgSWRlbnRpZmllciAoTUVQX0lEKS4gIEFzIHRvIHNvbWUgT3BlcmF0aW9uLCBBZG1p bmlzdHJhdGlvbiBhbmQNCiAgIE1haW50ZW5hbmNlIChPQU0pIGZ1bmN0aW9ucywgc3VjaCBhcyBD b25uZWN0aXZpdHkgVmVyaWZpY2F0aW9uIChDVikNCiAgIFtSRkM2NDI4XSwgc291cmNlIE1FUF9J RCBtdXN0IGJlIGluc2VydGVkIGluIHRoZSBPQU0gcGFja2V0cywgc28gdGhhdA0KICAgdGhlIHBl ZXIgZW5kcG9pbnQgY2FuIGNvbXBhcmUgdGhlIHJlY2VpdmVkIGFuZCBleHBlY3RlZCBNRVBfSURz IHRvDQogICBqdWRnZSB3aGV0aGVyIHRoZXJlIGlzIGEgbWlzLWNvbm5lY3Rpdml0eSBkZWZlY3Qg W1JGQzYzNzFdLCB3aGljaA0KICAgbWVhbnMgdGhhdCB0aGUgdHdvIE1FUCBub2RlcyBuZWVkIHRv IHByZS1zdG9yZSBlYWNoIG90aGVyJ3MgTUVQX0lEcy4NCg0KICAgVGhpcyBkb2N1bWVudCBkZWZp bmVzIHRoZSBzaWduYWxpbmcgZXh0ZW5zaW9ucyB0byBjb21tdW5pY2F0ZSB0aGUNCiAgIGxvY2Fs IGFzc2lnbmVkIFo5LVR1bm5lbF9OdW0gdG8gdGhlIGluZ3Jlc3MgTFNSIChMYWJlbCBTd2l0Y2hp bmcNCiAgIFJvdXRlcikgb2YgYSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuDQoNCg0KVGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0 ZS1leHQtdHVubmVsLW51bQ0KDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZh aWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAt bXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDQNCg0KDQpBIGRpZmYgZnJvbSB0aGUgcHJl dmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS0w NA0KDQoNCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMg RlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlz dA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2NhbXANCg0KDQoNCg== --=_alternative 0026409548257A5C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2UgaGF2ZSB1cGxvYWRlZCBhIG5l dyB2ZXJzaW9uIG9mIHRoaXMNCmRyYWZ0LCB0aGUgY2hhbmdlcyBhcmUgbGlzdGVkIGFzIGJlbG93 OjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MS4gQWRk IG9uZSBwYXJhZ3JhcGggaW4gc2VjdGlvbiAzIHRvDQphZGRyZXNzIHRoZSBleGNoYW5nZSBvZiBH bG9iYWxfSUQgaWYgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzIGFyZSBhY3Jvc3MNCmRpZmZl cmVudCBkb21haW5zLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Mi4gQWRkIG9uZSBzZWN0aW9uIDQuMiB0byBkZXNjcmliZSB0aGUNCnByb2Nlc3Npbmcg b2YgQVNTT0NJQVRJT04gb2JqZWN0cyB3aXRoIEFzc29jaWF0aW9uIFR5cGUgJnF1b3Q7TFNQIElk ZW50aWZpZXJzJnF1b3Q7DQppbiBtb3JlIGRldGFpbHMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4zLiBBZGQgJm5ic3A7UmVrZXNoIGFzIGEgY29hdXRo b3IgZm9yDQpoaXMgcmV2aWV3IGFuZCBjb250cmlidXRpb25zLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+NC4gRWRpdG9yaWFsIGNoYW5nZXMuPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgYXV0aG9ycyBi ZWxpZXZlIHRoYXQgdGhlIG1vdGl2YXRpb24NCmFuZCBzb2x1dGlvbiBpcyBzdGFibGUgYW5kIHRo ZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBkcmFmdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNA0KYW5k IHRoaXMgZHJhZnQgaXMgYWxzbyBjbGVhciBub3csIHdvdWxkIGxpa2UgdGhlIFdHIHRvIGNvbnNp ZGVyIGl0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hcyBhIFdH IGRvY3VtZW50IGFmdGVyIHRoZSByZXZpZXcuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5BbnkgY29tbWVudHMgYXJlIHdlbGNvbWU8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJlc3QgPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2 JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+ yMs6ICZuYnNwO2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wOC0xNiAxMzoxNDwvZm9udD4NCjx0ZCB3aWR0aD02MyU+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8 L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPmNjYW1wQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W 98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bQ0NB TVBdIEktRCBBY3Rpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtkcmFmdC16aGFuZy1j Y2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS0wNC50eHQ8L2ZvbnQ+PC90YWJsZT4N Cjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+ PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCkEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy48YnI+DQogVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29t bW9uIENvbnRyb2wgYW5kIE1lYXN1cmVtZW50IFBsYW5lDQpXb3JraW5nIEdyb3VwIG9mIHRoZSBJ RVRGLjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQpUaXRsZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDogUlNWUC1URSBFeHRlbnNpb25zIHRvIEV4Y2hhbmdlDQpNUExTLVRQIExTUCBUdW5uZWwgTnVt YmVyczxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQpBdXRob3IocykgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBGZWkgWmhhbmc8YnI+ DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO1ZlbmthdGVzYW4gTWFoYWxpbmdh bTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7WXVuYmluIFh1PGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDtSYWtlc2ggR2FuZGhpPGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCkZp bGVuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogZHJhZnQtemhhbmctY2NhbXAtbXBs cy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDQudHh0PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClBhZ2VzICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiA3PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCkRhdGUgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDIwMTItMDgtMTU8YnI+DQo8YnI+DQpBYnN0cmFjdDo8 YnI+DQogJm5ic3A7IFRoZSBNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBpZGVudGlm aWVycyBkb2N1bWVudCBbUkZDNjM3MF08YnI+DQogJm5ic3A7IHNwZWNpZmllcyBhbiBpbml0aWFs IHNldCBvZiBpZGVudGlmaWVycywgaW5jbHVkaW5nIHRoZSBsb2NhbCBhc3NpZ25lZDxicj4NCiAm bmJzcDsgWjktVHVubmVsX051bSwgd2hpY2ggY2FuIGJlIHVzZWQgdG8gZm9ybSBNYWludGVuYW5j ZSBFbnRpdHkgUG9pbnQ8YnI+DQogJm5ic3A7IElkZW50aWZpZXIgKE1FUF9JRCkuICZuYnNwO0Fz IHRvIHNvbWUgT3BlcmF0aW9uLCBBZG1pbmlzdHJhdGlvbg0KYW5kPGJyPg0KICZuYnNwOyBNYWlu dGVuYW5jZSAoT0FNKSBmdW5jdGlvbnMsIHN1Y2ggYXMgQ29ubmVjdGl2aXR5IFZlcmlmaWNhdGlv bg0KKENWKTxicj4NCiAmbmJzcDsgW1JGQzY0MjhdLCBzb3VyY2UgTUVQX0lEIG11c3QgYmUgaW5z ZXJ0ZWQgaW4gdGhlIE9BTSBwYWNrZXRzLCBzbw0KdGhhdDxicj4NCiAmbmJzcDsgdGhlIHBlZXIg ZW5kcG9pbnQgY2FuIGNvbXBhcmUgdGhlIHJlY2VpdmVkIGFuZCBleHBlY3RlZCBNRVBfSURzDQp0 bzxicj4NCiAmbmJzcDsganVkZ2Ugd2hldGhlciB0aGVyZSBpcyBhIG1pcy1jb25uZWN0aXZpdHkg ZGVmZWN0IFtSRkM2MzcxXSwgd2hpY2g8YnI+DQogJm5ic3A7IG1lYW5zIHRoYXQgdGhlIHR3byBN RVAgbm9kZXMgbmVlZCB0byBwcmUtc3RvcmUgZWFjaCBvdGhlcidzIE1FUF9JRHMuPGJyPg0KPGJy Pg0KICZuYnNwOyBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIHNpZ25hbGluZyBleHRlbnNpb25z IHRvIGNvbW11bmljYXRlIHRoZTxicj4NCiAmbmJzcDsgbG9jYWwgYXNzaWduZWQgWjktVHVubmVs X051bSB0byB0aGUgaW5ncmVzcyBMU1IgKExhYmVsIFN3aXRjaGluZzxicj4NCiAmbmJzcDsgUm91 dGVyKSBvZiBhIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUC48YnI+DQo8YnI+DQo8YnI+DQpU aGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRw LXJzdnB0ZS1leHQtdHVubmVsLW51bTxicj4NCjxicj4NClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVk IHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxicj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTA0PGJyPg0KPGJy Pg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4N Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMt dHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTA0PGJyPg0KPGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCmZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+ DQpDQ0FNUEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2NhbXA8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 0026409548257A5C_=-- From lberger@labn.net Thu Aug 16 07:57:48 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC28721F84EC for ; Thu, 16 Aug 2012 07:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.831 X-Spam-Level: X-Spam-Status: No, score=-98.831 tagged_above=-999 required=5 tests=[AWL=0.984, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uATq0S978HJa for ; Thu, 16 Aug 2012 07:57:42 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 7AE3B21F85D3 for ; Thu, 16 Aug 2012 07:57:42 -0700 (PDT) Received: (qmail 16848 invoked by uid 0); 16 Aug 2012 14:57:16 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 16 Aug 2012 14:57:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=QkRC43jX1CwErCkCaUCuKon844pRO8zwTU4YVphnWE8=; b=L4A9vEwAMAeY8SN5lH1AQyo8RjPBCRi47Gcopc6cWGdlGBAkM1ekbbCTpIQMn2fBaSBUdwqRqbWWaDxyNMrqrkoApKE4gAedctLVw7vSIQSIGTgLS4zs96VUsN7ObX5g; Received: from box313.bluehost.com ([69.89.31.113]:56288 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T21Vc-0005G1-Kv; Thu, 16 Aug 2012 08:57:16 -0600 Message-ID: <502D0A4A.7070201@labn.net> Date: Thu, 16 Aug 2012 10:57:14 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 14:57:50 -0000 Fei, I still don't understand the point you're trying to address (in your proposed language). Given that you said that you can live with the published text, shall we just not worry about this? If not, can you rephrase the issue in the current text that you'd like to address? Thanks, Lou On 8/16/2012 2:06 AM, zhang.fei3@zte.com.cn wrote: > > Lou > > Thank you for your clarification, see response in line with > > Regards > > Fei > > > *Lou Berger * > > 2012-08-16 00:22 > > > ÊÕ¼þÈË > zhang.fei3@zte.com.cn > ³­ËÍ > ccamp@ietf.org > Ö÷Ìâ > Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt > > > > > > > > > > Fei, > See below. > > On 8/14/2012 11:10 PM, zhang.fei3@zte.com.cn wrote: >> >> Hi Lou >> >> I can see there are some minor changes when taking a look at the updated >> new version, and want to check with you the intention of listed two >> revisions. >> >> 1. Section 3 No-GMPLS Recovery Usage >> >> The sentence "Note that there are times when no matching state is found, >> e.g., when processing an initial LSP or when the ASSOCIATION object >> contains >> otherwise useful information, and such cases do not alter the processing >> defined below." is deleted in the version 04, which indicates that the >> ASSOCIATION object >> can not be used in a single session whith any kinds of Association Types >> or the usage in a single session can be defined as an association type >> specific rules? > > Not sure exactly what you're asking, but this change was editorial in > nature only, as processing behavior continues to be specified (see the > 2nd to last paragraph in Section 3.1.2 and 3.2.2.) > > I want to check whether the ASSOCIATION object is allowed to be > used in a signal session, > and find the corresponding description in section 3.1 and 3.2 > "The use of an ASSOCIATION object in a single session is not precluded" > " Note, the use of an ASSOCIATION object in a single session is not > precluded" > No problem now, thanks. > > >> >> 2. The descriptions about Global Association Source in Section 4.1. >> IPv4 and IPv6 Extended ASSOCIATION Object Format >> >> Similarly, the sentence "It is expected that the global identifier will >> be derived from the globally unique ASN of the autonomous system hosting >> the Association Source." does not appear in the new version. The >> question here is whether the Global Association Source SHOULD host the >> Association Source or not? If yeah, it had better being described in >> the document. > > So the old text was informative only (and was taken from RFC6370). The > new text is normative and says use definition from [RFC6370]. So I'm not > sure what is ambiguous in the new text. What specific change would you > like to see? > > IMHO, the Global Associaiton Source should be the Global_ID that > hosting > Association Source, how about "the Global_ID as defined in [RFC6370]that > hosting > the Association Source SHALL be used"? Of course, the current > description is > correct and includes this possibility. > > > Lou > >> >> >> Best regards >> >> Fei >> >> >> *Lou Berger * >> ·¢¼þÈË: ccamp-bounces@ietf.org >> >> 2012-08-14 22:10 >> >> >> ÊÕ¼þÈË >> ccamp@ietf.org >> ³­ËÍ >> >> Ö÷Ìâ >> Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt >> >> >> >> >> >> >> >> >> >> The authors believe that this revision addresses the comments raised by >> Adrian and discussed on the list. (It also includes few other editorial >> nits identified by the authors.) >> >> Please note, as discussed, there has been one substantive technical >> change (MUST --> SHOULD): >> >> 3.2.1. Resv Message Format >> OLD >> Relative ordering of ASSOCIATION objects of the same type >> MUST be preserved by transit nodes. >> NEW >> Relative ordering of ASSOCIATION objects of the same type >> *SHOULD* be preserved by transit nodes. >> >> Lou (and co-authors) >> >> On 8/14/2012 9:45 AM, internet-drafts@ietf.org wrote: >>> >>> 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 Association Object Extensions >>> Author(s) : Lou Berger >>> Francois Le Faucheur >>> Ashok Narayanan >>> Filename : draft-ietf-ccamp-assoc-ext-04.txt >>> Pages : 16 >>> Date : 2012-08-14 >>> >>> Abstract: >>> The RSVP ASSOCIATION object was defined in the context of GMPLS >>> (Generalized Multi-Protocol Label Switching) controlled label >>> switched paths (LSPs). In this context, the object is used to >>> associate recovery LSPs with the LSP they are protecting. This >>> object also has broader applicability as a mechanism to associate >>> RSVP state, and this document defines how the ASSOCIATION object >>> can be more generally applied. This document also defines >>> Extended ASSOCIATION objects which, in particular, can be used in >>> the context of the Transport Profile of Multiprotocol Label >>> Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, >>> and RFC 3473. It also modifies the definition of the Association >>> ID field defined in RFC 4872. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-assoc-ext >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-assoc-ext-04 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> > > From gregb@grotto-networking.com Thu Aug 16 09:19:20 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB23621F85CE for ; Thu, 16 Aug 2012 09:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yzy1o8K6C8gO for ; Thu, 16 Aug 2012 09:19:20 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 444FB21F8611 for ; Thu, 16 Aug 2012 09:19:20 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id 340CA211E3CD; Thu, 16 Aug 2012 11:19:19 -0500 (CDT) Message-ID: <502D1D7E.1020603@grotto-networking.com> Date: Thu, 16 Aug 2012 09:19:10 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Lou Berger References: <50229C0B.5020509@grotto-networking.com> <502C173C.7040700@labn.net> In-Reply-To: <502C173C.7040700@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP , draft-ietf-ccamp-wson-signaling@tools.ietf.org Subject: Re: [CCAMP] WSON updates for Optical Interface Classes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:19:21 -0000 Hi Lou, I'll try to update today or tomorrow. On WSON routing, I still haven't heard from the OIC draft authors on resolving the undefined references mentioned below. Best Regards Greg On 8/15/2012 2:40 PM, Lou Berger wrote: > Greg/Authors, > When do you expect to have a rev of the signaling draft to match the > recent updates (including the previous addition of WSON-LSC type)? > > Thanks, > Lou > > On 8/8/2012 1:04 PM, Greg Bernstein wrote: >> Hi CCAMPers, per working group consensus we have updated the following >> WSON drafts: >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-10 >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-15 >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-15. >> >> We have removed "modulation type", "FEC type", and "Bit rate range" and replace with the "Optical Interface Class". >> We have applied the changes suggested on the CCAMP list and in the OIC draft. >> There are some undefined references that need to be filled in by the authors of the OIC draft. >> Please furnish references or suitable text. >> Info draft: >> ..."Where the term is defined by [xyz]." >> >> Encoding draft: >> ..."The Optical Interface Class format is defined within [x-ref-tbd]." >> >> See updated drafts for further context. Also if an encoding example is desired for >> appendix A of the encoding draft please furnish. >> >> To ease and expedite further changes on the OIC issue >> MS Word versions of these documents can be found at: >> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp-wson-signal-compatibility-ospf-10a.docx >> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp-rwa-wson-encode-15a.docx >> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp-rwa-info-15a.docx >> >> Best Regards >> Greg B. >> >> >> -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From prvs=35752a2f96=lyong@ciena.com Thu Aug 16 09:45:21 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F3221F84D4 for ; Thu, 16 Aug 2012 09:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEb5GSfImrdX for ; Thu, 16 Aug 2012 09:45:21 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id E239A21F84C4 for ; Thu, 16 Aug 2012 09:45:20 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q7GGjBlY014730; Thu, 16 Aug 2012 12:45:19 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 16s46br3js-11 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Aug 2012 12:45:19 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Thu, 16 Aug 2012 12:45:06 -0400 From: "Ong, Lyndon" To: Greg Bernstein , Lou Berger Date: Thu, 16 Aug 2012 12:45:06 -0400 Thread-Topic: [CCAMP] WSON updates for Optical Interface Classes Thread-Index: Ac17yufX+oKeVhd1SumBmgchPrC78wAAXE+w Message-ID: References: <50229C0B.5020509@grotto-networking.com> <502C173C.7040700@labn.net> <502D1D7E.1020603@grotto-networking.com> In-Reply-To: <502D1D7E.1020603@grotto-networking.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-16_06:2012-08-16, 2012-08-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208160163 Cc: CCAMP , "draft-ietf-ccamp-wson-signaling@tools.ietf.org" Subject: Re: [CCAMP] WSON updates for Optical Interface Classes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:45:21 -0000 Hi Greg, Lou, Sorry, a little confused - aren't you defining the OIC format within the ws= on encoding draft itself? I would think the external references you need a= re for the ITU-T application codes, rather than the OIC format. Am I missi= ng something? The ITU-T references would be=20 [ITU-G.698.1] ITU-T Recommendation G.698.1, "Multichannel DWDM applications= with single-channel optical interfaces", November, 2009. [ITU-G.698.2] ITU-T Recommendation G.698.2, "Amplified multichannel dense w= avelength division multiplexing applications with single channel optical in= terfaces", November, 2009. [ITU-G.959.1] ITU-T Recommendation G.959.1, "Optical transport networks phy= sical layer interfaces", February, 2012. Cheers, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G= reg Bernstein Sent: Thursday, August 16, 2012 9:19 AM To: Lou Berger Cc: CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org Subject: Re: [CCAMP] WSON updates for Optical Interface Classes Hi Lou, I'll try to update today or tomorrow. On WSON routing, I still hav= en't heard from the OIC draft authors on resolving the undefined references= mentioned below. Best Regards Greg On 8/15/2012 2:40 PM, Lou Berger wrote: > Greg/Authors, > When do you expect to have a rev of the signaling draft to match the=20 > recent updates (including the previous addition of WSON-LSC type)? > > Thanks, > Lou > > On 8/8/2012 1:04 PM, Greg Bernstein wrote: >> Hi CCAMPers, per working group consensus we have updated the=20 >> following WSON drafts: >> >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility >> -ospf-10 >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-15 >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-15. >> >> We have removed "modulation type", "FEC type", and "Bit rate range" and = replace with the "Optical Interface Class". >> We have applied the changes suggested on the CCAMP list and in the OIC d= raft. >> There are some undefined references that need to be filled in by the aut= hors of the OIC draft. >> Please furnish references or suitable text. >> Info draft: >> ..."Where the term is defined by [xyz]." >> =20 >> Encoding draft: >> ..."The Optical Interface Class format is defined within [x-ref-tbd]." >> >> See updated drafts for further context. Also if an encoding example=20 >> is desired for appendix A of the encoding draft please furnish. >> >> To ease and expedite further changes on the OIC issue MS Word=20 >> versions of these documents can be found at: >> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp >> -wson-signal-compatibility-ospf-10a.docx >> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp >> -rwa-wson-encode-15a.docx=20 >> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp >> -rwa-info-15a.docx >> >> Best Regards >> Greg B. >> >> >> -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From kam.lam@alcatel-lucent.com Thu Aug 16 11:33:33 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CF621F85DF for ; Thu, 16 Aug 2012 11:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5gFTLT5GLGy for ; Thu, 16 Aug 2012 11:33:32 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 468EE21F85D0 for ; Thu, 16 Aug 2012 11:33:32 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q7GIXHak016716 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Aug 2012 20:33:23 +0200 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 16 Aug 2012 20:33:18 +0200 Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.16]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Thu, 16 Aug 2012 14:33:16 -0400 From: "Lam, Hing-Kam (Kam)" To: "Ong, Lyndon" , Greg Bernstein , Lou Berger Thread-Topic: [CCAMP] WSON updates for Optical Interface Classes Thread-Index: AQHNe8sHKbH3avnnYUuJWSY2TE2hSpdc6HIA///aRZA= Date: Thu, 16 Aug 2012 18:33:14 +0000 Message-ID: <8DBC3FDAC14BE441AED9C5939C77758509BA2BAF@US70TWXCHMBA12.zam.alcatel-lucent.com> References: <50229C0B.5020509@grotto-networking.com> <502C173C.7040700@labn.net> <502D1D7E.1020603@grotto-networking.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: CCAMP , "draft-ietf-ccamp-wson-signaling@tools.ietf.org" Subject: Re: [CCAMP] WSON updates for Optical Interface Classes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 18:33:33 -0000 Hi, In addition to the ones that Lyndon mentioned, should also include=20 [ITU-T G.695] Recommendation ITU-T G.695 (2010), Optical interfaces for coa= rse wavelength division multiplexing applications. Regards, Kam > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Ong, Lyndon > Sent: Thursday, August 16, 2012 12:45 PM > To: Greg Bernstein; Lou Berger > Cc: CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org > Subject: Re: [CCAMP] WSON updates for Optical Interface Classes >=20 > Hi Greg, Lou, >=20 > Sorry, a little confused - aren't you defining the OIC format within > the wson encoding draft itself? I would think the external references > you need are for the ITU-T application codes, rather than the OIC > format. Am I missing something? >=20 > The ITU-T references would be > [ITU-G.698.1] ITU-T Recommendation G.698.1, "Multichannel DWDM > applications with > single-channel optical interfaces", November, 2009. > [ITU-G.698.2] ITU-T Recommendation G.698.2, "Amplified multichannel > dense wavelength division multiplexing applications with single channel > optical interfaces", November, 2009. > [ITU-G.959.1] ITU-T Recommendation G.959.1, "Optical transport networks > physical layer interfaces", February, 2012. >=20 > Cheers, >=20 > Lyndon >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Greg Bernstein > Sent: Thursday, August 16, 2012 9:19 AM > To: Lou Berger > Cc: CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org > Subject: Re: [CCAMP] WSON updates for Optical Interface Classes >=20 > Hi Lou, I'll try to update today or tomorrow. On WSON routing, I still > haven't heard from the OIC draft authors on resolving the undefined > references mentioned below. > Best Regards > Greg > On 8/15/2012 2:40 PM, Lou Berger wrote: > > Greg/Authors, > > When do you expect to have a rev of the signaling draft to match > the > > recent updates (including the previous addition of WSON-LSC type)? > > > > Thanks, > > Lou > > > > On 8/8/2012 1:04 PM, Greg Bernstein wrote: > >> Hi CCAMPers, per working group consensus we have updated the > >> following WSON drafts: > >> > >> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal- > compatibility > >> -ospf-10 > >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-15 > >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-15. > >> > >> We have removed "modulation type", "FEC type", and "Bit rate range" > and replace with the "Optical Interface Class". > >> We have applied the changes suggested on the CCAMP list and in the > OIC draft. > >> There are some undefined references that need to be filled in by the > authors of the OIC draft. > >> Please furnish references or suitable text. > >> Info draft: > >> ..."Where the term is defined by [xyz]." > >> > >> Encoding draft: > >> ..."The Optical Interface Class format is defined within [x-ref- > tbd]." > >> > >> See updated drafts for further context. Also if an encoding example > >> is desired for appendix A of the encoding draft please furnish. > >> > >> To ease and expedite further changes on the OIC issue MS Word > >> versions of these documents can be found at: > >> http://www.grotto-networking.com/sites/default/files/draft-ietf- > ccamp > >> -wson-signal-compatibility-ospf-10a.docx > >> http://www.grotto-networking.com/sites/default/files/draft-ietf- > ccamp > >> -rwa-wson-encode-15a.docx > >> http://www.grotto-networking.com/sites/default/files/draft-ietf- > ccamp > >> -rwa-info-15a.docx > >> > >> Best Regards > >> Greg B. > >> > >> > >> >=20 >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From rgandhi@cisco.com Thu Aug 16 12:19:01 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E826F21F85CE for ; Thu, 16 Aug 2012 12:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5uSvqukmgxM for ; Thu, 16 Aug 2012 12:19:01 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 525AE21F85CD for ; Thu, 16 Aug 2012 12:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=2651; q=dns/txt; s=iport; t=1345144741; x=1346354341; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EmUteWQaSHMjkjQjVhak+XgQ/C77XkEOUcx9q/dubV4=; b=WhQNDQoKd02M5VauoKHtE47t3p85A3p9MlVJNRFrn7QZ7zAP7MOy1ydb RAf5Q8NAEOlxgSdJ7Gf+z2fhgKT4d57pn8C2gd2bDiKDHcgHX6hpA4ijQ urakHVHPaa6CfDd2sc9DXnW1f/2ouVdYowgnvGRbLD1s5vhZkNWTtrXJj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAE1GLVCtJXHA/2dsb2JhbABFui2BB4IgAQEBBAEBAQ8BJzQLDAQCAQgRBAEBCxQJBycLFAkIAgQOBQgBGYdrC5o+oEiLCoV3YAOWY40YgWaCXw X-IronPort-AV: E=Sophos;i="4.77,780,1336348800"; d="scan'208";a="112377048" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 16 Aug 2012 19:19:01 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7GJJ0d3002611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 19:19:00 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 14:19:00 -0500 From: "Rakesh Gandhi (rgandhi)" To: "ccamp@ietf.org" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: AQHNevYlT2UleTyGokCrGl2xd368KJdczQxw Date: Thu, 16 Aug 2012 19:19:00 +0000 Message-ID: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> In-Reply-To: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.249.119] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19120.001 x-tm-as-result: No--30.086200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 19:19:02 -0000 Hi All, We have uploaded a new version of this draft with following changes: 1. Added a section on Signaling of Co-routed LSPs=20 2. Added clarification on Signaling of Associated Bidirectional Protection= LSPs=20 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs=20 4. Added clarification on Signaling of Inter-domain Associated Bidirection= al LSPs=20 5. The Extended ASSOCIATION object format with Association Type "Associate= d Bidirectional LSP". Clarified on how to populate different fields in this= object. We believe that some of these changes were necessary to avoid the interoper= ability issues due to potentially different interpretations. Your review comments are welcome. Thanks, Rakesh -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Wednesday, August 15, 2012 10:53 AM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated= -lsp-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : RSVP-TE Extensions for Associated Bidirectional LSPs Author(s) : Fei Zhang Ruiquan Jing Rakesh Gandhi Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.tx= t Pages : 17 Date : 2012-08-15 Abstract: The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], describes that MPLS-TP MUST support associated bidirectional point- to-point LSPs. This document provides a method to bind two unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining the new Association Type in the Extended ASSOCIATION object. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-l= sp-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Thu Aug 16 12:59:58 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0FF21F858A for ; Thu, 16 Aug 2012 12:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.074 X-Spam-Level: X-Spam-Status: No, score=-100.074 tagged_above=-999 required=5 tests=[AWL=2.191, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG7hn0lvwWrN for ; Thu, 16 Aug 2012 12:59:58 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 4B9FB21F854A for ; Thu, 16 Aug 2012 12:59:58 -0700 (PDT) Received: (qmail 27568 invoked by uid 0); 16 Aug 2012 19:59:36 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 16 Aug 2012 19:59:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=yP/yBpQDHLnKJRpFBMQkKHLegX1Nl0QJ38qnXIs4Rv0=; b=MLavXy3lbSSJLZldCQYEJesRqOSTVm8o36gRsOhFHnz+0mvhsvT99QEz5snFbF+fayP/WJP9VtF8iMDbGCJ587nC2xw3atlDUIh/Hu5+qUVDVxLwaLPZEOiARdlej2Do; Received: from box313.bluehost.com ([69.89.31.113]:35464 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T26EC-0000Y9-8B; Thu, 16 Aug 2012 13:59:36 -0600 Message-ID: <502D5125.6000105@labn.net> Date: Thu, 16 Aug 2012 15:59:33 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Rakesh Gandhi (rgandhi)" References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 19:59:58 -0000 Rakesh, Is this the start of the thread that I requested in http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html In particular, is it the response to: > I'd like to ask that someone (Rakesh, Fei, etc.) review each of the > proposed change and the rational for each change (in one or in > separate e-mails). The WG discussion can then really begin on the > proposed changes. (Which are quite substantial both in scope and > implication.) Lou On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: > Hi All, > > We have uploaded a new version of this draft with following changes: > > 1. Added a section on Signaling of Co-routed LSPs > 2. Added clarification on Signaling of Associated Bidirectional Protection LSPs > 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs > 4. Added clarification on Signaling of Inter-domain Associated Bidirectional LSPs > 5. The Extended ASSOCIATION object format with Association Type "Associated Bidirectional LSP". Clarified on how to populate different fields in this object. > > We believe that some of these changes were necessary to avoid the interoperability issues due to potentially different interpretations. > > Your review comments are welcome. > > Thanks, > Rakesh > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, August 15, 2012 10:53 AM > To: i-d-announce@ietf.org > Cc: ccamp@ietf.org > Subject: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : RSVP-TE Extensions for Associated Bidirectional LSPs > Author(s) : Fei Zhang > Ruiquan Jing > Rakesh Gandhi > Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > Pages : 17 > Date : 2012-08-15 > > Abstract: > The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], > describes that MPLS-TP MUST support associated bidirectional point- > to-point LSPs. > > This document provides a method to bind two unidirectional Label > Switched Paths (LSPs) into an associated bidirectional LSP. The > association is achieved by defining the new Association Type in the > Extended ASSOCIATION object. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From rgandhi@cisco.com Thu Aug 16 13:26:47 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4C621F85DF for ; Thu, 16 Aug 2012 13:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lN0fZ8YFh08 for ; Thu, 16 Aug 2012 13:26:46 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A47A821F85C9 for ; Thu, 16 Aug 2012 13:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=3875; q=dns/txt; s=iport; t=1345148806; x=1346358406; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7KjO0iqPN3iXmBBYdbnJsCByM517/xXhyzM6QNmyia8=; b=Cj9EJ0ipXEfeKC6r4Gm2bDe8h14DAKhcWNqHhmWLOKpPXqyEqR+MrXyb 9rSOHckB4fi+nL50gavmYxBuRuPu90LRtL0AxZjUbk5ABjnnGvz5QfbBw v75jxbmenfr6UDsM5o6QXUQshaqh5GWSm8e4J2gDNHfcSePhPcs6zNfsf 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMZWLVCtJXG9/2dsb2JhbABFujCBB4IgAQEBAwEBAQEPASc0CwUHBAIBCA4DBAEBAQoUCQcnCxQJCAIEDgUIARmHZQYLmj6gQ4sKGoVdYAOWY40YgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,780,1336348800"; d="scan'208";a="112379625" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 16 Aug 2012 20:26:46 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7GKQkfM027060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 20:26:46 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 15:26:45 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: AQHNevYlT2UleTyGokCrGl2xd368KJdczQxwgABkKID//7JBYA== Date: Thu, 16 Aug 2012 20:26:45 +0000 Message-ID: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> In-Reply-To: <502D5125.6000105@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.249.119] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19120.001 x-tm-as-result: No--47.071000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 20:26:47 -0000 Hi Lou, Yes. Please advise if you think detailed email is required.=20 We believe latest draft summarizes the changes well and we could start revi= ew/discussions from there. Thanks, Rakesh -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, August 16, 2012 4:00 PM To: Rakesh Gandhi (rgandhi) Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Rakesh, Is this the start of the thread that I requested in http://www.ietf.org/ma= il-archive/web/ccamp/current/msg13729.html In particular, is it the response to: > I'd like to ask that someone (Rakesh, Fei, etc.) review each of the=20 > proposed change and the rational for each change (in one or in=20 > separate e-mails). The WG discussion can then really begin on the=20 > proposed changes. (Which are quite substantial both in scope and > implication.) Lou On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: > Hi All, >=20 > We have uploaded a new version of this draft with following changes: =20 1. Added a section on Signaling of Co-routed LSPs=20 2. Added clarification on Signaling of Associated Bidirectional Protection= LSPs=20 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs=20 4. Added clarification on Signaling of Inter-domain Associated Bidirecti= onal LSPs=20 5. The Extended ASSOCIATION object format with Association Type "Associate= d Bidirectional LSP". Clarified on how to populate different fields in this= object. =20 > We believe that some of these changes were necessary to avoid the interop= erability issues due to potentially different interpretations. >=20 > Your review comments are welcome. >=20 > Thanks, > Rakesh >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=20 > Of internet-drafts@ietf.org > Sent: Wednesday, August 15, 2012 10:53 AM > To: i-d-announce@ietf.org > Cc: ccamp@ietf.org > Subject: [CCAMP] I-D Action:=20 > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Common Control and Measurement Plane Wo= rking Group of the IETF. >=20 > Title : RSVP-TE Extensions for Associated Bidirectional LSPs > Author(s) : Fei Zhang > Ruiquan Jing > Rakesh Gandhi > Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.= txt > Pages : 17 > Date : 2012-08-15 >=20 > Abstract: > The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], > describes that MPLS-TP MUST support associated bidirectional point- > to-point LSPs. >=20 > This document provides a method to bind two unidirectional Label > Switched Paths (LSPs) into an associated bidirectional LSP. The > association is achieved by defining the new Association Type in the > Extended ASSOCIATION object. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-a > ssociated-lsp >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associa > ted-lsp-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte-ext-a > ssociated-lsp-04 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 >=20 >=20 From lberger@labn.net Thu Aug 16 14:10:42 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7872921F8512 for ; Thu, 16 Aug 2012 14:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.112 X-Spam-Level: X-Spam-Status: No, score=-100.112 tagged_above=-999 required=5 tests=[AWL=2.153, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFgvAe5oZ0i9 for ; Thu, 16 Aug 2012 14:10:41 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id E815121F8510 for ; Thu, 16 Aug 2012 14:10:40 -0700 (PDT) Received: (qmail 6609 invoked by uid 0); 16 Aug 2012 21:10:19 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 16 Aug 2012 21:10:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=A+8wnKB1d24hw68deZhO1ajQmbRKYBaFWBSzIurzimw=; b=x3D3nVTrjV7zrR9tbBs1jicAEmDgasCbyAao8TMwFMBUeem5JDFr3t5zHGSk9zJ+SYbX5XsV5Op59cuA7C1/P7uvZ2U6mUOhOk2V7JQYESDqkRY+zrcIHlTKFJJDQ5xJ; Received: from box313.bluehost.com ([69.89.31.113]:43696 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T27Kc-0001AW-Ux; Thu, 16 Aug 2012 15:10:19 -0600 Message-ID: <502D61B8.5050106@labn.net> Date: Thu, 16 Aug 2012 17:10:16 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Rakesh Gandhi (rgandhi)" References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 21:10:42 -0000 Rakesh, Such major changes (in scope and functionality) to WG drafts are usually discussed with the WG prior to the authors/editors just publishing the changes. But, this is a judgment call by the document editors in how, quoting rfc2418, they "ensur[e] that the contents of the document accurately reflect the decisions that have been made by the working group." So let's jump into discussing the changes. As I see it this draft introduces several major functional changes that have not been discussed by the WG. Correct me if I get them wrong, but I believe they include: 1) Introduction of a second method for signaling Co-routed LSPs 2) Support for FRR bypass tunnels for piggybacked on the TP bidirectional LSP mechanisms. There are also other changes, but I'll defer discussing them until the discussion on the above is concluded. Is this correct? Assuming yes, I have questions about both rational and specific mechanisms. For now let's look at the former, so please: A) Articulate the issues/limitations with using the RFC3473 defined mechanisms for (co-routed) bidirectional LSPs that you'd like to see addressed. B.1) Articulate the FRR/GMPLS-related issue you'd like to address? B.2) Articulate why this issue should be solved in a TP-specific and not GMPLS generic fashion? Thanks, Lou On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, > > Yes. > > Please advise if you think detailed email is required. > We believe latest draft summarizes the changes well and we could start review/discussions from there. > > Thanks, > Rakesh > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 4:00 PM > To: Rakesh Gandhi (rgandhi) > Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > Rakesh, > Is this the start of the thread that I requested in http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html > > In particular, is it the response to: >> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >> proposed change and the rational for each change (in one or in >> separate e-mails). The WG discussion can then really begin on the >> proposed changes. (Which are quite substantial both in scope and >> implication.) > > Lou > > On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >> Hi All, >> >> We have uploaded a new version of this draft with following changes: > > 1. Added a section on Signaling of Co-routed LSPs > > 2. Added clarification on Signaling of Associated Bidirectional Protection LSPs > > 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs > > 4. Added clarification on Signaling of Inter-domain Associated Bidirectional LSPs > > 5. The Extended ASSOCIATION object format with Association Type "Associated Bidirectional LSP". Clarified on how to populate different fields in this object. > > >> We believe that some of these changes were necessary to avoid the interoperability issues due to potentially different interpretations. >> >> Your review comments are welcome. >> >> Thanks, >> Rakesh >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of internet-drafts@ietf.org >> Sent: Wednesday, August 15, 2012 10:53 AM >> To: i-d-announce@ietf.org >> Cc: ccamp@ietf.org >> Subject: [CCAMP] I-D Action: >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. >> >> Title : RSVP-TE Extensions for Associated Bidirectional LSPs >> Author(s) : Fei Zhang >> Ruiquan Jing >> Rakesh Gandhi >> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> Pages : 17 >> Date : 2012-08-15 >> >> Abstract: >> The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], >> describes that MPLS-TP MUST support associated bidirectional point- >> to-point LSPs. >> >> This document provides a method to bind two unidirectional Label >> Switched Paths (LSPs) into an associated bidirectional LSP. The >> association is achieved by defining the new Association Type in the >> Extended ASSOCIATION object. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-a >> ssociated-lsp >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associa >> ted-lsp-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext-a >> ssociated-lsp-04 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > > > > From rgandhi@cisco.com Thu Aug 16 14:26:54 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FA121F8647 for ; Thu, 16 Aug 2012 14:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enwaUU8eL830 for ; Thu, 16 Aug 2012 14:26:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id AFD5A21F8644 for ; Thu, 16 Aug 2012 14:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=6298; q=dns/txt; s=iport; t=1345152413; x=1346362013; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=T/rW97XzElhXHYlg0nzw1JETEERBC+8YfnN6fGMBmX8=; b=VWhlnzOO5+5AE/WyrRTvt716mv68VfEdIYjPIdIY9cVne89L4d/MevrW ukwizOqLtidX7lyRq1D3b56j0fKXLeHUJbSfTsgsoWpWrWA6DI/QVMpj6 u4FvUf3//9oUzhdpUPRfjjM3IrAlB38kVAXmFCsCM5g+KAZ4yspiOtYZk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB1lLVCtJXG+/2dsb2JhbABFui+BB4IgAQEBBAEBAQ8BJzQLDAQCAQgOAwQBAQEKFAkHJwsUCQgCBA4FCAEZh2sLmjmgPIsKGoVdYAOWY40YgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,781,1336348800"; d="scan'208";a="112403617" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 16 Aug 2012 21:26:53 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7GLQrTR004085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 21:26:53 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 16:26:52 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: AQHNevYlT2UleTyGokCrGl2xd368KJdczQxwgABkKID//7JBYIAAYYEA//+uAGA= Date: Thu, 16 Aug 2012 21:26:52 +0000 Message-ID: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> In-Reply-To: <502D61B8.5050106@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.249.119] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19120.001 x-tm-as-result: No--67.770500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 21:26:54 -0000 Hi Lou, Thank you for your comments. We had several email exchanges on the alias on "signaling of co-routed LSPs= " before it was added in the draft.=20 Regarding A) I agree with you that GMPLS signaling can be used for co-routed LSPs and ha= s many advantages. Goal of the associated bidirectional LSPs is to tie the two independent LSP= s together. These two LSPs may be non co-routed or co-routed. It is useful = for an application to specify the node to request both LSPs go on the same = path. Do you agree?=20 Thanks, Rakesh -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, August 16, 2012 5:10 PM To: Rakesh Gandhi (rgandhi) Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Rakesh, Such major changes (in scope and functionality) to WG drafts are usually d= iscussed with the WG prior to the authors/editors just publishing the chang= es. But, this is a judgment call by the document editors in how, quoting r= fc2418, they "ensur[e] that the contents of the document accurately reflect= the decisions that have been made by the working group." So let's jump into discussing the changes. As I see it this draft introduces several major functional changes that hav= e not been discussed by the WG. Correct me if I get them wrong, but I beli= eve they include: 1) Introduction of a second method for signaling Co-routed LSPs 2) Support for FRR bypass tunnels for piggybacked on the TP bidirectional L= SP mechanisms. There are also other changes, but I'll defer discussing them until the discussion on the above is concluded. Is this correct? Assuming yes, I have questions about both rational and specific mechanisms.= For now let's look at the former, so please: A) Articulate the issues/limitations with using the RFC3473 defined mechani= sms for (co-routed) bidirectional LSPs that you'd like to see addressed. B.1) Articulate the FRR/GMPLS-related issue you'd like to address? B.2) Articulate why this issue should be solved in a TP-specific and not GM= PLS generic fashion? Thanks, Lou On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, >=20 > Yes. >=20 > Please advise if you think detailed email is required.=20 > We believe latest draft summarizes the changes well and we could start re= view/discussions from there. >=20 > Thanks, > Rakesh >=20 >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 4:00 PM > To: Rakesh Gandhi (rgandhi) > Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn > Subject: Re: [CCAMP] I-D Action:=20 > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >=20 > Rakesh, > Is this the start of the thread that I requested in=20 > http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >=20 > In particular, is it the response to: >> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the=20 >> proposed change and the rational for each change (in one or in=20 >> separate e-mails). The WG discussion can then really begin on the=20 >> proposed changes. (Which are quite substantial both in scope and >> implication.) >=20 > Lou >=20 > On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >> Hi All, >> >> We have uploaded a new version of this draft with following changes: > =20 > 1. Added a section on Signaling of Co-routed LSPs >=20 > 2. Added clarification on Signaling of Associated Bidirectional=20 > Protection LSPs >=20 > 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >=20 > 4. Added clarification on Signaling of Inter-domain Associated Bidirec= tional LSPs=20 >=20 > 5. The Extended ASSOCIATION object format with Association Type "Associa= ted Bidirectional LSP". Clarified on how to populate different fields in th= is object. >=20 > =20 >> We believe that some of these changes were necessary to avoid the intero= perability issues due to potentially different interpretations. >> >> Your review comments are welcome. >> >> Thanks, >> Rakesh >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >> Behalf Of internet-drafts@ietf.org >> Sent: Wednesday, August 15, 2012 10:53 AM >> To: i-d-announce@ietf.org >> Cc: ccamp@ietf.org >> Subject: [CCAMP] I-D Action:=20 >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Common Control and Measurement Plane W= orking Group of the IETF. >> >> Title : RSVP-TE Extensions for Associated Bidirectional LSPs >> Author(s) : Fei Zhang >> Ruiquan Jing >> Rakesh Gandhi >> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04= .txt >> Pages : 17 >> Date : 2012-08-15 >> >> Abstract: >> The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], >> describes that MPLS-TP MUST support associated bidirectional point- >> to-point LSPs. >> >> This document provides a method to bind two unidirectional Label >> Switched Paths (LSPs) into an associated bidirectional LSP. The >> association is achieved by defining the new Association Type in the >> Extended ASSOCIATION object. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >> a >> ssociated-lsp >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ >> a >> ted-lsp-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte-ext- >> a >> ssociated-lsp-04 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> >=20 >=20 >=20 >=20 From jdrake@juniper.net Thu Aug 16 14:36:27 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E3E21F8650 for ; Thu, 16 Aug 2012 14:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[AWL=0.954, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLyIXnGsRFqP for ; Thu, 16 Aug 2012 14:36:26 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5416221F8620 for ; Thu, 16 Aug 2012 14:36:26 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUC1n1k/XPMfa0m/EMcPVlIdXaqjuAN6s@postini.com; Thu, 16 Aug 2012 14:36:26 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 16 Aug 2012 14:36:07 -0700 From: John E Drake To: Lou Berger , "Rakesh Gandhi (rgandhi)" Date: Thu, 16 Aug 2012 14:35:52 -0700 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac1785rSId2NZtIbQqC8AUMHyCWeygAAzqsw Message-ID: <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> In-Reply-To: <502D61B8.5050106@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 21:36:27 -0000 Lou, Since the WG did not agree to this changes, let alone discuss them, would i= t be possible to simply rollback these changes and ask the authors to write= a draft addressing the topics you list in your email, below? Thanks, John=20 Sent from my iPhone > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Thursday, August 16, 2012 2:10 PM > To: Rakesh Gandhi (rgandhi) > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- > associated-lsp-04.txt >=20 > Rakesh, > Such major changes (in scope and functionality) to WG drafts are > usually discussed with the WG prior to the authors/editors just > publishing the changes. But, this is a judgment call by the document > editors in how, quoting rfc2418, they "ensur[e] that the contents of > the document accurately reflect the decisions that have been made by > the working group." >=20 > So let's jump into discussing the changes. >=20 > As I see it this draft introduces several major functional changes that > have not been discussed by the WG. Correct me if I get them wrong, but > I believe they include: > 1) Introduction of a second method for signaling Co-routed LSPs > 2) Support for FRR bypass tunnels for piggybacked on the TP > bidirectional LSP mechanisms. >=20 > There are also other changes, but I'll defer discussing them > until the discussion on the above is concluded. >=20 > Is this correct? >=20 > Assuming yes, I have questions about both rational and specific > mechanisms. For now let's look at the former, so please: >=20 > A) Articulate the issues/limitations with using the RFC3473 defined > mechanisms for (co-routed) bidirectional LSPs that you'd like to see > addressed. >=20 > B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >=20 > B.2) Articulate why this issue should be solved in a TP-specific and > not GMPLS generic fashion? >=20 > Thanks, > Lou >=20 > On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: > > Hi Lou, > > > > Yes. > > > > Please advise if you think detailed email is required. > > We believe latest draft summarizes the changes well and we could > start review/discussions from there. > > > > Thanks, > > Rakesh > > > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Thursday, August 16, 2012 4:00 PM > > To: Rakesh Gandhi (rgandhi) > > Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn > > Subject: Re: [CCAMP] I-D Action: > > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > > > Rakesh, > > Is this the start of the thread that I requested in > > http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html > > > > In particular, is it the response to: > >> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the > >> proposed change and the rational for each change (in one or in > >> separate e-mails). The WG discussion can then really begin on the > >> proposed changes. (Which are quite substantial both in scope and > >> implication.) > > > > Lou > > > > On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: > >> Hi All, > >> > >> We have uploaded a new version of this draft with following changes: > > > > 1. Added a section on Signaling of Co-routed LSPs > > > > 2. Added clarification on Signaling of Associated Bidirectional > > Protection LSPs > > > > 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs > > > > 4. Added clarification on Signaling of Inter-domain Associated > Bidirectional LSPs > > > > 5. The Extended ASSOCIATION object format with Association Type > "Associated Bidirectional LSP". Clarified on how to populate different > fields in this object. > > > > > >> We believe that some of these changes were necessary to avoid the > interoperability issues due to potentially different interpretations. > >> > >> Your review comments are welcome. > >> > >> Thanks, > >> Rakesh > >> > >> -----Original Message----- > >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >> Behalf Of internet-drafts@ietf.org > >> Sent: Wednesday, August 15, 2012 10:53 AM > >> To: i-d-announce@ietf.org > >> Cc: ccamp@ietf.org > >> Subject: [CCAMP] I-D Action: > >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> This draft is a work item of the Common Control and Measurement > Plane Working Group of the IETF. > >> > >> Title : RSVP-TE Extensions for Associated Bidirectional > LSPs > >> Author(s) : Fei Zhang > >> Ruiquan Jing > >> Rakesh Gandhi > >> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- > lsp-04.txt > >> Pages : 17 > >> Date : 2012-08-15 > >> > >> Abstract: > >> The MPLS Transport Profile (MPLS-TP) requirements document > [RFC5654], > >> describes that MPLS-TP MUST support associated bidirectional > point- > >> to-point LSPs. > >> > >> This document provides a method to bind two unidirectional Label > >> Switched Paths (LSPs) into an associated bidirectional LSP. The > >> association is achieved by defining the new Association Type in > the > >> Extended ASSOCIATION object. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- > ext- > >> a > >> ssociated-lsp > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- > associ > >> a > >> ted-lsp-04 > >> > >> A diff from the previous version is available at: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- > ext- > >> a > >> ssociated-lsp-04 > >> > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > >> > >> > >> > >> > > > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Thu Aug 16 14:42:25 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A4C21F84C4 for ; Thu, 16 Aug 2012 14:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.149 X-Spam-Level: X-Spam-Status: No, score=-100.149 tagged_above=-999 required=5 tests=[AWL=2.116, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyzXL+u1Ojpm for ; Thu, 16 Aug 2012 14:42:24 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id ADC3F11E80A3 for ; Thu, 16 Aug 2012 14:42:23 -0700 (PDT) Received: (qmail 31803 invoked by uid 0); 16 Aug 2012 21:41:58 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 16 Aug 2012 21:41:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=LqKNLVx0Db+yNRuUnD3BNX8Mb+mdxq9rYY+c8B4Mc9g=; b=KwImkHQ/N8vttvnnj7Mc4YmPEqygJ2g6MbOWHMCTwrLFxQUyZum0W4dB5kgZYxc/PvAe1cB4tZpvw+pbMG9AKJDMowv7h8DT9dxkyjfmGlyi+AXnqLv5EjZ7Ooja8Rz+; Received: from box313.bluehost.com ([69.89.31.113]:47478 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T27pF-0003XO-8O; Thu, 16 Aug 2012 15:41:57 -0600 Message-ID: <502D6923.6090808@labn.net> Date: Thu, 16 Aug 2012 17:41:55 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Rakesh Gandhi (rgandhi)" References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 21:42:25 -0000 Rakesh, On 8/16/2012 5:26 PM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, > > Thank you for your comments. > > We had several email exchanges on the alias on "signaling of > co-routed LSPs" before it was added in the draft. I presume you're referring to your private e-mail exchange that was forwarded to the list, mid-stream, under the subject "Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03". I addressed this in http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html. If you disagree with that e-mail, please respond to it. > > Regarding A) > > I agree with you that GMPLS signaling can be used for co-routed LSPs > and has many advantages. > > Goal of the associated bidirectional LSPs is to tie the two > independent LSPs together. These two LSPs may be non co-routed or > co-routed. It is useful for an application to specify the node to > request both LSPs go on the same path. Do you agree? Not sure I understand your question. Per RFC5654 and RFC6373 there is a stated need for associated and co-routed MPLS TP transport paths. As discussed in RFC6373, RFC3473 already supports co-routed bidirectional LSPs. The draft we're discussing covers associated bidirectional. Can you rephrase the issue/function that you believe is not addressed in current signaling RFCs? Lou > > Thanks, > Rakesh > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 5:10 PM > To: Rakesh Gandhi (rgandhi) > Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > Rakesh, > Such major changes (in scope and functionality) to WG drafts are usually discussed with the WG prior to the authors/editors just publishing the changes. But, this is a judgment call by the document editors in how, quoting rfc2418, they "ensur[e] that the contents of the document accurately reflect the decisions that have been made by the working group." > > So let's jump into discussing the changes. > > As I see it this draft introduces several major functional changes that have not been discussed by the WG. Correct me if I get them wrong, but I believe they include: > 1) Introduction of a second method for signaling Co-routed LSPs > 2) Support for FRR bypass tunnels for piggybacked on the TP bidirectional LSP mechanisms. > > There are also other changes, but I'll defer discussing them > until the discussion on the above is concluded. > > Is this correct? > > Assuming yes, I have questions about both rational and specific mechanisms. For now let's look at the former, so please: > > A) Articulate the issues/limitations with using the RFC3473 defined mechanisms for (co-routed) bidirectional LSPs that you'd like to see addressed. > > B.1) Articulate the FRR/GMPLS-related issue you'd like to address? > > B.2) Articulate why this issue should be solved in a TP-specific and not GMPLS generic fashion? > > Thanks, > Lou > > On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >> Hi Lou, >> >> Yes. >> >> Please advise if you think detailed email is required. >> We believe latest draft summarizes the changes well and we could start review/discussions from there. >> >> Thanks, >> Rakesh >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Thursday, August 16, 2012 4:00 PM >> To: Rakesh Gandhi (rgandhi) >> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >> Subject: Re: [CCAMP] I-D Action: >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> Rakesh, >> Is this the start of the thread that I requested in >> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >> >> In particular, is it the response to: >>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>> proposed change and the rational for each change (in one or in >>> separate e-mails). The WG discussion can then really begin on the >>> proposed changes. (Which are quite substantial both in scope and >>> implication.) >> >> Lou >> >> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>> Hi All, >>> >>> We have uploaded a new version of this draft with following changes: >> >> 1. Added a section on Signaling of Co-routed LSPs >> >> 2. Added clarification on Signaling of Associated Bidirectional >> Protection LSPs >> >> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >> >> 4. Added clarification on Signaling of Inter-domain Associated Bidirectional LSPs >> >> 5. The Extended ASSOCIATION object format with Association Type "Associated Bidirectional LSP". Clarified on how to populate different fields in this object. >> >> >>> We believe that some of these changes were necessary to avoid the interoperability issues due to potentially different interpretations. >>> >>> Your review comments are welcome. >>> >>> Thanks, >>> Rakesh >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>> Behalf Of internet-drafts@ietf.org >>> Sent: Wednesday, August 15, 2012 10:53 AM >>> To: i-d-announce@ietf.org >>> Cc: ccamp@ietf.org >>> Subject: [CCAMP] I-D Action: >>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. >>> >>> Title : RSVP-TE Extensions for Associated Bidirectional LSPs >>> Author(s) : Fei Zhang >>> Ruiquan Jing >>> Rakesh Gandhi >>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>> Pages : 17 >>> Date : 2012-08-15 >>> >>> Abstract: >>> The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], >>> describes that MPLS-TP MUST support associated bidirectional point- >>> to-point LSPs. >>> >>> This document provides a method to bind two unidirectional Label >>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>> association is achieved by defining the new Association Type in the >>> Extended ASSOCIATION object. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> a >>> ssociated-lsp >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ >>> a >>> ted-lsp-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> a >>> ssociated-lsp-04 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> >> >> >> >> > > > > From gregb@grotto-networking.com Thu Aug 16 14:51:40 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859F111E808E for ; Thu, 16 Aug 2012 14:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TO4fivS2gkM for ; Thu, 16 Aug 2012 14:51:39 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AC94B11E808A for ; Thu, 16 Aug 2012 14:51:39 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id 2D80F212BA57; Thu, 16 Aug 2012 16:51:38 -0500 (CDT) Message-ID: <502D6B60.5070206@grotto-networking.com> Date: Thu, 16 Aug 2012 14:51:28 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Ong, Lyndon" References: <50229C0B.5020509@grotto-networking.com> <502C173C.7040700@labn.net> <502D1D7E.1020603@grotto-networking.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP , "draft-ietf-ccamp-wson-signaling@tools.ietf.org" Subject: Re: [CCAMP] WSON updates for Optical Interface Classes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 21:51:40 -0000 We implemented the WSON Info changes requested in Giovanni's CCAMP list email dated 07/05/2012. Don't know what those references were referring to. Please review changes to updated WSON info and WSON encoding drafts and send us any deltas. Best Regards Greg On 8/16/2012 9:45 AM, Ong, Lyndon wrote: > Hi Greg, Lou, > > Sorry, a little confused - aren't you defining the OIC format within the wson encoding draft itself? I would think the external references you need are for the ITU-T application codes, rather than the OIC format. Am I missing something? > > The ITU-T references would be > [ITU-G.698.1] ITU-T Recommendation G.698.1, "Multichannel DWDM applications with > single-channel optical interfaces", November, 2009. > [ITU-G.698.2] ITU-T Recommendation G.698.2, "Amplified multichannel dense wavelength division multiplexing applications with single channel optical interfaces", November, 2009. > [ITU-G.959.1] ITU-T Recommendation G.959.1, "Optical transport networks physical layer interfaces", February, 2012. > > Cheers, > > Lyndon > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein > Sent: Thursday, August 16, 2012 9:19 AM > To: Lou Berger > Cc: CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org > Subject: Re: [CCAMP] WSON updates for Optical Interface Classes > > Hi Lou, I'll try to update today or tomorrow. On WSON routing, I still haven't heard from the OIC draft authors on resolving the undefined references mentioned below. > Best Regards > Greg > On 8/15/2012 2:40 PM, Lou Berger wrote: >> Greg/Authors, >> When do you expect to have a rev of the signaling draft to match the >> recent updates (including the previous addition of WSON-LSC type)? >> >> Thanks, >> Lou >> >> On 8/8/2012 1:04 PM, Greg Bernstein wrote: >>> Hi CCAMPers, per working group consensus we have updated the >>> following WSON drafts: >>> >>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility >>> -ospf-10 >>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-15 >>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-15. >>> >>> We have removed "modulation type", "FEC type", and "Bit rate range" and replace with the "Optical Interface Class". >>> We have applied the changes suggested on the CCAMP list and in the OIC draft. >>> There are some undefined references that need to be filled in by the authors of the OIC draft. >>> Please furnish references or suitable text. >>> Info draft: >>> ..."Where the term is defined by [xyz]." >>> >>> Encoding draft: >>> ..."The Optical Interface Class format is defined within [x-ref-tbd]." >>> >>> See updated drafts for further context. Also if an encoding example >>> is desired for appendix A of the encoding draft please furnish. >>> >>> To ease and expedite further changes on the OIC issue MS Word >>> versions of these documents can be found at: >>> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp >>> -wson-signal-compatibility-ospf-10a.docx >>> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp >>> -rwa-wson-encode-15a.docx >>> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccamp >>> -rwa-info-15a.docx >>> >>> Best Regards >>> Greg B. >>> >>> >>> > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From rgandhi@cisco.com Thu Aug 16 14:59:43 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E6921F8557 for ; Thu, 16 Aug 2012 14:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBuOHE--EMnD for ; Thu, 16 Aug 2012 14:59:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D2FDF21F8554 for ; Thu, 16 Aug 2012 14:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8011; q=dns/txt; s=iport; t=1345154383; x=1346363983; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cI9X5TCz3KXb1o1dW+neWnS9WsEk3uuhcPWHUKx0Vuo=; b=DblCYsY3yv4jHxp1FWZ9VVZqtAgdK3SMVhcEh1IaCq5/zn/n58HUEDD6 8L6fscOBag2SHrgQRWESpR77qmO+ESkssDCHMldvTiJZ7HR1MPYzg1sfw q184pfkY3E10nFQ4Fk8sDg9IlNQaBChL50T7NbFCOrtJ5hkmPCWaL0Olu 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFNsLVCtJXG+/2dsb2JhbABFujOBB4IgAQEBAwEBAQEPASc0CwwEAgEIDgMEAQEBChQJBycLFAkIAgQOBQgBGYdlBguaMaA8iwoahV1gA5ZjjRiBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,781,1336348800"; d="scan'208";a="109414675" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 16 Aug 2012 21:59:42 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7GLxg6x005003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 21:59:42 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 16:59:42 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: AQHNevYlT2UleTyGokCrGl2xd368KJdczQxwgABkKID//7JBYIAAYYEA//+uAGCAAFrYgP//r1Lg Date: Thu, 16 Aug 2012 21:59:41 +0000 Message-ID: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <502D6923.6090808@labn.net> In-Reply-To: <502D6923.6090808@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.249.119] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19120.001 x-tm-as-result: No--77.874600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 21:59:44 -0000 Hi Lou, Please see inline.... -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, August 16, 2012 5:42 PM To: Rakesh Gandhi (rgandhi) Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Rakesh, On 8/16/2012 5:26 PM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, >=20 > Thank you for your comments. >=20 > We had several email exchanges on the alias on "signaling of co-routed=20 > LSPs" before it was added in the draft. I presume you're referring to your private e-mail exchange that was forward= ed to the list, mid-stream, under the subject "Re: [CCAMP] Comments on draf= t-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03". I addressed this in http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html. If you d= isagree with that e-mail, please respond to it. >=20 > Regarding A) >=20 > I agree with you that GMPLS signaling can be used for co-routed LSPs=20 > and has many advantages. >=20 > Goal of the associated bidirectional LSPs is to tie the two=20 > independent LSPs together. These two LSPs may be non co-routed or=20 > co-routed. It is useful for an application to specify the node to=20 > request both LSPs go on the same path. Do you agree? Not sure I understand your question. Per RFC5654 and RFC6373 there is a st= ated need for associated and co-routed MPLS TP transport paths. As discuss= ed in RFC6373, RFC3473 already supports co-routed bidirectional LSPs. The = draft we're discussing covers associated bidirectional. Can you rephrase the issue/function that you believe is not addressed in cu= rrent signaling RFCs? I understand what you are saying and do not see any issue there. But I= am not looking at it from that view point. All we are saying is that when = bidirectional LSPs are associated via signaling, they could take the same p= ath and it can be provisioned to do so. =20 Thanks, Rakesh Lou >=20 > Thanks, > Rakesh >=20 >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 5:10 PM > To: Rakesh Gandhi (rgandhi) > Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn > Subject: Re: [CCAMP] I-D Action:=20 > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >=20 > Rakesh, > Such major changes (in scope and functionality) to WG drafts are usually= discussed with the WG prior to the authors/editors just publishing the cha= nges. But, this is a judgment call by the document editors in how, quoting= rfc2418, they "ensur[e] that the contents of the document accurately refle= ct the decisions that have been made by the working group." >=20 > So let's jump into discussing the changes. >=20 > As I see it this draft introduces several major functional changes that h= ave not been discussed by the WG. Correct me if I get them wrong, but I be= lieve they include: > 1) Introduction of a second method for signaling Co-routed LSPs > 2) Support for FRR bypass tunnels for piggybacked on the TP bidirectional= LSP mechanisms. >=20 > There are also other changes, but I'll defer discussing them > until the discussion on the above is concluded. >=20 > Is this correct? >=20 > Assuming yes, I have questions about both rational and specific mechanism= s. For now let's look at the former, so please: >=20 > A) Articulate the issues/limitations with using the RFC3473 defined mecha= nisms for (co-routed) bidirectional LSPs that you'd like to see addressed. >=20 > B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >=20 > B.2) Articulate why this issue should be solved in a TP-specific and not = GMPLS generic fashion? >=20 > Thanks, > Lou >=20 > On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >> Hi Lou, >> >> Yes. >> >> Please advise if you think detailed email is required.=20 >> We believe latest draft summarizes the changes well and we could start r= eview/discussions from there. >> >> Thanks, >> Rakesh >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Thursday, August 16, 2012 4:00 PM >> To: Rakesh Gandhi (rgandhi) >> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >> Subject: Re: [CCAMP] I-D Action:=20 >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> Rakesh, >> Is this the start of the thread that I requested in=20 >> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >> >> In particular, is it the response to: >>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the=20 >>> proposed change and the rational for each change (in one or in=20 >>> separate e-mails). The WG discussion can then really begin on the=20 >>> proposed changes. (Which are quite substantial both in scope and >>> implication.) >> >> Lou >> >> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>> Hi All, >>> >>> We have uploaded a new version of this draft with following changes: >> =20 >> 1. Added a section on Signaling of Co-routed LSPs >> >> 2. Added clarification on Signaling of Associated Bidirectional=20 >> Protection LSPs >> >> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >> >> 4. Added clarification on Signaling of Inter-domain Associated Bidire= ctional LSPs=20 >> >> 5. The Extended ASSOCIATION object format with Association Type "Associ= ated Bidirectional LSP". Clarified on how to populate different fields in t= his object. >> >> =20 >>> We believe that some of these changes were necessary to avoid the inter= operability issues due to potentially different interpretations. >>> >>> Your review comments are welcome. >>> >>> Thanks, >>> Rakesh >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>> Behalf Of internet-drafts@ietf.org >>> Sent: Wednesday, August 15, 2012 10:53 AM >>> To: i-d-announce@ietf.org >>> Cc: ccamp@ietf.org >>> Subject: [CCAMP] I-D Action:=20 >>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>> This draft is a work item of the Common Control and Measurement Plane = Working Group of the IETF. >>> >>> Title : RSVP-TE Extensions for Associated Bidirectional LSPs >>> Author(s) : Fei Zhang >>> Ruiquan Jing >>> Rakesh Gandhi >>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-0= 4.txt >>> Pages : 17 >>> Date : 2012-08-15 >>> >>> Abstract: >>> The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654]= , >>> describes that MPLS-TP MUST support associated bidirectional point- >>> to-point LSPs. >>> >>> This document provides a method to bind two unidirectional Label >>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>> association is achieved by defining the new Association Type in the >>> Extended ASSOCIATION object. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext >>> - >>> a >>> ssociated-lsp >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-assoc >>> i >>> a >>> ted-lsp-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte-ext >>> - >>> a >>> ssociated-lsp-04 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> >> >> >> >> >=20 >=20 >=20 >=20 From prvs=35752a2f96=lyong@ciena.com Thu Aug 16 15:07:29 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317BA21F858A for ; Thu, 16 Aug 2012 15:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gR5Mg2spm6mL for ; Thu, 16 Aug 2012 15:07:28 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3A57121F856F for ; Thu, 16 Aug 2012 15:07:28 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q7GM5fYf021711; Thu, 16 Aug 2012 18:07:26 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 16s8pcr4bm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Aug 2012 18:07:26 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT01.ciena.com ([::1]) with mapi; Thu, 16 Aug 2012 18:07:27 -0400 From: "Ong, Lyndon" To: Greg Bernstein Date: Thu, 16 Aug 2012 18:07:32 -0400 Thread-Topic: [CCAMP] WSON updates for Optical Interface Classes Thread-Index: Ac17+VKG7ehHi6XSTqO+CxGcdzpM2wAAG7jg Message-ID: References: <50229C0B.5020509@grotto-networking.com> <502C173C.7040700@labn.net> <502D1D7E.1020603@grotto-networking.com> <502D6B60.5070206@grotto-networking.com> In-Reply-To: <502D6B60.5070206@grotto-networking.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-19120.002 x-tm-as-result: No--45.049800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-16_06:2012-08-16, 2012-08-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208160259 Cc: CCAMP , "draft-ietf-ccamp-wson-signaling@tools.ietf.org" Subject: Re: [CCAMP] WSON updates for Optical Interface Classes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 22:07:29 -0000 Hi Greg, Well my two cents would be the following: 1) WSON encoding draft, section 5.2:=20 The Optical Interface Class format is defined within [x-ref-tbd]. Propose to remove the sentence as the format is defined within the encoding= draft itself. 2) WSON information model draft, section 5.3: Where the term is defined by [xyz?]. Propose to replace the sentence with text from draft-martinelli section 3.1= (with some grammatical edits): The Optical Interface Class is a unique number that identifies all information related to optical characteristics of a physical interface. The class may include other optical parameters related to other interface properties. A class MUST always include signal compatibility information. The content of each class is out of the scope of this draft and can be defined by other entities (e.g. ITU, optical equipment vendors, etc.). Since even current implementation of physical interfaces may support different optical characteristics, a single interface may support multiple interface classes. Which optical interface class is used among all the ones available for an interface is out of the scope of this draft but is an output of the RWA process. Cheers, Lyndon -----Original Message----- From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Thursday, August 16, 2012 2:51 PM To: Ong, Lyndon Cc: Lou Berger; CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org Subject: Re: [CCAMP] WSON updates for Optical Interface Classes We implemented the WSON Info changes requested in Giovanni's CCAMP list ema= il dated 07/05/2012. Don't know what those references were referring to. P= lease review changes to updated WSON info and WSON encoding drafts and send= us any deltas. Best Regards Greg On 8/16/2012 9:45 AM, Ong, Lyndon wrote: > Hi Greg, Lou, > > Sorry, a little confused - aren't you defining the OIC format within the = wson encoding draft itself? I would think the external references you need= are for the ITU-T application codes, rather than the OIC format. Am I mis= sing something? > > The ITU-T references would be > [ITU-G.698.1] ITU-T Recommendation G.698.1, "Multichannel DWDM=20 > applications with single-channel optical interfaces", November, 2009. > [ITU-G.698.2] ITU-T Recommendation G.698.2, "Amplified multichannel dense= wavelength division multiplexing applications with single channel optical = interfaces", November, 2009. > [ITU-G.959.1] ITU-T Recommendation G.959.1, "Optical transport networks p= hysical layer interfaces", February, 2012. > > Cheers, > > Lyndon > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=20 > Of Greg Bernstein > Sent: Thursday, August 16, 2012 9:19 AM > To: Lou Berger > Cc: CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org > Subject: Re: [CCAMP] WSON updates for Optical Interface Classes > > Hi Lou, I'll try to update today or tomorrow. On WSON routing, I still h= aven't heard from the OIC draft authors on resolving the undefined referenc= es mentioned below. > Best Regards > Greg > On 8/15/2012 2:40 PM, Lou Berger wrote: >> Greg/Authors, >> When do you expect to have a rev of the signaling draft to match the=20 >> recent updates (including the previous addition of WSON-LSC type)? >> >> Thanks, >> Lou >> >> On 8/8/2012 1:04 PM, Greg Bernstein wrote: >>> Hi CCAMPers, per working group consensus we have updated the=20 >>> following WSON drafts: >>> >>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibilit >>> y >>> -ospf-10 >>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-15 >>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-15. >>> >>> We have removed "modulation type", "FEC type", and "Bit rate range" and= replace with the "Optical Interface Class". >>> We have applied the changes suggested on the CCAMP list and in the OIC = draft. >>> There are some undefined references that need to be filled in by the au= thors of the OIC draft. >>> Please furnish references or suitable text. >>> Info draft: >>> ..."Where the term is defined by [xyz]." >>> =20 >>> Encoding draft: >>> ..."The Optical Interface Class format is defined within [x-ref-tbd]." >>> >>> See updated drafts for further context. Also if an encoding example=20 >>> is desired for appendix A of the encoding draft please furnish. >>> >>> To ease and expedite further changes on the OIC issue MS Word=20 >>> versions of these documents can be found at: >>> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccam >>> p -wson-signal-compatibility-ospf-10a.docx >>> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccam >>> p >>> -rwa-wson-encode-15a.docx >>> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccam >>> p >>> -rwa-info-15a.docx >>> >>> Best Regards >>> Greg B. >>> >>> >>> > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 From lberger@labn.net Thu Aug 16 15:08:41 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E12821F858A for ; Thu, 16 Aug 2012 15:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[AWL=2.080, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDYjowScqBLI for ; Thu, 16 Aug 2012 15:08:40 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id B062521F856F for ; Thu, 16 Aug 2012 15:08:40 -0700 (PDT) Received: (qmail 22920 invoked by uid 0); 16 Aug 2012 22:08:16 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 16 Aug 2012 22:08:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=1TnWuWHJQtGSqXxEzel4Gh/tM2uy2CA5CLCIIuSuDUs=; b=ulOo3WM5WPQJgC4RT96Y//fWYrduDtAlkUwp7NSTUtJWe2ZJULNLpEb1vSwIED3hiZJg+7BXFQk8OWrzTMjQVj3gr0YfBhhaBuQxZzM3cqQFkO2o1uNPjKAV+U8m2wr4; Received: from box313.bluehost.com ([69.89.31.113]:50131 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T28Eh-0004Bw-S9; Thu, 16 Aug 2012 16:08:16 -0600 Message-ID: <502D6F4D.7020707@labn.net> Date: Thu, 16 Aug 2012 18:08:13 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John E Drake References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 22:08:41 -0000 John, While strictly speaking WG drafts should only reflect current WG consensus, and it is the WG draft editor's job to ensure this, in practice authors/editors are given a lot of latitude in timing / ordering in introduction to changes. I personally think this is a practical way of keeping the process moving. Also if the WG disagrees with a change, it can always be backed out. So, yes, the WG could do exactly as you say if it comes to it. (The chairs can even appoint different editor if needed, e.g., to make this happen.) While I'm not happy with how this revision came about, as I covered in earlier mail, my feeling is to let the discussion take place on the list (and at the next IETF, if needed) and then have the draft updated to reflect the WG discussion/consensus. Lou On 8/16/2012 5:35 PM, John E Drake wrote: > Lou, > > Since the WG did not agree to this changes, let alone discuss them, > would it be possible to simply rollback these changes and ask the > authors to write a draft addressing the topics you list in your > email, below? > > Thanks, > > John > > Sent from my iPhone > > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Lou Berger >> Sent: Thursday, August 16, 2012 2:10 PM >> To: Rakesh Gandhi (rgandhi) >> Cc: ccamp@ietf.org >> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >> associated-lsp-04.txt >> >> Rakesh, >> Such major changes (in scope and functionality) to WG drafts are >> usually discussed with the WG prior to the authors/editors just >> publishing the changes. But, this is a judgment call by the document >> editors in how, quoting rfc2418, they "ensur[e] that the contents of >> the document accurately reflect the decisions that have been made by >> the working group." >> >> So let's jump into discussing the changes. >> >> As I see it this draft introduces several major functional changes that >> have not been discussed by the WG. Correct me if I get them wrong, but >> I believe they include: >> 1) Introduction of a second method for signaling Co-routed LSPs >> 2) Support for FRR bypass tunnels for piggybacked on the TP >> bidirectional LSP mechanisms. >> >> There are also other changes, but I'll defer discussing them >> until the discussion on the above is concluded. >> >> Is this correct? >> >> Assuming yes, I have questions about both rational and specific >> mechanisms. For now let's look at the former, so please: >> >> A) Articulate the issues/limitations with using the RFC3473 defined >> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >> addressed. >> >> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >> >> B.2) Articulate why this issue should be solved in a TP-specific and >> not GMPLS generic fashion? >> >> Thanks, >> Lou >> >> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>> Hi Lou, >>> >>> Yes. >>> >>> Please advise if you think detailed email is required. >>> We believe latest draft summarizes the changes well and we could >> start review/discussions from there. >>> >>> Thanks, >>> Rakesh >>> >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Thursday, August 16, 2012 4:00 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>> Subject: Re: [CCAMP] I-D Action: >>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>> >>> Rakesh, >>> Is this the start of the thread that I requested in >>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>> >>> In particular, is it the response to: >>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>> proposed change and the rational for each change (in one or in >>>> separate e-mails). The WG discussion can then really begin on the >>>> proposed changes. (Which are quite substantial both in scope and >>>> implication.) >>> >>> Lou >>> >>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi All, >>>> >>>> We have uploaded a new version of this draft with following changes: >>> >>> 1. Added a section on Signaling of Co-routed LSPs >>> >>> 2. Added clarification on Signaling of Associated Bidirectional >>> Protection LSPs >>> >>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>> >>> 4. Added clarification on Signaling of Inter-domain Associated >> Bidirectional LSPs >>> >>> 5. The Extended ASSOCIATION object format with Association Type >> "Associated Bidirectional LSP". Clarified on how to populate different >> fields in this object. >>> >>> >>>> We believe that some of these changes were necessary to avoid the >> interoperability issues due to potentially different interpretations. >>>> >>>> Your review comments are welcome. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>> Behalf Of internet-drafts@ietf.org >>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>> To: i-d-announce@ietf.org >>>> Cc: ccamp@ietf.org >>>> Subject: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>>> This draft is a work item of the Common Control and Measurement >> Plane Working Group of the IETF. >>>> >>>> Title : RSVP-TE Extensions for Associated Bidirectional >> LSPs >>>> Author(s) : Fei Zhang >>>> Ruiquan Jing >>>> Rakesh Gandhi >>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >> lsp-04.txt >>>> Pages : 17 >>>> Date : 2012-08-15 >>>> >>>> Abstract: >>>> The MPLS Transport Profile (MPLS-TP) requirements document >> [RFC5654], >>>> describes that MPLS-TP MUST support associated bidirectional >> point- >>>> to-point LSPs. >>>> >>>> This document provides a method to bind two unidirectional Label >>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>> association is achieved by defining the new Association Type in >> the >>>> Extended ASSOCIATION object. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >> ext- >>>> a >>>> ssociated-lsp >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >> associ >>>> a >>>> ted-lsp-04 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte- >> ext- >>>> a >>>> ssociated-lsp-04 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > > > From rgandhi@cisco.com Thu Aug 16 15:16:38 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B8E21F8582 for ; Thu, 16 Aug 2012 15:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.918 X-Spam-Level: X-Spam-Status: No, score=-6.918 tagged_above=-999 required=5 tests=[AWL=3.681, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdayEP0PQ5p6 for ; Thu, 16 Aug 2012 15:16:37 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9466A21F8499 for ; Thu, 16 Aug 2012 15:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=8068; q=dns/txt; s=iport; t=1345155397; x=1346364997; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DnxTcjew61nnvKfxchL4GnjBOquvTAp0m3yA9LGDTDI=; b=W/eRqSQqy+5yXpqrwoYzFriazvq9HTWgzlfO8+c243DLIkAhJqPYmoGg w+gU0fKUQaUQYABclzXT3ItxEMJCqCsHOcqKIBfL1UDJIKvrtmROHb3mA Fnlpqq+/lStM9nks5CfS6kfU4EdNMZWQA/G8en+tyK0PaW8xyGxfkilHF M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAI5wLVCtJXG//2dsb2JhbABFujKBB4IgAQEBAwEBAQEPASc0CwwEAgEIDgMEAQEBChQJBycLFAkIAgQBDQUIARmHZQYLmi2gP4sKGoVdYAOWY40YgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,781,1336348800"; d="scan'208";a="112407442" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 16 Aug 2012 22:16:36 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7GMGY0F017093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 22:16:34 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 17:16:34 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger , John E Drake Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: AQHNe/cx34lJSZEEcUqtz7dC7WQXiZddUyWA//+stfA= Date: Thu, 16 Aug 2012 22:16:33 +0000 Message-ID: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> In-Reply-To: <502D6F4D.7020707@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.249.119] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19120.001 x-tm-as-result: No--63.567500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 22:16:38 -0000 Hi Lou, Thanks for initiating discussions on the changes in the draft.=20 Agree with you here, if we/WG do not agree on the "co-routed associated bid= irectional LSP" part, we are ok to remove it from this draft and can always= submit a new draft just for that. We respect your/WG decision. Thanks, Rakesh -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, August 16, 2012 6:08 PM To: John E Drake Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt John, While strictly speaking WG drafts should only reflect current WG consensus= , and it is the WG draft editor's job to ensure this, in practice authors/e= ditors are given a lot of latitude in timing / ordering in introduction to = changes. I personally think this is a practical way of keeping the process= moving. Also if the WG disagrees with a change, it can always be backed o= ut. So, yes, the WG could do exactly as you say if it comes to it. (The chairs= can even appoint different editor if needed, e.g., to make this happen.) While I'm not happy with how this revision came about, as I cover= ed in earlier mail, my feeling is to let the discussion take place on the l= ist (and at the next IETF, if needed) and then have the draft updated to re= flect the WG discussion/consensus. Lou On 8/16/2012 5:35 PM, John E Drake wrote: > Lou, >=20 > Since the WG did not agree to this changes, let alone discuss them,=20 > would it be possible to simply rollback these changes and ask the=20 > authors to write a draft addressing the topics you list in your email,=20 > below? >=20 > Thanks, >=20 > John >=20 > Sent from my iPhone >=20 >=20 >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >> Behalf Of Lou Berger >> Sent: Thursday, August 16, 2012 2:10 PM >> To: Rakesh Gandhi (rgandhi) >> Cc: ccamp@ietf.org >> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >> associated-lsp-04.txt >> >> Rakesh, >> Such major changes (in scope and functionality) to WG drafts are=20 >> usually discussed with the WG prior to the authors/editors just=20 >> publishing the changes. But, this is a judgment call by the document=20 >> editors in how, quoting rfc2418, they "ensur[e] that the contents of=20 >> the document accurately reflect the decisions that have been made by=20 >> the working group." >> >> So let's jump into discussing the changes. >> >> As I see it this draft introduces several major functional changes=20 >> that have not been discussed by the WG. Correct me if I get them=20 >> wrong, but I believe they include: >> 1) Introduction of a second method for signaling Co-routed LSPs >> 2) Support for FRR bypass tunnels for piggybacked on the TP=20 >> bidirectional LSP mechanisms. >> >> There are also other changes, but I'll defer discussing them >> until the discussion on the above is concluded. >> >> Is this correct? >> >> Assuming yes, I have questions about both rational and specific=20 >> mechanisms. For now let's look at the former, so please: >> >> A) Articulate the issues/limitations with using the RFC3473 defined=20 >> mechanisms for (co-routed) bidirectional LSPs that you'd like to see=20 >> addressed. >> >> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >> >> B.2) Articulate why this issue should be solved in a TP-specific and=20 >> not GMPLS generic fashion? >> >> Thanks, >> Lou >> >> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>> Hi Lou, >>> >>> Yes. >>> >>> Please advise if you think detailed email is required. >>> We believe latest draft summarizes the changes well and we could >> start review/discussions from there. >>> >>> Thanks, >>> Rakesh >>> >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Thursday, August 16, 2012 4:00 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>> Subject: Re: [CCAMP] I-D Action: >>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>> >>> Rakesh, >>> Is this the start of the thread that I requested in=20 >>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>> >>> In particular, is it the response to: >>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the=20 >>>> proposed change and the rational for each change (in one or in=20 >>>> separate e-mails). The WG discussion can then really begin on the=20 >>>> proposed changes. (Which are quite substantial both in scope and >>>> implication.) >>> >>> Lou >>> >>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi All, >>>> >>>> We have uploaded a new version of this draft with following changes: >>> >>> 1. Added a section on Signaling of Co-routed LSPs >>> >>> 2. Added clarification on Signaling of Associated Bidirectional=20 >>> Protection LSPs >>> >>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>> >>> 4. Added clarification on Signaling of Inter-domain Associated >> Bidirectional LSPs >>> >>> 5. The Extended ASSOCIATION object format with Association Type >> "Associated Bidirectional LSP". Clarified on how to populate=20 >> different fields in this object. >>> >>> >>>> We believe that some of these changes were necessary to avoid the >> interoperability issues due to potentially different interpretations. >>>> >>>> Your review comments are welcome. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>>> Behalf Of internet-drafts@ietf.org >>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>> To: i-d-announce@ietf.org >>>> Cc: ccamp@ietf.org >>>> Subject: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>>> This draft is a work item of the Common Control and Measurement >> Plane Working Group of the IETF. >>>> >>>> Title : RSVP-TE Extensions for Associated Bidirectional >> LSPs >>>> Author(s) : Fei Zhang >>>> Ruiquan Jing >>>> Rakesh Gandhi >>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >> lsp-04.txt >>>> Pages : 17 >>>> Date : 2012-08-15 >>>> >>>> Abstract: >>>> The MPLS Transport Profile (MPLS-TP) requirements document >> [RFC5654], >>>> describes that MPLS-TP MUST support associated bidirectional >> point- >>>> to-point LSPs. >>>> >>>> This document provides a method to bind two unidirectional Label >>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>> association is achieved by defining the new Association Type in >> the >>>> Extended ASSOCIATION object. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >> ext- >>>> a >>>> ssociated-lsp >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >> associ >>>> a >>>> ted-lsp-04 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >> ext- >>>> a >>>> ssociated-lsp-04 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 >=20 >=20 From lberger@labn.net Thu Aug 16 15:17:45 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A35F21F8499 for ; Thu, 16 Aug 2012 15:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.22 X-Spam-Level: X-Spam-Status: No, score=-100.22 tagged_above=-999 required=5 tests=[AWL=2.045, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoRcBI936YHo for ; Thu, 16 Aug 2012 15:17:44 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 2453321F8582 for ; Thu, 16 Aug 2012 15:17:44 -0700 (PDT) Received: (qmail 13044 invoked by uid 0); 16 Aug 2012 22:17:20 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 16 Aug 2012 22:17:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=tbNNNjGAztlNEX8Vg9M4NhlhvyJsqrAkOniaWlo4S6Q=; b=GEeWbikEiYXaL+w1HRalzGws1YQuq8f2RkGlrYSqmD9XYJ7usjlBBd+8w6C6W+TYVvtdpG/+SMNZUI7ZZ02EbEJWfbSDf4AX/7XRCS3aYgobwCOcmwj2vENnWS4FnudA; Received: from box313.bluehost.com ([69.89.31.113]:50936 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T28NT-0006wT-TS; Thu, 16 Aug 2012 16:17:20 -0600 Message-ID: <502D716D.9090503@labn.net> Date: Thu, 16 Aug 2012 18:17:17 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Rakesh Gandhi (rgandhi)" References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <502D6923.6090808@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 22:17:45 -0000 Rakesh, See below. On 8/16/2012 5:59 PM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, > > Please see inline.... > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 5:42 PM > To: Rakesh Gandhi (rgandhi) > Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > Rakesh, > > On 8/16/2012 5:26 PM, Rakesh Gandhi (rgandhi) wrote: >> Hi Lou, >> >> Thank you for your comments. >> >> We had several email exchanges on the alias on "signaling of co-routed >> LSPs" before it was added in the draft. > > I presume you're referring to your private e-mail exchange that was forwarded to the list, mid-stream, under the subject "Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03". > > I addressed this in > http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html. If you disagree with that e-mail, please respond to it. > >> >> Regarding A) >> >> I agree with you that GMPLS signaling can be used for co-routed LSPs >> and has many advantages. >> >> Goal of the associated bidirectional LSPs is to tie the two >> independent LSPs together. These two LSPs may be non co-routed or >> co-routed. It is useful for an application to specify the node to >> request both LSPs go on the same path. Do you agree? > > Not sure I understand your question. Per RFC5654 and RFC6373 there is a stated need for associated and co-routed MPLS TP transport paths. As discussed in RFC6373, RFC3473 already supports co-routed bidirectional LSPs. The draft we're discussing covers associated bidirectional. > > Can you rephrase the issue/function that you believe is not addressed in current signaling RFCs? > > I understand what you are saying and do not see any issue there. > But I am not looking at it from that view point. Actually, I'm not making any statement on if there's an issue or not. I'm asking you to state the issue or new function that you'd like addressed by a new mechanism. It's really simple, if there's no issue or need for a new function, then there's no need to defined a new mechanism. I'm guessing that you see an issue or limitation, and I'd genuinely like to understand what it is. > All we are saying is > that when bidirectional LSPs are associated via signaling, they could > take the same path and it can be provisioned to do so. Well, this is already stated in RFC5654 (and referenced RFC6373). If that's it, we can easily close this topic. Lou > > Thanks, > Rakesh > > Lou > >> >> Thanks, >> Rakesh >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Thursday, August 16, 2012 5:10 PM >> To: Rakesh Gandhi (rgandhi) >> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >> Subject: Re: [CCAMP] I-D Action: >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> Rakesh, >> Such major changes (in scope and functionality) to WG drafts are usually discussed with the WG prior to the authors/editors just publishing the changes. But, this is a judgment call by the document editors in how, quoting rfc2418, they "ensur[e] that the contents of the document accurately reflect the decisions that have been made by the working group." >> >> So let's jump into discussing the changes. >> >> As I see it this draft introduces several major functional changes that have not been discussed by the WG. Correct me if I get them wrong, but I believe they include: >> 1) Introduction of a second method for signaling Co-routed LSPs >> 2) Support for FRR bypass tunnels for piggybacked on the TP bidirectional LSP mechanisms. >> >> There are also other changes, but I'll defer discussing them >> until the discussion on the above is concluded. >> >> Is this correct? >> >> Assuming yes, I have questions about both rational and specific mechanisms. For now let's look at the former, so please: >> >> A) Articulate the issues/limitations with using the RFC3473 defined mechanisms for (co-routed) bidirectional LSPs that you'd like to see addressed. >> >> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >> >> B.2) Articulate why this issue should be solved in a TP-specific and not GMPLS generic fashion? >> >> Thanks, >> Lou >> >> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>> Hi Lou, >>> >>> Yes. >>> >>> Please advise if you think detailed email is required. >>> We believe latest draft summarizes the changes well and we could start review/discussions from there. >>> >>> Thanks, >>> Rakesh >>> >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Thursday, August 16, 2012 4:00 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>> Subject: Re: [CCAMP] I-D Action: >>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>> >>> Rakesh, >>> Is this the start of the thread that I requested in >>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>> >>> In particular, is it the response to: >>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>> proposed change and the rational for each change (in one or in >>>> separate e-mails). The WG discussion can then really begin on the >>>> proposed changes. (Which are quite substantial both in scope and >>>> implication.) >>> >>> Lou >>> >>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi All, >>>> >>>> We have uploaded a new version of this draft with following changes: >>> >>> 1. Added a section on Signaling of Co-routed LSPs >>> >>> 2. Added clarification on Signaling of Associated Bidirectional >>> Protection LSPs >>> >>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>> >>> 4. Added clarification on Signaling of Inter-domain Associated Bidirectional LSPs >>> >>> 5. The Extended ASSOCIATION object format with Association Type "Associated Bidirectional LSP". Clarified on how to populate different fields in this object. >>> >>> >>>> We believe that some of these changes were necessary to avoid the interoperability issues due to potentially different interpretations. >>>> >>>> Your review comments are welcome. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>> Behalf Of internet-drafts@ietf.org >>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>> To: i-d-announce@ietf.org >>>> Cc: ccamp@ietf.org >>>> Subject: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. >>>> >>>> Title : RSVP-TE Extensions for Associated Bidirectional LSPs >>>> Author(s) : Fei Zhang >>>> Ruiquan Jing >>>> Rakesh Gandhi >>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> Pages : 17 >>>> Date : 2012-08-15 >>>> >>>> Abstract: >>>> The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], >>>> describes that MPLS-TP MUST support associated bidirectional point- >>>> to-point LSPs. >>>> >>>> This document provides a method to bind two unidirectional Label >>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>> association is achieved by defining the new Association Type in the >>>> Extended ASSOCIATION object. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext >>>> - >>>> a >>>> ssociated-lsp >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-assoc >>>> i >>>> a >>>> ted-lsp-04 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext >>>> - >>>> a >>>> ssociated-lsp-04 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > > From rgandhi@cisco.com Thu Aug 16 15:24:39 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A27321F8599 for ; Thu, 16 Aug 2012 15:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.838 X-Spam-Level: X-Spam-Status: No, score=-7.838 tagged_above=-999 required=5 tests=[AWL=2.761, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zi6tNXcKZ8j for ; Thu, 16 Aug 2012 15:24:38 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id EE67721F8592 for ; Thu, 16 Aug 2012 15:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=9250; q=dns/txt; s=iport; t=1345155878; x=1346365478; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8USgiOPn/4cTQcvr4LUP1OWl2Qit0zCkJvkQlH4a4Vo=; b=i0ZJ66eFEGgBEVy5R5qXNMvwv/v1GDax/17YBwIjBC47SXTPxssDIL7E SohqY+0aR6aHs6iPK2qGKok4/qBVpDCg/knAwFPO62+dV+TXodSGFLL/H CDTRtS+xmSEc8S+JPNSi2WLVp1kgfxjFWLqIcTBWYAH/HHCxxdaxXnfQq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPhxLVCtJXG8/2dsb2JhbABFujKBB4IgAQEBAwEBAQEPASc0CwUHBAIBCA4DBAEBAQoUCQcnCxQJCAIEDgUIARmHZQYLmi+gP4sKGoVdYAOWY40YgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,781,1336348800"; d="scan'208";a="112409196" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 16 Aug 2012 22:24:37 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7GMObiR010576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 22:24:37 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 17:24:36 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: AQHNevYlT2UleTyGokCrGl2xd368KJdczQxwgABkKID//7JBYIAAYYEA//+uAGCAAFrYgP//r1LgAAtR9YAACkdycA== Date: Thu, 16 Aug 2012 22:24:36 +0000 Message-ID: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <502D6923.6090808@labn.net> <502D716D.9090503@labn.net> In-Reply-To: <502D716D.9090503@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.249.119] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19116.000 x-tm-as-result: No--77.115600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 22:24:39 -0000 Hi Lou. Let me go through the references listed below and get back. Thanks, Rakesh -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, August 16, 2012 6:17 PM To: Rakesh Gandhi (rgandhi) Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Rakesh, See below. On 8/16/2012 5:59 PM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, >=20 > Please see inline.... >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 5:42 PM > To: Rakesh Gandhi (rgandhi) > Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn > Subject: Re: [CCAMP] I-D Action:=20 > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >=20 > Rakesh, >=20 > On 8/16/2012 5:26 PM, Rakesh Gandhi (rgandhi) wrote: >> Hi Lou, >> >> Thank you for your comments. >> >> We had several email exchanges on the alias on "signaling of=20 >> co-routed LSPs" before it was added in the draft. >=20 > I presume you're referring to your private e-mail exchange that was forwa= rded to the list, mid-stream, under the subject "Re: [CCAMP] Comments on dr= aft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03". >=20 > I addressed this in > http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html. If you= disagree with that e-mail, please respond to it. >=20 >> >> Regarding A) >> >> I agree with you that GMPLS signaling can be used for co-routed LSPs=20 >> and has many advantages. >> >> Goal of the associated bidirectional LSPs is to tie the two=20 >> independent LSPs together. These two LSPs may be non co-routed or=20 >> co-routed. It is useful for an application to specify the node to=20 >> request both LSPs go on the same path. Do you agree? >=20 > Not sure I understand your question. Per RFC5654 and RFC6373 there is a = stated need for associated and co-routed MPLS TP transport paths. As discu= ssed in RFC6373, RFC3473 already supports co-routed bidirectional LSPs. Th= e draft we're discussing covers associated bidirectional. >=20 > Can you rephrase the issue/function that you believe is not addressed in = current signaling RFCs? >=20 > I understand what you are saying and do not see any issue there. > But I am not looking at it from that view point. Actually, I'm not making any statement on if there's an issue or not. I'm asking you to state the issue or new function that you'd like addressed= by a new mechanism. It's really simple, if there's no issue or need for a= new function, then there's no need to defined a new mechanism. I'm guessing that you see an issue or limitation, and I'd genuinely like to= understand what it is. > All we are saying is > that when bidirectional LSPs are associated via signaling, they could=20 > take the same path and it can be provisioned to do so. Well, this is already stated in RFC5654 (and referenced RFC6373). If that'= s it, we can easily close this topic. Lou >=20 > Thanks, > Rakesh >=20 > Lou >=20 >> >> Thanks, >> Rakesh >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Thursday, August 16, 2012 5:10 PM >> To: Rakesh Gandhi (rgandhi) >> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >> Subject: Re: [CCAMP] I-D Action:=20 >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> Rakesh, >> Such major changes (in scope and functionality) to WG drafts are usuall= y discussed with the WG prior to the authors/editors just publishing the ch= anges. But, this is a judgment call by the document editors in how, quotin= g rfc2418, they "ensur[e] that the contents of the document accurately refl= ect the decisions that have been made by the working group." >> >> So let's jump into discussing the changes. >> >> As I see it this draft introduces several major functional changes that = have not been discussed by the WG. Correct me if I get them wrong, but I b= elieve they include: >> 1) Introduction of a second method for signaling Co-routed LSPs >> 2) Support for FRR bypass tunnels for piggybacked on the TP bidirectiona= l LSP mechanisms. >> >> There are also other changes, but I'll defer discussing them >> until the discussion on the above is concluded. >> >> Is this correct? >> >> Assuming yes, I have questions about both rational and specific mechanis= ms. For now let's look at the former, so please: >> >> A) Articulate the issues/limitations with using the RFC3473 defined mech= anisms for (co-routed) bidirectional LSPs that you'd like to see addressed. >> >> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >> >> B.2) Articulate why this issue should be solved in a TP-specific and not= GMPLS generic fashion? >> >> Thanks, >> Lou >> >> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>> Hi Lou, >>> >>> Yes. >>> >>> Please advise if you think detailed email is required.=20 >>> We believe latest draft summarizes the changes well and we could start = review/discussions from there. >>> >>> Thanks, >>> Rakesh >>> >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Thursday, August 16, 2012 4:00 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>> Subject: Re: [CCAMP] I-D Action:=20 >>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>> >>> Rakesh, >>> Is this the start of the thread that I requested in=20 >>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>> >>> In particular, is it the response to: >>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the=20 >>>> proposed change and the rational for each change (in one or in=20 >>>> separate e-mails). The WG discussion can then really begin on the=20 >>>> proposed changes. (Which are quite substantial both in scope and >>>> implication.) >>> >>> Lou >>> >>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi All, >>>> >>>> We have uploaded a new version of this draft with following changes: >>> =20 >>> 1. Added a section on Signaling of Co-routed LSPs >>> >>> 2. Added clarification on Signaling of Associated Bidirectional=20 >>> Protection LSPs >>> >>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>> >>> 4. Added clarification on Signaling of Inter-domain Associated Bidir= ectional LSPs=20 >>> >>> 5. The Extended ASSOCIATION object format with Association Type "Assoc= iated Bidirectional LSP". Clarified on how to populate different fields in = this object. >>> >>> =20 >>>> We believe that some of these changes were necessary to avoid the inte= roperability issues due to potentially different interpretations. >>>> >>>> Your review comments are welcome. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>>> Behalf Of internet-drafts@ietf.org >>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>> To: i-d-announce@ietf.org >>>> Cc: ccamp@ietf.org >>>> Subject: [CCAMP] I-D Action:=20 >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>> This draft is a work item of the Common Control and Measurement Plane= Working Group of the IETF. >>>> >>>> Title : RSVP-TE Extensions for Associated Bidirectional LSP= s >>>> Author(s) : Fei Zhang >>>> Ruiquan Jing >>>> Rakesh Gandhi >>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-= 04.txt >>>> Pages : 17 >>>> Date : 2012-08-15 >>>> >>>> Abstract: >>>> The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654= ], >>>> describes that MPLS-TP MUST support associated bidirectional point- >>>> to-point LSPs. >>>> >>>> This document provides a method to bind two unidirectional Label >>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>> association is achieved by defining the new Association Type in the >>>> Extended ASSOCIATION object. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ex >>>> t >>>> - >>>> a >>>> ssociated-lsp >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso >>>> c >>>> i >>>> a >>>> ted-lsp-04 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte-ex >>>> t >>>> - >>>> a >>>> ssociated-lsp-04 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> >=20 >=20 >=20 >=20 From internet-drafts@ietf.org Thu Aug 16 16:10:23 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D5321F84C9; Thu, 16 Aug 2012 16:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxR47vlXB05c; Thu, 16 Aug 2012 16:10:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406B121F84B6; Thu, 16 Aug 2012 16:10:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120816231023.23889.76871.idtracker@ietfa.amsl.com> Date: Thu, 16 Aug 2012 16:10:23 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-16.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 23:10:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Routing and Wavelength Assignment Information Model for = Wavelength Switched Optical Networks Author(s) : Young Lee Greg M. Bernstein Dan Li Wataru Imajuku Filename : draft-ietf-ccamp-rwa-info-16.txt Pages : 28 Date : 2012-08-16 Abstract: This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-info There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rwa-info-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Aug 16 16:14:53 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A219011E808A; Thu, 16 Aug 2012 16:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dr0dxFFPmRsw; Thu, 16 Aug 2012 16:14:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327DE21F84FC; Thu, 16 Aug 2012 16:14:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> Date: Thu, 16 Aug 2012 16:14:53 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 23:14:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Routing and Wavelength Assignment Information Encoding f= or Wavelength Switched Optical Networks Author(s) : Greg M. Bernstein Young Lee Dan Li Wataru Imajuku Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt Pages : 33 Date : 2012-08-16 Abstract: A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are fairly specific to WSONs. This document provides efficient, protocol-agnostic encodings for the WSON specific information elements. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rwa-wson-encode-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gregb@grotto-networking.com Thu Aug 16 16:21:49 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D4F21F853F for ; Thu, 16 Aug 2012 16:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTbKzG3qV6B1 for ; Thu, 16 Aug 2012 16:21:46 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7E70D21F853E for ; Thu, 16 Aug 2012 16:21:46 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id 5F1A4212BA57; Thu, 16 Aug 2012 18:21:45 -0500 (CDT) Message-ID: <502D807F.3010604@grotto-networking.com> Date: Thu, 16 Aug 2012 16:21:35 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Ong, Lyndon" References: <50229C0B.5020509@grotto-networking.com> <502C173C.7040700@labn.net> <502D1D7E.1020603@grotto-networking.com> <502D6B60.5070206@grotto-networking.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP , "draft-ietf-ccamp-wson-signaling@tools.ietf.org" Subject: Re: [CCAMP] WSON updates for Optical Interface Classes X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 23:21:49 -0000 Hi Lyndon and CCAMPers, we have updated the drafts with your suggested changes. Please see: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-16 The authors believe that these drafts and the draft http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-10 are now ready for last call. Best Regards Greg On 8/16/2012 3:07 PM, Ong, Lyndon wrote: > Hi Greg, > > Well my two cents would be the following: > > 1) WSON encoding draft, section 5.2: > The Optical Interface Class format is defined within [x-ref-tbd]. > > Propose to remove the sentence as the format is defined within the encoding draft itself. > > 2) WSON information model draft, section 5.3: > Where the term is defined by [xyz?]. > > Propose to replace the sentence with text from draft-martinelli section 3.1 (with some grammatical edits): > The Optical Interface Class is a unique number that identifies all > information related to optical characteristics of a physical > interface. The class may include other optical parameters related > to other interface properties. A class MUST always include signal > compatibility information. > > The content of each class is out of the scope of this draft and can > be defined by other entities (e.g. ITU, optical equipment vendors, > etc.). > > Since even current implementation of physical interfaces may support > different optical characteristics, a single interface may support > multiple interface classes. Which optical interface class is used > among all the ones available for an interface is out of the scope > of this draft but is an output of the RWA process. > > Cheers, > > Lyndon > -----Original Message----- > From: Greg Bernstein [mailto:gregb@grotto-networking.com] > Sent: Thursday, August 16, 2012 2:51 PM > To: Ong, Lyndon > Cc: Lou Berger; CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org > Subject: Re: [CCAMP] WSON updates for Optical Interface Classes > > We implemented the WSON Info changes requested in Giovanni's CCAMP list email dated 07/05/2012. Don't know what those references were referring to. Please review changes to updated WSON info and WSON encoding drafts and send us any deltas. > Best Regards > Greg > On 8/16/2012 9:45 AM, Ong, Lyndon wrote: >> Hi Greg, Lou, >> >> Sorry, a little confused - aren't you defining the OIC format within the wson encoding draft itself? I would think the external references you need are for the ITU-T application codes, rather than the OIC format. Am I missing something? >> >> The ITU-T references would be >> [ITU-G.698.1] ITU-T Recommendation G.698.1, "Multichannel DWDM >> applications with single-channel optical interfaces", November, 2009. >> [ITU-G.698.2] ITU-T Recommendation G.698.2, "Amplified multichannel dense wavelength division multiplexing applications with single channel optical interfaces", November, 2009. >> [ITU-G.959.1] ITU-T Recommendation G.959.1, "Optical transport networks physical layer interfaces", February, 2012. >> >> Cheers, >> >> Lyndon >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Greg Bernstein >> Sent: Thursday, August 16, 2012 9:19 AM >> To: Lou Berger >> Cc: CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org >> Subject: Re: [CCAMP] WSON updates for Optical Interface Classes >> >> Hi Lou, I'll try to update today or tomorrow. On WSON routing, I still haven't heard from the OIC draft authors on resolving the undefined references mentioned below. >> Best Regards >> Greg >> On 8/15/2012 2:40 PM, Lou Berger wrote: >>> Greg/Authors, >>> When do you expect to have a rev of the signaling draft to match the >>> recent updates (including the previous addition of WSON-LSC type)? >>> >>> Thanks, >>> Lou >>> >>> On 8/8/2012 1:04 PM, Greg Bernstein wrote: >>>> Hi CCAMPers, per working group consensus we have updated the >>>> following WSON drafts: >>>> >>>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibilit >>>> y >>>> -ospf-10 >>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-15 >>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-15. >>>> >>>> We have removed "modulation type", "FEC type", and "Bit rate range" and replace with the "Optical Interface Class". >>>> We have applied the changes suggested on the CCAMP list and in the OIC draft. >>>> There are some undefined references that need to be filled in by the authors of the OIC draft. >>>> Please furnish references or suitable text. >>>> Info draft: >>>> ..."Where the term is defined by [xyz]." >>>> >>>> Encoding draft: >>>> ..."The Optical Interface Class format is defined within [x-ref-tbd]." >>>> >>>> See updated drafts for further context. Also if an encoding example >>>> is desired for appendix A of the encoding draft please furnish. >>>> >>>> To ease and expedite further changes on the OIC issue MS Word >>>> versions of these documents can be found at: >>>> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccam >>>> p -wson-signal-compatibility-ospf-10a.docx >>>> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccam >>>> p >>>> -rwa-wson-encode-15a.docx >>>> http://www.grotto-networking.com/sites/default/files/draft-ietf-ccam >>>> p >>>> -rwa-info-15a.docx >>>> >>>> Best Regards >>>> Greg B. >>>> >>>> >>>> >> -- >> =================================================== >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From zhang.fei3@zte.com.cn Thu Aug 16 17:56:09 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D8821F8526; Thu, 16 Aug 2012 17:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.148 X-Spam-Level: X-Spam-Status: No, score=-97.148 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOmoKjsy2w9C; Thu, 16 Aug 2012 17:56:08 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6706521F84F3; Thu, 16 Aug 2012 17:56:06 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 107231461793122; Fri, 17 Aug 2012 08:42:09 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 38775.3183536426; Fri, 17 Aug 2012 08:56:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7H0tsK5038416; Fri, 17 Aug 2012 08:55:54 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <502D6F4D.7020707@labn.net> To: Lou Berger , John E Drake MIME-Version: 1.0 X-KeepSent: 58C24C71:A27369FB-48257A5D:0003FE09; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 17 Aug 2012 08:55:47 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-17 08:55:34, Serialize complete at 2012-08-17 08:55:34 Content-Type: multipart/alternative; boundary="=_alternative 00050D2F48257A5D_=" X-MAIL: mse02.zte.com.cn q7H0tsK5038416 Cc: "ccamp@ietf.org" , ccamp-bounces@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 00:56:09 -0000 This is a multipart message in MIME format. --=_alternative 00050D2F48257A5D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTG91LCBKb2huDQoNCkFzIGFuIGVkaXRvciBvZiB0aGlzIGRyYWZ0LCBiZSBhcG9sb2dpemVk IHRoYXQgSSBhbSBub3QgZmFtaWxhciB3aXRoIHRoZSANCldHIGNvbnNlbnN1cyBwcm9jZWR1cmVz IGFuZCBldmVuIGRvIG5vdCByZWFkIFJGQzI0MTguIEl0IGlzIG15IGZhdWx0IGFuZCANCndpbGwg bm90IGhhcHBlbiBhZ2Fpbi4NCg0KQmVzdCByZWdhcmRzDQoNCkZlaQ0KDQoNCg0KTG91IEJlcmdl ciA8bGJlcmdlckBsYWJuLm5ldD4gDQq3orz+yMs6ICBjY2FtcC1ib3VuY2VzQGlldGYub3JnDQoy MDEyLTA4LTE3IDA2OjA4DQoNCsrVvP7Iyw0KSm9obiBFIERyYWtlIDxqZHJha2VAanVuaXBlci5u ZXQ+DQqzrcvNDQoiY2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4NCtb3zOINClJlOiBb Q0NBTVBdICAgICBJLUQgICAgIEFjdGlvbjogDQpkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2 cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCg0KDQoNCg0KDQoNCkpvaG4sDQogICAgICAg ICAgICAgICAgIFdoaWxlIHN0cmljdGx5IHNwZWFraW5nIFdHIGRyYWZ0cyBzaG91bGQgb25seSBy ZWZsZWN0IA0KY3VycmVudCBXRw0KY29uc2Vuc3VzLCBhbmQgaXQgaXMgdGhlIFdHIGRyYWZ0IGVk aXRvcidzIGpvYiB0byBlbnN1cmUgdGhpcywgaW4NCnByYWN0aWNlIGF1dGhvcnMvZWRpdG9ycyBh cmUgZ2l2ZW4gYSBsb3Qgb2YgbGF0aXR1ZGUgaW4gdGltaW5nIC8NCm9yZGVyaW5nIGluIGludHJv ZHVjdGlvbiB0byBjaGFuZ2VzLiAgSSBwZXJzb25hbGx5IHRoaW5rIHRoaXMgaXMgYQ0KcHJhY3Rp Y2FsIHdheSBvZiBrZWVwaW5nIHRoZSBwcm9jZXNzIG1vdmluZy4gIEFsc28gaWYgdGhlIFdHIGRp c2FncmVlcw0Kd2l0aCBhIGNoYW5nZSwgaXQgY2FuIGFsd2F5cyBiZSBiYWNrZWQgb3V0Lg0KDQpT bywgeWVzLCB0aGUgV0cgY291bGQgZG8gZXhhY3RseSBhcyB5b3Ugc2F5IGlmIGl0IGNvbWVzIHRv IGl0LiAgKFRoZQ0KY2hhaXJzIGNhbiBldmVuIGFwcG9pbnQgZGlmZmVyZW50IGVkaXRvciBpZiBu ZWVkZWQsIGUuZy4sIHRvIG1ha2UgdGhpcw0KaGFwcGVuLikgIFdoaWxlIEknbSBub3QgaGFwcHkg d2l0aCBob3cgdGhpcyByZXZpc2lvbiBjYW1lIGFib3V0LCBhcyBJDQpjb3ZlcmVkIGluIGVhcmxp ZXIgbWFpbCwgbXkgZmVlbGluZyBpcyB0byBsZXQgdGhlIGRpc2N1c3Npb24gdGFrZSBwbGFjZQ0K b24gdGhlIGxpc3QgKGFuZCBhdCB0aGUgbmV4dCBJRVRGLCBpZiBuZWVkZWQpIGFuZCB0aGVuIGhh dmUgdGhlIGRyYWZ0DQp1cGRhdGVkIHRvIHJlZmxlY3QgdGhlIFdHIGRpc2N1c3Npb24vY29uc2Vu c3VzLg0KDQpMb3UNCg0KT24gOC8xNi8yMDEyIDU6MzUgUE0sIEpvaG4gRSBEcmFrZSB3cm90ZToN Cj4gTG91LA0KPiANCj4gU2luY2UgdGhlIFdHIGRpZCBub3QgYWdyZWUgdG8gdGhpcyBjaGFuZ2Vz LCBsZXQgYWxvbmUgZGlzY3VzcyB0aGVtLA0KPiB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBzaW1w bHkgcm9sbGJhY2sgdGhlc2UgY2hhbmdlcyBhbmQgYXNrIHRoZQ0KPiBhdXRob3JzIHRvIHdyaXRl IGEgZHJhZnQgYWRkcmVzc2luZyB0aGUgdG9waWNzIHlvdSBsaXN0IGluIHlvdXINCj4gZW1haWws IGJlbG93Pw0KPiANCj4gVGhhbmtzLA0KPiANCj4gSm9obiANCj4gDQo+IFNlbnQgZnJvbSBteSBp UGhvbmUNCj4gDQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGNj YW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYNCj4+IE9mIExvdSBCZXJnZXINCj4+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTYsIDIw MTIgMjoxMCBQTQ0KPj4gVG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo+PiBDYzogY2NhbXBA aWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt Y2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LQ0KPj4gYXNzb2NpYXRlZC1sc3AtMDQudHh0DQo+Pg0K Pj4gUmFrZXNoLA0KPj4gICAgICAgICAgICAgICBTdWNoIG1ham9yIGNoYW5nZXMgKGluIHNjb3Bl IGFuZCBmdW5jdGlvbmFsaXR5KSB0byBXRyANCmRyYWZ0cyBhcmUNCj4+IHVzdWFsbHkgZGlzY3Vz c2VkIHdpdGggdGhlIFdHIHByaW9yIHRvIHRoZSBhdXRob3JzL2VkaXRvcnMganVzdA0KPj4gcHVi bGlzaGluZyB0aGUgY2hhbmdlcy4gIEJ1dCwgdGhpcyBpcyBhIGp1ZGdtZW50IGNhbGwgYnkgdGhl IGRvY3VtZW50DQo+PiBlZGl0b3JzIGluIGhvdywgcXVvdGluZyByZmMyNDE4LCB0aGV5ICJlbnN1 cltlXSB0aGF0IHRoZSBjb250ZW50cyBvZg0KPj4gdGhlIGRvY3VtZW50IGFjY3VyYXRlbHkgcmVm bGVjdCB0aGUgZGVjaXNpb25zIHRoYXQgaGF2ZSBiZWVuIG1hZGUgYnkNCj4+IHRoZSB3b3JraW5n IGdyb3VwLiINCj4+DQo+PiBTbyBsZXQncyBqdW1wIGludG8gZGlzY3Vzc2luZyB0aGUgY2hhbmdl cy4NCj4+DQo+PiBBcyBJIHNlZSBpdCB0aGlzIGRyYWZ0IGludHJvZHVjZXMgc2V2ZXJhbCBtYWpv ciBmdW5jdGlvbmFsIGNoYW5nZXMgdGhhdA0KPj4gaGF2ZSBub3QgYmVlbiBkaXNjdXNzZWQgYnkg dGhlIFdHLiAgQ29ycmVjdCBtZSBpZiBJIGdldCB0aGVtIHdyb25nLCBidXQNCj4+IEkgYmVsaWV2 ZSB0aGV5IGluY2x1ZGU6DQo+PiAxKSBJbnRyb2R1Y3Rpb24gb2YgYSBzZWNvbmQgbWV0aG9kIGZv ciBzaWduYWxpbmcgQ28tcm91dGVkIExTUHMNCj4+IDIpIFN1cHBvcnQgZm9yIEZSUiBieXBhc3Mg dHVubmVscyBmb3IgcGlnZ3liYWNrZWQgb24gdGhlIFRQDQo+PiBiaWRpcmVjdGlvbmFsIExTUCBt ZWNoYW5pc21zLg0KPj4NCj4+ICAgIFRoZXJlIGFyZSBhbHNvIG90aGVyIGNoYW5nZXMsIGJ1dCBJ J2xsIGRlZmVyIGRpc2N1c3NpbmcgdGhlbQ0KPj4gICAgdW50aWwgdGhlIGRpc2N1c3Npb24gb24g dGhlIGFib3ZlIGlzIGNvbmNsdWRlZC4NCj4+DQo+PiBJcyB0aGlzIGNvcnJlY3Q/DQo+Pg0KPj4g QXNzdW1pbmcgeWVzLCBJIGhhdmUgcXVlc3Rpb25zIGFib3V0IGJvdGggcmF0aW9uYWwgYW5kIHNw ZWNpZmljDQo+PiBtZWNoYW5pc21zLiAgRm9yIG5vdyBsZXQncyBsb29rIGF0IHRoZSBmb3JtZXIs IHNvIHBsZWFzZToNCj4+DQo+PiBBKSBBcnRpY3VsYXRlIHRoZSBpc3N1ZXMvbGltaXRhdGlvbnMg d2l0aCB1c2luZyB0aGUgUkZDMzQ3MyBkZWZpbmVkDQo+PiBtZWNoYW5pc21zIGZvciAoY28tcm91 dGVkKSBiaWRpcmVjdGlvbmFsIExTUHMgdGhhdCB5b3UnZCBsaWtlIHRvIHNlZQ0KPj4gYWRkcmVz c2VkLg0KPj4NCj4+IEIuMSkgQXJ0aWN1bGF0ZSB0aGUgRlJSL0dNUExTLXJlbGF0ZWQgaXNzdWUg eW91J2QgbGlrZSB0byBhZGRyZXNzPw0KPj4NCj4+IEIuMikgQXJ0aWN1bGF0ZSB3aHkgdGhpcyBp c3N1ZSBzaG91bGQgYmUgc29sdmVkIGluIGEgVFAtc3BlY2lmaWMgYW5kDQo+PiBub3QgR01QTFMg Z2VuZXJpYyBmYXNoaW9uPw0KPj4NCj4+IFRoYW5rcywNCj4+IExvdQ0KPj4NCj4+IE9uIDgvMTYv MjAxMiA0OjI2IFBNLCBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSB3cm90ZToNCj4+PiBIaSBMb3Us DQo+Pj4NCj4+PiBZZXMuDQo+Pj4NCj4+PiBQbGVhc2UgYWR2aXNlIGlmIHlvdSB0aGluayBkZXRh aWxlZCBlbWFpbCBpcyByZXF1aXJlZC4NCj4+PiBXZSBiZWxpZXZlIGxhdGVzdCBkcmFmdCBzdW1t YXJpemVzIHRoZSBjaGFuZ2VzIHdlbGwgYW5kIHdlIGNvdWxkDQo+PiBzdGFydCByZXZpZXcvZGlz Y3Vzc2lvbnMgZnJvbSB0aGVyZS4NCj4+Pg0KPj4+IFRoYW5rcywNCj4+PiBSYWtlc2gNCj4+Pg0K Pj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBMb3UgQmVyZ2Vy IFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCj4+PiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDE2 LCAyMDEyIDQ6MDAgUE0NCj4+PiBUbzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCj4+PiBDYzog Y2NhbXBAaWV0Zi5vcmc7IHpoYW5nLmZlaTNAenRlLmNvbS5jbg0KPj4+IFN1YmplY3Q6IFJlOiBb Q0NBTVBdIEktRCBBY3Rpb246DQo+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1l eHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQo+Pj4NCj4+PiBSYWtlc2gsDQo+Pj4gICAgICAgICAg ICAgIElzIHRoaXMgdGhlIHN0YXJ0IG9mIHRoZSB0aHJlYWQgdGhhdCBJIHJlcXVlc3RlZCBpbg0K Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9jY2FtcC9jdXJyZW50L21z ZzEzNzI5Lmh0bWwNCj4+Pg0KPj4+IEluIHBhcnRpY3VsYXIsIGlzIGl0IHRoZSByZXNwb25zZSB0 bzoNCj4+Pj4gSSdkIGxpa2UgdG8gYXNrIHRoYXQgc29tZW9uZSAoUmFrZXNoLCBGZWksIGV0Yy4p IHJldmlldyBlYWNoIG9mIHRoZQ0KPj4+PiBwcm9wb3NlZCBjaGFuZ2UgYW5kIHRoZSByYXRpb25h bCBmb3IgZWFjaCBjaGFuZ2UgKGluIG9uZSBvciBpbg0KPj4+PiBzZXBhcmF0ZSBlLW1haWxzKS4g VGhlIFdHIGRpc2N1c3Npb24gY2FuIHRoZW4gcmVhbGx5IGJlZ2luIG9uIHRoZQ0KPj4+PiBwcm9w b3NlZCBjaGFuZ2VzLiAoV2hpY2ggYXJlIHF1aXRlIHN1YnN0YW50aWFsIGJvdGggaW4gc2NvcGUg YW5kDQo+Pj4+IGltcGxpY2F0aW9uLikNCj4+Pg0KPj4+IExvdQ0KPj4+DQo+Pj4gT24gOC8xNi8y MDEyIDM6MTkgUE0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIHdyb3RlOg0KPj4+PiBIaSBBbGws DQo+Pj4+DQo+Pj4+IFdlIGhhdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0 IHdpdGggZm9sbG93aW5nIGNoYW5nZXM6DQo+Pj4NCj4+PiAxLiAgQWRkZWQgYSBzZWN0aW9uIG9u IFNpZ25hbGluZyBvZiBDby1yb3V0ZWQgTFNQcw0KPj4+DQo+Pj4gMi4gIEFkZGVkIGNsYXJpZmlj YXRpb24gb24gU2lnbmFsaW5nIG9mIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbA0KPj4+IFByb3Rl Y3Rpb24gTFNQcw0KPj4+DQo+Pj4gMy4gIEFkZGVkIGEgc2VjdGlvbiBvbiBTaWduYWxpbmcgb2Yg QXV0by10dW5uZWwgTWVzaC1ncm91cCBMU1BzDQo+Pj4NCj4+PiA0LiAgIEFkZGVkIGNsYXJpZmlj YXRpb24gb24gU2lnbmFsaW5nIG9mIEludGVyLWRvbWFpbiBBc3NvY2lhdGVkDQo+PiBCaWRpcmVj dGlvbmFsIExTUHMNCj4+Pg0KPj4+IDUuICBUaGUgRXh0ZW5kZWQgQVNTT0NJQVRJT04gb2JqZWN0 IGZvcm1hdCB3aXRoIEFzc29jaWF0aW9uIFR5cGUNCj4+ICJBc3NvY2lhdGVkIEJpZGlyZWN0aW9u YWwgTFNQIi4gQ2xhcmlmaWVkIG9uIGhvdyB0byBwb3B1bGF0ZSBkaWZmZXJlbnQNCj4+IGZpZWxk cyBpbiB0aGlzIG9iamVjdC4NCj4+Pg0KPj4+DQo+Pj4+IFdlIGJlbGlldmUgdGhhdCBzb21lIG9m IHRoZXNlIGNoYW5nZXMgd2VyZSBuZWNlc3NhcnkgdG8gYXZvaWQgdGhlDQo+PiBpbnRlcm9wZXJh YmlsaXR5IGlzc3VlcyBkdWUgdG8gcG90ZW50aWFsbHkgZGlmZmVyZW50IGludGVycHJldGF0aW9u cy4NCj4+Pj4NCj4+Pj4gWW91ciByZXZpZXcgY29tbWVudHMgYXJlIHdlbGNvbWUuDQo+Pj4+DQo+ Pj4+IFRoYW5rcywNCj4+Pj4gUmFrZXNoDQo+Pj4+DQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1i b3VuY2VzQGlldGYub3JnXSBPbg0KPj4+PiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnDQo+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE1LCAyMDEyIDEwOjUzIEFNDQo+Pj4+ IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+Pj4gQ2M6IGNjYW1wQGlldGYub3JnDQo+Pj4+ IFN1YmplY3Q6IFtDQ0FNUF0gSS1EIEFjdGlvbjoNCj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxz LXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQo+Pj4+DQo+Pj4+DQo+Pj4+IEEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cw0KPj4gZGlyZWN0b3JpZXMuDQo+Pj4+ICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVt IG9mIHRoZSBDb21tb24gQ29udHJvbCBhbmQgTWVhc3VyZW1lbnQNCj4+IFBsYW5lIFdvcmtpbmcg R3JvdXAgb2YgdGhlIElFVEYuDQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgIFRpdGxlICAgICAgICAg ICA6IFJTVlAtVEUgRXh0ZW5zaW9ucyBmb3IgQXNzb2NpYXRlZCANCkJpZGlyZWN0aW9uYWwNCj4+ IExTUHMNCj4+Pj4gICAgICAgICAgICAgQXV0aG9yKHMpICAgICAgIDogRmVpIFpoYW5nDQo+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgUnVpcXVhbiBKaW5nDQo+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgUmFrZXNoIEdhbmRoaQ0KPj4+PiAgICAgICAgICAgICBGaWxlbmFtZSAg ICAgICAgOiANCmRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQt DQo+PiBsc3AtMDQudHh0DQo+Pj4+ICAgICAgICAgICAgIFBhZ2VzICAgICAgICAgICA6IDE3DQo+ Pj4+ICAgICAgICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTItMDgtMTUNCj4+Pj4NCj4+Pj4g QWJzdHJhY3Q6DQo+Pj4+ICAgIFRoZSBNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBy ZXF1aXJlbWVudHMgZG9jdW1lbnQNCj4+IFtSRkM1NjU0XSwNCj4+Pj4gICAgZGVzY3JpYmVzIHRo YXQgTVBMUy1UUCBNVVNUIHN1cHBvcnQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQo+PiBwb2lu dC0NCj4+Pj4gICAgdG8tcG9pbnQgTFNQcy4NCj4+Pj4NCj4+Pj4gICAgVGhpcyBkb2N1bWVudCBw cm92aWRlcyBhIG1ldGhvZCB0byBiaW5kIHR3byB1bmlkaXJlY3Rpb25hbCBMYWJlbA0KPj4+PiAg ICBTd2l0Y2hlZCBQYXRocyAoTFNQcykgaW50byBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwg TFNQLiAgVGhlDQo+Pj4+ICAgIGFzc29jaWF0aW9uIGlzIGFjaGlldmVkIGJ5IGRlZmluaW5nIHRo ZSBuZXcgQXNzb2NpYXRpb24gVHlwZSBpbg0KPj4gdGhlDQo+Pj4+ICAgIEV4dGVuZGVkIEFTU09D SUFUSU9OIG9iamVjdC4NCj4+Pj4NCj4+Pj4NCj4+Pj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtDQo+PiBleHQtDQo+Pj4+ IGENCj4+Pj4gc3NvY2lhdGVkLWxzcA0KPj4+Pg0KPj4+PiBUaGVyZSdzIGFsc28gYSBodG1saXpl ZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtDQo+PiBhc3NvY2kNCj4+Pj4gYQ0K Pj4+PiB0ZWQtbHNwLTA0DQo+Pj4+DQo+Pj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS0NCj4+IGV4dC0NCj4+Pj4gYQ0KPj4+ PiBzc29jaWF0ZWQtbHNwLTA0DQo+Pj4+DQo+Pj4+DQo+Pj4+IEludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+Pj4gZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+Pj4+IEND QU1QQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2NhbXANCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IENDQU1QIG1h aWxpbmcgbGlzdA0KPj4gQ0NBTVBAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2NhbXANCj4gDQo+IA0KPiANCj4gDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQoN Cg0K --=_alternative 00050D2F48257A5D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIExvdSwgSm9objwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgYW4gZWRpdG9yIG9m IHRoaXMgZHJhZnQsIGJlIGFwb2xvZ2l6ZWQNCnRoYXQgSSBhbSBub3QgZmFtaWxhciB3aXRoIHRo ZSBXRyBjb25zZW5zdXMgcHJvY2VkdXJlcyBhbmQgZXZlbiBkbyBub3QNCnJlYWQgUkZDMjQxOC4g SXQgaXMgbXkgZmF1bHQgYW5kIHdpbGwgbm90IGhhcHBlbiBhZ2Fpbi48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJlc3QgcmVnYXJkczwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RmVpPC9mb250Pg0KPGJyPg0K PGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0 aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkxvdSBCZXJnZXIgJmx0O2xi ZXJnZXJAbGFibi5uZXQmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wOC0xNyAwNjowODwvZm9udD4N Cjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5Kb2huIEUg RHJha2UgJmx0O2pkcmFrZUBqdW5pcGVyLm5ldCZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOt y808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90 O2NjYW1wQGlldGYub3JnJnF1b3Q7ICZsdDtjY2FtcEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPlJlOiBbQ0NBTVBdICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ktRA0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7QWN0aW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtk cmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQ8 L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRk PjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PkpvaG4sPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCldoaWxlIHN0cmljdGx5IHNwZWFraW5nIFdHIGRyYWZ0cyBzaG91bGQgb25s eSByZWZsZWN0IGN1cnJlbnQgV0c8YnI+DQpjb25zZW5zdXMsIGFuZCBpdCBpcyB0aGUgV0cgZHJh ZnQgZWRpdG9yJ3Mgam9iIHRvIGVuc3VyZSB0aGlzLCBpbjxicj4NCnByYWN0aWNlIGF1dGhvcnMv ZWRpdG9ycyBhcmUgZ2l2ZW4gYSBsb3Qgb2YgbGF0aXR1ZGUgaW4gdGltaW5nIC88YnI+DQpvcmRl cmluZyBpbiBpbnRyb2R1Y3Rpb24gdG8gY2hhbmdlcy4gJm5ic3A7SSBwZXJzb25hbGx5IHRoaW5r IHRoaXMgaXMgYTxicj4NCnByYWN0aWNhbCB3YXkgb2Yga2VlcGluZyB0aGUgcHJvY2VzcyBtb3Zp bmcuICZuYnNwO0Fsc28gaWYgdGhlIFdHIGRpc2FncmVlczxicj4NCndpdGggYSBjaGFuZ2UsIGl0 IGNhbiBhbHdheXMgYmUgYmFja2VkIG91dC48YnI+DQo8YnI+DQpTbywgeWVzLCB0aGUgV0cgY291 bGQgZG8gZXhhY3RseSBhcyB5b3Ugc2F5IGlmIGl0IGNvbWVzIHRvIGl0LiAmbmJzcDsoVGhlPGJy Pg0KY2hhaXJzIGNhbiBldmVuIGFwcG9pbnQgZGlmZmVyZW50IGVkaXRvciBpZiBuZWVkZWQsIGUu Zy4sIHRvIG1ha2UgdGhpczxicj4NCmhhcHBlbi4pICZuYnNwO1doaWxlIEknbSBub3QgaGFwcHkg d2l0aCBob3cgdGhpcyByZXZpc2lvbiBjYW1lIGFib3V0LCBhcw0KSTxicj4NCmNvdmVyZWQgaW4g ZWFybGllciBtYWlsLCBteSBmZWVsaW5nIGlzIHRvIGxldCB0aGUgZGlzY3Vzc2lvbiB0YWtlIHBs YWNlPGJyPg0Kb24gdGhlIGxpc3QgKGFuZCBhdCB0aGUgbmV4dCBJRVRGLCBpZiBuZWVkZWQpIGFu ZCB0aGVuIGhhdmUgdGhlIGRyYWZ0PGJyPg0KdXBkYXRlZCB0byByZWZsZWN0IHRoZSBXRyBkaXNj dXNzaW9uL2NvbnNlbnN1cy48YnI+DQo8YnI+DQpMb3U8YnI+DQo8YnI+DQpPbiA4LzE2LzIwMTIg NTozNSBQTSwgSm9obiBFIERyYWtlIHdyb3RlOjxicj4NCiZndDsgTG91LDxicj4NCiZndDsgPGJy Pg0KJmd0OyBTaW5jZSB0aGUgV0cgZGlkIG5vdCBhZ3JlZSB0byB0aGlzIGNoYW5nZXMsIGxldCBh bG9uZSBkaXNjdXNzIHRoZW0sPGJyPg0KJmd0OyB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBzaW1w bHkgcm9sbGJhY2sgdGhlc2UgY2hhbmdlcyBhbmQgYXNrIHRoZTxicj4NCiZndDsgYXV0aG9ycyB0 byB3cml0ZSBhIGRyYWZ0IGFkZHJlc3NpbmcgdGhlIHRvcGljcyB5b3UgbGlzdCBpbiB5b3VyPGJy Pg0KJmd0OyBlbWFpbCwgYmVsb3c/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQom Z3Q7IDxicj4NCiZndDsgSm9obiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgU2VudCBmcm9tIG15IGlQ aG9uZTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbg0KQmVoYWxmPGJyPg0KJmd0OyZndDsgT2Yg TG91IEJlcmdlcjxicj4NCiZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTYsIDIwMTIg MjoxMCBQTTxicj4NCiZndDsmZ3Q7IFRvOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKTxicj4NCiZn dDsmZ3Q7IENjOiBjY2FtcEBpZXRmLm9yZzxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbQ0NB TVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LTxicj4N CiZndDsmZ3Q7IGFzc29jaWF0ZWQtbHNwLTA0LnR4dDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgUmFrZXNoLDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO1N1Y2ggbWFqb3IgY2hhbmdlcyAoaW4gc2Nv cGUgYW5kIGZ1bmN0aW9uYWxpdHkpIHRvIFdHIGRyYWZ0cw0KYXJlPGJyPg0KJmd0OyZndDsgdXN1 YWxseSBkaXNjdXNzZWQgd2l0aCB0aGUgV0cgcHJpb3IgdG8gdGhlIGF1dGhvcnMvZWRpdG9ycyBq dXN0PGJyPg0KJmd0OyZndDsgcHVibGlzaGluZyB0aGUgY2hhbmdlcy4gJm5ic3A7QnV0LCB0aGlz IGlzIGEganVkZ21lbnQgY2FsbCBieQ0KdGhlIGRvY3VtZW50PGJyPg0KJmd0OyZndDsgZWRpdG9y cyBpbiBob3csIHF1b3RpbmcgcmZjMjQxOCwgdGhleSAmcXVvdDtlbnN1cltlXSB0aGF0IHRoZQ0K Y29udGVudHMgb2Y8YnI+DQomZ3Q7Jmd0OyB0aGUgZG9jdW1lbnQgYWNjdXJhdGVseSByZWZsZWN0 IHRoZSBkZWNpc2lvbnMgdGhhdCBoYXZlIGJlZW4gbWFkZQ0KYnk8YnI+DQomZ3Q7Jmd0OyB0aGUg d29ya2luZyBncm91cC4mcXVvdDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFNvIGxldCdz IGp1bXAgaW50byBkaXNjdXNzaW5nIHRoZSBjaGFuZ2VzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgQXMgSSBzZWUgaXQgdGhpcyBkcmFmdCBpbnRyb2R1Y2VzIHNldmVyYWwgbWFqb3IgZnVu Y3Rpb25hbCBjaGFuZ2VzDQp0aGF0PGJyPg0KJmd0OyZndDsgaGF2ZSBub3QgYmVlbiBkaXNjdXNz ZWQgYnkgdGhlIFdHLiAmbmJzcDtDb3JyZWN0IG1lIGlmIEkgZ2V0IHRoZW0NCndyb25nLCBidXQ8 YnI+DQomZ3Q7Jmd0OyBJIGJlbGlldmUgdGhleSBpbmNsdWRlOjxicj4NCiZndDsmZ3Q7IDEpIElu dHJvZHVjdGlvbiBvZiBhIHNlY29uZCBtZXRob2QgZm9yIHNpZ25hbGluZyBDby1yb3V0ZWQgTFNQ czxicj4NCiZndDsmZ3Q7IDIpIFN1cHBvcnQgZm9yIEZSUiBieXBhc3MgdHVubmVscyBmb3IgcGln Z3liYWNrZWQgb24gdGhlIFRQPGJyPg0KJmd0OyZndDsgYmlkaXJlY3Rpb25hbCBMU1AgbWVjaGFu aXNtcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtUaGVyZSBhcmUg YWxzbyBvdGhlciBjaGFuZ2VzLCBidXQgSSdsbCBkZWZlciBkaXNjdXNzaW5nDQp0aGVtPGJyPg0K Jmd0OyZndDsgJm5ic3A7ICZuYnNwO3VudGlsIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBhYm92ZSBp cyBjb25jbHVkZWQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJcyB0aGlzIGNvcnJlY3Q/ PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBc3N1bWluZyB5ZXMsIEkgaGF2ZSBxdWVzdGlv bnMgYWJvdXQgYm90aCByYXRpb25hbCBhbmQgc3BlY2lmaWM8YnI+DQomZ3Q7Jmd0OyBtZWNoYW5p c21zLiAmbmJzcDtGb3Igbm93IGxldCdzIGxvb2sgYXQgdGhlIGZvcm1lciwgc28gcGxlYXNlOjxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQSkgQXJ0aWN1bGF0ZSB0aGUgaXNzdWVzL2xpbWl0 YXRpb25zIHdpdGggdXNpbmcgdGhlIFJGQzM0NzMgZGVmaW5lZDxicj4NCiZndDsmZ3Q7IG1lY2hh bmlzbXMgZm9yIChjby1yb3V0ZWQpIGJpZGlyZWN0aW9uYWwgTFNQcyB0aGF0IHlvdSdkIGxpa2UN CnRvIHNlZTxicj4NCiZndDsmZ3Q7IGFkZHJlc3NlZC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IEIuMSkgQXJ0aWN1bGF0ZSB0aGUgRlJSL0dNUExTLXJlbGF0ZWQgaXNzdWUgeW91J2QgbGlr ZSB0byBhZGRyZXNzPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQi4yKSBBcnRpY3VsYXRl IHdoeSB0aGlzIGlzc3VlIHNob3VsZCBiZSBzb2x2ZWQgaW4gYSBUUC1zcGVjaWZpYw0KYW5kPGJy Pg0KJmd0OyZndDsgbm90IEdNUExTIGdlbmVyaWMgZmFzaGlvbj88YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyBMb3U8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IE9uIDgvMTYvMjAxMiA0OjI2IFBNLCBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSB3cm90 ZTo8YnI+DQomZ3Q7Jmd0OyZndDsgSGkgTG91LDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyBZZXMuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFBsZWFzZSBh ZHZpc2UgaWYgeW91IHRoaW5rIGRldGFpbGVkIGVtYWlsIGlzIHJlcXVpcmVkLjxicj4NCiZndDsm Z3Q7Jmd0OyBXZSBiZWxpZXZlIGxhdGVzdCBkcmFmdCBzdW1tYXJpemVzIHRoZSBjaGFuZ2VzIHdl bGwgYW5kIHdlDQpjb3VsZDxicj4NCiZndDsmZ3Q7IHN0YXJ0IHJldmlldy9kaXNjdXNzaW9ucyBm cm9tIHRoZXJlLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGFua3MsPGJy Pg0KJmd0OyZndDsmZ3Q7IFJha2VzaDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsm Z3Q7Jmd0OyBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF08YnI+DQom Z3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxNiwgMjAxMiA0OjAwIFBNPGJyPg0K Jmd0OyZndDsmZ3Q7IFRvOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKTxicj4NCiZndDsmZ3Q7Jmd0 OyBDYzogY2NhbXBAaWV0Zi5vcmc7IHpoYW5nLmZlaTNAenRlLmNvbS5jbjxicj4NCiZndDsmZ3Q7 Jmd0OyBTdWJqZWN0OiBSZTogW0NDQU1QXSBJLUQgQWN0aW9uOjxicj4NCiZndDsmZ3Q7Jmd0OyBk cmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQ8 YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgUmFrZXNoLDxicj4NCiZndDsmZ3Q7 Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDtJcyB0aGlzIHRoZSBzdGFydCBvZiB0aGUgdGhyZWFkIHRoYXQgSSByZXF1ZXN0 ZWQgaW48YnI+DQomZ3Q7Jmd0OyZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2NjYW1wL2N1cnJlbnQvbXNnMTM3MjkuaHRtbDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyBJbiBwYXJ0aWN1bGFyLCBpcyBpdCB0aGUgcmVzcG9uc2UgdG86PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyBJJ2QgbGlrZSB0byBhc2sgdGhhdCBzb21lb25lIChSYWtlc2gsIEZlaSwg ZXRjLikgcmV2aWV3DQplYWNoIG9mIHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgcHJvcG9zZWQg Y2hhbmdlIGFuZCB0aGUgcmF0aW9uYWwgZm9yIGVhY2ggY2hhbmdlIChpbiBvbmUNCm9yIGluPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBzZXBhcmF0ZSBlLW1haWxzKS4gVGhlIFdHIGRpc2N1c3Npb24g Y2FuIHRoZW4gcmVhbGx5IGJlZ2luDQpvbiB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHByb3Bv c2VkIGNoYW5nZXMuIChXaGljaCBhcmUgcXVpdGUgc3Vic3RhbnRpYWwgYm90aCBpbg0Kc2NvcGUg YW5kPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBpbXBsaWNhdGlvbi4pPGJyPg0KJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7IExvdTxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyBPbiA4LzE2LzIwMTIgMzoxOSBQTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBIaSBBbGwsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgV2UgaGF2ZSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoaXMgZHJh ZnQgd2l0aCBmb2xsb3dpbmcNCmNoYW5nZXM6PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7IDEuICZuYnNwO0FkZGVkIGEgc2VjdGlvbiBvbiBTaWduYWxpbmcgb2YgQ28tcm91dGVk IExTUHM8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgMi4gJm5ic3A7QWRkZWQg Y2xhcmlmaWNhdGlvbiBvbiBTaWduYWxpbmcgb2YgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsPGJy Pg0KJmd0OyZndDsmZ3Q7IFByb3RlY3Rpb24gTFNQczxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyAzLiAmbmJzcDtBZGRlZCBhIHNlY3Rpb24gb24gU2lnbmFsaW5nIG9mIEF1dG8t dHVubmVsIE1lc2gtZ3JvdXANCkxTUHM8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsgNC4gJm5ic3A7IEFkZGVkIGNsYXJpZmljYXRpb24gb24gU2lnbmFsaW5nIG9mIEludGVyLWRv bWFpbg0KQXNzb2NpYXRlZDxicj4NCiZndDsmZ3Q7IEJpZGlyZWN0aW9uYWwgTFNQczxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyA1LiAmbmJzcDtUaGUgRXh0ZW5kZWQgQVNTT0NJ QVRJT04gb2JqZWN0IGZvcm1hdCB3aXRoIEFzc29jaWF0aW9uDQpUeXBlPGJyPg0KJmd0OyZndDsg JnF1b3Q7QXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUCZxdW90Oy4gQ2xhcmlmaWVkIG9uIGhv dyB0bw0KcG9wdWxhdGUgZGlmZmVyZW50PGJyPg0KJmd0OyZndDsgZmllbGRzIGluIHRoaXMgb2Jq ZWN0Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsgV2UgYmVsaWV2ZSB0aGF0IHNvbWUgb2YgdGhlc2UgY2hhbmdlcyB3ZXJlIG5lY2Vzc2Fy eSB0bw0KYXZvaWQgdGhlPGJyPg0KJmd0OyZndDsgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMgZHVl IHRvIHBvdGVudGlhbGx5IGRpZmZlcmVudCBpbnRlcnByZXRhdGlvbnMuPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgWW91ciByZXZpZXcgY29tbWVudHMgYXJlIHdl bGNvbWUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtz LDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgUmFrZXNoPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3Vu Y2VzQGlldGYub3JnXQ0KT248YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEJlaGFsZiBPZiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwg QXVndXN0IDE1LCAyMDEyIDEwOjUzIEFNPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBUbzogaS1kLWFu bm91bmNlQGlldGYub3JnPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBDYzogY2NhbXBAaWV0Zi5vcmc8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFtDQ0FNUF0gSS1EIEFjdGlvbjo8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29j aWF0ZWQtbHNwLTA0LnR4dDxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8YnI+DQomZ3Q7Jmd0OyBkaXJlY3Rv cmllcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwO1RoaXMgZHJhZnQgaXMgYSB3b3JrIGl0 ZW0gb2YgdGhlIENvbW1vbiBDb250cm9sDQphbmQgTWVhc3VyZW1lbnQ8YnI+DQomZ3Q7Jmd0OyBQ bGFuZSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO1RpdGxlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgOiBSU1ZQLVRFDQpFeHRlbnNpb25zIGZvciBBc3NvY2lhdGVkIEJpZGlyZWN0aW9u YWw8YnI+DQomZ3Q7Jmd0OyBMU1BzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDtBdXRob3Io cykgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBGZWkgWmhhbmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUnVpcXVhbiBKaW5nPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJha2VzaCBH YW5kaGk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO0ZpbGVuYW1lICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzogZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2Np YXRlZC08YnI+DQomZ3Q7Jmd0OyBsc3AtMDQudHh0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDtQYWdlcyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMTc8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwO0RhdGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs6IDIwMTItMDgtMTU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtUaGUg TVBMUyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgcmVxdWlyZW1lbnRzDQpkb2N1bWVudDxi cj4NCiZndDsmZ3Q7IFtSRkM1NjU0XSw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJz cDtkZXNjcmliZXMgdGhhdCBNUExTLVRQIE1VU1Qgc3VwcG9ydCBhc3NvY2lhdGVkDQpiaWRpcmVj dGlvbmFsPGJyPg0KJmd0OyZndDsgcG9pbnQtPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsg Jm5ic3A7dG8tcG9pbnQgTFNQcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIG1ldGhvZCB0byBi aW5kIHR3bw0KdW5pZGlyZWN0aW9uYWwgTGFiZWw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNw OyAmbmJzcDtTd2l0Y2hlZCBQYXRocyAoTFNQcykgaW50byBhbiBhc3NvY2lhdGVkDQpiaWRpcmVj dGlvbmFsIExTUC4gJm5ic3A7VGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 YXNzb2NpYXRpb24gaXMgYWNoaWV2ZWQgYnkgZGVmaW5pbmcgdGhlIG5ldw0KQXNzb2NpYXRpb24g VHlwZSBpbjxicj4NCiZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZu YnNwO0V4dGVuZGVkIEFTU09DSUFUSU9OIG9iamVjdC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVGhlIElFVEYgZGF0YXRy YWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLW1wbHMt dHAtcnN2cHRlLTxicj4NCiZndDsmZ3Q7IGV4dC08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGE8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IHNzb2NpYXRlZC1sc3A8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWls YWJsZSBhdDo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LTxicj4NCiZndDsmZ3Q7IGFzc29j aTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgYTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgdGVkLWxzcC0w NDxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2NhbXAtbXBs cy10cC1yc3ZwdGUtPGJyPg0KJmd0OyZndDsgZXh0LTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgYTxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgc3NvY2lhdGVkLWxzcC0wNDxicj4NCiZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzxicj4NCiZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBDQ0FNUCBtYWls aW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IENDQU1QQGlldGYub3JnPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyZndDsgQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgQ0NBTVBAaWV0Zi5vcmc8YnI+ DQomZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkNDQU1QIG1haWxpbmcg bGlzdDxicj4NCkNDQU1QQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jY2FtcDxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 00050D2F48257A5D_=-- From zhang.fei3@zte.com.cn Thu Aug 16 17:58:04 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF72711E808D for ; Thu, 16 Aug 2012 17:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.196 X-Spam-Level: X-Spam-Status: No, score=-97.196 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id revqO9-50TJU for ; Thu, 16 Aug 2012 17:58:03 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 132A611E808A for ; Thu, 16 Aug 2012 17:58:02 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723473195744; Fri, 17 Aug 2012 08:44:07 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 67006.984958751; Fri, 17 Aug 2012 08:57:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q7H0vuTT078531; Fri, 17 Aug 2012 08:57:56 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <502D0A4A.7070201@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: 07558BF8:70D7487F-48257A5D:00052100; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 17 Aug 2012 08:57:49 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-17 08:57:36, Serialize complete at 2012-08-17 08:57:36 Content-Type: multipart/alternative; boundary="=_alternative 00053CFE48257A5D_=" X-MAIL: mse01.zte.com.cn q7H0vuTT078531 Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 00:58:04 -0000 This is a multipart message in MIME format. --=_alternative 00053CFE48257A5D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TG91DQoNCkFmdGVyIGEgc2Vjb25kIHRoaW5raW5nLCBJIGFncmVlIHRoYXQgdGhlIHB1Ymxpc2hl ZCB0ZXh0IGhhcyBubyBwcm9ibGVtLg0KDQpUaGFua3MNCg0KRmVpDQoNCg0KDQpMb3UgQmVyZ2Vy IDxsYmVyZ2VyQGxhYm4ubmV0PiANCjIwMTItMDgtMTYgMjI6NTcNCg0KytW8/sjLDQp6aGFuZy5m ZWkzQHp0ZS5jb20uY24NCrOty80NCmNjYW1wQGlldGYub3JnDQrW98ziDQpSZTogW0NDQU1QXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC0wNC50eHQNCg0KDQoNCg0KDQoN CkZlaSwNCiAgICAgICAgICAgICAgICAgSSBzdGlsbCBkb24ndCB1bmRlcnN0YW5kIHRoZSBwb2lu dCB5b3UncmUgdHJ5aW5nIHRvIA0KYWRkcmVzcyAoaW4geW91cg0KcHJvcG9zZWQgbGFuZ3VhZ2Up LiAgR2l2ZW4gdGhhdCB5b3Ugc2FpZCB0aGF0IHlvdSBjYW4gbGl2ZSB3aXRoIHRoZQ0KcHVibGlz aGVkIHRleHQsIHNoYWxsIHdlIGp1c3Qgbm90IHdvcnJ5IGFib3V0IHRoaXM/ICBJZiBub3QsIGNh biB5b3UNCnJlcGhyYXNlIHRoZSBpc3N1ZSBpbiB0aGUgY3VycmVudCB0ZXh0IHRoYXQgeW91J2Qg bGlrZSB0byBhZGRyZXNzPw0KDQpUaGFua3MsDQpMb3UNCg0KT24gOC8xNi8yMDEyIDI6MDYgQU0s IHpoYW5nLmZlaTNAenRlLmNvbS5jbiB3cm90ZToNCj4gDQo+IExvdQ0KPiANCj4gVGhhbmsgeW91 IGZvciB5b3VyIGNsYXJpZmljYXRpb24sIHNlZSByZXNwb25zZSBpbiBsaW5lIHdpdGggPGZlaT4N Cj4gDQo+IFJlZ2FyZHMNCj4gDQo+IEZlaQ0KPiANCj4gDQo+ICpMb3UgQmVyZ2VyIDxsYmVyZ2Vy QGxhYm4ubmV0PioNCj4gDQo+IDIwMTItMDgtMTYgMDA6MjINCj4gDQo+IA0KPiDK1bz+yMsNCj4g ICAgICAgICAgICAgICAgemhhbmcuZmVpM0B6dGUuY29tLmNuDQo+ILOty80NCj4gICAgICAgICAg ICAgICAgY2NhbXBAaWV0Zi5vcmcNCj4g1vfM4g0KPiAgICAgICAgICAgICAgICBSZTogW0NDQU1Q XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC0wNC50eHQNCj4gDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gRmVpLA0KPiAgICAgICAgICAgICAgICAgU2Vl IGJlbG93Lg0KPiANCj4gT24gOC8xNC8yMDEyIDExOjEwIFBNLCB6aGFuZy5mZWkzQHp0ZS5jb20u Y24gd3JvdGU6DQo+Pg0KPj4gSGkgTG91DQo+Pg0KPj4gSSBjYW4gc2VlIHRoZXJlIGFyZSBzb21l IG1pbm9yIGNoYW5nZXMgd2hlbiB0YWtpbmcgYSBsb29rIGF0IHRoZSANCnVwZGF0ZWQNCj4+IG5l dyB2ZXJzaW9uLCBhbmQgd2FudCB0byBjaGVjayB3aXRoIHlvdSB0aGUgaW50ZW50aW9uIG9mIGxp c3RlZCB0d28NCj4+IHJldmlzaW9ucy4NCj4+DQo+PiAxLiBTZWN0aW9uIDMgTm8tR01QTFMgUmVj b3ZlcnkgVXNhZ2UNCj4+DQo+PiBUaGUgc2VudGVuY2UgIk5vdGUgdGhhdCB0aGVyZSBhcmUgdGlt ZXMgd2hlbiBubyBtYXRjaGluZyBzdGF0ZSBpcyANCmZvdW5kLA0KPj4gZS5nLiwgd2hlbiBwcm9j ZXNzaW5nIGFuIGluaXRpYWwgTFNQIG9yIHdoZW4gdGhlIEFTU09DSUFUSU9OIG9iamVjdA0KPj4g Y29udGFpbnMNCj4+IG90aGVyd2lzZSB1c2VmdWwgaW5mb3JtYXRpb24sIGFuZCBzdWNoIGNhc2Vz IGRvIG5vdCBhbHRlciB0aGUgDQpwcm9jZXNzaW5nDQo+PiBkZWZpbmVkIGJlbG93LiIgaXMgZGVs ZXRlZCBpbiB0aGUgdmVyc2lvbiAwNCwgd2hpY2ggaW5kaWNhdGVzIHRoYXQgdGhlDQo+PiBBU1NP Q0lBVElPTiBvYmplY3QNCj4+IGNhbiBub3QgYmUgdXNlZCBpbiBhIHNpbmdsZSBzZXNzaW9uIHdo aXRoIGFueSBraW5kcyBvZiBBc3NvY2lhdGlvbiANClR5cGVzDQo+PiBvciB0aGUgdXNhZ2UgaW4g YSBzaW5nbGUgc2Vzc2lvbiBjYW4gYmUgZGVmaW5lZCBhcyBhbiBhc3NvY2lhdGlvbiB0eXBlDQo+ PiBzcGVjaWZpYyBydWxlcz8NCj4gDQo+IE5vdCBzdXJlIGV4YWN0bHkgd2hhdCB5b3UncmUgYXNr aW5nLCBidXQgdGhpcyBjaGFuZ2Ugd2FzIGVkaXRvcmlhbCBpbg0KPiBuYXR1cmUgb25seSwgYXMg cHJvY2Vzc2luZyBiZWhhdmlvciBjb250aW51ZXMgdG8gYmUgc3BlY2lmaWVkIChzZWUgdGhlDQo+ IDJuZCB0byBsYXN0IHBhcmFncmFwaCBpbiBTZWN0aW9uIDMuMS4yIGFuZCAzLjIuMi4pDQo+IA0K PiA8ZmVpPiBJIHdhbnQgdG8gY2hlY2sgd2hldGhlciB0aGUgQVNTT0NJQVRJT04gb2JqZWN0IGlz IGFsbG93ZWQgdG8gYmUNCj4gdXNlZCBpbiBhIHNpZ25hbCBzZXNzaW9uLA0KPiBhbmQgZmluZCB0 aGUgY29ycmVzcG9uZGluZyBkZXNjcmlwdGlvbiBpbiBzZWN0aW9uIDMuMSBhbmQgMy4yDQo+ICJU aGUgdXNlIG9mIGFuIEFTU09DSUFUSU9OIG9iamVjdCBpbiBhIHNpbmdsZSBzZXNzaW9uIGlzIG5v dCBwcmVjbHVkZWQiDQo+ICIgTm90ZSwgdGhlIHVzZSBvZiBhbiBBU1NPQ0lBVElPTiBvYmplY3Qg aW4gYSBzaW5nbGUgc2Vzc2lvbiBpcyBub3QNCj4gcHJlY2x1ZGVkIg0KPiBObyBwcm9ibGVtIG5v dywgdGhhbmtzLg0KPiANCj4gDQo+Pg0KPj4gMi4gVGhlIGRlc2NyaXB0aW9ucyBhYm91dCBHbG9i YWwgQXNzb2NpYXRpb24gU291cmNlIGluIFNlY3Rpb24gNC4xLg0KPj4gIElQdjQgYW5kIElQdjYg RXh0ZW5kZWQgQVNTT0NJQVRJT04gT2JqZWN0IEZvcm1hdA0KPj4NCj4+IFNpbWlsYXJseSwgdGhl IHNlbnRlbmNlICJJdCBpcyBleHBlY3RlZCB0aGF0IHRoZSBnbG9iYWwgaWRlbnRpZmllciB3aWxs DQo+PiBiZSBkZXJpdmVkIGZyb20gdGhlIGdsb2JhbGx5IHVuaXF1ZSBBU04gb2YgdGhlIGF1dG9u b21vdXMgc3lzdGVtIA0KaG9zdGluZw0KPj4gdGhlIEFzc29jaWF0aW9uIFNvdXJjZS4iIGRvZXMg bm90IGFwcGVhciBpbiB0aGUgbmV3IHZlcnNpb24uIFRoZQ0KPj4gcXVlc3Rpb24gaGVyZSBpcyB3 aGV0aGVyIHRoZSBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlIFNIT1VMRCBob3N0IHRoZQ0KPj4g QXNzb2NpYXRpb24gU291cmNlIG9yIG5vdD8gIElmIHllYWgsIGl0IGhhZCBiZXR0ZXIgYmVpbmcg ZGVzY3JpYmVkIGluDQo+PiB0aGUgZG9jdW1lbnQuDQo+IA0KPiBTbyB0aGUgb2xkIHRleHQgd2Fz IGluZm9ybWF0aXZlIG9ubHkgKGFuZCB3YXMgdGFrZW4gZnJvbSBSRkM2MzcwKS4gIFRoZQ0KPiBu ZXcgdGV4dCBpcyBub3JtYXRpdmUgYW5kIHNheXMgdXNlIGRlZmluaXRpb24gZnJvbSBbUkZDNjM3 MF0uIFNvIEknbSBub3QNCj4gc3VyZSB3aGF0IGlzIGFtYmlndW91cyBpbiB0aGUgbmV3IHRleHQu ICBXaGF0IHNwZWNpZmljIGNoYW5nZSB3b3VsZCB5b3UNCj4gbGlrZSB0byBzZWU/DQo+IA0KPiA8 ZmVpPiBJTUhPLCB0aGUgR2xvYmFsIEFzc29jaWFpdG9uIFNvdXJjZSBzaG91bGQgYmUgdGhlIEds b2JhbF9JRCB0aGF0DQo+IGhvc3RpbmcNCj4gQXNzb2NpYXRpb24gU291cmNlLCBob3cgYWJvdXQg InRoZSBHbG9iYWxfSUQgYXMgZGVmaW5lZCBpbiBbUkZDNjM3MF10aGF0DQo+IGhvc3RpbmcNCj4g dGhlIEFzc29jaWF0aW9uIFNvdXJjZSBTSEFMTCBiZSB1c2VkIj8gT2YgY291cnNlLCB0aGUgY3Vy cmVudA0KPiBkZXNjcmlwdGlvbiBpcw0KPiBjb3JyZWN0IGFuZCBpbmNsdWRlcyB0aGlzIHBvc3Np YmlsaXR5Lg0KPiANCj4gDQo+IExvdQ0KPiANCj4+DQo+Pg0KPj4gQmVzdCByZWdhcmRzDQo+Pg0K Pj4gRmVpDQo+Pg0KPj4NCj4+ICpMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PioNCj4+ILei vP7IyzogIGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcNCj4+DQo+PiAyMDEyLTA4LTE0IDIyOjEwDQo+ Pg0KPj4gDQo+PiDK1bz+yMsNCj4+ICAgICAgICAgICAgICAgICAgY2NhbXBAaWV0Zi5vcmcNCj4+ ILOty80NCj4+IA0KPj4g1vfM4g0KPj4gICAgICAgICAgICAgICAgICBSZTogW0NDQU1QXSBJLUQg QWN0aW9uOiANCmRyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0LTA0LnR4dA0KPj4NCj4+DQo+PiAN Cj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IFRoZSBhdXRob3JzIGJlbGlldmUgdGhhdCB0aGlz IHJldmlzaW9uIGFkZHJlc3NlcyB0aGUgY29tbWVudHMgcmFpc2VkIGJ5DQo+PiBBZHJpYW4gYW5k IGRpc2N1c3NlZCBvbiB0aGUgbGlzdC4gKEl0IGFsc28gaW5jbHVkZXMgZmV3IG90aGVyIGVkaXRv cmlhbA0KPj4gbml0cyBpZGVudGlmaWVkIGJ5IHRoZSBhdXRob3JzLikNCj4+DQo+PiBQbGVhc2Ug bm90ZSwgYXMgZGlzY3Vzc2VkLCB0aGVyZSBoYXMgYmVlbiBvbmUgc3Vic3RhbnRpdmUgdGVjaG5p Y2FsDQo+PiBjaGFuZ2UgKE1VU1QgLS0+IFNIT1VMRCk6DQo+Pg0KPj4gIDMuMi4xLiBSZXN2IE1l c3NhZ2UgRm9ybWF0DQo+PiBPTEQNCj4+ICBSZWxhdGl2ZSBvcmRlcmluZyBvZiBBU1NPQ0lBVElP TiBvYmplY3RzIG9mIHRoZSBzYW1lIHR5cGUNCj4+ICBNVVNUIGJlIHByZXNlcnZlZCBieSB0cmFu c2l0IG5vZGVzLg0KPj4gTkVXDQo+PiAgUmVsYXRpdmUgb3JkZXJpbmcgb2YgQVNTT0NJQVRJT04g b2JqZWN0cyBvZiB0aGUgc2FtZSB0eXBlDQo+PiAgKlNIT1VMRCogYmUgcHJlc2VydmVkIGJ5IHRy YW5zaXQgbm9kZXMuDQo+Pg0KPj4gTG91IChhbmQgY28tYXV0aG9ycykNCj4+DQo+PiBPbiA4LzE0 LzIwMTIgOTo0NSBBTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPj4+DQo+Pj4g QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzDQo+PiBkaXJlY3Rvcmllcy4NCj4+PiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl bSBvZiB0aGUgQ29tbW9uIENvbnRyb2wgYW5kIE1lYXN1cmVtZW50IFBsYW5lDQo+PiBXb3JraW5n IEdyb3VwIG9mIHRoZSBJRVRGLg0KPj4+DQo+Pj4gICAgICAgICAgICAgICAgICBUaXRsZSAgICAg ICAgICAgOiBSU1ZQIEFzc29jaWF0aW9uIE9iamVjdCBFeHRlbnNpb25zDQo+Pj4gICAgICAgICAg ICAgICAgICBBdXRob3IocykgICAgICAgOiBMb3UgQmVyZ2VyDQo+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICBGcmFuY29pcyBMZSBGYXVjaGV1cg0KPj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgQXNob2sgTmFyYXlhbmFuDQo+Pj4gICAgICAgICAgICAgICAgICBGaWxlbmFtZSAgICAg ICAgOiBkcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC0wNC50eHQNCj4+PiAgICAgICAgICAgICAg ICAgIFBhZ2VzICAgICAgICAgICA6IDE2DQo+Pj4gICAgICAgICAgICAgICAgICBEYXRlICAgICAg ICAgICAgOiAyMDEyLTA4LTE0DQo+Pj4NCj4+PiBBYnN0cmFjdDoNCj4+PiAgICBUaGUgUlNWUCBB U1NPQ0lBVElPTiBvYmplY3Qgd2FzIGRlZmluZWQgaW4gdGhlIGNvbnRleHQgb2YgR01QTFMNCj4+ PiAgICAoR2VuZXJhbGl6ZWQgTXVsdGktUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nKSBjb250cm9s bGVkIGxhYmVsDQo+Pj4gICAgc3dpdGNoZWQgcGF0aHMgKExTUHMpLiAgSW4gdGhpcyBjb250ZXh0 LCB0aGUgb2JqZWN0IGlzIHVzZWQgdG8NCj4+PiAgICBhc3NvY2lhdGUgcmVjb3ZlcnkgTFNQcyB3 aXRoIHRoZSBMU1AgdGhleSBhcmUgcHJvdGVjdGluZy4gIFRoaXMNCj4+PiAgICBvYmplY3QgYWxz byBoYXMgYnJvYWRlciBhcHBsaWNhYmlsaXR5IGFzIGEgbWVjaGFuaXNtIHRvIGFzc29jaWF0ZQ0K Pj4+ICAgIFJTVlAgc3RhdGUsIGFuZCB0aGlzIGRvY3VtZW50IGRlZmluZXMgaG93IHRoZSBBU1NP Q0lBVElPTiBvYmplY3QNCj4+PiAgICBjYW4gYmUgbW9yZSBnZW5lcmFsbHkgYXBwbGllZC4gIFRo aXMgZG9jdW1lbnQgYWxzbyBkZWZpbmVzDQo+Pj4gICAgRXh0ZW5kZWQgQVNTT0NJQVRJT04gb2Jq ZWN0cyB3aGljaCwgaW4gcGFydGljdWxhciwgY2FuIGJlIHVzZWQgaW4NCj4+PiAgICB0aGUgY29u dGV4dCBvZiB0aGUgVHJhbnNwb3J0IFByb2ZpbGUgb2YgTXVsdGlwcm90b2NvbCBMYWJlbA0KPj4+ ICAgIFN3aXRjaGluZyAoTVBMUy1UUCkuICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDIDIyMDUs IFJGQyAzMjA5LA0KPj4+ICAgIGFuZCBSRkMgMzQ3My4gSXQgYWxzbyBtb2RpZmllcyB0aGUgZGVm aW5pdGlvbiBvZiB0aGUgQXNzb2NpYXRpb24NCj4+PiAgICBJRCBmaWVsZCBkZWZpbmVkIGluIFJG QyA0ODcyLg0KPj4+DQo+Pj4NCj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczoNCj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dA0KPj4+DQo+Pj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6 ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDQNCj4+Pg0KPj4+IEEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+PiBodHRwOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC0wNA0KPj4+DQo+Pj4NCj4+ PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 DQo+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pg0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gQ0NBTVAgbWFp bGluZyBsaXN0DQo+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBDQ0FNUCBtYWlsaW5nIGxp c3QNCj4+IENDQU1QQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NjYW1wDQo+Pg0KPj4NCj4gDQo+IA0KDQoNCg0K --=_alternative 00053CFE48257A5D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxvdTwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QWZ0ZXIgYSBzZWNvbmQgdGhpbmtpbmcs IEkgYWdyZWUgdGhhdA0KdGhlIHB1Ymxpc2hlZCB0ZXh0IGhhcyBubyBwcm9ibGVtLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GZWk8L2ZvbnQ+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+TG91IEJlcmdlciAmbHQ7 bGJlcmdlckBsYWJuLm5ldCZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+MjAxMi0wOC0xNiAyMjo1NzwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj56aGFuZy5mZWkzQHp0ZS5jb20uY248L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPmNjYW1wQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW0NDQU1Q XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC0wNC50eHQ8L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkZlaSw8YnI+ DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KSSBzdGlsbCBkb24ndCB1bmRlcnN0YW5kIHRoZSBwb2ludCB5b3UncmUgdHJ5aW5nIHRvIGFk ZHJlc3MgKGluIHlvdXI8YnI+DQpwcm9wb3NlZCBsYW5ndWFnZSkuICZuYnNwO0dpdmVuIHRoYXQg eW91IHNhaWQgdGhhdCB5b3UgY2FuIGxpdmUgd2l0aCB0aGU8YnI+DQpwdWJsaXNoZWQgdGV4dCwg c2hhbGwgd2UganVzdCBub3Qgd29ycnkgYWJvdXQgdGhpcz8gJm5ic3A7SWYgbm90LCBjYW4geW91 PGJyPg0KcmVwaHJhc2UgdGhlIGlzc3VlIGluIHRoZSBjdXJyZW50IHRleHQgdGhhdCB5b3UnZCBs aWtlIHRvIGFkZHJlc3M/PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkxvdTxicj4NCjxicj4NCk9u IDgvMTYvMjAxMiAyOjA2IEFNLCB6aGFuZy5mZWkzQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IExvdTxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFuayB5b3UgZm9yIHlvdXIg Y2xhcmlmaWNhdGlvbiwgc2VlIHJlc3BvbnNlIGluIGxpbmUgd2l0aCAmbHQ7ZmVpJmd0Ozxicj4N CiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZlaTxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICpMb3UgQmVyZ2VyICZsdDtsYmVyZ2VyQGxhYm4ubmV0 Jmd0Oyo8YnI+DQomZ3Q7IDxicj4NCiZndDsgMjAxMi0wOC0xNiAwMDoyMjxicj4NCiZndDsgPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzxicj4NCiZndDsgytW8/sjLPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3poYW5nLmZlaTNA enRlLmNvbS5jbjxicj4NCiZndDsgs63LzTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjY2FtcEBpZXRmLm9yZzxi cj4NCiZndDsg1vfM4jxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSZToNCltDQ0FNUF0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDQudHh0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZlaSw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2VlIGJlbG93Ljxi cj4NCiZndDsgPGJyPg0KJmd0OyBPbiA4LzE0LzIwMTIgMTE6MTAgUE0sIHpoYW5nLmZlaTNAenRl LmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEhpIExvdTxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBjYW4gc2VlIHRoZXJlIGFyZSBzb21lIG1pbm9yIGNoYW5n ZXMgd2hlbiB0YWtpbmcgYSBsb29rIGF0IHRoZQ0KdXBkYXRlZDxicj4NCiZndDsmZ3Q7IG5ldyB2 ZXJzaW9uLCBhbmQgd2FudCB0byBjaGVjayB3aXRoIHlvdSB0aGUgaW50ZW50aW9uIG9mIGxpc3Rl ZA0KdHdvPGJyPg0KJmd0OyZndDsgcmV2aXNpb25zLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgMS4gU2VjdGlvbiAzIE5vLUdNUExTIFJlY292ZXJ5IFVzYWdlPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBUaGUgc2VudGVuY2UgJnF1b3Q7Tm90ZSB0aGF0IHRoZXJlIGFyZSB0aW1lcyB3 aGVuIG5vIG1hdGNoaW5nDQpzdGF0ZSBpcyBmb3VuZCw8YnI+DQomZ3Q7Jmd0OyBlLmcuLCB3aGVu IHByb2Nlc3NpbmcgYW4gaW5pdGlhbCBMU1Agb3Igd2hlbiB0aGUgQVNTT0NJQVRJT04gb2JqZWN0 PGJyPg0KJmd0OyZndDsgY29udGFpbnM8YnI+DQomZ3Q7Jmd0OyBvdGhlcndpc2UgdXNlZnVsIGlu Zm9ybWF0aW9uLCBhbmQgc3VjaCBjYXNlcyBkbyBub3QgYWx0ZXIgdGhlDQpwcm9jZXNzaW5nPGJy Pg0KJmd0OyZndDsgZGVmaW5lZCBiZWxvdy4mcXVvdDsgaXMgZGVsZXRlZCBpbiB0aGUgdmVyc2lv biAwNCwgd2hpY2ggaW5kaWNhdGVzDQp0aGF0IHRoZTxicj4NCiZndDsmZ3Q7IEFTU09DSUFUSU9O IG9iamVjdDxicj4NCiZndDsmZ3Q7IGNhbiBub3QgYmUgdXNlZCBpbiBhIHNpbmdsZSBzZXNzaW9u IHdoaXRoIGFueSBraW5kcyBvZiBBc3NvY2lhdGlvbg0KVHlwZXM8YnI+DQomZ3Q7Jmd0OyBvciB0 aGUgdXNhZ2UgaW4gYSBzaW5nbGUgc2Vzc2lvbiBjYW4gYmUgZGVmaW5lZCBhcyBhbiBhc3NvY2lh dGlvbg0KdHlwZTxicj4NCiZndDsmZ3Q7IHNwZWNpZmljIHJ1bGVzPzxicj4NCiZndDsgPGJyPg0K Jmd0OyBOb3Qgc3VyZSBleGFjdGx5IHdoYXQgeW91J3JlIGFza2luZywgYnV0IHRoaXMgY2hhbmdl IHdhcyBlZGl0b3JpYWwNCmluPGJyPg0KJmd0OyBuYXR1cmUgb25seSwgYXMgcHJvY2Vzc2luZyBi ZWhhdmlvciBjb250aW51ZXMgdG8gYmUgc3BlY2lmaWVkIChzZWUNCnRoZTxicj4NCiZndDsgMm5k IHRvIGxhc3QgcGFyYWdyYXBoIGluIFNlY3Rpb24gMy4xLjIgYW5kIDMuMi4yLik8YnI+DQomZ3Q7 IDxicj4NCiZndDsgJmx0O2ZlaSZndDsgSSB3YW50IHRvIGNoZWNrIHdoZXRoZXIgdGhlIEFTU09D SUFUSU9OIG9iamVjdCBpcyBhbGxvd2VkDQp0byBiZTxicj4NCiZndDsgdXNlZCBpbiBhIHNpZ25h bCBzZXNzaW9uLDxicj4NCiZndDsgYW5kIGZpbmQgdGhlIGNvcnJlc3BvbmRpbmcgZGVzY3JpcHRp b24gaW4gc2VjdGlvbiAzLjEgYW5kIDMuMjxicj4NCiZndDsgJnF1b3Q7VGhlIHVzZSBvZiBhbiBB U1NPQ0lBVElPTiBvYmplY3QgaW4gYSBzaW5nbGUgc2Vzc2lvbiBpcyBub3QNCnByZWNsdWRlZCZx dW90Ozxicj4NCiZndDsgJnF1b3Q7IE5vdGUsIHRoZSB1c2Ugb2YgYW4gQVNTT0NJQVRJT04gb2Jq ZWN0IGluIGEgc2luZ2xlIHNlc3Npb24NCmlzIG5vdDxicj4NCiZndDsgcHJlY2x1ZGVkJnF1b3Q7 PGJyPg0KJmd0OyBObyBwcm9ibGVtIG5vdywgdGhhbmtzLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDIuIFRoZSBkZXNjcmlwdGlvbnMgYWJvdXQgR2xv YmFsIEFzc29jaWF0aW9uIFNvdXJjZSBpbiBTZWN0aW9uDQo0LjEuPGJyPg0KJmd0OyZndDsgJm5i c3A7SVB2NCBhbmQgSVB2NiBFeHRlbmRlZCBBU1NPQ0lBVElPTiBPYmplY3QgRm9ybWF0PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBTaW1pbGFybHksIHRoZSBzZW50ZW5jZSAmcXVvdDtJdCBp cyBleHBlY3RlZCB0aGF0IHRoZSBnbG9iYWwgaWRlbnRpZmllcg0Kd2lsbDxicj4NCiZndDsmZ3Q7 IGJlIGRlcml2ZWQgZnJvbSB0aGUgZ2xvYmFsbHkgdW5pcXVlIEFTTiBvZiB0aGUgYXV0b25vbW91 cyBzeXN0ZW0NCmhvc3Rpbmc8YnI+DQomZ3Q7Jmd0OyB0aGUgQXNzb2NpYXRpb24gU291cmNlLiZx dW90OyBkb2VzIG5vdCBhcHBlYXIgaW4gdGhlIG5ldyB2ZXJzaW9uLg0KVGhlPGJyPg0KJmd0OyZn dDsgcXVlc3Rpb24gaGVyZSBpcyB3aGV0aGVyIHRoZSBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNl IFNIT1VMRA0KaG9zdCB0aGU8YnI+DQomZ3Q7Jmd0OyBBc3NvY2lhdGlvbiBTb3VyY2Ugb3Igbm90 PyAmbmJzcDtJZiB5ZWFoLCBpdCBoYWQgYmV0dGVyIGJlaW5nDQpkZXNjcmliZWQgaW48YnI+DQom Z3Q7Jmd0OyB0aGUgZG9jdW1lbnQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNvIHRoZSBvbGQgdGV4 dCB3YXMgaW5mb3JtYXRpdmUgb25seSAoYW5kIHdhcyB0YWtlbiBmcm9tIFJGQzYzNzApLg0KJm5i c3A7VGhlPGJyPg0KJmd0OyBuZXcgdGV4dCBpcyBub3JtYXRpdmUgYW5kIHNheXMgdXNlIGRlZmlu aXRpb24gZnJvbSBbUkZDNjM3MF0uIFNvIEknbQ0Kbm90PGJyPg0KJmd0OyBzdXJlIHdoYXQgaXMg YW1iaWd1b3VzIGluIHRoZSBuZXcgdGV4dC4gJm5ic3A7V2hhdCBzcGVjaWZpYyBjaGFuZ2UNCndv dWxkIHlvdTxicj4NCiZndDsgbGlrZSB0byBzZWU/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZsdDtm ZWkmZ3Q7IElNSE8sIHRoZSBHbG9iYWwgQXNzb2NpYWl0b24gU291cmNlIHNob3VsZCBiZSB0aGUg R2xvYmFsX0lEDQp0aGF0PGJyPg0KJmd0OyBob3N0aW5nPGJyPg0KJmd0OyBBc3NvY2lhdGlvbiBT b3VyY2UsIGhvdyBhYm91dCAmcXVvdDt0aGUgR2xvYmFsX0lEIGFzIGRlZmluZWQgaW4gW1JGQzYz NzBddGhhdDxicj4NCiZndDsgaG9zdGluZzxicj4NCiZndDsgdGhlIEFzc29jaWF0aW9uIFNvdXJj ZSBTSEFMTCBiZSB1c2VkJnF1b3Q7PyBPZiBjb3Vyc2UsIHRoZSBjdXJyZW50PGJyPg0KJmd0OyBk ZXNjcmlwdGlvbiBpczxicj4NCiZndDsgY29ycmVjdCBhbmQgaW5jbHVkZXMgdGhpcyBwb3NzaWJp bGl0eS48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBMb3U8YnI+DQomZ3Q7IDxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBCZXN0IHJlZ2FyZHM8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZlaTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAqTG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDsqPGJyPg0KJmd0 OyZndDsgt6K8/sjLOiAmbmJzcDtjY2FtcC1ib3VuY2VzQGlldGYub3JnPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyAyMDEyLTA4LTE0IDIyOjEwPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzxicj4NCiZndDsmZ3Q7IMrVvP7Iyzxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2NhbXBAaWV0 Zi5vcmc8YnI+DQomZ3Q7Jmd0OyCzrcvNPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7Jmd0 OyDW98ziPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSZToNCltDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1jY2FtcC1hc3NvYy1leHQtMDQudHh0PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgVGhlIGF1dGhvcnMgYmVsaWV2ZSB0aGF0IHRoaXMgcmV2aXNpb24gYWRkcmVzc2VzIHRoZSBj b21tZW50cw0KcmFpc2VkIGJ5PGJyPg0KJmd0OyZndDsgQWRyaWFuIGFuZCBkaXNjdXNzZWQgb24g dGhlIGxpc3QuIChJdCBhbHNvIGluY2x1ZGVzIGZldyBvdGhlcg0KZWRpdG9yaWFsPGJyPg0KJmd0 OyZndDsgbml0cyBpZGVudGlmaWVkIGJ5IHRoZSBhdXRob3JzLik8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IFBsZWFzZSBub3RlLCBhcyBkaXNjdXNzZWQsIHRoZXJlIGhhcyBiZWVuIG9uZSBz dWJzdGFudGl2ZSB0ZWNobmljYWw8YnI+DQomZ3Q7Jmd0OyBjaGFuZ2UgKE1VU1QgLS0mZ3Q7IFNI T1VMRCk6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDszLjIuMS4gUmVzdiBNZXNz YWdlIEZvcm1hdDxicj4NCiZndDsmZ3Q7IE9MRDxicj4NCiZndDsmZ3Q7ICZuYnNwO1JlbGF0aXZl IG9yZGVyaW5nIG9mIEFTU09DSUFUSU9OIG9iamVjdHMgb2YgdGhlIHNhbWUgdHlwZTxicj4NCiZn dDsmZ3Q7ICZuYnNwO01VU1QgYmUgcHJlc2VydmVkIGJ5IHRyYW5zaXQgbm9kZXMuPGJyPg0KJmd0 OyZndDsgTkVXPGJyPg0KJmd0OyZndDsgJm5ic3A7UmVsYXRpdmUgb3JkZXJpbmcgb2YgQVNTT0NJ QVRJT04gb2JqZWN0cyBvZiB0aGUgc2FtZSB0eXBlPGJyPg0KJmd0OyZndDsgJm5ic3A7KlNIT1VM RCogYmUgcHJlc2VydmVkIGJ5IHRyYW5zaXQgbm9kZXMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBMb3UgKGFuZCBjby1hdXRob3JzKTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgT24g OC8xNC8yMDEyIDk6NDUgQU0sIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZTo8YnI+DQom Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzPGJyPg0KJmd0OyZndDsgZGly ZWN0b3JpZXMuPGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwO1RoaXMgZHJhZnQgaXMgYSB3b3JrIGl0 ZW0gb2YgdGhlIENvbW1vbiBDb250cm9sIGFuZA0KTWVhc3VyZW1lbnQgUGxhbmU8YnI+DQomZ3Q7 Jmd0OyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO1RpdGxlDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDogUlNWUCBBc3NvY2lhdGlvbiBPYmplY3QgRXh0ZW5zaW9uczxicj4NCiZndDsmZ3Q7Jmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO0F1dGhvcihzKQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBMb3UgQmVyZ2VyPGJyPg0KJmd0 OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRnJhbmNvaXMgTGUg RmF1Y2hldXI8YnI+DQomZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBBc2hvayBOYXJheWFuYW48YnI+DQomZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWxlbmFtZQ0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBkcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC0wNC50 eHQ8YnI+DQomZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQYWdlcw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA6IDE2PGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGF0ZQ0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDIwMTItMDgtMTQ8YnI+DQomZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAm bmJzcDtUaGUgUlNWUCBBU1NPQ0lBVElPTiBvYmplY3Qgd2FzIGRlZmluZWQgaW4gdGhlDQpjb250 ZXh0IG9mIEdNUExTPGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsoR2VuZXJhbGl6ZWQg TXVsdGktUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nKQ0KY29udHJvbGxlZCBsYWJlbDxicj4NCiZn dDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7c3dpdGNoZWQgcGF0aHMgKExTUHMpLiAmbmJzcDtJbiB0 aGlzIGNvbnRleHQsDQp0aGUgb2JqZWN0IGlzIHVzZWQgdG88YnI+DQomZ3Q7Jmd0OyZndDsgJm5i c3A7ICZuYnNwO2Fzc29jaWF0ZSByZWNvdmVyeSBMU1BzIHdpdGggdGhlIExTUCB0aGV5IGFyZQ0K cHJvdGVjdGluZy4gJm5ic3A7VGhpczxicj4NCiZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7b2Jq ZWN0IGFsc28gaGFzIGJyb2FkZXIgYXBwbGljYWJpbGl0eSBhcyBhIG1lY2hhbmlzbQ0KdG8gYXNz b2NpYXRlPGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtSU1ZQIHN0YXRlLCBhbmQgdGhp cyBkb2N1bWVudCBkZWZpbmVzIGhvdyB0aGUNCkFTU09DSUFUSU9OIG9iamVjdDxicj4NCiZndDsm Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7Y2FuIGJlIG1vcmUgZ2VuZXJhbGx5IGFwcGxpZWQuICZuYnNw O1RoaXMgZG9jdW1lbnQNCmFsc28gZGVmaW5lczxicj4NCiZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5i c3A7RXh0ZW5kZWQgQVNTT0NJQVRJT04gb2JqZWN0cyB3aGljaCwgaW4gcGFydGljdWxhciwNCmNh biBiZSB1c2VkIGluPGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDt0aGUgY29udGV4dCBv ZiB0aGUgVHJhbnNwb3J0IFByb2ZpbGUgb2YgTXVsdGlwcm90b2NvbA0KTGFiZWw8YnI+DQomZ3Q7 Jmd0OyZndDsgJm5ic3A7ICZuYnNwO1N3aXRjaGluZyAoTVBMUy1UUCkuICZuYnNwO1RoaXMgZG9j dW1lbnQgdXBkYXRlcw0KUkZDIDIyMDUsIFJGQyAzMjA5LDxicj4NCiZndDsmZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7YW5kIFJGQyAzNDczLiBJdCBhbHNvIG1vZGlmaWVzIHRoZSBkZWZpbml0aW9uDQpv ZiB0aGUgQXNzb2NpYXRpb248YnI+DQomZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwO0lEIGZpZWxk IGRlZmluZWQgaW4gUkZDIDQ4NzIuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0 aGlzIGRyYWZ0IGlzOjxicj4NCiZndDsmZ3Q7Jmd0OyBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBh dDo8YnI+DQomZ3Q7Jmd0OyZndDsgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1jY2FtcC1hc3NvYy1leHQtMDQ8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCiZn dDsmZ3Q7Jmd0OyBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNj YW1wLWFzc29jLWV4dC0wNDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6PGJyPg0KJmd0OyZndDsmZ3Q7IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7IEND QU1QIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyBDQ0FNUEBpZXRmLm9yZzxicj4NCiZn dDsmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wPGJy Pg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7Jmd0OyBDQ0FNUEBpZXRmLm9yZzxicj4NCiZndDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2NhbXA8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 00053CFE48257A5D_=-- From zhang.fei3@zte.com.cn Thu Aug 16 18:19:45 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE8221F84A7 for ; Thu, 16 Aug 2012 18:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.265 X-Spam-Level: X-Spam-Status: No, score=-97.265 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hb5HC48qxsX for ; Thu, 16 Aug 2012 18:19:44 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0722B21F84A5 for ; Thu, 16 Aug 2012 18:19:43 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 23255473195744; Fri, 17 Aug 2012 09:14:08 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 38775.2685115152; Fri, 17 Aug 2012 09:19:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7H1Jbh1068764; Fri, 17 Aug 2012 09:19:37 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <502D61B8.5050106@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: ECE3928A:B1472469-48257A5D:0005EB19; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 17 Aug 2012 09:19:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-17 09:19:17, Serialize complete at 2012-08-17 09:19:17 Content-Type: multipart/alternative; boundary="=_alternative 0007394848257A5D_=" X-MAIL: mse02.zte.com.cn q7H1Jbh1068764 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 01:19:46 -0000 This is a multipart message in MIME format. --=_alternative 0007394848257A5D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TG91DQoNClJlZ2FyZGluZyBCLjEgYW5kIEIuMg0KDQoyKSBTdXBwb3J0IGZvciBGUlIgYnlwYXNz IHR1bm5lbHMgZm9yIHBpZ2d5YmFja2VkIG9uIHRoZSBUUA0KYmlkaXJlY3Rpb25hbCBMU1AgbWVj aGFuaXNtcw0KDQpCLjEpIEFydGljdWxhdGUgdGhlIEZSUi9HTVBMUy1yZWxhdGVkIGlzc3VlIHlv dSdkIGxpa2UgdG8gYWRkcmVzcz8NCg0KQi4yKSBBcnRpY3VsYXRlIHdoeSB0aGlzIGlzc3VlIHNo b3VsZCBiZSBzb2x2ZWQgaW4gYSBUUC1zcGVjaWZpYyBhbmQgbm90IA0KR01QTFMgZ2VuZXJpYyBm YXNoaW9uPw0KDQpJIGRvIG5vdCB0aGluayB3ZSBpbnRyb2R1Y2UgdGhlIEZSUiBieXBhc3MgdHVu bmVscyBpbiB0aGlzIGRyYWZ0LCB3aGljaCBpcyANCnVzZWQgZm9yIGxvY2FsIHByb3RlY3Rpb24g KFJGQzQwOTApLg0KDQpEbyB5b3Ugc2VlIHRoZW0gaW4gc2VjdGlvbiAzLjIuNCBvciBzZWN0aW9u IDMuMi42LCBJIHBlcnNvbmFsbHkgdGhpbmsgdGhleSANCmFyZSBHTVBMUyBnZW5lcmljIGZhc2hp b24gYW5kIGFyZSB0b3RhbGx5IGluZm9ybWF0aW9uYWwuDQoNCklmIHRoZSBkZXNjcmlwdGlvbnMg bWlzbGVhZCB5b3UsIHBsZWFzZSBnaXZlIHVzIHNvbWUgZ3VpZGFuY2UgYW5kIHdlIGFyZSANCmhh cHB5IHRvIHJldmlzZSB0aGVtLg0KDQoNCkJlc3QgcmVnYXJkcw0KDQpGZWkNCg0KDQoNCkxvdSBC ZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+IA0KMjAxMi0wOC0xNyAwNToxMA0KDQrK1bz+yMsNCiJS YWtlc2ggR2FuZGhpIChyZ2FuZGhpKSIgPHJnYW5kaGlAY2lzY28uY29tPg0Ks63LzQ0KImNjYW1w QGlldGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+LCAiemhhbmcuZmVpM0B6dGUuY29tLmNuIiANCjx6 aGFuZy5mZWkzQHp0ZS5jb20uY24+DQrW98ziDQpSZTogW0NDQU1QXSBJLUQgQWN0aW9uOiANCmRy YWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0K DQoNCg0KDQoNCg0KUmFrZXNoLA0KICAgICAgICAgICAgICAgICBTdWNoIG1ham9yIGNoYW5nZXMg KGluIHNjb3BlIGFuZCBmdW5jdGlvbmFsaXR5KSB0byBXRyANCmRyYWZ0cyBhcmUNCnVzdWFsbHkg ZGlzY3Vzc2VkIHdpdGggdGhlIFdHIHByaW9yIHRvIHRoZSBhdXRob3JzL2VkaXRvcnMganVzdA0K cHVibGlzaGluZyB0aGUgY2hhbmdlcy4gIEJ1dCwgdGhpcyBpcyBhIGp1ZGdtZW50IGNhbGwgYnkg dGhlIGRvY3VtZW50DQplZGl0b3JzIGluIGhvdywgcXVvdGluZyByZmMyNDE4LCB0aGV5ICJlbnN1 cltlXSB0aGF0IHRoZSBjb250ZW50cyBvZiB0aGUNCmRvY3VtZW50IGFjY3VyYXRlbHkgcmVmbGVj dCB0aGUgZGVjaXNpb25zIHRoYXQgaGF2ZSBiZWVuIG1hZGUgYnkgdGhlDQp3b3JraW5nIGdyb3Vw LiINCg0KU28gbGV0J3MganVtcCBpbnRvIGRpc2N1c3NpbmcgdGhlIGNoYW5nZXMuDQoNCkFzIEkg c2VlIGl0IHRoaXMgZHJhZnQgaW50cm9kdWNlcyBzZXZlcmFsIG1ham9yIGZ1bmN0aW9uYWwgY2hh bmdlcyB0aGF0DQpoYXZlIG5vdCBiZWVuIGRpc2N1c3NlZCBieSB0aGUgV0cuICBDb3JyZWN0IG1l IGlmIEkgZ2V0IHRoZW0gd3JvbmcsIGJ1dA0KSSBiZWxpZXZlIHRoZXkgaW5jbHVkZToNCjEpIElu dHJvZHVjdGlvbiBvZiBhIHNlY29uZCBtZXRob2QgZm9yIHNpZ25hbGluZyBDby1yb3V0ZWQgTFNQ cw0KMikgU3VwcG9ydCBmb3IgRlJSIGJ5cGFzcyB0dW5uZWxzIGZvciBwaWdneWJhY2tlZCBvbiB0 aGUgVFANCmJpZGlyZWN0aW9uYWwgTFNQIG1lY2hhbmlzbXMuDQoNCiAgIFRoZXJlIGFyZSBhbHNv IG90aGVyIGNoYW5nZXMsIGJ1dCBJJ2xsIGRlZmVyIGRpc2N1c3NpbmcgdGhlbQ0KICAgdW50aWwg dGhlIGRpc2N1c3Npb24gb24gdGhlIGFib3ZlIGlzIGNvbmNsdWRlZC4NCg0KSXMgdGhpcyBjb3Jy ZWN0Pw0KDQpBc3N1bWluZyB5ZXMsIEkgaGF2ZSBxdWVzdGlvbnMgYWJvdXQgYm90aCByYXRpb25h bCBhbmQgc3BlY2lmaWMNCm1lY2hhbmlzbXMuICBGb3Igbm93IGxldCdzIGxvb2sgYXQgdGhlIGZv cm1lciwgc28gcGxlYXNlOg0KDQpBKSBBcnRpY3VsYXRlIHRoZSBpc3N1ZXMvbGltaXRhdGlvbnMg d2l0aCB1c2luZyB0aGUgUkZDMzQ3MyBkZWZpbmVkDQptZWNoYW5pc21zIGZvciAoY28tcm91dGVk KSBiaWRpcmVjdGlvbmFsIExTUHMgdGhhdCB5b3UnZCBsaWtlIHRvIHNlZQ0KYWRkcmVzc2VkLg0K DQpCLjEpIEFydGljdWxhdGUgdGhlIEZSUi9HTVBMUy1yZWxhdGVkIGlzc3VlIHlvdSdkIGxpa2Ug dG8gYWRkcmVzcz8NCg0KQi4yKSBBcnRpY3VsYXRlIHdoeSB0aGlzIGlzc3VlIHNob3VsZCBiZSBz b2x2ZWQgaW4gYSBUUC1zcGVjaWZpYyBhbmQgbm90DQpHTVBMUyBnZW5lcmljIGZhc2hpb24/DQoN ClRoYW5rcywNCkxvdQ0KDQpPbiA4LzE2LzIwMTIgNDoyNiBQTSwgUmFrZXNoIEdhbmRoaSAocmdh bmRoaSkgd3JvdGU6DQo+IEhpIExvdSwNCj4gDQo+IFllcy4NCj4gDQo+IFBsZWFzZSBhZHZpc2Ug aWYgeW91IHRoaW5rIGRldGFpbGVkIGVtYWlsIGlzIHJlcXVpcmVkLiANCj4gV2UgYmVsaWV2ZSBs YXRlc3QgZHJhZnQgc3VtbWFyaXplcyB0aGUgY2hhbmdlcyB3ZWxsIGFuZCB3ZSBjb3VsZCBzdGFy dCANCnJldmlldy9kaXNjdXNzaW9ucyBmcm9tIHRoZXJlLg0KPiANCj4gVGhhbmtzLA0KPiBSYWtl c2gNCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb3UgQmVy Z2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQo+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3Qg MTYsIDIwMTIgNDowMCBQTQ0KPiBUbzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCj4gQ2M6IGNj YW1wQGlldGYub3JnOyB6aGFuZy5mZWkzQHp0ZS5jb20uY24NCj4gU3ViamVjdDogUmU6IFtDQ0FN UF0gSS1EIEFjdGlvbjogDQpkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3Nv Y2lhdGVkLWxzcC0wNC50eHQNCj4gDQo+IFJha2VzaCwNCj4gICAgICAgICAgICAgICAgSXMgdGhp cyB0aGUgc3RhcnQgb2YgdGhlIHRocmVhZCB0aGF0IEkgcmVxdWVzdGVkIGluIA0KaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NjYW1wL2N1cnJlbnQvbXNnMTM3MjkuaHRtbA0K PiANCj4gSW4gcGFydGljdWxhciwgaXMgaXQgdGhlIHJlc3BvbnNlIHRvOg0KPj4gSSdkIGxpa2Ug dG8gYXNrIHRoYXQgc29tZW9uZSAoUmFrZXNoLCBGZWksIGV0Yy4pIHJldmlldyBlYWNoIG9mIHRo ZSANCj4+IHByb3Bvc2VkIGNoYW5nZSBhbmQgdGhlIHJhdGlvbmFsIGZvciBlYWNoIGNoYW5nZSAo aW4gb25lIG9yIGluIA0KPj4gc2VwYXJhdGUgZS1tYWlscykuIFRoZSBXRyBkaXNjdXNzaW9uIGNh biB0aGVuIHJlYWxseSBiZWdpbiBvbiB0aGUgDQo+PiBwcm9wb3NlZCBjaGFuZ2VzLiAoV2hpY2gg YXJlIHF1aXRlIHN1YnN0YW50aWFsIGJvdGggaW4gc2NvcGUgYW5kDQo+PiBpbXBsaWNhdGlvbi4p DQo+IA0KPiBMb3UNCj4gDQo+IE9uIDgvMTYvMjAxMiAzOjE5IFBNLCBSYWtlc2ggR2FuZGhpIChy Z2FuZGhpKSB3cm90ZToNCj4+IEhpIEFsbCwNCj4+DQo+PiBXZSBoYXZlIHVwbG9hZGVkIGEgbmV3 IHZlcnNpb24gb2YgdGhpcyBkcmFmdCB3aXRoIGZvbGxvd2luZyBjaGFuZ2VzOg0KPiANCj4gMS4g IEFkZGVkIGEgc2VjdGlvbiBvbiBTaWduYWxpbmcgb2YgQ28tcm91dGVkIExTUHMgDQo+IA0KPiAy LiAgQWRkZWQgY2xhcmlmaWNhdGlvbiBvbiBTaWduYWxpbmcgb2YgQXNzb2NpYXRlZCBCaWRpcmVj dGlvbmFsIA0KUHJvdGVjdGlvbiBMU1BzIA0KPiANCj4gMy4gIEFkZGVkIGEgc2VjdGlvbiBvbiBT aWduYWxpbmcgb2YgQXV0by10dW5uZWwgTWVzaC1ncm91cCBMU1BzIA0KPiANCj4gNC4gICBBZGRl ZCBjbGFyaWZpY2F0aW9uIG9uIFNpZ25hbGluZyBvZiBJbnRlci1kb21haW4gQXNzb2NpYXRlZCAN CkJpZGlyZWN0aW9uYWwgTFNQcyANCj4gDQo+IDUuICBUaGUgRXh0ZW5kZWQgQVNTT0NJQVRJT04g b2JqZWN0IGZvcm1hdCB3aXRoIEFzc29jaWF0aW9uIFR5cGUgDQoiQXNzb2NpYXRlZCBCaWRpcmVj dGlvbmFsIExTUCIuIENsYXJpZmllZCBvbiBob3cgdG8gcG9wdWxhdGUgZGlmZmVyZW50IA0KZmll bGRzIGluIHRoaXMgb2JqZWN0Lg0KPiANCj4gDQo+PiBXZSBiZWxpZXZlIHRoYXQgc29tZSBvZiB0 aGVzZSBjaGFuZ2VzIHdlcmUgbmVjZXNzYXJ5IHRvIGF2b2lkIHRoZSANCmludGVyb3BlcmFiaWxp dHkgaXNzdWVzIGR1ZSB0byBwb3RlbnRpYWxseSBkaWZmZXJlbnQgaW50ZXJwcmV0YXRpb25zLg0K Pj4NCj4+IFlvdXIgcmV2aWV3IGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KPj4NCj4+IFRoYW5rcywN Cj4+IFJha2VzaA0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBj Y2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIA0KPj4gT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+PiBTZW50OiBXZWRuZXNk YXksIEF1Z3VzdCAxNSwgMjAxMiAxMDo1MyBBTQ0KPj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9y Zw0KPj4gQ2M6IGNjYW1wQGlldGYub3JnDQo+PiBTdWJqZWN0OiBbQ0NBTVBdIEktRCBBY3Rpb246 IA0KPj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3At MDQudHh0DQo+Pg0KPj4NCj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyANCmRpcmVjdG9yaWVzLg0KPj4gIFRoaXMgZHJh ZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENvbW1vbiBDb250cm9sIGFuZCBNZWFzdXJlbWVudCBQ bGFuZSANCldvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+Pg0KPj4gICAgICAgICAgICAgICBU aXRsZSAgICAgICAgICAgOiBSU1ZQLVRFIEV4dGVuc2lvbnMgZm9yIEFzc29jaWF0ZWQgDQpCaWRp cmVjdGlvbmFsIExTUHMNCj4+ICAgICAgICAgICAgICAgQXV0aG9yKHMpICAgICAgIDogRmVpIFpo YW5nDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFJ1aXF1YW4gSmluZw0KPj4gICAgICAg ICAgICAgICAgICAgICAgICAgICBSYWtlc2ggR2FuZGhpDQo+PiAgICAgICAgICAgICAgIEZpbGVu YW1lICAgICAgICA6IA0KZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2Np YXRlZC1sc3AtMDQudHh0DQo+PiAgICAgICAgICAgICAgIFBhZ2VzICAgICAgICAgICA6IDE3DQo+ PiAgICAgICAgICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTItMDgtMTUNCj4+DQo+PiBBYnN0 cmFjdDoNCj4+ICAgIFRoZSBNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSByZXF1aXJl bWVudHMgZG9jdW1lbnQgDQpbUkZDNTY1NF0sDQo+PiAgICBkZXNjcmliZXMgdGhhdCBNUExTLVRQ IE1VU1Qgc3VwcG9ydCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcG9pbnQtDQo+PiAgICB0by1w b2ludCBMU1BzLg0KPj4NCj4+ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBtZXRob2QgdG8g YmluZCB0d28gdW5pZGlyZWN0aW9uYWwgTGFiZWwNCj4+ICAgIFN3aXRjaGVkIFBhdGhzIChMU1Bz KSBpbnRvIGFuIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuICBUaGUNCj4+ICAgIGFzc29j aWF0aW9uIGlzIGFjaGlldmVkIGJ5IGRlZmluaW5nIHRoZSBuZXcgQXNzb2NpYXRpb24gVHlwZSBp biB0aGUNCj4+ICAgIEV4dGVuZGVkIEFTU09DSUFUSU9OIG9iamVjdC4NCj4+DQo+Pg0KPj4gVGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+PiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2 cHRlLWV4dC1hDQo+PiBzc29jaWF0ZWQtbHNwDQo+Pg0KPj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6 ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhDQo+PiB0ZWQtbHNwLTA0 DQo+Pg0KPj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0 Og0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jY2FtcC1t cGxzLXRwLXJzdnB0ZS1leHQtYQ0KPj4gc3NvY2lhdGVkLWxzcC0wNA0KPj4NCj4+DQo+PiBJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4NCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBDQ0FNUCBtYWlsaW5nIGxpc3QN Cj4+IENDQU1QQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NjYW1wDQo+Pg0KPj4NCj4+DQo+Pg0KPiANCj4gDQo+IA0KPiANCg0KDQoNCg== --=_alternative 0007394848257A5D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxvdTwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UmVnYXJkaW5nIEIuMSBhbmQgQi4yPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4yKSBTdXBwb3J0 IGZvciBGUlIgYnlwYXNzIHR1bm5lbHMgZm9yDQpwaWdneWJhY2tlZCBvbiB0aGUgVFA8YnI+DQpi aWRpcmVjdGlvbmFsIExTUCBtZWNoYW5pc21zPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5CLjEpIEFydGljdWxhdGUgdGhlIEZSUi9HTVBMUy1yZWxhdGVk DQppc3N1ZSB5b3UnZCBsaWtlIHRvIGFkZHJlc3M/PGJyPg0KPGJyPg0KQi4yKSBBcnRpY3VsYXRl IHdoeSB0aGlzIGlzc3VlIHNob3VsZCBiZSBzb2x2ZWQgaW4gYSBUUC1zcGVjaWZpYyBhbmQgbm90 DQpHTVBMUyBnZW5lcmljIGZhc2hpb24/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5JIGRvIG5vdCB0aGluayB3ZSBpbnRyb2R1Y2UgdGhlIEZSUg0KYnlw YXNzIHR1bm5lbHMgaW4gdGhpcyBkcmFmdCwgd2hpY2ggaXMgdXNlZCBmb3IgbG9jYWwgcHJvdGVj dGlvbiAoUkZDNDA5MCkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5EbyB5b3Ugc2VlIHRoZW0gaW4gc2VjdGlvbiAzLjIuNCBvcg0Kc2VjdGlvbiAzLjIu NiwgSSBwZXJzb25hbGx5IHRoaW5rIHRoZXkgYXJlIEdNUExTIGdlbmVyaWMgZmFzaGlvbiBhbmQg YXJlDQp0b3RhbGx5IGluZm9ybWF0aW9uYWwuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiB0aGUgZGVzY3JpcHRpb25zIG1pc2xlYWQgeW91LCBwbGVh c2UNCmdpdmUgdXMgc29tZSBndWlkYW5jZSBhbmQgd2UgYXJlIGhhcHB5IHRvIHJldmlzZSB0aGVt LjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ QmVzdCByZWdhcmRzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5GZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+TG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDs8L2I+DQo8L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wOC0xNyAwNToxMDwvZm9udD4N Cjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtS YWtlc2ggR2FuZGhpIChyZ2FuZGhpKSZxdW90Ow0KJmx0O3JnYW5kaGlAY2lzY28uY29tJmd0Ozwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Y2NhbXBAaWV0Zi5vcmcmcXVvdDsgJmx0O2NjYW1wQGll dGYub3JnJmd0OywNCiZxdW90O3poYW5nLmZlaTNAenRlLmNvbS5jbiZxdW90OyAmbHQ7emhhbmcu ZmVpM0B6dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtDQ0FNUF0gSS1EIEFj dGlvbjogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO2RyYWZ0LWlldGYtY2NhbXAtbXBscy10 cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0K PHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxl Pg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+UmFrZXNoLDxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpTdWNoIG1h am9yIGNoYW5nZXMgKGluIHNjb3BlIGFuZCBmdW5jdGlvbmFsaXR5KSB0byBXRyBkcmFmdHMgYXJl PGJyPg0KdXN1YWxseSBkaXNjdXNzZWQgd2l0aCB0aGUgV0cgcHJpb3IgdG8gdGhlIGF1dGhvcnMv ZWRpdG9ycyBqdXN0PGJyPg0KcHVibGlzaGluZyB0aGUgY2hhbmdlcy4gJm5ic3A7QnV0LCB0aGlz IGlzIGEganVkZ21lbnQgY2FsbCBieSB0aGUgZG9jdW1lbnQ8YnI+DQplZGl0b3JzIGluIGhvdywg cXVvdGluZyByZmMyNDE4LCB0aGV5ICZxdW90O2Vuc3VyW2VdIHRoYXQgdGhlIGNvbnRlbnRzDQpv ZiB0aGU8YnI+DQpkb2N1bWVudCBhY2N1cmF0ZWx5IHJlZmxlY3QgdGhlIGRlY2lzaW9ucyB0aGF0 IGhhdmUgYmVlbiBtYWRlIGJ5IHRoZTxicj4NCndvcmtpbmcgZ3JvdXAuJnF1b3Q7PGJyPg0KPGJy Pg0KU28gbGV0J3MganVtcCBpbnRvIGRpc2N1c3NpbmcgdGhlIGNoYW5nZXMuPGJyPg0KPGJyPg0K QXMgSSBzZWUgaXQgdGhpcyBkcmFmdCBpbnRyb2R1Y2VzIHNldmVyYWwgbWFqb3IgZnVuY3Rpb25h bCBjaGFuZ2VzIHRoYXQ8YnI+DQpoYXZlIG5vdCBiZWVuIGRpc2N1c3NlZCBieSB0aGUgV0cuICZu YnNwO0NvcnJlY3QgbWUgaWYgSSBnZXQgdGhlbSB3cm9uZywNCmJ1dDxicj4NCkkgYmVsaWV2ZSB0 aGV5IGluY2x1ZGU6PGJyPg0KMSkgSW50cm9kdWN0aW9uIG9mIGEgc2Vjb25kIG1ldGhvZCBmb3Ig c2lnbmFsaW5nIENvLXJvdXRlZCBMU1BzPGJyPg0KMikgU3VwcG9ydCBmb3IgRlJSIGJ5cGFzcyB0 dW5uZWxzIGZvciBwaWdneWJhY2tlZCBvbiB0aGUgVFA8YnI+DQpiaWRpcmVjdGlvbmFsIExTUCBt ZWNoYW5pc21zLjxicj4NCjxicj4NCiAmbmJzcDsgVGhlcmUgYXJlIGFsc28gb3RoZXIgY2hhbmdl cywgYnV0IEknbGwgZGVmZXIgZGlzY3Vzc2luZyB0aGVtPGJyPg0KICZuYnNwOyB1bnRpbCB0aGUg ZGlzY3Vzc2lvbiBvbiB0aGUgYWJvdmUgaXMgY29uY2x1ZGVkLjxicj4NCjxicj4NCklzIHRoaXMg Y29ycmVjdD88YnI+DQo8YnI+DQpBc3N1bWluZyB5ZXMsIEkgaGF2ZSBxdWVzdGlvbnMgYWJvdXQg Ym90aCByYXRpb25hbCBhbmQgc3BlY2lmaWM8YnI+DQptZWNoYW5pc21zLiAmbmJzcDtGb3Igbm93 IGxldCdzIGxvb2sgYXQgdGhlIGZvcm1lciwgc28gcGxlYXNlOjxicj4NCjxicj4NCkEpIEFydGlj dWxhdGUgdGhlIGlzc3Vlcy9saW1pdGF0aW9ucyB3aXRoIHVzaW5nIHRoZSBSRkMzNDczIGRlZmlu ZWQ8YnI+DQptZWNoYW5pc21zIGZvciAoY28tcm91dGVkKSBiaWRpcmVjdGlvbmFsIExTUHMgdGhh dCB5b3UnZCBsaWtlIHRvIHNlZTxicj4NCmFkZHJlc3NlZC48YnI+DQo8YnI+DQpCLjEpIEFydGlj dWxhdGUgdGhlIEZSUi9HTVBMUy1yZWxhdGVkIGlzc3VlIHlvdSdkIGxpa2UgdG8gYWRkcmVzcz88 YnI+DQo8YnI+DQpCLjIpIEFydGljdWxhdGUgd2h5IHRoaXMgaXNzdWUgc2hvdWxkIGJlIHNvbHZl ZCBpbiBhIFRQLXNwZWNpZmljIGFuZCBub3Q8YnI+DQpHTVBMUyBnZW5lcmljIGZhc2hpb24/PGJy Pg0KPGJyPg0KVGhhbmtzLDxicj4NCkxvdTxicj4NCjxicj4NCk9uIDgvMTYvMjAxMiA0OjI2IFBN LCBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSB3cm90ZTo8YnI+DQomZ3Q7IEhpIExvdSw8YnI+DQom Z3Q7IDxicj4NCiZndDsgWWVzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2UgYWR2aXNlIGlm IHlvdSB0aGluayBkZXRhaWxlZCBlbWFpbCBpcyByZXF1aXJlZC4gPGJyPg0KJmd0OyBXZSBiZWxp ZXZlIGxhdGVzdCBkcmFmdCBzdW1tYXJpemVzIHRoZSBjaGFuZ2VzIHdlbGwgYW5kIHdlIGNvdWxk IHN0YXJ0DQpyZXZpZXcvZGlzY3Vzc2lvbnMgZnJvbSB0aGVyZS48YnI+DQomZ3Q7IDxicj4NCiZn dDsgVGhhbmtzLDxicj4NCiZndDsgUmFrZXNoPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IExvdSBCZXJnZXIg W21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSA8YnI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBdWd1 c3QgMTYsIDIwMTIgNDowMCBQTTxicj4NCiZndDsgVG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkp PGJyPg0KJmd0OyBDYzogY2NhbXBAaWV0Zi5vcmc7IHpoYW5nLmZlaTNAenRlLmNvbS5jbjxicj4N CiZndDsgU3ViamVjdDogUmU6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1t cGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFJha2VzaCw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SXMNCnRoaXMgdGhlIHN0YXJ0IG9mIHRoZSB0aHJl YWQgdGhhdCBJIHJlcXVlc3RlZCBpbiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvY2NhbXAvY3VycmVudC9tc2cxMzcyOS5odG1sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIHBh cnRpY3VsYXIsIGlzIGl0IHRoZSByZXNwb25zZSB0bzo8YnI+DQomZ3Q7Jmd0OyBJJ2QgbGlrZSB0 byBhc2sgdGhhdCBzb21lb25lIChSYWtlc2gsIEZlaSwgZXRjLikgcmV2aWV3IGVhY2ggb2YNCnRo ZSA8YnI+DQomZ3Q7Jmd0OyBwcm9wb3NlZCBjaGFuZ2UgYW5kIHRoZSByYXRpb25hbCBmb3IgZWFj aCBjaGFuZ2UgKGluIG9uZSBvciBpbg0KPGJyPg0KJmd0OyZndDsgc2VwYXJhdGUgZS1tYWlscyku IFRoZSBXRyBkaXNjdXNzaW9uIGNhbiB0aGVuIHJlYWxseSBiZWdpbiBvbg0KdGhlIDxicj4NCiZn dDsmZ3Q7IHByb3Bvc2VkIGNoYW5nZXMuIChXaGljaCBhcmUgcXVpdGUgc3Vic3RhbnRpYWwgYm90 aCBpbiBzY29wZSBhbmQ8YnI+DQomZ3Q7Jmd0OyBpbXBsaWNhdGlvbi4pPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IExvdTxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiA4LzE2LzIwMTIgMzoxOSBQTSwgUmFr ZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6PGJyPg0KJmd0OyZndDsgSGkgQWxsLDxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2UgaGF2ZSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRo aXMgZHJhZnQgd2l0aCBmb2xsb3dpbmcgY2hhbmdlczo8YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZn dDsgMS4gJm5ic3A7QWRkZWQgYSBzZWN0aW9uIG9uIFNpZ25hbGluZyBvZiBDby1yb3V0ZWQgTFNQ cyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgMi4gJm5ic3A7QWRkZWQgY2xhcmlmaWNhdGlvbiBvbiBT aWduYWxpbmcgb2YgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsDQpQcm90ZWN0aW9uIExTUHMgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDMuICZuYnNwO0FkZGVkIGEgc2VjdGlvbiBvbiBTaWduYWxpbmcg b2YgQXV0by10dW5uZWwgTWVzaC1ncm91cCBMU1BzDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgNC4g Jm5ic3A7IEFkZGVkIGNsYXJpZmljYXRpb24gb24gU2lnbmFsaW5nIG9mIEludGVyLWRvbWFpbiBB c3NvY2lhdGVkDQombmJzcDtCaWRpcmVjdGlvbmFsIExTUHMgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDUuICZuYnNwO1RoZSBFeHRlbmRlZCBBU1NPQ0lBVElPTiBvYmplY3QgZm9ybWF0IHdpdGggQXNz b2NpYXRpb24gVHlwZQ0KJnF1b3Q7QXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUCZxdW90Oy4g Q2xhcmlmaWVkIG9uIGhvdyB0byBwb3B1bGF0ZQ0KZGlmZmVyZW50IGZpZWxkcyBpbiB0aGlzIG9i amVjdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0OyZndDsgV2UgYmVsaWV2 ZSB0aGF0IHNvbWUgb2YgdGhlc2UgY2hhbmdlcyB3ZXJlIG5lY2Vzc2FyeSB0byBhdm9pZA0KdGhl IGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIGR1ZSB0byBwb3RlbnRpYWxseSBkaWZmZXJlbnQgaW50 ZXJwcmV0YXRpb25zLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgWW91ciByZXZpZXcgY29t bWVudHMgYXJlIHdlbGNvbWUuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGFua3MsPGJy Pg0KJmd0OyZndDsgUmFrZXNoPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbg0KQmVoYWxmIDxicj4NCiZndDsm Z3Q7IE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxicj4NCiZndDsmZ3Q7IFNlbnQ6IFdlZG5l c2RheSwgQXVndXN0IDE1LCAyMDEyIDEwOjUzIEFNPGJyPg0KJmd0OyZndDsgVG86IGktZC1hbm5v dW5jZUBpZXRmLm9yZzxicj4NCiZndDsmZ3Q7IENjOiBjY2FtcEBpZXRmLm9yZzxicj4NCiZndDsm Z3Q7IFN1YmplY3Q6IFtDQ0FNUF0gSS1EIEFjdGlvbjogPGJyPg0KJmd0OyZndDsgZHJhZnQtaWV0 Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KZGlyZWN0b3JpZXMu PGJyPg0KJmd0OyZndDsgJm5ic3A7VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29t bW9uIENvbnRyb2wgYW5kIE1lYXN1cmVtZW50DQpQbGFuZSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJ RVRGLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7VGl0bGUgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IFJTVlAtVEUgRXh0ZW5zaW9ucw0KZm9yIEFzc29jaWF0 ZWQgQmlkaXJlY3Rpb25hbCBMU1BzPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7QXV0aG9yKHMpICZuYnNw OyAmbmJzcDsgJm5ic3A7IDogRmVpIFpoYW5nPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBSdWlxdWFuIEppbmc8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJha2VzaCBHYW5kaGk8YnI+DQomZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDtGaWxlbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IGRyYWZ0LWlldGYtY2NhbXAt bXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dDxicj4NCiZndDsmZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwO1BhZ2VzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAxNzxicj4NCiZn dDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwO0RhdGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs6IDIwMTItMDgtMTU8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEFic3RyYWN0Ojxicj4N CiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtUaGUgTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1U UCkgcmVxdWlyZW1lbnRzDQpkb2N1bWVudCBbUkZDNTY1NF0sPGJyPg0KJmd0OyZndDsgJm5ic3A7 ICZuYnNwO2Rlc2NyaWJlcyB0aGF0IE1QTFMtVFAgTVVTVCBzdXBwb3J0IGFzc29jaWF0ZWQgYmlk aXJlY3Rpb25hbA0KcG9pbnQtPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO3RvLXBvaW50IExT UHMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVu dCBwcm92aWRlcyBhIG1ldGhvZCB0byBiaW5kIHR3byB1bmlkaXJlY3Rpb25hbA0KTGFiZWw8YnI+ DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7U3dpdGNoZWQgUGF0aHMgKExTUHMpIGludG8gYW4gYXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsDQpMU1AuICZuYnNwO1RoZTxicj4NCiZndDsmZ3Q7ICZuYnNw OyAmbmJzcDthc3NvY2lhdGlvbiBpcyBhY2hpZXZlZCBieSBkZWZpbmluZyB0aGUgbmV3IEFzc29j aWF0aW9uDQpUeXBlIGluIHRoZTxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtFeHRlbmRlZCBB U1NPQ0lBVElPTiBvYmplY3QuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxi cj4NCiZndDsmZ3Q7IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt Y2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWE8YnI+DQomZ3Q7Jmd0OyBzc29jaWF0ZWQtbHNwPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9u IGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7Jmd0OyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhPGJyPg0KJmd0OyZndDsg dGVkLWxzcC0wNDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQSBkaWZmIGZyb20gdGhlIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsmZ3Q7IGh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0 LWE8YnI+DQomZ3Q7Jmd0OyBzc29jaWF0ZWQtbHNwLTA0PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDo8YnI+DQomZ3Q7Jmd0OyBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBDQ0FNUCBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7Jmd0OyBDQ0FNUEBpZXRmLm9yZzxicj4NCiZndDsmZ3Q7IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 0007394848257A5D_=-- From zhang.fei3@zte.com.cn Fri Aug 17 00:28:11 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E286B21F853A; Fri, 17 Aug 2012 00:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.307 X-Spam-Level: X-Spam-Status: No, score=-96.307 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgZe4ToIh0J0; Fri, 17 Aug 2012 00:28:11 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id DE68821F852B; Fri, 17 Aug 2012 00:28:09 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 107231461793122; Fri, 17 Aug 2012 15:14:09 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 67006.1973556129; Fri, 17 Aug 2012 15:27:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q7H7RvQx058726; Fri, 17 Aug 2012 15:27:57 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Lou Berger MIME-Version: 1.0 X-KeepSent: BA961BDF:AE0336D2-48257A5D:0025E014; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 17 Aug 2012 15:27:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-17 15:27:38, Serialize complete at 2012-08-17 15:27:38 Content-Type: multipart/alternative; boundary="=_alternative 0028F24848257A5D_=" X-MAIL: mse01.zte.com.cn q7H7RvQx058726 Cc: ccamp@ietf.org, ccamp-bounces@ietf.org Subject: Re: [CCAMP] I-D Action: draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:28:12 -0000 This is a multipart message in MIME format. --=_alternative 0028F24848257A5D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTG91DQoNCkkgYW0gbm90IHN1cmUgd2hldGhlciB0aGlzIGRyYWZ0IHNob3VsZCBmb2xsb3cg dGhlIHRoZSBwcm9jZWR1cmVzIGRlZmluZWQgDQpmb3IgV0cgZG9jdW1lbnRzIG9yIG5vdC4NCg0K SWYgaXQgU0hPVUxELCB0aGUgbWFqb3IgY2hhbmdlcyBhcmUgbmVlZGVkIHRvIGhhdmUgYSBjb25z ZW5zdXMgaW4gV0cgDQpiZWZvcmUgcHVibGlzaGluZyB0aGVtIGFsc28sIHdoaWNoIGFyZSBsaXN0 ZWQgYmVsb3c6DQoNCkEpIEFkZCBvbmUgcGFyYWdyYXBoIGluIHNlY3Rpb24gMyB0byBhZGRyZXNz IHRoZSBleGNoYW5nZSBvZiBHbG9iYWxfSUQgaWYgDQpjb3JvdXRlZCBiaWRpcmVjdGlvbmFsIExT UHMgYXJlIGFjcm9zcyBkaWZmZXJlbnQgZG9tYWlucy4gDQoNCkIpIEFkZCBvbmUgc2VjdGlvbiA0 LjIgdG8gZGVzY3JpYmUgdGhlIHByb2Nlc3Npbmcgb2YgQVNTT0NJQVRJT04gb2JqZWN0cyANCndp dGggQXNzb2NpYXRpb24gVHlwZSAiTFNQIElkZW50aWZpZXJzIiBpbiBtb3JlIGRldGFpbHMuIA0K DQpUaGUgYXV0aG9ycyByZXNwZWN0IHRoZSBXRydzIGRlY2lzaW9uLCBhbmQgaWYgdGhlcmUgaXMg bm8gY29uc2Vuc3VzLCB0aGVzZSANCnBhcnRzIHdpbGwgYmUgZGVsZXRlZCBpbiBuZXh0IHZlcnNp b24uDQoNCkJlIGFwb2xvZ2l6ZWQNCg0KRmVpDQoNCg0KDQp6aGFuZy5mZWkzQHp0ZS5jb20uY24g DQq3orz+yMs6ICBjY2FtcC1ib3VuY2VzQGlldGYub3JnDQoyMDEyLTA4LTE2IDE0OjU4DQoNCsrV vP7Iyw0KY2NhbXBAaWV0Zi5vcmcNCrOty80NCg0K1vfM4g0KUmU6IFtDQ0FNUF0gSS1EIEFjdGlv bjogDQpkcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS0wNC50 eHQNCg0KDQoNCg0KDQoNCg0KSGkgYWxsIA0KDQpXZSBoYXZlIHVwbG9hZGVkIGEgbmV3IHZlcnNp b24gb2YgdGhpcyBkcmFmdCwgdGhlIGNoYW5nZXMgYXJlIGxpc3RlZCBhcyANCmJlbG93OiANCg0K MS4gQWRkIG9uZSBwYXJhZ3JhcGggaW4gc2VjdGlvbiAzIHRvIGFkZHJlc3MgdGhlIGV4Y2hhbmdl IG9mIEdsb2JhbF9JRCBpZiANCmNvcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQcyBhcmUgYWNyb3Nz IGRpZmZlcmVudCBkb21haW5zLiANCg0KMi4gQWRkIG9uZSBzZWN0aW9uIDQuMiB0byBkZXNjcmli ZSB0aGUgcHJvY2Vzc2luZyBvZiBBU1NPQ0lBVElPTiBvYmplY3RzIA0Kd2l0aCBBc3NvY2lhdGlv biBUeXBlICJMU1AgSWRlbnRpZmllcnMiIGluIG1vcmUgZGV0YWlscy4gDQoNCjMuIEFkZCAgUmVr ZXNoIGFzIGEgY29hdXRob3IgZm9yIGhpcyByZXZpZXcgYW5kIGNvbnRyaWJ1dGlvbnMuIA0KDQo0 LiBFZGl0b3JpYWwgY2hhbmdlcy4gDQoNClRoZSBhdXRob3JzIGJlbGlldmUgdGhhdCB0aGUgbW90 aXZhdGlvbiBhbmQgc29sdXRpb24gaXMgc3RhYmxlIGFuZCB0aGUgDQpyZWxhdGlvbnNoaXAgYmV0 d2VlbiBkcmFmdCANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAt bXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0IA0KYW5kIHRoaXMgZHJhZnQgaXMg YWxzbyBjbGVhciBub3csIHdvdWxkIGxpa2UgdGhlIFdHIHRvIGNvbnNpZGVyIGl0IA0KYXMgYSBX RyBkb2N1bWVudCBhZnRlciB0aGUgcmV2aWV3LiANCg0KQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21l IA0KDQpCZXN0IA0KDQpGZWkgDQoNCg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIA0Kt6K8/sjL OiAgY2NhbXAtYm91bmNlc0BpZXRmLm9yZyANCjIwMTItMDgtMTYgMTM6MTQgDQoNCg0KytW8/sjL DQppLWQtYW5ub3VuY2VAaWV0Zi5vcmcgDQqzrcvNDQpjY2FtcEBpZXRmLm9yZyANCtb3zOINCltD Q0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1 bm5lbC1udW0tMDQudHh0DQoNCg0KDQoNCg0KDQoNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgDQpkaXJlY3Rvcmll cy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENvbW1vbiBDb250cm9sIGFuZCBN ZWFzdXJlbWVudCBQbGFuZSANCldvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNCiAgICAgICAg ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBSU1ZQLVRFIEV4dGVuc2lvbnMgdG8gRXhjaGFuZ2Ug TVBMUy1UUCANCkxTUCBUdW5uZWwgTnVtYmVycw0KICAgICAgICAgICAgICAgIEF1dGhvcihzKSAg ICAgICA6IEZlaSBaaGFuZw0KICAgICAgICAgICAgICAgICAgICAgICAgIFZlbmthdGVzYW4gTWFo YWxpbmdhbQ0KICAgICAgICAgICAgICAgICAgICAgICAgIFl1bmJpbiBYdQ0KICAgICAgICAgICAg ICAgICAgICAgICAgIFJha2VzaCBHYW5kaGkNCiAgICAgICAgICAgICAgICBGaWxlbmFtZSAgICAg ICAgOiANCmRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTA0 LnR4dA0KICAgICAgICAgICAgICAgIFBhZ2VzICAgICAgICAgICA6IDcNCiAgICAgICAgICAgICAg ICBEYXRlICAgICAgICAgICAgOiAyMDEyLTA4LTE1DQoNCkFic3RyYWN0Og0KICBUaGUgTVBMUyBU cmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgaWRlbnRpZmllcnMgZG9jdW1lbnQgW1JGQzYzNzBd DQogIHNwZWNpZmllcyBhbiBpbml0aWFsIHNldCBvZiBpZGVudGlmaWVycywgaW5jbHVkaW5nIHRo ZSBsb2NhbCBhc3NpZ25lZA0KICBaOS1UdW5uZWxfTnVtLCB3aGljaCBjYW4gYmUgdXNlZCB0byBm b3JtIE1haW50ZW5hbmNlIEVudGl0eSBQb2ludA0KICBJZGVudGlmaWVyIChNRVBfSUQpLiAgQXMg dG8gc29tZSBPcGVyYXRpb24sIEFkbWluaXN0cmF0aW9uIGFuZA0KICBNYWludGVuYW5jZSAoT0FN KSBmdW5jdGlvbnMsIHN1Y2ggYXMgQ29ubmVjdGl2aXR5IFZlcmlmaWNhdGlvbiAoQ1YpDQogIFtS RkM2NDI4XSwgc291cmNlIE1FUF9JRCBtdXN0IGJlIGluc2VydGVkIGluIHRoZSBPQU0gcGFja2V0 cywgc28gdGhhdA0KICB0aGUgcGVlciBlbmRwb2ludCBjYW4gY29tcGFyZSB0aGUgcmVjZWl2ZWQg YW5kIGV4cGVjdGVkIE1FUF9JRHMgdG8NCiAganVkZ2Ugd2hldGhlciB0aGVyZSBpcyBhIG1pcy1j b25uZWN0aXZpdHkgZGVmZWN0IFtSRkM2MzcxXSwgd2hpY2gNCiAgbWVhbnMgdGhhdCB0aGUgdHdv IE1FUCBub2RlcyBuZWVkIHRvIHByZS1zdG9yZSBlYWNoIG90aGVyJ3MgTUVQX0lEcy4NCg0KICBU aGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIHNpZ25hbGluZyBleHRlbnNpb25zIHRvIGNvbW11bmlj YXRlIHRoZQ0KICBsb2NhbCBhc3NpZ25lZCBaOS1UdW5uZWxfTnVtIHRvIHRoZSBpbmdyZXNzIExT UiAoTGFiZWwgU3dpdGNoaW5nDQogIFJvdXRlcikgb2YgYSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25h bCBMU1AuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJh ZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1jY2Ft cC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bQ0KDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxp emVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDQNCg0KDQpBIGRp ZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1l eHQtdHVubmVsLW51bS0wNA0KDQoNCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkND QU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2NhbXANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg0KDQo= --=_alternative 0028F24848257A5D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIExvdTwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBhbSBub3Qgc3VyZSB3aGV0aGVy IHRoaXMgZHJhZnQgc2hvdWxkDQpmb2xsb3cgdGhlIHRoZSBwcm9jZWR1cmVzIGRlZmluZWQgZm9y IFdHIGRvY3VtZW50cyBvciBub3QuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5JZiBpdCBTSE9VTEQsIHRoZSBtYWpvciBjaGFuZ2VzIGFyZQ0KbmVlZGVk IHRvIGhhdmUgYSBjb25zZW5zdXMgaW4gV0cgYmVmb3JlIHB1Ymxpc2hpbmcgdGhlbSBhbHNvLCB3 aGljaCBhcmUNCmxpc3RlZCBiZWxvdzo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPkEpIEFkZCBvbmUgcGFyYWdyYXBoIGluIHNlY3Rpb24gMyB0bw0KYWRk cmVzcyB0aGUgZXhjaGFuZ2Ugb2YgR2xvYmFsX0lEIGlmIGNvcm91dGVkIGJpZGlyZWN0aW9uYWwg TFNQcyBhcmUgYWNyb3NzDQpkaWZmZXJlbnQgZG9tYWlucy4gPGJyPg0KPGJyPg0KQikgQWRkIG9u ZSBzZWN0aW9uIDQuMiB0byBkZXNjcmliZSB0aGUgcHJvY2Vzc2luZyBvZiBBU1NPQ0lBVElPTiBv YmplY3RzDQp3aXRoIEFzc29jaWF0aW9uIFR5cGUgJnF1b3Q7TFNQIElkZW50aWZpZXJzJnF1b3Q7 IGluIG1vcmUgZGV0YWlscy4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5UaGUgYXV0aG9ycyByZXNwZWN0IHRoZSBXRydzIGRlY2lzaW9uLA0KYW5kIGlm IHRoZXJlIGlzIG5vIGNvbnNlbnN1cywgdGhlc2UgcGFydHMgd2lsbCBiZSBkZWxldGVkIGluIG5l eHQgdmVyc2lvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkJlIGFwb2xvZ2l6ZWQ8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkZlaTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj48Yj56aGFuZy5mZWkzQHp0ZS5jb20uY248L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7Y2NhbXAtYm91bmNlc0BpZXRm Lm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTA4LTE2 IDE0OjU4PC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPmNjYW1wQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250Pjwv ZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW0NDQU1QXSBJLUQgQWN0aW9uOiAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7ZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1 bm5lbC1udW0tMDQudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpIGFsbDwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KV2UgaGF2ZSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoaXMg ZHJhZnQsIHRoZSBjaGFuZ2VzIGFyZSBsaXN0ZWQgYXMNCmJlbG93OjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KMS4gQWRkIG9uZSBwYXJhZ3JhcGggaW4gc2VjdGlvbiAzIHRvIGFkZHJl c3MgdGhlIGV4Y2hhbmdlIG9mIEdsb2JhbF9JRA0KaWYgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBM U1BzIGFyZSBhY3Jvc3MgZGlmZmVyZW50IGRvbWFpbnMuPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KMi4gQWRkIG9uZSBzZWN0aW9uIDQuMiB0byBkZXNjcmliZSB0aGUgcHJvY2Vzc2lu ZyBvZiBBU1NPQ0lBVElPTiBvYmplY3RzDQp3aXRoIEFzc29jaWF0aW9uIFR5cGUgJnF1b3Q7TFNQ IElkZW50aWZpZXJzJnF1b3Q7IGluIG1vcmUgZGV0YWlscy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQozLiBBZGQgJm5ic3A7UmVrZXNoIGFzIGEgY29hdXRob3IgZm9yIGhpcyByZXZp ZXcgYW5kIGNvbnRyaWJ1dGlvbnMuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KNC4g RWRpdG9yaWFsIGNoYW5nZXMuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4g PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUaGUgYXV0 aG9ycyBiZWxpZXZlIHRoYXQgdGhlIG1vdGl2YXRpb24gYW5kIHNvbHV0aW9uIGlzIHN0YWJsZSBh bmQgdGhlDQpyZWxhdGlvbnNoaXAgYmV0d2VlbiBkcmFmdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0w NA0KYW5kIHRoaXMgZHJhZnQgaXMgYWxzbyBjbGVhciBub3csIHdvdWxkIGxpa2UgdGhlIFdHIHRv IGNvbnNpZGVyIGl0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KYXMgYSBXRyBkb2N1bWVudCBh ZnRlciB0aGUgcmV2aWV3LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkFueSBjb21t ZW50cyBhcmUgd2VsY29tZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxi cj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQmVzdCA8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KRmVpPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4gPGJyPg0KPGJyPg0KPC9mb250Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PjxiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYj4NCjxicj4NCreivP7IyzogJm5ic3A7Y2Nh bXAtYm91bmNlc0BpZXRmLm9yZzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wOC0xNiAx MzoxNDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGQg d2lkdGg9NzMlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD02JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MyU+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjYW1wQGlldGYub3JnPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ 1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W0ND QU1QXSBJLUQgQWN0aW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ZHJhZnQtemhhbmct Y2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDQudHh0PC9mb250PjwvdGFibGU+ DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTUwJT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PHR0Pjxmb250IHNp emU9Mj48YnI+DQo8YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRyb2wgYW5kIE1lYXN1cmVtZW50IFBsYW5l IFdvcmtpbmcNCkdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGl0bGUgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBSU1ZQLVRFIEV4dGVuc2lvbnMgdG8gRXhjaGFuZ2Ug TVBMUy1UUCBMU1AgVHVubmVsDQpOdW1iZXJzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBdXRob3IocykgJm5ic3A7DQombmJzcDsg Jm5ic3A7IDogRmVpIFpoYW5nPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyBWZW5r YXRlc2FuIE1haGFsaW5nYW08YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IFl1bmJp biBYdTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgUmFrZXNoIEdhbmRoaTxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 RmlsZW5hbWUgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOzogZHJhZnQtemhhbmctY2NhbXAt bXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDQudHh0PGJyPg0KICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQYWdlcyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyA6IDc8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0RhdGUgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAyMDEyLTA4LTE1PGJyPg0KPGJyPg0KQWJzdHJhY3Q6 PGJyPg0KICZuYnNwO1RoZSBNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBpZGVudGlm aWVycyBkb2N1bWVudCBbUkZDNjM3MF08YnI+DQogJm5ic3A7c3BlY2lmaWVzIGFuIGluaXRpYWwg c2V0IG9mIGlkZW50aWZpZXJzLCBpbmNsdWRpbmcgdGhlIGxvY2FsIGFzc2lnbmVkPGJyPg0KICZu YnNwO1o5LVR1bm5lbF9OdW0sIHdoaWNoIGNhbiBiZSB1c2VkIHRvIGZvcm0gTWFpbnRlbmFuY2Ug RW50aXR5IFBvaW50PGJyPg0KICZuYnNwO0lkZW50aWZpZXIgKE1FUF9JRCkuICZuYnNwO0FzIHRv IHNvbWUgT3BlcmF0aW9uLCBBZG1pbmlzdHJhdGlvbg0KYW5kPGJyPg0KICZuYnNwO01haW50ZW5h bmNlIChPQU0pIGZ1bmN0aW9ucywgc3VjaCBhcyBDb25uZWN0aXZpdHkgVmVyaWZpY2F0aW9uIChD Vik8YnI+DQogJm5ic3A7W1JGQzY0MjhdLCBzb3VyY2UgTUVQX0lEIG11c3QgYmUgaW5zZXJ0ZWQg aW4gdGhlIE9BTSBwYWNrZXRzLCBzbw0KdGhhdDxicj4NCiAmbmJzcDt0aGUgcGVlciBlbmRwb2lu dCBjYW4gY29tcGFyZSB0aGUgcmVjZWl2ZWQgYW5kIGV4cGVjdGVkIE1FUF9JRHMNCnRvPGJyPg0K ICZuYnNwO2p1ZGdlIHdoZXRoZXIgdGhlcmUgaXMgYSBtaXMtY29ubmVjdGl2aXR5IGRlZmVjdCBb UkZDNjM3MV0sIHdoaWNoPGJyPg0KICZuYnNwO21lYW5zIHRoYXQgdGhlIHR3byBNRVAgbm9kZXMg bmVlZCB0byBwcmUtc3RvcmUgZWFjaCBvdGhlcidzIE1FUF9JRHMuPGJyPg0KPGJyPg0KICZuYnNw O1RoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgc2lnbmFsaW5nIGV4dGVuc2lvbnMgdG8gY29tbXVu aWNhdGUgdGhlPGJyPg0KICZuYnNwO2xvY2FsIGFzc2lnbmVkIFo5LVR1bm5lbF9OdW0gdG8gdGhl IGluZ3Jlc3MgTFNSIChMYWJlbCBTd2l0Y2hpbmc8YnI+DQogJm5ic3A7Um91dGVyKSBvZiBhIGNv LXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUC48YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQt dHVubmVsLW51bTxicj4NCjxicj4NClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZh aWxhYmxlIGF0Ojxicj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNj YW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTA0PGJyPg0KPGJyPg0KQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCmh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4 dC10dW5uZWwtbnVtLTA0PGJyPg0KPGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCmZ0cDovL2Z0cC5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQpDQ0FNUEBpZXRm Lm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8YnI+ DQo8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250 Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQpDQ0FNUEBpZXRmLm9yZzxicj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8YnI+DQo8L2ZvbnQ+ PC90dD4NCjxicj4NCg== --=_alternative 0028F24848257A5D_=-- From francesco.fondelli@gmail.com Fri Aug 17 01:48:51 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8740B21F858E for ; Fri, 17 Aug 2012 01:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVYlNFnckb5i for ; Fri, 17 Aug 2012 01:48:50 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3855921F8589 for ; Fri, 17 Aug 2012 01:48:50 -0700 (PDT) Received: by yhq56 with SMTP id 56so4126951yhq.31 for ; Fri, 17 Aug 2012 01:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RDMxk8Tcb6ko8aULuUsili8OyHpaQfz9Ef5VHLFc+fU=; b=WooeqH/QasqL+kzWb7HGb0w+2u81+gx5hI8CTESOJbTCQR8N8qmDzebryGsZSsHOmK A0dcADdCU7HK4tInidf40+i5DboudSzkxvEb0jAf5RCmdTzvXWru543YoN/JRB0nmaOT 874Q5ImAeHp2NiYXKYt6JwVJbUr+T2a/TBasKCFo0NUOXVBG48DShQY6ChxYGcHHIEGJ OEcKrwACmu/LME1/4qgHR3aWu241i4o4BHNgXhSaZEOgKSf7MK71LK/AqpRJzElotg0J 9L+X/Lk4lziuYQ91jsP/GeXG4A2f7LDtjwSd2rkybiqM9S5zbWP9sJcBdvOVcMhtEY5h bHLg== MIME-Version: 1.0 Received: by 10.66.87.2 with SMTP id t2mr8126980paz.6.1345193329127; Fri, 17 Aug 2012 01:48:49 -0700 (PDT) Received: by 10.66.249.135 with HTTP; Fri, 17 Aug 2012 01:48:49 -0700 (PDT) In-Reply-To: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> Date: Fri, 17 Aug 2012 10:48:49 +0200 Message-ID: From: Francesco Fondelli To: "Rakesh Gandhi (rgandhi)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 08:48:51 -0000 Hi All, I think I'm lost, please help. Rakesh is talking about "co-routed associated bidirectional LSP"... for the sake of clarity, let me try to categorize LSPs from a control plane view point: a) Point-to-point unidirectional b) Point-to-point co-routed bidirectional c) Point-to-point associated bidirectional c1) fwd and rev LSP follow different paths c2) fwd and rev LSP follow same path d) Point-to-multipoint unidirectional e) Multipoint-to-point unidirectional Is section 3.2.5 (Signaling of Co-routed LSPs) of mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? In my opinion: - b) should be signaled with 3473 - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) Am I missing something? thank you ciao fra PS from a data-plane view point b) and c2) are the same thing. On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, > > Thanks for initiating discussions on the changes in the draft. > > Agree with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can alwa= ys submit a new draft just for that. We respect your/WG decision. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 6:08 PM > To: John E Drake > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The chai= rs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I cov= ered in earlier mail, my feeling is to let the discussion take place on the= list (and at the next IETF, if needed) and then have the draft updated to = reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your email, >> below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes >>> that have not been discussed by the WG. Correct me if I get them >>> wrong, but I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate >>> different fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From zhang.fei3@zte.com.cn Fri Aug 17 02:31:48 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7F221F853B; Fri, 17 Aug 2012 02:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.192 X-Spam-Level: X-Spam-Status: No, score=-97.192 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWKNY0FbtyQF; Fri, 17 Aug 2012 02:31:46 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id C606921F8532; Fri, 17 Aug 2012 02:31:45 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 107231461793122; Fri, 17 Aug 2012 17:17:43 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 14596.5251907761; Fri, 17 Aug 2012 17:31:24 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q7H9VG2d007990; Fri, 17 Aug 2012 17:31:16 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Francesco Fondelli MIME-Version: 1.0 X-KeepSent: 13CD29DB:2FE090B2-48257A5D:0033B400; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 17 Aug 2012 17:31:06 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-17 17:30:57, Serialize complete at 2012-08-17 17:30:57 Content-Type: multipart/alternative; boundary="=_alternative 00343B3248257A5D_=" X-MAIL: mse01.zte.com.cn q7H9VG2d007990 Cc: "ccamp@ietf.org" , ccamp-bounces@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 09:31:48 -0000 This is a multipart message in MIME format. --=_alternative 00343B3248257A5D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRnJhbmNlc2NvLCBzbmlwcGVkDQoNCklzIHNlY3Rpb24gMy4yLjUgKFNpZ25hbGluZyBvZiBD by1yb3V0ZWQgTFNQcykgb2YNCm1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcCBhYm91 dCBiKSBvciBpdCBpcyBhYm91dCBjMik/DQoNCjxmZWk+IEl0IGlzIGFib3V0IGMyKSwgaW4gb3Ro ZXIgd29yZHMsIGl0IGlzIFNpZ25hbGluZyBvZiBhc3NvY2lhdGVkIA0KY29uZ3J1ZW50IExTUHMu DQoNCkJlc3QgDQoNCkZlaQ0KDQoNCg0KRnJhbmNlc2NvIEZvbmRlbGxpIDxmcmFuY2VzY28uZm9u ZGVsbGlAZ21haWwuY29tPiANCreivP7IyzogIGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTIt MDgtMTcgMTY6NDgNCg0KytW8/sjLDQoiUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkiIDxyZ2FuZGhp QGNpc2NvLmNvbT4NCrOty80NCiJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPg0K1vfM 4g0KUmU6IFtDQ0FNUF0gSS1EIEFjdGlvbjogDQpkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2 cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCg0KDQoNCg0KDQoNCkhpIEFsbCwNCg0KSSB0 aGluayBJJ20gbG9zdCwgcGxlYXNlIGhlbHAuDQoNClJha2VzaCBpcyB0YWxraW5nIGFib3V0ICJj by1yb3V0ZWQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQpMU1AiLi4uIGZvciB0aGUgc2FrZSBv ZiBjbGFyaXR5LCBsZXQgbWUgdHJ5IHRvIGNhdGVnb3JpemUNCkxTUHMgZnJvbSBhIGNvbnRyb2wg cGxhbmUgdmlldyBwb2ludDoNCg0KICBhKSBQb2ludC10by1wb2ludCB1bmlkaXJlY3Rpb25hbA0K ICBiKSBQb2ludC10by1wb2ludCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KICBjKSBQb2ludC10 by1wb2ludCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCiAgIGMxKSBmd2QgYW5kIHJldiBMU1Ag Zm9sbG93IGRpZmZlcmVudCBwYXRocw0KICAgYzIpIGZ3ZCBhbmQgcmV2IExTUCBmb2xsb3cgc2Ft ZSBwYXRoDQogIGQpIFBvaW50LXRvLW11bHRpcG9pbnQgdW5pZGlyZWN0aW9uYWwNCiAgZSkgTXVs dGlwb2ludC10by1wb2ludCB1bmlkaXJlY3Rpb25hbA0KDQpJcyBzZWN0aW9uIDMuMi41IChTaWdu YWxpbmcgb2YgQ28tcm91dGVkIExTUHMpIG9mDQptcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRl ZC1sc3AgYWJvdXQgYikgb3IgaXQgaXMgYWJvdXQgYzIpPw0KDQpJbiBteSBvcGluaW9uOg0KDQot IGIpIHNob3VsZCBiZSBzaWduYWxlZCB3aXRoIDM0NzMNCi0gYykgYXJlIGFkZHJlc3NlZCBieSB0 aGlzIEktRCAobXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwKQ0KDQpBbSBJIG1pc3Np bmcgc29tZXRoaW5nPw0KDQp0aGFuayB5b3UNCmNpYW8NCmZyYQ0KDQpQUw0KZnJvbSBhIGRhdGEt cGxhbmUgdmlldyBwb2ludCBiKSBhbmQgYzIpIGFyZSB0aGUgc2FtZSB0aGluZy4NCg0KT24gRnJp LCBBdWcgMTcsIDIwMTIgYXQgMTI6MTYgQU0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo8cmdh bmRoaUBjaXNjby5jb20+IHdyb3RlOg0KPiBIaSBMb3UsDQo+DQo+IFRoYW5rcyBmb3IgaW5pdGlh dGluZyBkaXNjdXNzaW9ucyBvbiB0aGUgY2hhbmdlcyBpbiB0aGUgZHJhZnQuDQo+DQo+IEFncmVl IHdpdGggeW91IGhlcmUsIGlmIHdlL1dHIGRvIG5vdCBhZ3JlZSBvbiB0aGUgImNvLXJvdXRlZCBh c3NvY2lhdGVkIA0KYmlkaXJlY3Rpb25hbCBMU1AiIHBhcnQsIHdlIGFyZSBvayB0byByZW1vdmUg aXQgZnJvbSB0aGlzIGRyYWZ0IGFuZCBjYW4gDQphbHdheXMgc3VibWl0IGEgbmV3IGRyYWZ0IGp1 c3QgZm9yIHRoYXQuIFdlIHJlc3BlY3QgeW91ci9XRyBkZWNpc2lvbi4NCj4NCj4gVGhhbmtzLA0K PiBSYWtlc2gNCj4NCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog TG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+IFNlbnQ6IFRodXJzZGF5LCBB dWd1c3QgMTYsIDIwMTIgNjowOCBQTQ0KPiBUbzogSm9obiBFIERyYWtlDQo+IENjOiBSYWtlc2gg R2FuZGhpIChyZ2FuZGhpKTsgY2NhbXBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtDQ0FNUF0g SS1EIEFjdGlvbjogDQpkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lh dGVkLWxzcC0wNC50eHQNCj4NCj4gSm9obiwNCj4gICAgICAgICBXaGlsZSBzdHJpY3RseSBzcGVh a2luZyBXRyBkcmFmdHMgc2hvdWxkIG9ubHkgcmVmbGVjdCBjdXJyZW50IFdHIA0KY29uc2Vuc3Vz LCBhbmQgaXQgaXMgdGhlIFdHIGRyYWZ0IGVkaXRvcidzIGpvYiB0byBlbnN1cmUgdGhpcywgaW4g cHJhY3RpY2UgDQphdXRob3JzL2VkaXRvcnMgYXJlIGdpdmVuIGEgbG90IG9mIGxhdGl0dWRlIGlu IHRpbWluZyAvIG9yZGVyaW5nIGluIA0KaW50cm9kdWN0aW9uIHRvIGNoYW5nZXMuICBJIHBlcnNv bmFsbHkgdGhpbmsgdGhpcyBpcyBhIHByYWN0aWNhbCB3YXkgb2YgDQprZWVwaW5nIHRoZSBwcm9j ZXNzIG1vdmluZy4gIEFsc28gaWYgdGhlIFdHIGRpc2FncmVlcyB3aXRoIGEgY2hhbmdlLCBpdCAN CmNhbiBhbHdheXMgYmUgYmFja2VkIG91dC4NCj4NCj4gU28sIHllcywgdGhlIFdHIGNvdWxkIGRv IGV4YWN0bHkgYXMgeW91IHNheSBpZiBpdCBjb21lcyB0byBpdC4gIChUaGUgDQpjaGFpcnMgY2Fu IGV2ZW4gYXBwb2ludCBkaWZmZXJlbnQgZWRpdG9yIGlmIG5lZWRlZCwgZS5nLiwgdG8gbWFrZSB0 aGlzDQo+IGhhcHBlbi4pICBXaGlsZSBJJ20gbm90IGhhcHB5IHdpdGggaG93IHRoaXMgcmV2aXNp b24gY2FtZSBhYm91dCwgYXMgSSANCmNvdmVyZWQgaW4gZWFybGllciBtYWlsLCBteSBmZWVsaW5n IGlzIHRvIGxldCB0aGUgZGlzY3Vzc2lvbiB0YWtlIHBsYWNlIG9uIA0KdGhlIGxpc3QgKGFuZCBh dCB0aGUgbmV4dCBJRVRGLCBpZiBuZWVkZWQpIGFuZCB0aGVuIGhhdmUgdGhlIGRyYWZ0IHVwZGF0 ZWQgDQp0byByZWZsZWN0IHRoZSBXRyBkaXNjdXNzaW9uL2NvbnNlbnN1cy4NCj4NCj4gTG91DQo+ DQo+IE9uIDgvMTYvMjAxMiA1OjM1IFBNLCBKb2huIEUgRHJha2Ugd3JvdGU6DQo+PiBMb3UsDQo+ Pg0KPj4gU2luY2UgdGhlIFdHIGRpZCBub3QgYWdyZWUgdG8gdGhpcyBjaGFuZ2VzLCBsZXQgYWxv bmUgZGlzY3VzcyB0aGVtLA0KPj4gd291bGQgaXQgYmUgcG9zc2libGUgdG8gc2ltcGx5IHJvbGxi YWNrIHRoZXNlIGNoYW5nZXMgYW5kIGFzayB0aGUNCj4+IGF1dGhvcnMgdG8gd3JpdGUgYSBkcmFm dCBhZGRyZXNzaW5nIHRoZSB0b3BpY3MgeW91IGxpc3QgaW4geW91ciBlbWFpbCwNCj4+IGJlbG93 Pw0KPj4NCj4+IFRoYW5rcywNCj4+DQo+PiBKb2huDQo+Pg0KPj4gU2VudCBmcm9tIG15IGlQaG9u ZQ0KPj4NCj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBjY2Ft cC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+ PiBCZWhhbGYgT2YgTG91IEJlcmdlcg0KPj4+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTYsIDIw MTIgMjoxMCBQTQ0KPj4+IFRvOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KPj4+IENjOiBjY2Ft cEBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LQ0KPj4+IGFzc29jaWF0ZWQtbHNwLTA0LnR4dA0K Pj4+DQo+Pj4gUmFrZXNoLA0KPj4+ICAgICAgU3VjaCBtYWpvciBjaGFuZ2VzIChpbiBzY29wZSBh bmQgZnVuY3Rpb25hbGl0eSkgdG8gV0cgZHJhZnRzIGFyZQ0KPj4+IHVzdWFsbHkgZGlzY3Vzc2Vk IHdpdGggdGhlIFdHIHByaW9yIHRvIHRoZSBhdXRob3JzL2VkaXRvcnMganVzdA0KPj4+IHB1Ymxp c2hpbmcgdGhlIGNoYW5nZXMuICBCdXQsIHRoaXMgaXMgYSBqdWRnbWVudCBjYWxsIGJ5IHRoZSBk b2N1bWVudA0KPj4+IGVkaXRvcnMgaW4gaG93LCBxdW90aW5nIHJmYzI0MTgsIHRoZXkgImVuc3Vy W2VdIHRoYXQgdGhlIGNvbnRlbnRzIG9mDQo+Pj4gdGhlIGRvY3VtZW50IGFjY3VyYXRlbHkgcmVm bGVjdCB0aGUgZGVjaXNpb25zIHRoYXQgaGF2ZSBiZWVuIG1hZGUgYnkNCj4+PiB0aGUgd29ya2lu ZyBncm91cC4iDQo+Pj4NCj4+PiBTbyBsZXQncyBqdW1wIGludG8gZGlzY3Vzc2luZyB0aGUgY2hh bmdlcy4NCj4+Pg0KPj4+IEFzIEkgc2VlIGl0IHRoaXMgZHJhZnQgaW50cm9kdWNlcyBzZXZlcmFs IG1ham9yIGZ1bmN0aW9uYWwgY2hhbmdlcw0KPj4+IHRoYXQgaGF2ZSBub3QgYmVlbiBkaXNjdXNz ZWQgYnkgdGhlIFdHLiAgQ29ycmVjdCBtZSBpZiBJIGdldCB0aGVtDQo+Pj4gd3JvbmcsIGJ1dCBJ IGJlbGlldmUgdGhleSBpbmNsdWRlOg0KPj4+IDEpIEludHJvZHVjdGlvbiBvZiBhIHNlY29uZCBt ZXRob2QgZm9yIHNpZ25hbGluZyBDby1yb3V0ZWQgTFNQcw0KPj4+IDIpIFN1cHBvcnQgZm9yIEZS UiBieXBhc3MgdHVubmVscyBmb3IgcGlnZ3liYWNrZWQgb24gdGhlIFRQDQo+Pj4gYmlkaXJlY3Rp b25hbCBMU1AgbWVjaGFuaXNtcy4NCj4+Pg0KPj4+ICAgIFRoZXJlIGFyZSBhbHNvIG90aGVyIGNo YW5nZXMsIGJ1dCBJJ2xsIGRlZmVyIGRpc2N1c3NpbmcgdGhlbQ0KPj4+ICAgIHVudGlsIHRoZSBk aXNjdXNzaW9uIG9uIHRoZSBhYm92ZSBpcyBjb25jbHVkZWQuDQo+Pj4NCj4+PiBJcyB0aGlzIGNv cnJlY3Q/DQo+Pj4NCj4+PiBBc3N1bWluZyB5ZXMsIEkgaGF2ZSBxdWVzdGlvbnMgYWJvdXQgYm90 aCByYXRpb25hbCBhbmQgc3BlY2lmaWMNCj4+PiBtZWNoYW5pc21zLiAgRm9yIG5vdyBsZXQncyBs b29rIGF0IHRoZSBmb3JtZXIsIHNvIHBsZWFzZToNCj4+Pg0KPj4+IEEpIEFydGljdWxhdGUgdGhl IGlzc3Vlcy9saW1pdGF0aW9ucyB3aXRoIHVzaW5nIHRoZSBSRkMzNDczIGRlZmluZWQNCj4+PiBt ZWNoYW5pc21zIGZvciAoY28tcm91dGVkKSBiaWRpcmVjdGlvbmFsIExTUHMgdGhhdCB5b3UnZCBs aWtlIHRvIHNlZQ0KPj4+IGFkZHJlc3NlZC4NCj4+Pg0KPj4+IEIuMSkgQXJ0aWN1bGF0ZSB0aGUg RlJSL0dNUExTLXJlbGF0ZWQgaXNzdWUgeW91J2QgbGlrZSB0byBhZGRyZXNzPw0KPj4+DQo+Pj4g Qi4yKSBBcnRpY3VsYXRlIHdoeSB0aGlzIGlzc3VlIHNob3VsZCBiZSBzb2x2ZWQgaW4gYSBUUC1z cGVjaWZpYyBhbmQNCj4+PiBub3QgR01QTFMgZ2VuZXJpYyBmYXNoaW9uPw0KPj4+DQo+Pj4gVGhh bmtzLA0KPj4+IExvdQ0KPj4+DQo+Pj4gT24gOC8xNi8yMDEyIDQ6MjYgUE0sIFJha2VzaCBHYW5k aGkgKHJnYW5kaGkpIHdyb3RlOg0KPj4+PiBIaSBMb3UsDQo+Pj4+DQo+Pj4+IFllcy4NCj4+Pj4N Cj4+Pj4gUGxlYXNlIGFkdmlzZSBpZiB5b3UgdGhpbmsgZGV0YWlsZWQgZW1haWwgaXMgcmVxdWly ZWQuDQo+Pj4+IFdlIGJlbGlldmUgbGF0ZXN0IGRyYWZ0IHN1bW1hcml6ZXMgdGhlIGNoYW5nZXMg d2VsbCBhbmQgd2UgY291bGQNCj4+PiBzdGFydCByZXZpZXcvZGlzY3Vzc2lvbnMgZnJvbSB0aGVy ZS4NCj4+Pj4NCj4+Pj4gVGhhbmtzLA0KPj4+PiBSYWtlc2gNCj4+Pj4NCj4+Pj4NCj4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxi ZXJnZXJAbGFibi5uZXRdDQo+Pj4+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTYsIDIwMTIgNDow MCBQTQ0KPj4+PiBUbzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCj4+Pj4gQ2M6IGNjYW1wQGll dGYub3JnOyB6aGFuZy5mZWkzQHp0ZS5jb20uY24NCj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0g SS1EIEFjdGlvbjoNCj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNz b2NpYXRlZC1sc3AtMDQudHh0DQo+Pj4+DQo+Pj4+IFJha2VzaCwNCj4+Pj4gICAgIElzIHRoaXMg dGhlIHN0YXJ0IG9mIHRoZSB0aHJlYWQgdGhhdCBJIHJlcXVlc3RlZCBpbg0KPj4+PiBodHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY2NhbXAvY3VycmVudC9tc2cxMzcyOS5odG1s DQo+Pj4+DQo+Pj4+IEluIHBhcnRpY3VsYXIsIGlzIGl0IHRoZSByZXNwb25zZSB0bzoNCj4+Pj4+ IEknZCBsaWtlIHRvIGFzayB0aGF0IHNvbWVvbmUgKFJha2VzaCwgRmVpLCBldGMuKSByZXZpZXcg ZWFjaCBvZiB0aGUNCj4+Pj4+IHByb3Bvc2VkIGNoYW5nZSBhbmQgdGhlIHJhdGlvbmFsIGZvciBl YWNoIGNoYW5nZSAoaW4gb25lIG9yIGluDQo+Pj4+PiBzZXBhcmF0ZSBlLW1haWxzKS4gVGhlIFdH IGRpc2N1c3Npb24gY2FuIHRoZW4gcmVhbGx5IGJlZ2luIG9uIHRoZQ0KPj4+Pj4gcHJvcG9zZWQg Y2hhbmdlcy4gKFdoaWNoIGFyZSBxdWl0ZSBzdWJzdGFudGlhbCBib3RoIGluIHNjb3BlIGFuZA0K Pj4+Pj4gaW1wbGljYXRpb24uKQ0KPj4+Pg0KPj4+PiBMb3UNCj4+Pj4NCj4+Pj4gT24gOC8xNi8y MDEyIDM6MTkgUE0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIHdyb3RlOg0KPj4+Pj4gSGkgQWxs LA0KPj4+Pj4NCj4+Pj4+IFdlIGhhdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGlzIGRy YWZ0IHdpdGggZm9sbG93aW5nIGNoYW5nZXM6DQo+Pj4+DQo+Pj4+IDEuICBBZGRlZCBhIHNlY3Rp b24gb24gU2lnbmFsaW5nIG9mIENvLXJvdXRlZCBMU1BzDQo+Pj4+DQo+Pj4+IDIuICBBZGRlZCBj bGFyaWZpY2F0aW9uIG9uIFNpZ25hbGluZyBvZiBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwNCj4+ Pj4gUHJvdGVjdGlvbiBMU1BzDQo+Pj4+DQo+Pj4+IDMuICBBZGRlZCBhIHNlY3Rpb24gb24gU2ln bmFsaW5nIG9mIEF1dG8tdHVubmVsIE1lc2gtZ3JvdXAgTFNQcw0KPj4+Pg0KPj4+PiA0LiAgIEFk ZGVkIGNsYXJpZmljYXRpb24gb24gU2lnbmFsaW5nIG9mIEludGVyLWRvbWFpbiBBc3NvY2lhdGVk DQo+Pj4gQmlkaXJlY3Rpb25hbCBMU1BzDQo+Pj4+DQo+Pj4+IDUuICBUaGUgRXh0ZW5kZWQgQVNT T0NJQVRJT04gb2JqZWN0IGZvcm1hdCB3aXRoIEFzc29jaWF0aW9uIFR5cGUNCj4+PiAiQXNzb2Np YXRlZCBCaWRpcmVjdGlvbmFsIExTUCIuIENsYXJpZmllZCBvbiBob3cgdG8gcG9wdWxhdGUNCj4+ PiBkaWZmZXJlbnQgZmllbGRzIGluIHRoaXMgb2JqZWN0Lg0KPj4+Pg0KPj4+Pg0KPj4+Pj4gV2Ug YmVsaWV2ZSB0aGF0IHNvbWUgb2YgdGhlc2UgY2hhbmdlcyB3ZXJlIG5lY2Vzc2FyeSB0byBhdm9p ZCB0aGUNCj4+PiBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyBkdWUgdG8gcG90ZW50aWFsbHkgZGlm ZmVyZW50IGludGVycHJldGF0aW9ucy4NCj4+Pj4+DQo+Pj4+PiBZb3VyIHJldmlldyBjb21tZW50 cyBhcmUgd2VsY29tZS4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MsDQo+Pj4+PiBSYWtlc2gNCj4+Pj4+ DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogY2NhbXAtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj4+PiBC ZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+Pj4+PiBTZW50OiBXZWRuZXNkYXks IEF1Z3VzdCAxNSwgMjAxMiAxMDo1MyBBTQ0KPj4+Pj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9y Zw0KPj4+Pj4gQ2M6IGNjYW1wQGlldGYub3JnDQo+Pj4+PiBTdWJqZWN0OiBbQ0NBTVBdIEktRCBB Y3Rpb246DQo+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lh dGVkLWxzcC0wNC50eHQNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+Pj4gZGlyZWN0 b3JpZXMuDQo+Pj4+PiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENv bnRyb2wgYW5kIE1lYXN1cmVtZW50DQo+Pj4gUGxhbmUgV29ya2luZyBHcm91cCBvZiB0aGUgSUVU Ri4NCj4+Pj4+DQo+Pj4+PiAgICBUaXRsZSAgICAgICAgICAgOiBSU1ZQLVRFIEV4dGVuc2lvbnMg Zm9yIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbA0KPj4+IExTUHMNCj4+Pj4+ICAgIEF1dGhvcihz KSAgICAgICA6IEZlaSBaaGFuZw0KPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICBSdWlx dWFuIEppbmcNCj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgUmFrZXNoIEdhbmRoaQ0K Pj4+Pj4gICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0 ZS1leHQtYXNzb2NpYXRlZC0NCj4+PiBsc3AtMDQudHh0DQo+Pj4+PiAgICBQYWdlcyAgICAgICAg ICAgOiAxNw0KPj4+Pj4gICAgRGF0ZSAgICAgICAgICAgIDogMjAxMi0wOC0xNQ0KPj4+Pj4NCj4+ Pj4+IEFic3RyYWN0Og0KPj4+Pj4gICAgVGhlIE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUgKE1QTFMt VFApIHJlcXVpcmVtZW50cyBkb2N1bWVudA0KPj4+IFtSRkM1NjU0XSwNCj4+Pj4+ICAgIGRlc2Ny aWJlcyB0aGF0IE1QTFMtVFAgTVVTVCBzdXBwb3J0IGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbA0K Pj4+IHBvaW50LQ0KPj4+Pj4gICAgdG8tcG9pbnQgTFNQcy4NCj4+Pj4+DQo+Pj4+PiAgICBUaGlz IGRvY3VtZW50IHByb3ZpZGVzIGEgbWV0aG9kIHRvIGJpbmQgdHdvIHVuaWRpcmVjdGlvbmFsIExh YmVsDQo+Pj4+PiAgICBTd2l0Y2hlZCBQYXRocyAoTFNQcykgaW50byBhbiBhc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgTFNQLiAgVGhlDQo+Pj4+PiAgICBhc3NvY2lhdGlvbiBpcyBhY2hpZXZlZCBi eSBkZWZpbmluZyB0aGUgbmV3IEFzc29jaWF0aW9uIFR5cGUgaW4NCj4+PiB0aGUNCj4+Pj4+ICAg IEV4dGVuZGVkIEFTU09DSUFUSU9OIG9iamVjdC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4+PiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2 cHRlLQ0KPj4+IGV4dC0NCj4+Pj4+IGENCj4+Pj4+IHNzb2NpYXRlZC1sc3ANCj4+Pj4+DQo+Pj4+ PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+Pj4+IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUt ZXh0LQ0KPj4+IGFzc29jaQ0KPj4+Pj4gYQ0KPj4+Pj4gdGVkLWxzcC0wNA0KPj4+Pj4NCj4+Pj4+ IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+Pj4+ IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2NhbXAtbXBscy10 cC1yc3ZwdGUtDQo+Pj4gZXh0LQ0KPj4+Pj4gYQ0KPj4+Pj4gc3NvY2lhdGVkLWxzcC0wNA0KPj4+ Pj4NCj4+Pj4+DQo+Pj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu b255bW91cyBGVFAgYXQ6DQo+Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz Lw0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+Pj4+IENDQU1QQGlldGYub3JnDQo+ Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+Pj4+Pg0K Pj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gQ0NBTVAgbWFpbGlu ZyBsaXN0DQo+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NjYW1wDQo+Pg0KPj4NCj4+DQo+Pg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gQ0NB TVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft cA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1Q IG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY2NhbXANCg0KDQoNCg== --=_alternative 00343B3248257A5D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEZyYW5jZXNjbywgc25pcHBl ZDwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPklzIHNlY3Rpb24gMy4yLjUgKFNp Z25hbGluZyBvZiBDby1yb3V0ZWQgTFNQcykgb2Y8YnI+DQptcGxzLXRwLXJzdnB0ZS1leHQtYXNz b2NpYXRlZC1sc3AgYWJvdXQgYikgb3IgaXQgaXMgYWJvdXQgYzIpPzwvZm9udD48L3R0Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtmZWkm Z3Q7IEl0IGlzIGFib3V0IGMyKSwNCmluIG90aGVyIHdvcmRzLCBpdCBpcyA8L2ZvbnQ+PHR0Pjxm b250IHNpemU9MiBjb2xvcj1ibHVlPlNpZ25hbGluZyBvZiBhc3NvY2lhdGVkDQpjb25ncnVlbnQg TFNQcy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+QmVzdCA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PkZlaTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48 Yj5GcmFuY2VzY28gRm9uZGVsbGkgJmx0O2ZyYW5jZXNjby5mb25kZWxsaUBnbWFpbC5jb20mZ3Q7 PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6 ICZuYnNwO2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MjAxMi0wOC0xNyAxNjo0ODwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtSYWtlc2ggR2FuZGhpIChyZ2Fu ZGhpKSZxdW90Ow0KJmx0O3JnYW5kaGlAY2lzY28uY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ JnF1b3Q7Y2NhbXBAaWV0Zi5vcmcmcXVvdDsgJmx0O2NjYW1wQGlldGYub3JnJmd0OzwvZm9udD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+UmU6IFtDQ0FNUF0gSS1EIEFjdGlvbjogJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwO2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNw LTA0LnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+SGkgQWxsLDxicj4NCjxicj4NCkkgdGhpbmsgSSdtIGxvc3QsIHBsZWFzZSBoZWxw Ljxicj4NCjxicj4NClJha2VzaCBpcyB0YWxraW5nIGFib3V0ICZxdW90O2NvLXJvdXRlZCBhc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWw8YnI+DQpMU1AmcXVvdDsuLi4gZm9yIHRoZSBzYWtlIG9mIGNs YXJpdHksIGxldCBtZSB0cnkgdG8gY2F0ZWdvcml6ZTxicj4NCkxTUHMgZnJvbSBhIGNvbnRyb2wg cGxhbmUgdmlldyBwb2ludDo8YnI+DQo8YnI+DQogJm5ic3A7YSkgUG9pbnQtdG8tcG9pbnQgdW5p ZGlyZWN0aW9uYWw8YnI+DQogJm5ic3A7YikgUG9pbnQtdG8tcG9pbnQgY28tcm91dGVkIGJpZGly ZWN0aW9uYWw8YnI+DQogJm5ic3A7YykgUG9pbnQtdG8tcG9pbnQgYXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsPGJyPg0KICZuYnNwOyBjMSkgZndkIGFuZCByZXYgTFNQIGZvbGxvdyBkaWZmZXJlbnQg cGF0aHM8YnI+DQogJm5ic3A7IGMyKSBmd2QgYW5kIHJldiBMU1AgZm9sbG93IHNhbWUgcGF0aDxi cj4NCiAmbmJzcDtkKSBQb2ludC10by1tdWx0aXBvaW50IHVuaWRpcmVjdGlvbmFsPGJyPg0KICZu YnNwO2UpIE11bHRpcG9pbnQtdG8tcG9pbnQgdW5pZGlyZWN0aW9uYWw8YnI+DQo8YnI+DQpJcyBz ZWN0aW9uIDMuMi41IChTaWduYWxpbmcgb2YgQ28tcm91dGVkIExTUHMpIG9mPGJyPg0KbXBscy10 cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwIGFib3V0IGIpIG9yIGl0IGlzIGFib3V0IGMyKT88 YnI+DQo8YnI+DQpJbiBteSBvcGluaW9uOjxicj4NCjxicj4NCi0gYikgc2hvdWxkIGJlIHNpZ25h bGVkIHdpdGggMzQ3Mzxicj4NCi0gYykgYXJlIGFkZHJlc3NlZCBieSB0aGlzIEktRCAobXBscy10 cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwKTxicj4NCjxicj4NCkFtIEkgbWlzc2luZyBzb21l dGhpbmc/PGJyPg0KPGJyPg0KdGhhbmsgeW91PGJyPg0KY2lhbzxicj4NCmZyYTxicj4NCjxicj4N ClBTPGJyPg0KZnJvbSBhIGRhdGEtcGxhbmUgdmlldyBwb2ludCBiKSBhbmQgYzIpIGFyZSB0aGUg c2FtZSB0aGluZy48YnI+DQo8YnI+DQpPbiBGcmksIEF1ZyAxNywgMjAxMiBhdCAxMjoxNiBBTSwg UmFrZXNoIEdhbmRoaSAocmdhbmRoaSk8YnI+DQombHQ7cmdhbmRoaUBjaXNjby5jb20mZ3Q7IHdy b3RlOjxicj4NCiZndDsgSGkgTG91LDxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyBmb3IgaW5p dGlhdGluZyBkaXNjdXNzaW9ucyBvbiB0aGUgY2hhbmdlcyBpbiB0aGUgZHJhZnQuPGJyPg0KJmd0 Ozxicj4NCiZndDsgQWdyZWUgd2l0aCB5b3UgaGVyZSwgaWYgd2UvV0cgZG8gbm90IGFncmVlIG9u IHRoZSAmcXVvdDtjby1yb3V0ZWQNCmFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AmcXVvdDsg cGFydCwgd2UgYXJlIG9rIHRvIHJlbW92ZSBpdCBmcm9tIHRoaXMNCmRyYWZ0IGFuZCBjYW4gYWx3 YXlzIHN1Ym1pdCBhIG5ldyBkcmFmdCBqdXN0IGZvciB0aGF0LiBXZSByZXNwZWN0IHlvdXIvV0cN CmRlY2lzaW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7IFJha2VzaDxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4u bmV0XTxicj4NCiZndDsgU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxNiwgMjAxMiA2OjA4IFBNPGJy Pg0KJmd0OyBUbzogSm9obiBFIERyYWtlPGJyPg0KJmd0OyBDYzogUmFrZXNoIEdhbmRoaSAocmdh bmRoaSk7IGNjYW1wQGlldGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW0NDQU1QXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxz cC0wNC50eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBKb2huLDxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IFdoaWxlIHN0cmljdGx5IHNwZWFraW5nIFdHIGRyYWZ0cyBzaG91bGQN Cm9ubHkgcmVmbGVjdCBjdXJyZW50IFdHIGNvbnNlbnN1cywgYW5kIGl0IGlzIHRoZSBXRyBkcmFm dCBlZGl0b3IncyBqb2INCnRvIGVuc3VyZSB0aGlzLCBpbiBwcmFjdGljZSBhdXRob3JzL2VkaXRv cnMgYXJlIGdpdmVuIGEgbG90IG9mIGxhdGl0dWRlDQppbiB0aW1pbmcgLyBvcmRlcmluZyBpbiBp bnRyb2R1Y3Rpb24gdG8gY2hhbmdlcy4gJm5ic3A7SSBwZXJzb25hbGx5IHRoaW5rDQp0aGlzIGlz IGEgcHJhY3RpY2FsIHdheSBvZiBrZWVwaW5nIHRoZSBwcm9jZXNzIG1vdmluZy4gJm5ic3A7QWxz byBpZiB0aGUNCldHIGRpc2FncmVlcyB3aXRoIGEgY2hhbmdlLCBpdCBjYW4gYWx3YXlzIGJlIGJh Y2tlZCBvdXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgU28sIHllcywgdGhlIFdHIGNvdWxkIGRvIGV4 YWN0bHkgYXMgeW91IHNheSBpZiBpdCBjb21lcyB0byBpdC4gJm5ic3A7KFRoZQ0KY2hhaXJzIGNh biBldmVuIGFwcG9pbnQgZGlmZmVyZW50IGVkaXRvciBpZiBuZWVkZWQsIGUuZy4sIHRvIG1ha2Ug dGhpczxicj4NCiZndDsgaGFwcGVuLikgJm5ic3A7V2hpbGUgSSdtIG5vdCBoYXBweSB3aXRoIGhv dyB0aGlzIHJldmlzaW9uIGNhbWUgYWJvdXQsDQphcyBJIGNvdmVyZWQgaW4gZWFybGllciBtYWls LCBteSBmZWVsaW5nIGlzIHRvIGxldCB0aGUgZGlzY3Vzc2lvbiB0YWtlDQpwbGFjZSBvbiB0aGUg bGlzdCAoYW5kIGF0IHRoZSBuZXh0IElFVEYsIGlmIG5lZWRlZCkgYW5kIHRoZW4gaGF2ZSB0aGUg ZHJhZnQNCnVwZGF0ZWQgdG8gcmVmbGVjdCB0aGUgV0cgZGlzY3Vzc2lvbi9jb25zZW5zdXMuPGJy Pg0KJmd0Ozxicj4NCiZndDsgTG91PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gOC8xNi8yMDEyIDU6 MzUgUE0sIEpvaG4gRSBEcmFrZSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBMb3UsPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBTaW5jZSB0aGUgV0cgZGlkIG5vdCBhZ3JlZSB0byB0aGlzIGNoYW5n ZXMsIGxldCBhbG9uZSBkaXNjdXNzDQp0aGVtLDxicj4NCiZndDsmZ3Q7IHdvdWxkIGl0IGJlIHBv c3NpYmxlIHRvIHNpbXBseSByb2xsYmFjayB0aGVzZSBjaGFuZ2VzIGFuZCBhc2sNCnRoZTxicj4N CiZndDsmZ3Q7IGF1dGhvcnMgdG8gd3JpdGUgYSBkcmFmdCBhZGRyZXNzaW5nIHRoZSB0b3BpY3Mg eW91IGxpc3QgaW4geW91cg0KZW1haWwsPGJyPg0KJmd0OyZndDsgYmVsb3c/PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBUaGFua3MsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBKb2hu PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBTZW50IGZyb20gbXkgaVBob25lPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10NCk9uPGJyPg0KJmd0OyZndDsmZ3Q7IEJlaGFs ZiBPZiBMb3UgQmVyZ2VyPGJyPg0KJmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3Qg MTYsIDIwMTIgMjoxMCBQTTxicj4NCiZndDsmZ3Q7Jmd0OyBUbzogUmFrZXNoIEdhbmRoaSAocmdh bmRoaSk8YnI+DQomZ3Q7Jmd0OyZndDsgQ2M6IGNjYW1wQGlldGYub3JnPGJyPg0KJmd0OyZndDsm Z3Q7IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtbXBs cy10cC1yc3ZwdGUtZXh0LTxicj4NCiZndDsmZ3Q7Jmd0OyBhc3NvY2lhdGVkLWxzcC0wNC50eHQ8 YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgUmFrZXNoLDxicj4NCiZndDsmZ3Q7 Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1N1Y2ggbWFqb3IgY2hhbmdlcyAoaW4gc2NvcGUgYW5k IGZ1bmN0aW9uYWxpdHkpDQp0byBXRyBkcmFmdHMgYXJlPGJyPg0KJmd0OyZndDsmZ3Q7IHVzdWFs bHkgZGlzY3Vzc2VkIHdpdGggdGhlIFdHIHByaW9yIHRvIHRoZSBhdXRob3JzL2VkaXRvcnMNCmp1 c3Q8YnI+DQomZ3Q7Jmd0OyZndDsgcHVibGlzaGluZyB0aGUgY2hhbmdlcy4gJm5ic3A7QnV0LCB0 aGlzIGlzIGEganVkZ21lbnQgY2FsbA0KYnkgdGhlIGRvY3VtZW50PGJyPg0KJmd0OyZndDsmZ3Q7 IGVkaXRvcnMgaW4gaG93LCBxdW90aW5nIHJmYzI0MTgsIHRoZXkgJnF1b3Q7ZW5zdXJbZV0gdGhh dA0KdGhlIGNvbnRlbnRzIG9mPGJyPg0KJmd0OyZndDsmZ3Q7IHRoZSBkb2N1bWVudCBhY2N1cmF0 ZWx5IHJlZmxlY3QgdGhlIGRlY2lzaW9ucyB0aGF0IGhhdmUgYmVlbg0KbWFkZSBieTxicj4NCiZn dDsmZ3Q7Jmd0OyB0aGUgd29ya2luZyBncm91cC4mcXVvdDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgU28gbGV0J3MganVtcCBpbnRvIGRpc2N1c3NpbmcgdGhlIGNoYW5nZXMu PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEFzIEkgc2VlIGl0IHRoaXMgZHJh ZnQgaW50cm9kdWNlcyBzZXZlcmFsIG1ham9yIGZ1bmN0aW9uYWwNCmNoYW5nZXM8YnI+DQomZ3Q7 Jmd0OyZndDsgdGhhdCBoYXZlIG5vdCBiZWVuIGRpc2N1c3NlZCBieSB0aGUgV0cuICZuYnNwO0Nv cnJlY3QgbWUgaWYNCkkgZ2V0IHRoZW08YnI+DQomZ3Q7Jmd0OyZndDsgd3JvbmcsIGJ1dCBJIGJl bGlldmUgdGhleSBpbmNsdWRlOjxicj4NCiZndDsmZ3Q7Jmd0OyAxKSBJbnRyb2R1Y3Rpb24gb2Yg YSBzZWNvbmQgbWV0aG9kIGZvciBzaWduYWxpbmcgQ28tcm91dGVkDQpMU1BzPGJyPg0KJmd0OyZn dDsmZ3Q7IDIpIFN1cHBvcnQgZm9yIEZSUiBieXBhc3MgdHVubmVscyBmb3IgcGlnZ3liYWNrZWQg b24gdGhlIFRQPGJyPg0KJmd0OyZndDsmZ3Q7IGJpZGlyZWN0aW9uYWwgTFNQIG1lY2hhbmlzbXMu PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtUaGVyZSBh cmUgYWxzbyBvdGhlciBjaGFuZ2VzLCBidXQgSSdsbCBkZWZlcg0KZGlzY3Vzc2luZyB0aGVtPGJy Pg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDt1bnRpbCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUg YWJvdmUgaXMgY29uY2x1ZGVkLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJ cyB0aGlzIGNvcnJlY3Q/PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEFzc3Vt aW5nIHllcywgSSBoYXZlIHF1ZXN0aW9ucyBhYm91dCBib3RoIHJhdGlvbmFsIGFuZCBzcGVjaWZp Yzxicj4NCiZndDsmZ3Q7Jmd0OyBtZWNoYW5pc21zLiAmbmJzcDtGb3Igbm93IGxldCdzIGxvb2sg YXQgdGhlIGZvcm1lciwgc28gcGxlYXNlOjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyBBKSBBcnRpY3VsYXRlIHRoZSBpc3N1ZXMvbGltaXRhdGlvbnMgd2l0aCB1c2luZyB0aGUg UkZDMzQ3Mw0KZGVmaW5lZDxicj4NCiZndDsmZ3Q7Jmd0OyBtZWNoYW5pc21zIGZvciAoY28tcm91 dGVkKSBiaWRpcmVjdGlvbmFsIExTUHMgdGhhdCB5b3UnZCBsaWtlDQp0byBzZWU8YnI+DQomZ3Q7 Jmd0OyZndDsgYWRkcmVzc2VkLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBC LjEpIEFydGljdWxhdGUgdGhlIEZSUi9HTVBMUy1yZWxhdGVkIGlzc3VlIHlvdSdkIGxpa2UgdG8N CmFkZHJlc3M/PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEIuMikgQXJ0aWN1 bGF0ZSB3aHkgdGhpcyBpc3N1ZSBzaG91bGQgYmUgc29sdmVkIGluIGEgVFAtc3BlY2lmaWMNCmFu ZDxicj4NCiZndDsmZ3Q7Jmd0OyBub3QgR01QTFMgZ2VuZXJpYyBmYXNoaW9uPzxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGFua3MsPGJyPg0KJmd0OyZndDsmZ3Q7IExvdTxi cj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBPbiA4LzE2LzIwMTIgNDoyNiBQTSwg UmFrZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBIaSBM b3UsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgWWVzLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFBsZWFzZSBhZHZpc2UgaWYg eW91IHRoaW5rIGRldGFpbGVkIGVtYWlsIGlzIHJlcXVpcmVkLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgV2UgYmVsaWV2ZSBsYXRlc3QgZHJhZnQgc3VtbWFyaXplcyB0aGUgY2hhbmdlcyB3ZWxsIGFu ZA0Kd2UgY291bGQ8YnI+DQomZ3Q7Jmd0OyZndDsgc3RhcnQgcmV2aWV3L2Rpc2N1c3Npb25zIGZy b20gdGhlcmUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVGhh bmtzLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgUmFrZXNoPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBGcm9tOiBMb3UgQmVyZ2VyIFttYWls dG86bGJlcmdlckBsYWJuLm5ldF08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5 LCBBdWd1c3QgMTYsIDIwMTIgNDowMCBQTTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVG86IFJha2Vz aCBHYW5kaGkgKHJnYW5kaGkpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBDYzogY2NhbXBAaWV0Zi5v cmc7IHpoYW5nLmZlaTNAenRlLmNvbS5jbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgU3ViamVjdDog UmU6IFtDQ0FNUF0gSS1EIEFjdGlvbjo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0LWlldGYt Y2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dDxicj4NCiZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFJha2VzaCw8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7ICZuYnNwOyAmbmJzcDsgSXMgdGhpcyB0aGUgc3RhcnQgb2YgdGhlIHRocmVhZCB0aGF0 IEkgcmVxdWVzdGVkDQppbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL2NjYW1wL2N1cnJlbnQvbXNnMTM3MjkuaHRtbDxicj4NCiZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEluIHBhcnRpY3VsYXIsIGlzIGl0IHRo ZSByZXNwb25zZSB0bzo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJJ2QgbGlrZSB0byBhc2sg dGhhdCBzb21lb25lIChSYWtlc2gsIEZlaSwgZXRjLikgcmV2aWV3DQplYWNoIG9mIHRoZTxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByb3Bvc2VkIGNoYW5nZSBhbmQgdGhlIHJhdGlvbmFsIGZv ciBlYWNoIGNoYW5nZSAoaW4NCm9uZSBvciBpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNl cGFyYXRlIGUtbWFpbHMpLiBUaGUgV0cgZGlzY3Vzc2lvbiBjYW4gdGhlbiByZWFsbHkNCmJlZ2lu IG9uIHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByb3Bvc2VkIGNoYW5nZXMuIChXaGlj aCBhcmUgcXVpdGUgc3Vic3RhbnRpYWwgYm90aA0KaW4gc2NvcGUgYW5kPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgaW1wbGljYXRpb24uKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7IExvdTxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IE9uIDgvMTYvMjAxMiAzOjE5IFBNLCBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSB3cm90ZTo8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSBBbGwsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXZSBoYXZlIHVwbG9hZGVkIGEgbmV3IHZlcnNp b24gb2YgdGhpcyBkcmFmdCB3aXRoDQpmb2xsb3dpbmcgY2hhbmdlczo8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAxLiAmbmJzcDtBZGRlZCBhIHNlY3Rpb24gb24g U2lnbmFsaW5nIG9mIENvLXJvdXRlZCBMU1BzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgMi4gJm5ic3A7QWRkZWQgY2xhcmlmaWNhdGlvbiBvbiBTaWduYWxpbmcg b2YgQXNzb2NpYXRlZA0KQmlkaXJlY3Rpb25hbDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgUHJvdGVj dGlvbiBMU1BzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgMy4g Jm5ic3A7QWRkZWQgYSBzZWN0aW9uIG9uIFNpZ25hbGluZyBvZiBBdXRvLXR1bm5lbCBNZXNoLWdy b3VwDQpMU1BzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgNC4g Jm5ic3A7IEFkZGVkIGNsYXJpZmljYXRpb24gb24gU2lnbmFsaW5nIG9mIEludGVyLWRvbWFpbg0K QXNzb2NpYXRlZDxicj4NCiZndDsmZ3Q7Jmd0OyBCaWRpcmVjdGlvbmFsIExTUHM8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA1LiAmbmJzcDtUaGUgRXh0ZW5kZWQg QVNTT0NJQVRJT04gb2JqZWN0IGZvcm1hdCB3aXRoIEFzc29jaWF0aW9uDQpUeXBlPGJyPg0KJmd0 OyZndDsmZ3Q7ICZxdW90O0Fzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1AmcXVvdDsuIENsYXJp ZmllZCBvbiBob3cNCnRvIHBvcHVsYXRlPGJyPg0KJmd0OyZndDsmZ3Q7IGRpZmZlcmVudCBmaWVs ZHMgaW4gdGhpcyBvYmplY3QuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXZSBiZWxpZXZlIHRoYXQgc29tZSBvZiB0 aGVzZSBjaGFuZ2VzIHdlcmUgbmVjZXNzYXJ5DQp0byBhdm9pZCB0aGU8YnI+DQomZ3Q7Jmd0OyZn dDsgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMgZHVlIHRvIHBvdGVudGlhbGx5IGRpZmZlcmVudCBp bnRlcnByZXRhdGlvbnMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBZb3VyIHJldmlldyBjb21tZW50cyBhcmUgd2VsY29tZS48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBSYWtlc2g8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1w LWJvdW5jZXNAaWV0Zi5vcmddDQpPbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJlaGFsZiBP ZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZW50 OiBXZWRuZXNkYXksIEF1Z3VzdCAxNSwgMjAxMiAxMDo1MyBBTTxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBDYzogY2NhbXBAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBb Q0NBTVBdIEktRCBBY3Rpb246PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJhZnQtaWV0Zi1j Y2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lDQpJbnRlcm5ldC1EcmFmdHM8YnI+DQomZ3Q7Jmd0OyZndDsgZGlyZWN0b3JpZXMuPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgQ29tbW9uIENvbnRyb2wNCmFuZCBNZWFzdXJlbWVudDxicj4NCiZndDsmZ3Q7Jmd0OyBQbGFu ZSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwO1RpdGxlICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCjogUlNWUC1URSBFeHRlbnNpb25zIGZvciBBc3NvY2lhdGVk IEJpZGlyZWN0aW9uYWw8YnI+DQomZ3Q7Jmd0OyZndDsgTFNQczxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7ICZuYnNwOyAmbmJzcDtBdXRob3IocykgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBGZWkN ClpoYW5nPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBSdWlxdWFuIEppbmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJha2VzaCBHYW5kaGk8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7RmlsZW5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Og0KZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC08YnI+ DQomZ3Q7Jmd0OyZndDsgbHNwLTA0LnR4dDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNw OyAmbmJzcDtQYWdlcyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQo6IDE3PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwO0RhdGUgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7OiAyMDEyLTA4LTE1PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7VGhlIE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUgKE1Q TFMtVFApDQpyZXF1aXJlbWVudHMgZG9jdW1lbnQ8YnI+DQomZ3Q7Jmd0OyZndDsgW1JGQzU2NTRd LDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtkZXNjcmliZXMgdGhhdCBN UExTLVRQIE1VU1Qgc3VwcG9ydCBhc3NvY2lhdGVkDQpiaWRpcmVjdGlvbmFsPGJyPg0KJmd0OyZn dDsmZ3Q7IHBvaW50LTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDt0by1w b2ludCBMU1BzLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBtZXRob2QgdG8gYmlu ZA0KdHdvIHVuaWRpcmVjdGlvbmFsIExhYmVsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5i c3A7ICZuYnNwO1N3aXRjaGVkIFBhdGhzIChMU1BzKSBpbnRvIGFuIGFzc29jaWF0ZWQNCmJpZGly ZWN0aW9uYWwgTFNQLiAmbmJzcDtUaGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsg Jm5ic3A7YXNzb2NpYXRpb24gaXMgYWNoaWV2ZWQgYnkgZGVmaW5pbmcgdGhlDQpuZXcgQXNzb2Np YXRpb24gVHlwZSBpbjxicj4NCiZndDsmZ3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAmbmJzcDsgJm5ic3A7RXh0ZW5kZWQgQVNTT0NJQVRJT04gb2JqZWN0Ljxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLTxicj4NCiZndDsmZ3Q7Jmd0 OyBleHQtPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHNzb2NpYXRlZC1sc3A8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0 Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LTxicj4NCiZndDsmZ3Q7Jmd0OyBhc3Nv Y2k8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg dGVkLWxzcC0wNDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtPGJyPg0KJmd0OyZndDsmZ3Q7IGV4dC08 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3Nv Y2lhdGVkLWxzcC0wNDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFs c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFANCmF0Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENDQU1Q IG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENDQU1QQGlldGYub3JnPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jY2FtcDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0 OyBDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsgQ0NBTVBAaWV0Zi5vcmc8YnI+ DQomZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft cDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsgQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBDQ0FNUEBpZXRmLm9yZzxi cj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ0NB TVAgbWFpbGluZyBsaXN0PGJyPg0KQ0NBTVBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+ DQo= --=_alternative 00343B3248257A5D_=-- From lberger@labn.net Fri Aug 17 05:34:13 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DC221F8535 for ; Fri, 17 Aug 2012 05:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.195 X-Spam-Level: X-Spam-Status: No, score=-99.195 tagged_above=-999 required=5 tests=[AWL=0.954, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JymjLLacoV+1 for ; Fri, 17 Aug 2012 05:34:12 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 1D5E921F852C for ; Fri, 17 Aug 2012 05:34:12 -0700 (PDT) Received: (qmail 8413 invoked by uid 0); 17 Aug 2012 12:33:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 17 Aug 2012 12:33:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=WWxGUoqA0u8u6gwAhRz5G81qP1NyS6W1B0ggE9TrpgQ=; b=NaVTL/N7tq14VpmYl+tmJDUdKJPmnQiBScJrZYBT+e5sM46SGZEYB6hvBq5wfW6LL+jEeWUvORi48KA6DIuWqN0wdmKBSMd41lX11JZCibT4AVizu6yMruc3RrDR1Cwe; Received: from box313.bluehost.com ([69.89.31.113]:46784 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T2LkK-000519-37; Fri, 17 Aug 2012 06:33:48 -0600 Message-ID: <502E3A2A.7010103@labn.net> Date: Fri, 17 Aug 2012 08:33:46 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 12:34:13 -0000 Fei, It isn't uncommon for authors of WG documents to agree on a change, publish it, then try to confirm consensus with the WG even though the formal procedures say it should happen the other way around. But this isn't typically done with major changes/additions. Either way, it's the responsibility of those proposing/supporting a change to describe the change, and its rationale, to the WG. My original objection (on Wednesday) was that you seemed to bring the WG into the middle of a (perfectly reasonable) private discussion without any context for the WG. This is why I asked for you/Rakesh to review the rational for the changes. (A more typical approach is for the private discussion to be summarized on the list, and to include specific questions/issues for the WG to consider -- but this is up to the individual not formal procedure.) It seems this is now happening, at least in piecemeal fashion, so don't worry about it too much. Lou On 8/16/2012 8:55 PM, zhang.fei3@zte.com.cn wrote: > > Hi Lou, John > > As an editor of this draft, be apologized that I am not familar with the > WG consensus procedures and even do not read RFC2418. It is my fault and > will not happen again. > > Best regards > > Fei > > > *Lou Berger * > ·¢¼þÈË: ccamp-bounces@ietf.org > > 2012-08-17 06:08 > > > ÊÕ¼þÈË > John E Drake > ³­ËÍ > "ccamp@ietf.org" > Ö÷Ìâ > Re: [CCAMP] I-D Action: > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > > > > > > > > John, > While strictly speaking WG drafts should only reflect > current WG > consensus, and it is the WG draft editor's job to ensure this, in > practice authors/editors are given a lot of latitude in timing / > ordering in introduction to changes. I personally think this is a > practical way of keeping the process moving. Also if the WG disagrees > with a change, it can always be backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The > chairs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I > covered in earlier mail, my feeling is to let the discussion take place > on the list (and at the next IETF, if needed) and then have the draft > updated to reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your >> email, below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>> Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to > WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes that >>> have not been discussed by the WG. Correct me if I get them wrong, but >>> I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate different >>> fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for > Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > From lberger@labn.net Fri Aug 17 05:38:13 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5BD21F8539 for ; Fri, 17 Aug 2012 05:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.211 X-Spam-Level: X-Spam-Status: No, score=-99.211 tagged_above=-999 required=5 tests=[AWL=0.938, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vuvawp5ZjtiD for ; Fri, 17 Aug 2012 05:38:13 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id BDC9B21F847D for ; Fri, 17 Aug 2012 05:38:12 -0700 (PDT) Received: (qmail 17072 invoked by uid 0); 17 Aug 2012 12:37:50 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 17 Aug 2012 12:37:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=2G22sESVEmINIpwfr3jkjB9SiiHkcJjUKS4xl0rbRpE=; b=1bDY6YslVwTiEankzo3BtLQAfMGqH0PRFLQNfCWSdSeJXtOlf6WOiNPDdPL9XdHPA7BInxRwTNM8KQhTKEFBaIsElW9DmP8aF0IId7F3xhoNbFQ69PnA7U5C6i2ngBwo; Received: from box313.bluehost.com ([69.89.31.113]:47331 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T2LoE-0006CE-6o; Fri, 17 Aug 2012 06:37:50 -0600 Message-ID: <502E3B1C.4030200@labn.net> Date: Fri, 17 Aug 2012 08:37:48 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 12:38:14 -0000 Fei, Okay, perhaps I read too much into the reference to FRR in the discussion and current text. I'm still trying to understand the rational for the changes and the issues being addressed. Any light you, or anyone else, can shed on this would be most appreciate. Lou On 8/16/2012 9:19 PM, zhang.fei3@zte.com.cn wrote: > > Lou > > Regarding B.1 and B.2 > > 2) Support for FRR bypass tunnels for piggybacked on the TP > bidirectional LSP mechanisms > > B.1) Articulate the FRR/GMPLS-related issue you'd like to address? > > B.2) Articulate why this issue should be solved in a TP-specific and not > GMPLS generic fashion? > > I do not think we introduce the FRR bypass tunnels in this draft, which > is used for local protection (RFC4090). > > Do you see them in section 3.2.4 or section 3.2.6, I personally think > they are GMPLS generic fashion and are totally informational. > > If the descriptions mislead you, please give us some guidance and we are > happy to revise them. > > > Best regards > > Fei > > > *Lou Berger * > > 2012-08-17 05:10 > > > ÊÕ¼þÈË > "Rakesh Gandhi (rgandhi)" > ³­ËÍ > "ccamp@ietf.org" , "zhang.fei3@zte.com.cn" > > Ö÷Ìâ > Re: [CCAMP] I-D Action: > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > > > > > > > > Rakesh, > Such major changes (in scope and functionality) to WG > drafts are > usually discussed with the WG prior to the authors/editors just > publishing the changes. But, this is a judgment call by the document > editors in how, quoting rfc2418, they "ensur[e] that the contents of the > document accurately reflect the decisions that have been made by the > working group." > > So let's jump into discussing the changes. > > As I see it this draft introduces several major functional changes that > have not been discussed by the WG. Correct me if I get them wrong, but > I believe they include: > 1) Introduction of a second method for signaling Co-routed LSPs > 2) Support for FRR bypass tunnels for piggybacked on the TP > bidirectional LSP mechanisms. > > There are also other changes, but I'll defer discussing them > until the discussion on the above is concluded. > > Is this correct? > > Assuming yes, I have questions about both rational and specific > mechanisms. For now let's look at the former, so please: > > A) Articulate the issues/limitations with using the RFC3473 defined > mechanisms for (co-routed) bidirectional LSPs that you'd like to see > addressed. > > B.1) Articulate the FRR/GMPLS-related issue you'd like to address? > > B.2) Articulate why this issue should be solved in a TP-specific and not > GMPLS generic fashion? > > Thanks, > Lou > > On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >> Hi Lou, >> >> Yes. >> >> Please advise if you think detailed email is required. >> We believe latest draft summarizes the changes well and we could start > review/discussions from there. >> >> Thanks, >> Rakesh >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Thursday, August 16, 2012 4:00 PM >> To: Rakesh Gandhi (rgandhi) >> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >> Subject: Re: [CCAMP] I-D Action: > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> Rakesh, >> Is this the start of the thread that I requested in > http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >> >> In particular, is it the response to: >>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>> proposed change and the rational for each change (in one or in >>> separate e-mails). The WG discussion can then really begin on the >>> proposed changes. (Which are quite substantial both in scope and >>> implication.) >> >> Lou >> >> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>> Hi All, >>> >>> We have uploaded a new version of this draft with following changes: >> >> 1. Added a section on Signaling of Co-routed LSPs >> >> 2. Added clarification on Signaling of Associated Bidirectional > Protection LSPs >> >> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >> >> 4. Added clarification on Signaling of Inter-domain Associated > Bidirectional LSPs >> >> 5. The Extended ASSOCIATION object format with Association Type > "Associated Bidirectional LSP". Clarified on how to populate different > fields in this object. >> >> >>> We believe that some of these changes were necessary to avoid the > interoperability issues due to potentially different interpretations. >>> >>> Your review comments are welcome. >>> >>> Thanks, >>> Rakesh >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>> Of internet-drafts@ietf.org >>> Sent: Wednesday, August 15, 2012 10:53 AM >>> To: i-d-announce@ietf.org >>> Cc: ccamp@ietf.org >>> Subject: [CCAMP] I-D Action: >>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >>> This draft is a work item of the Common Control and Measurement > Plane Working Group of the IETF. >>> >>> Title : RSVP-TE Extensions for Associated > Bidirectional LSPs >>> Author(s) : Fei Zhang >>> Ruiquan Jing >>> Rakesh Gandhi >>> Filename : > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>> Pages : 17 >>> Date : 2012-08-15 >>> >>> Abstract: >>> The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], >>> describes that MPLS-TP MUST support associated bidirectional point- >>> to-point LSPs. >>> >>> This document provides a method to bind two unidirectional Label >>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>> association is achieved by defining the new Association Type in the >>> Extended ASSOCIATION object. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-a >>> ssociated-lsp >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associa >>> ted-lsp-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext-a >>> ssociated-lsp-04 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> >> >> >> >> > > From lberger@labn.net Fri Aug 17 07:38:38 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EB621F85D7 for ; Fri, 17 Aug 2012 07:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.283 X-Spam-Level: X-Spam-Status: No, score=-100.283 tagged_above=-999 required=5 tests=[AWL=1.982, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLe2uDIEAg2R for ; Fri, 17 Aug 2012 07:38:37 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 1977A21F85B4 for ; Fri, 17 Aug 2012 07:38:37 -0700 (PDT) Received: (qmail 18158 invoked by uid 0); 17 Aug 2012 14:38:08 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 17 Aug 2012 14:38:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=03gnCDPM1iL31tDb8X8kFE0G5QYRkHEAPx7PIL9CB5k=; b=1fvbXkYkNlBtmc1OxHZMstubBqvct7LV54uyFFBBop7RasVkHLyXE0n4ffPB2hbBCn7QayuPmeFb669bqVua/Xy1EqZCTSVZK26vLhCLPEFNxnx2ICIBQq4era/FXZIA; Received: from box313.bluehost.com ([69.89.31.113]:35549 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T2Nge-0006ag-0W; Fri, 17 Aug 2012 08:38:08 -0600 Message-ID: <502E574E.90405@labn.net> Date: Fri, 17 Aug 2012 10:38:06 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Francesco Fondelli References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 14:38:38 -0000 Francesco, Nice summary. I think your last observation, about b and c2 being the same in the data plane, is the key one. Up to now, I don't know of anyone or any draft that has suggested anything but using b for the control plane representation of co-routed TP paths. The JWT even called out using b. We had a lot of discussion (okay, arguments) about this in the early days of GMPLS where we debated just using the then practice of using EROs to provide a bidirectional co-routed data path using 2 unidirectional control plane LSPs. Obviously the position of using (b) won out. Largely because the b approach greatly simplified the control plane for complex behaviors such as MBB, rerouting, recovery, etc. It does seem that the draft/proposal is in fact for c2, as confirmed by Fei's mail. I was hoping that we could get someone to describe the issue they are trying to address (perhaps as an intended usage scenario) as well as why the added control plane complexity is a good idea. Particularly as all the corner cases need to be addressed. Lou On 8/17/2012 4:48 AM, Francesco Fondelli wrote: > Hi All, > > I think I'm lost, please help. > > Rakesh is talking about "co-routed associated bidirectional > LSP"... for the sake of clarity, let me try to categorize > LSPs from a control plane view point: > > a) Point-to-point unidirectional > b) Point-to-point co-routed bidirectional > c) Point-to-point associated bidirectional > c1) fwd and rev LSP follow different paths > c2) fwd and rev LSP follow same path > d) Point-to-multipoint unidirectional > e) Multipoint-to-point unidirectional > > Is section 3.2.5 (Signaling of Co-routed LSPs) of > mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? > > In my opinion: > > - b) should be signaled with 3473 > - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) > > Am I missing something? > > thank you > ciao > fra > > PS > from a data-plane view point b) and c2) are the same thing. > > On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: >> Hi Lou, >> >> Thanks for initiating discussions on the changes in the draft. >> >> Agree with you here, if we/WG do not agree on the "co-routed associated bidirectional LSP" part, we are ok to remove it from this draft and can always submit a new draft just for that. We respect your/WG decision. >> >> Thanks, >> Rakesh >> >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Thursday, August 16, 2012 6:08 PM >> To: John E Drake >> Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org >> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> John, >> While strictly speaking WG drafts should only reflect current WG consensus, and it is the WG draft editor's job to ensure this, in practice authors/editors are given a lot of latitude in timing / ordering in introduction to changes. I personally think this is a practical way of keeping the process moving. Also if the WG disagrees with a change, it can always be backed out. >> >> So, yes, the WG could do exactly as you say if it comes to it. (The chairs can even appoint different editor if needed, e.g., to make this >> happen.) While I'm not happy with how this revision came about, as I covered in earlier mail, my feeling is to let the discussion take place on the list (and at the next IETF, if needed) and then have the draft updated to reflect the WG discussion/consensus. >> >> Lou >> >> On 8/16/2012 5:35 PM, John E Drake wrote: >>> Lou, >>> >>> Since the WG did not agree to this changes, let alone discuss them, >>> would it be possible to simply rollback these changes and ask the >>> authors to write a draft addressing the topics you list in your email, >>> below? >>> >>> Thanks, >>> >>> John >>> >>> Sent from my iPhone >>> >>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>> Behalf Of Lou Berger >>>> Sent: Thursday, August 16, 2012 2:10 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org >>>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>>> associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Such major changes (in scope and functionality) to WG drafts are >>>> usually discussed with the WG prior to the authors/editors just >>>> publishing the changes. But, this is a judgment call by the document >>>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>>> the document accurately reflect the decisions that have been made by >>>> the working group." >>>> >>>> So let's jump into discussing the changes. >>>> >>>> As I see it this draft introduces several major functional changes >>>> that have not been discussed by the WG. Correct me if I get them >>>> wrong, but I believe they include: >>>> 1) Introduction of a second method for signaling Co-routed LSPs >>>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>>> bidirectional LSP mechanisms. >>>> >>>> There are also other changes, but I'll defer discussing them >>>> until the discussion on the above is concluded. >>>> >>>> Is this correct? >>>> >>>> Assuming yes, I have questions about both rational and specific >>>> mechanisms. For now let's look at the former, so please: >>>> >>>> A) Articulate the issues/limitations with using the RFC3473 defined >>>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>>> addressed. >>>> >>>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>>> >>>> B.2) Articulate why this issue should be solved in a TP-specific and >>>> not GMPLS generic fashion? >>>> >>>> Thanks, >>>> Lou >>>> >>>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi Lou, >>>>> >>>>> Yes. >>>>> >>>>> Please advise if you think detailed email is required. >>>>> We believe latest draft summarizes the changes well and we could >>>> start review/discussions from there. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Thursday, August 16, 2012 4:00 PM >>>>> To: Rakesh Gandhi (rgandhi) >>>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>>> Subject: Re: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> Rakesh, >>>>> Is this the start of the thread that I requested in >>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>>> >>>>> In particular, is it the response to: >>>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>>> proposed change and the rational for each change (in one or in >>>>>> separate e-mails). The WG discussion can then really begin on the >>>>>> proposed changes. (Which are quite substantial both in scope and >>>>>> implication.) >>>>> >>>>> Lou >>>>> >>>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>>> Hi All, >>>>>> >>>>>> We have uploaded a new version of this draft with following changes: >>>>> >>>>> 1. Added a section on Signaling of Co-routed LSPs >>>>> >>>>> 2. Added clarification on Signaling of Associated Bidirectional >>>>> Protection LSPs >>>>> >>>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>>> >>>>> 4. Added clarification on Signaling of Inter-domain Associated >>>> Bidirectional LSPs >>>>> >>>>> 5. The Extended ASSOCIATION object format with Association Type >>>> "Associated Bidirectional LSP". Clarified on how to populate >>>> different fields in this object. >>>>> >>>>> >>>>>> We believe that some of these changes were necessary to avoid the >>>> interoperability issues due to potentially different interpretations. >>>>>> >>>>>> Your review comments are welcome. >>>>>> >>>>>> Thanks, >>>>>> Rakesh >>>>>> >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>> Behalf Of internet-drafts@ietf.org >>>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>>> To: i-d-announce@ietf.org >>>>>> Cc: ccamp@ietf.org >>>>>> Subject: [CCAMP] I-D Action: >>>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>>>> This draft is a work item of the Common Control and Measurement >>>> Plane Working Group of the IETF. >>>>>> >>>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>>> LSPs >>>>>> Author(s) : Fei Zhang >>>>>> Ruiquan Jing >>>>>> Rakesh Gandhi >>>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>>> lsp-04.txt >>>>>> Pages : 17 >>>>>> Date : 2012-08-15 >>>>>> >>>>>> Abstract: >>>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>>> [RFC5654], >>>>>> describes that MPLS-TP MUST support associated bidirectional >>>> point- >>>>>> to-point LSPs. >>>>>> >>>>>> This document provides a method to bind two unidirectional Label >>>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>>> association is achieved by defining the new Association Type in >>>> the >>>>>> Extended ASSOCIATION object. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>>> ext- >>>>>> a >>>>>> ssociated-lsp >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>>> associ >>>>>> a >>>>>> ted-lsp-04 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte- >>>> ext- >>>>>> a >>>>>> ssociated-lsp-04 >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > > > From jdrake@juniper.net Fri Aug 17 10:07:40 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF13F21F8484 for ; Fri, 17 Aug 2012 10:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.66 X-Spam-Level: X-Spam-Status: No, score=-5.66 tagged_above=-999 required=5 tests=[AWL=0.939, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT7CV6DQJJpY for ; Fri, 17 Aug 2012 10:07:40 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id CDFC721F846B for ; Fri, 17 Aug 2012 10:07:39 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUC56Wui2ydsk2GRSBLYxw3QV84yBFdm6@postini.com; Fri, 17 Aug 2012 10:07:39 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 17 Aug 2012 10:07:27 -0700 From: John E Drake To: Lou Berger , "Rakesh Gandhi (rgandhi)" Date: Fri, 17 Aug 2012 10:07:26 -0700 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac17/PgwaZkX4I9GRy2OsUyDuTDXEwAfERpQ Message-ID: <5E893DB832F57341992548CDBB333163A631A84BF8@EMBX01-HQ.jnpr.net> References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <502D6923.6090808@labn.net> <502D716D.9090503@labn.net> In-Reply-To: <502D716D.9090503@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 17:07:41 -0000 Hi, It's my understanding that this draft started by describing how to instanti= ate associated bi-directional LSPs by creating an association in signaling = between two uni-directional LSPs. Then came the observation that these two= uni-directional LSPs might have congruent paths. From what I understand, = the authors then decided it would be useful to have an option to force two = uni-directional LSPs onto congruent paths. This is when the disconnect occurred. I think we should simply state that if a co-routed bi-directional LSP is re= quired use RFC 3473, and we should remove the option of forcing two uni-dir= ectional LSPs onto congruent paths from the draft. I also think that the bi-directional FRR material should be removed from th= e draft. Thanks, John=20 Sent from my iPhone > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Thursday, August 16, 2012 3:17 PM > To: Rakesh Gandhi (rgandhi) > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- > associated-lsp-04.txt >=20 > Rakesh, > See below. >=20 > On 8/16/2012 5:59 PM, Rakesh Gandhi (rgandhi) wrote: > > Hi Lou, > > > > Please see inline.... > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Thursday, August 16, 2012 5:42 PM > > To: Rakesh Gandhi (rgandhi) > > Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn > > Subject: Re: [CCAMP] I-D Action: > > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > > > Rakesh, > > > > On 8/16/2012 5:26 PM, Rakesh Gandhi (rgandhi) wrote: > >> Hi Lou, > >> > >> Thank you for your comments. > >> > >> We had several email exchanges on the alias on "signaling of > >> co-routed LSPs" before it was added in the draft. > > > > I presume you're referring to your private e-mail exchange that was > forwarded to the list, mid-stream, under the subject "Re: [CCAMP] > Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03". > > > > I addressed this in > > http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html. If > you disagree with that e-mail, please respond to it. > > > >> > >> Regarding A) > >> > >> I agree with you that GMPLS signaling can be used for co-routed LSPs > >> and has many advantages. > >> > >> Goal of the associated bidirectional LSPs is to tie the two > >> independent LSPs together. These two LSPs may be non co-routed or > >> co-routed. It is useful for an application to specify the node to > >> request both LSPs go on the same path. Do you agree? > > > > Not sure I understand your question. Per RFC5654 and RFC6373 there > is a stated need for associated and co-routed MPLS TP transport paths. > As discussed in RFC6373, RFC3473 already supports co-routed > bidirectional LSPs. The draft we're discussing covers associated > bidirectional. > > > > Can you rephrase the issue/function that you believe is not addressed > in current signaling RFCs? > > > > I understand what you are saying and do not see any issue there. > > But I am not looking at it from that view point. >=20 > Actually, I'm not making any statement on if there's an issue or not. > I'm asking you to state the issue or new function that you'd like > addressed by a new mechanism. It's really simple, if there's no issue > or need for a new function, then there's no need to defined a new > mechanism. >=20 > I'm guessing that you see an issue or limitation, and I'd genuinely > like to understand what it is. >=20 > > All we are saying is > > that when bidirectional LSPs are associated via signaling, they could > > take the same path and it can be provisioned to do so. >=20 > Well, this is already stated in RFC5654 (and referenced RFC6373). If > that's it, we can easily close this topic. >=20 > Lou >=20 > > > > Thanks, > > Rakesh > > > > Lou > > > >> > >> Thanks, > >> Rakesh > >> > >> > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Thursday, August 16, 2012 5:10 PM > >> To: Rakesh Gandhi (rgandhi) > >> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn > >> Subject: Re: [CCAMP] I-D Action: > >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > >> > >> Rakesh, > >> Such major changes (in scope and functionality) to WG drafts are > usually discussed with the WG prior to the authors/editors just > publishing the changes. But, this is a judgment call by the document > editors in how, quoting rfc2418, they "ensur[e] that the contents of > the document accurately reflect the decisions that have been made by > the working group." > >> > >> So let's jump into discussing the changes. > >> > >> As I see it this draft introduces several major functional changes > that have not been discussed by the WG. Correct me if I get them > wrong, but I believe they include: > >> 1) Introduction of a second method for signaling Co-routed LSPs > >> 2) Support for FRR bypass tunnels for piggybacked on the TP > bidirectional LSP mechanisms. > >> > >> There are also other changes, but I'll defer discussing them > >> until the discussion on the above is concluded. > >> > >> Is this correct? > >> > >> Assuming yes, I have questions about both rational and specific > mechanisms. For now let's look at the former, so please: > >> > >> A) Articulate the issues/limitations with using the RFC3473 defined > mechanisms for (co-routed) bidirectional LSPs that you'd like to see > addressed. > >> > >> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? > >> > >> B.2) Articulate why this issue should be solved in a TP-specific and > not GMPLS generic fashion? > >> > >> Thanks, > >> Lou > >> > >> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: > >>> Hi Lou, > >>> > >>> Yes. > >>> > >>> Please advise if you think detailed email is required. > >>> We believe latest draft summarizes the changes well and we could > start review/discussions from there. > >>> > >>> Thanks, > >>> Rakesh > >>> > >>> > >>> -----Original Message----- > >>> From: Lou Berger [mailto:lberger@labn.net] > >>> Sent: Thursday, August 16, 2012 4:00 PM > >>> To: Rakesh Gandhi (rgandhi) > >>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn > >>> Subject: Re: [CCAMP] I-D Action: > >>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > >>> > >>> Rakesh, > >>> Is this the start of the thread that I requested in > >>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html > >>> > >>> In particular, is it the response to: > >>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of > the > >>>> proposed change and the rational for each change (in one or in > >>>> separate e-mails). The WG discussion can then really begin on the > >>>> proposed changes. (Which are quite substantial both in scope and > >>>> implication.) > >>> > >>> Lou > >>> > >>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: > >>>> Hi All, > >>>> > >>>> We have uploaded a new version of this draft with following > changes: > >>> > >>> 1. Added a section on Signaling of Co-routed LSPs > >>> > >>> 2. Added clarification on Signaling of Associated Bidirectional > >>> Protection LSPs > >>> > >>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs > >>> > >>> 4. Added clarification on Signaling of Inter-domain Associated > Bidirectional LSPs > >>> > >>> 5. The Extended ASSOCIATION object format with Association Type > "Associated Bidirectional LSP". Clarified on how to populate different > fields in this object. > >>> > >>> > >>>> We believe that some of these changes were necessary to avoid the > interoperability issues due to potentially different interpretations. > >>>> > >>>> Your review comments are welcome. > >>>> > >>>> Thanks, > >>>> Rakesh > >>>> > >>>> -----Original Message----- > >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >>>> Behalf Of internet-drafts@ietf.org > >>>> Sent: Wednesday, August 15, 2012 10:53 AM > >>>> To: i-d-announce@ietf.org > >>>> Cc: ccamp@ietf.org > >>>> Subject: [CCAMP] I-D Action: > >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > >>>> > >>>> > >>>> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >>>> This draft is a work item of the Common Control and Measurement > Plane Working Group of the IETF. > >>>> > >>>> Title : RSVP-TE Extensions for Associated Bidirectional > LSPs > >>>> Author(s) : Fei Zhang > >>>> Ruiquan Jing > >>>> Rakesh Gandhi > >>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- > lsp-04.txt > >>>> Pages : 17 > >>>> Date : 2012-08-15 > >>>> > >>>> Abstract: > >>>> The MPLS Transport Profile (MPLS-TP) requirements document > [RFC5654], > >>>> describes that MPLS-TP MUST support associated bidirectional > point- > >>>> to-point LSPs. > >>>> > >>>> This document provides a method to bind two unidirectional > Label > >>>> Switched Paths (LSPs) into an associated bidirectional LSP. > The > >>>> association is achieved by defining the new Association Type in > the > >>>> Extended ASSOCIATION object. > >>>> > >>>> > >>>> The IETF datatracker status page for this draft is: > >>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- > ex > >>>> t > >>>> - > >>>> a > >>>> ssociated-lsp > >>>> > >>>> There's also a htmlized version available at: > >>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- > asso > >>>> c > >>>> i > >>>> a > >>>> ted-lsp-04 > >>>> > >>>> A diff from the previous version is available at: > >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- > ex > >>>> t > >>>> - > >>>> a > >>>> ssociated-lsp-04 > >>>> > >>>> > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> > >>>> _______________________________________________ > >>>> CCAMP mailing list > >>>> CCAMP@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >> > >> > >> > >> > > > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From rgandhi@cisco.com Fri Aug 17 10:28:44 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3A011E80A5 for ; Fri, 17 Aug 2012 10:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFwx1zpH9BNy for ; Fri, 17 Aug 2012 10:28:43 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3733911E809B for ; Fri, 17 Aug 2012 10:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=15830; q=dns/txt; s=iport; t=1345224523; x=1346434123; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xD+c5cnKpFGvzNgdhYkdchHv3msXnmXikkfT0XAQk58=; b=ChBexcdQ7IJ9mAVCP74NqPe5yf3NgSFrFKfnMk3oZCgAosNZjo6Np9Tc Xyn2WNBincvSv2PRlAiPRFyuz2zFRuph/NIGrI6zRxgC2KDUghg6G0Pd+ FRy7VMfzKoN4fUp0Mb53Yuw1WGcZ8xVJr/yJWhBvX4MA9Ue/CgsX7SC9k A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJZ+LlCtJXHA/2dsb2JhbABFhgGzVWmBB4IgAQEBBAEBAQ8BEBE6CwwEAgEIDgMEAQEBAgIGHQMCAgIlCxQBCAgCBAENBQgBFgOHawuaBo0YkyqBIYlqGoVPMmADlmONGIFmgmCBYQ X-IronPort-AV: E=Sophos;i="4.77,785,1336348800"; d="scan'208";a="112715181" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 17 Aug 2012 17:28:34 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7HHSX5l010917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Aug 2012 17:28:33 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Fri, 17 Aug 2012 12:28:33 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger , Francesco Fondelli Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: AQHNfFUlLNlyxvO8A0+szRTdhFvnqpdeZvsA///YPBA= Date: Fri, 17 Aug 2012 17:28:33 +0000 Message-ID: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <502E574E.90405@labn.net> In-Reply-To: <502E574E.90405@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.249.119] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19122.000 x-tm-as-result: No--72.877100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 17:28:44 -0000 VGhhbmtzIEZyYW5jZXNjbyBhbmQgTG91Lg0KDQpKdXN0IGxpa2UgYzEgaW4gdGhlIGluaXRpYWwg cHJvcG9zYWwgb2YgdGhlIGRyYWZ0IGZvciB0aGUgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExT UCwgYzIgYWxsb3dzIHRoZSBNUExTLVRFIHBhY2tldCBjb250cm9sIHBsYW5lIGN1cnJlbnRseSBk ZXBsb3llZCBpbiB0aGUgbmV0d29yayAobm9uIEdNUExTKSB0byBiZSB1c2VkIHRvIHByb3ZpZGUg Y28tcm91dGVkICAoYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsKSBMU1AgZnVuY3Rpb25hbGl0eSB3 aXRob3V0IGhhdmluZyB0byBtaWdyYXRlIHRvIEdNUExTIHByb3RvY29sIGluIFJGQyAzNDczLiAN Cg0KSSBkbyBhZ3JlZSB3aXRoIHlvdSBMb3Ugb24gc29tZSBvZiB0aGUgY29tcGxleGl0eSB0aGF0 IG1heSBjb21lIHdpdGggaXQgKE1CQiwgcmVyb3V0aW5nLCByZWNvdmVyeSwgZXRjLikuDQoNClRo YW5rcywNClJha2VzaA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb3Ug QmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQpTZW50OiBGcmlkYXksIEF1Z3VzdCAx NywgMjAxMiAxMDozOCBBTQ0KVG86IEZyYW5jZXNjbyBGb25kZWxsaQ0KQ2M6IFJha2VzaCBHYW5k aGkgKHJnYW5kaGkpOyBKb2huIEUgRHJha2U7IGNjYW1wQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1h c3NvY2lhdGVkLWxzcC0wNC50eHQNCg0KRnJhbmNlc2NvLA0KDQoJTmljZSBzdW1tYXJ5LiAgSSB0 aGluayB5b3VyIGxhc3Qgb2JzZXJ2YXRpb24sIGFib3V0IGIgYW5kIGMyIGJlaW5nIHRoZSBzYW1l IGluIHRoZSBkYXRhIHBsYW5lLCBpcyB0aGUga2V5IG9uZS4gIFVwIHRvIG5vdywgSSBkb24ndCBr bm93IG9mIGFueW9uZSBvciBhbnkgZHJhZnQgdGhhdCBoYXMgc3VnZ2VzdGVkIGFueXRoaW5nIGJ1 dCB1c2luZyBiIGZvciB0aGUgY29udHJvbCBwbGFuZSByZXByZXNlbnRhdGlvbiBvZiBjby1yb3V0 ZWQgVFAgcGF0aHMuICBUaGUgSldUIGV2ZW4gY2FsbGVkIG91dCB1c2luZyBiLg0KDQpXZSBoYWQg YSBsb3Qgb2YgZGlzY3Vzc2lvbiAob2theSwgYXJndW1lbnRzKSBhYm91dCB0aGlzIGluIHRoZSBl YXJseSBkYXlzIG9mIEdNUExTIHdoZXJlIHdlIGRlYmF0ZWQganVzdCB1c2luZyB0aGUgdGhlbiBw cmFjdGljZSBvZiB1c2luZyBFUk9zIHRvIHByb3ZpZGUgYSBiaWRpcmVjdGlvbmFsIGNvLXJvdXRl ZCBkYXRhIHBhdGggdXNpbmcgMiB1bmlkaXJlY3Rpb25hbCBjb250cm9sIHBsYW5lIExTUHMuICBP YnZpb3VzbHkgdGhlIHBvc2l0aW9uIG9mIHVzaW5nIChiKSB3b24gb3V0LiAgTGFyZ2VseSBiZWNh dXNlIHRoZSBiIGFwcHJvYWNoIGdyZWF0bHkgc2ltcGxpZmllZCB0aGUgY29udHJvbCBwbGFuZSBm b3IgY29tcGxleCBiZWhhdmlvcnMgc3VjaCBhcyBNQkIsIHJlcm91dGluZywgcmVjb3ZlcnksIGV0 Yy4NCg0KSXQgZG9lcyBzZWVtIHRoYXQgdGhlIGRyYWZ0L3Byb3Bvc2FsIGlzIGluIGZhY3QgZm9y IGMyLCBhcyBjb25maXJtZWQgYnkgRmVpJ3MgbWFpbC4gIEkgd2FzIGhvcGluZyB0aGF0IHdlIGNv dWxkIGdldCBzb21lb25lIHRvIGRlc2NyaWJlIHRoZSBpc3N1ZSB0aGV5IGFyZSB0cnlpbmcgdG8g YWRkcmVzcyAocGVyaGFwcyBhcyBhbiBpbnRlbmRlZCB1c2FnZSBzY2VuYXJpbykgYXMgd2VsbCBh cyB3aHkgdGhlIGFkZGVkIGNvbnRyb2wgcGxhbmUgY29tcGxleGl0eSBpcyBhIGdvb2QgaWRlYS4N ClBhcnRpY3VsYXJseSBhcyBhbGwgdGhlIGNvcm5lciBjYXNlcyBuZWVkIHRvIGJlIGFkZHJlc3Nl ZC4NCg0KTG91DQoNCk9uIDgvMTcvMjAxMiA0OjQ4IEFNLCBGcmFuY2VzY28gRm9uZGVsbGkgd3Jv dGU6DQo+IEhpIEFsbCwNCj4gDQo+IEkgdGhpbmsgSSdtIGxvc3QsIHBsZWFzZSBoZWxwLg0KPiAN Cj4gUmFrZXNoIGlzIHRhbGtpbmcgYWJvdXQgImNvLXJvdXRlZCBhc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgTFNQIi4uLiANCj4gZm9yIHRoZSBzYWtlIG9mIGNsYXJpdHksIGxldCBtZSB0cnkgdG8g Y2F0ZWdvcml6ZSBMU1BzIGZyb20gYSBjb250cm9sIA0KPiBwbGFuZSB2aWV3IHBvaW50Og0KPiAN Cj4gICBhKSBQb2ludC10by1wb2ludCB1bmlkaXJlY3Rpb25hbA0KPiAgIGIpIFBvaW50LXRvLXBv aW50IGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsDQo+ICAgYykgUG9pbnQtdG8tcG9pbnQgYXNzb2Np YXRlZCBiaWRpcmVjdGlvbmFsDQo+ICAgIGMxKSBmd2QgYW5kIHJldiBMU1AgZm9sbG93IGRpZmZl cmVudCBwYXRocw0KPiAgICBjMikgZndkIGFuZCByZXYgTFNQIGZvbGxvdyBzYW1lIHBhdGgNCj4g ICBkKSBQb2ludC10by1tdWx0aXBvaW50IHVuaWRpcmVjdGlvbmFsDQo+ICAgZSkgTXVsdGlwb2lu dC10by1wb2ludCB1bmlkaXJlY3Rpb25hbA0KPiANCj4gSXMgc2VjdGlvbiAzLjIuNSAoU2lnbmFs aW5nIG9mIENvLXJvdXRlZCBMU1BzKSBvZiANCj4gbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0 ZWQtbHNwIGFib3V0IGIpIG9yIGl0IGlzIGFib3V0IGMyKT8NCj4gDQo+IEluIG15IG9waW5pb246 DQo+IA0KPiAtIGIpIHNob3VsZCBiZSBzaWduYWxlZCB3aXRoIDM0NzMNCj4gLSBjKSBhcmUgYWRk cmVzc2VkIGJ5IHRoaXMgSS1EIChtcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3ApDQo+ IA0KPiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KPiANCj4gdGhhbmsgeW91DQo+IGNpYW8NCj4g ZnJhDQo+IA0KPiBQUw0KPiBmcm9tIGEgZGF0YS1wbGFuZSB2aWV3IHBvaW50IGIpIGFuZCBjMikg YXJlIHRoZSBzYW1lIHRoaW5nLg0KPiANCj4gT24gRnJpLCBBdWcgMTcsIDIwMTIgYXQgMTI6MTYg QU0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIA0KPiA8cmdhbmRoaUBjaXNjby5jb20+IHdyb3Rl Og0KPj4gSGkgTG91LA0KPj4NCj4+IFRoYW5rcyBmb3IgaW5pdGlhdGluZyBkaXNjdXNzaW9ucyBv biB0aGUgY2hhbmdlcyBpbiB0aGUgZHJhZnQuDQo+Pg0KPj4gQWdyZWUgd2l0aCB5b3UgaGVyZSwg aWYgd2UvV0cgZG8gbm90IGFncmVlIG9uIHRoZSAiY28tcm91dGVkIGFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCBMU1AiIHBhcnQsIHdlIGFyZSBvayB0byByZW1vdmUgaXQgZnJvbSB0aGlzIGRyYWZ0 IGFuZCBjYW4gYWx3YXlzIHN1Ym1pdCBhIG5ldyBkcmFmdCBqdXN0IGZvciB0aGF0LiBXZSByZXNw ZWN0IHlvdXIvV0cgZGVjaXNpb24uDQo+Pg0KPj4gVGhhbmtzLA0KPj4gUmFrZXNoDQo+Pg0KPj4N Cj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogTG91IEJlcmdlciBb bWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+PiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDE2LCAy MDEyIDY6MDggUE0NCj4+IFRvOiBKb2huIEUgRHJha2UNCj4+IENjOiBSYWtlc2ggR2FuZGhpIChy Z2FuZGhpKTsgY2NhbXBAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBBY3Rp b246IA0KPj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1s c3AtMDQudHh0DQo+Pg0KPj4gSm9obiwNCj4+ICAgICAgICAgV2hpbGUgc3RyaWN0bHkgc3BlYWtp bmcgV0cgZHJhZnRzIHNob3VsZCBvbmx5IHJlZmxlY3QgY3VycmVudCBXRyBjb25zZW5zdXMsIGFu ZCBpdCBpcyB0aGUgV0cgZHJhZnQgZWRpdG9yJ3Mgam9iIHRvIGVuc3VyZSB0aGlzLCBpbiBwcmFj dGljZSBhdXRob3JzL2VkaXRvcnMgYXJlIGdpdmVuIGEgbG90IG9mIGxhdGl0dWRlIGluIHRpbWlu ZyAvIG9yZGVyaW5nIGluIGludHJvZHVjdGlvbiB0byBjaGFuZ2VzLiAgSSBwZXJzb25hbGx5IHRo aW5rIHRoaXMgaXMgYSBwcmFjdGljYWwgd2F5IG9mIGtlZXBpbmcgdGhlIHByb2Nlc3MgbW92aW5n LiAgQWxzbyBpZiB0aGUgV0cgZGlzYWdyZWVzIHdpdGggYSBjaGFuZ2UsIGl0IGNhbiBhbHdheXMg YmUgYmFja2VkIG91dC4NCj4+DQo+PiBTbywgeWVzLCB0aGUgV0cgY291bGQgZG8gZXhhY3RseSBh cyB5b3Ugc2F5IGlmIGl0IGNvbWVzIHRvIGl0LiAgKFRoZSANCj4+IGNoYWlycyBjYW4gZXZlbiBh cHBvaW50IGRpZmZlcmVudCBlZGl0b3IgaWYgbmVlZGVkLCBlLmcuLCB0byBtYWtlIA0KPj4gdGhp cw0KPj4gaGFwcGVuLikgIFdoaWxlIEknbSBub3QgaGFwcHkgd2l0aCBob3cgdGhpcyByZXZpc2lv biBjYW1lIGFib3V0LCBhcyBJIGNvdmVyZWQgaW4gZWFybGllciBtYWlsLCBteSBmZWVsaW5nIGlz IHRvIGxldCB0aGUgZGlzY3Vzc2lvbiB0YWtlIHBsYWNlIG9uIHRoZSBsaXN0IChhbmQgYXQgdGhl IG5leHQgSUVURiwgaWYgbmVlZGVkKSBhbmQgdGhlbiBoYXZlIHRoZSBkcmFmdCB1cGRhdGVkIHRv IHJlZmxlY3QgdGhlIFdHIGRpc2N1c3Npb24vY29uc2Vuc3VzLg0KPj4NCj4+IExvdQ0KPj4NCj4+ IE9uIDgvMTYvMjAxMiA1OjM1IFBNLCBKb2huIEUgRHJha2Ugd3JvdGU6DQo+Pj4gTG91LA0KPj4+ DQo+Pj4gU2luY2UgdGhlIFdHIGRpZCBub3QgYWdyZWUgdG8gdGhpcyBjaGFuZ2VzLCBsZXQgYWxv bmUgZGlzY3VzcyB0aGVtLCANCj4+PiB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBzaW1wbHkgcm9s bGJhY2sgdGhlc2UgY2hhbmdlcyBhbmQgYXNrIHRoZSANCj4+PiBhdXRob3JzIHRvIHdyaXRlIGEg ZHJhZnQgYWRkcmVzc2luZyB0aGUgdG9waWNzIHlvdSBsaXN0IGluIHlvdXIgDQo+Pj4gZW1haWws IGJlbG93Pw0KPj4+DQo+Pj4gVGhhbmtzLA0KPj4+DQo+Pj4gSm9obg0KPj4+DQo+Pj4gU2VudCBm cm9tIG15IGlQaG9uZQ0KPj4+DQo+Pj4NCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+Pj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNA aWV0Zi5vcmddIE9uIA0KPj4+PiBCZWhhbGYgT2YgTG91IEJlcmdlcg0KPj4+PiBTZW50OiBUaHVy c2RheSwgQXVndXN0IDE2LCAyMDEyIDI6MTAgUE0NCj4+Pj4gVG86IFJha2VzaCBHYW5kaGkgKHJn YW5kaGkpDQo+Pj4+IENjOiBjY2FtcEBpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSZTogW0NDQU1Q XSBJLUQgQWN0aW9uOiANCj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQt DQo+Pj4+IGFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KPj4+Pg0KPj4+PiBSYWtlc2gsDQo+Pj4+ICAg ICAgU3VjaCBtYWpvciBjaGFuZ2VzIChpbiBzY29wZSBhbmQgZnVuY3Rpb25hbGl0eSkgdG8gV0cg ZHJhZnRzIA0KPj4+PiBhcmUgdXN1YWxseSBkaXNjdXNzZWQgd2l0aCB0aGUgV0cgcHJpb3IgdG8g dGhlIGF1dGhvcnMvZWRpdG9ycyBqdXN0IA0KPj4+PiBwdWJsaXNoaW5nIHRoZSBjaGFuZ2VzLiAg QnV0LCB0aGlzIGlzIGEganVkZ21lbnQgY2FsbCBieSB0aGUgDQo+Pj4+IGRvY3VtZW50IGVkaXRv cnMgaW4gaG93LCBxdW90aW5nIHJmYzI0MTgsIHRoZXkgImVuc3VyW2VdIHRoYXQgdGhlIA0KPj4+ PiBjb250ZW50cyBvZiB0aGUgZG9jdW1lbnQgYWNjdXJhdGVseSByZWZsZWN0IHRoZSBkZWNpc2lv bnMgdGhhdCBoYXZlIA0KPj4+PiBiZWVuIG1hZGUgYnkgdGhlIHdvcmtpbmcgZ3JvdXAuIg0KPj4+ Pg0KPj4+PiBTbyBsZXQncyBqdW1wIGludG8gZGlzY3Vzc2luZyB0aGUgY2hhbmdlcy4NCj4+Pj4N Cj4+Pj4gQXMgSSBzZWUgaXQgdGhpcyBkcmFmdCBpbnRyb2R1Y2VzIHNldmVyYWwgbWFqb3IgZnVu Y3Rpb25hbCBjaGFuZ2VzIA0KPj4+PiB0aGF0IGhhdmUgbm90IGJlZW4gZGlzY3Vzc2VkIGJ5IHRo ZSBXRy4gIENvcnJlY3QgbWUgaWYgSSBnZXQgdGhlbSANCj4+Pj4gd3JvbmcsIGJ1dCBJIGJlbGll dmUgdGhleSBpbmNsdWRlOg0KPj4+PiAxKSBJbnRyb2R1Y3Rpb24gb2YgYSBzZWNvbmQgbWV0aG9k IGZvciBzaWduYWxpbmcgQ28tcm91dGVkIExTUHMNCj4+Pj4gMikgU3VwcG9ydCBmb3IgRlJSIGJ5 cGFzcyB0dW5uZWxzIGZvciBwaWdneWJhY2tlZCBvbiB0aGUgVFAgDQo+Pj4+IGJpZGlyZWN0aW9u YWwgTFNQIG1lY2hhbmlzbXMuDQo+Pj4+DQo+Pj4+ICAgIFRoZXJlIGFyZSBhbHNvIG90aGVyIGNo YW5nZXMsIGJ1dCBJJ2xsIGRlZmVyIGRpc2N1c3NpbmcgdGhlbQ0KPj4+PiAgICB1bnRpbCB0aGUg ZGlzY3Vzc2lvbiBvbiB0aGUgYWJvdmUgaXMgY29uY2x1ZGVkLg0KPj4+Pg0KPj4+PiBJcyB0aGlz IGNvcnJlY3Q/DQo+Pj4+DQo+Pj4+IEFzc3VtaW5nIHllcywgSSBoYXZlIHF1ZXN0aW9ucyBhYm91 dCBib3RoIHJhdGlvbmFsIGFuZCBzcGVjaWZpYyANCj4+Pj4gbWVjaGFuaXNtcy4gIEZvciBub3cg bGV0J3MgbG9vayBhdCB0aGUgZm9ybWVyLCBzbyBwbGVhc2U6DQo+Pj4+DQo+Pj4+IEEpIEFydGlj dWxhdGUgdGhlIGlzc3Vlcy9saW1pdGF0aW9ucyB3aXRoIHVzaW5nIHRoZSBSRkMzNDczIGRlZmlu ZWQgDQo+Pj4+IG1lY2hhbmlzbXMgZm9yIChjby1yb3V0ZWQpIGJpZGlyZWN0aW9uYWwgTFNQcyB0 aGF0IHlvdSdkIGxpa2UgdG8gDQo+Pj4+IHNlZSBhZGRyZXNzZWQuDQo+Pj4+DQo+Pj4+IEIuMSkg QXJ0aWN1bGF0ZSB0aGUgRlJSL0dNUExTLXJlbGF0ZWQgaXNzdWUgeW91J2QgbGlrZSB0byBhZGRy ZXNzPw0KPj4+Pg0KPj4+PiBCLjIpIEFydGljdWxhdGUgd2h5IHRoaXMgaXNzdWUgc2hvdWxkIGJl IHNvbHZlZCBpbiBhIFRQLXNwZWNpZmljIA0KPj4+PiBhbmQgbm90IEdNUExTIGdlbmVyaWMgZmFz aGlvbj8NCj4+Pj4NCj4+Pj4gVGhhbmtzLA0KPj4+PiBMb3UNCj4+Pj4NCj4+Pj4gT24gOC8xNi8y MDEyIDQ6MjYgUE0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIHdyb3RlOg0KPj4+Pj4gSGkgTG91 LA0KPj4+Pj4NCj4+Pj4+IFllcy4NCj4+Pj4+DQo+Pj4+PiBQbGVhc2UgYWR2aXNlIGlmIHlvdSB0 aGluayBkZXRhaWxlZCBlbWFpbCBpcyByZXF1aXJlZC4NCj4+Pj4+IFdlIGJlbGlldmUgbGF0ZXN0 IGRyYWZ0IHN1bW1hcml6ZXMgdGhlIGNoYW5nZXMgd2VsbCBhbmQgd2UgY291bGQNCj4+Pj4gc3Rh cnQgcmV2aWV3L2Rpc2N1c3Npb25zIGZyb20gdGhlcmUuDQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzLA0K Pj4+Pj4gUmFrZXNoDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCj4+ Pj4+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTYsIDIwMTIgNDowMCBQTQ0KPj4+Pj4gVG86IFJh a2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo+Pj4+PiBDYzogY2NhbXBAaWV0Zi5vcmc7IHpoYW5nLmZl aTNAenRlLmNvbS5jbg0KPj4+Pj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gSS1EIEFjdGlvbjoNCj4+ Pj4+IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0 LnR4dA0KPj4+Pj4NCj4+Pj4+IFJha2VzaCwNCj4+Pj4+ICAgICBJcyB0aGlzIHRoZSBzdGFydCBv ZiB0aGUgdGhyZWFkIHRoYXQgSSByZXF1ZXN0ZWQgaW4gDQo+Pj4+PiBodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvY2NhbXAvY3VycmVudC9tc2cxMzcyOS5odG1sDQo+Pj4+Pg0K Pj4+Pj4gSW4gcGFydGljdWxhciwgaXMgaXQgdGhlIHJlc3BvbnNlIHRvOg0KPj4+Pj4+IEknZCBs aWtlIHRvIGFzayB0aGF0IHNvbWVvbmUgKFJha2VzaCwgRmVpLCBldGMuKSByZXZpZXcgZWFjaCBv ZiANCj4+Pj4+PiB0aGUgcHJvcG9zZWQgY2hhbmdlIGFuZCB0aGUgcmF0aW9uYWwgZm9yIGVhY2gg Y2hhbmdlIChpbiBvbmUgb3IgDQo+Pj4+Pj4gaW4gc2VwYXJhdGUgZS1tYWlscykuIFRoZSBXRyBk aXNjdXNzaW9uIGNhbiB0aGVuIHJlYWxseSBiZWdpbiBvbiANCj4+Pj4+PiB0aGUgcHJvcG9zZWQg Y2hhbmdlcy4gKFdoaWNoIGFyZSBxdWl0ZSBzdWJzdGFudGlhbCBib3RoIGluIHNjb3BlIA0KPj4+ Pj4+IGFuZA0KPj4+Pj4+IGltcGxpY2F0aW9uLikNCj4+Pj4+DQo+Pj4+PiBMb3UNCj4+Pj4+DQo+ Pj4+PiBPbiA4LzE2LzIwMTIgMzoxOSBQTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6 DQo+Pj4+Pj4gSGkgQWxsLA0KPj4+Pj4+DQo+Pj4+Pj4gV2UgaGF2ZSB1cGxvYWRlZCBhIG5ldyB2 ZXJzaW9uIG9mIHRoaXMgZHJhZnQgd2l0aCBmb2xsb3dpbmcgY2hhbmdlczoNCj4+Pj4+DQo+Pj4+ PiAxLiAgQWRkZWQgYSBzZWN0aW9uIG9uIFNpZ25hbGluZyBvZiBDby1yb3V0ZWQgTFNQcw0KPj4+ Pj4NCj4+Pj4+IDIuICBBZGRlZCBjbGFyaWZpY2F0aW9uIG9uIFNpZ25hbGluZyBvZiBBc3NvY2lh dGVkIEJpZGlyZWN0aW9uYWwgDQo+Pj4+PiBQcm90ZWN0aW9uIExTUHMNCj4+Pj4+DQo+Pj4+PiAz LiAgQWRkZWQgYSBzZWN0aW9uIG9uIFNpZ25hbGluZyBvZiBBdXRvLXR1bm5lbCBNZXNoLWdyb3Vw IExTUHMNCj4+Pj4+DQo+Pj4+PiA0LiAgIEFkZGVkIGNsYXJpZmljYXRpb24gb24gU2lnbmFsaW5n IG9mIEludGVyLWRvbWFpbiBBc3NvY2lhdGVkDQo+Pj4+IEJpZGlyZWN0aW9uYWwgTFNQcw0KPj4+ Pj4NCj4+Pj4+IDUuICBUaGUgRXh0ZW5kZWQgQVNTT0NJQVRJT04gb2JqZWN0IGZvcm1hdCB3aXRo IEFzc29jaWF0aW9uIFR5cGUNCj4+Pj4gIkFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1AiLiBD bGFyaWZpZWQgb24gaG93IHRvIHBvcHVsYXRlIA0KPj4+PiBkaWZmZXJlbnQgZmllbGRzIGluIHRo aXMgb2JqZWN0Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pj4gV2UgYmVsaWV2ZSB0aGF0IHNvbWUgb2Yg dGhlc2UgY2hhbmdlcyB3ZXJlIG5lY2Vzc2FyeSB0byBhdm9pZCB0aGUNCj4+Pj4gaW50ZXJvcGVy YWJpbGl0eSBpc3N1ZXMgZHVlIHRvIHBvdGVudGlhbGx5IGRpZmZlcmVudCBpbnRlcnByZXRhdGlv bnMuDQo+Pj4+Pj4NCj4+Pj4+PiBZb3VyIHJldmlldyBjb21tZW50cyBhcmUgd2VsY29tZS4NCj4+ Pj4+Pg0KPj4+Pj4+IFRoYW5rcywNCj4+Pj4+PiBSYWtlc2gNCj4+Pj4+Pg0KPj4+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPj4+Pj4+IEJlaGFsZiBPZiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4+Pj4+PiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAx NSwgMjAxMiAxMDo1MyBBTQ0KPj4+Pj4+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+Pj4+ PiBDYzogY2NhbXBAaWV0Zi5vcmcNCj4+Pj4+PiBTdWJqZWN0OiBbQ0NBTVBdIEktRCBBY3Rpb246 DQo+Pj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1s c3AtMDQudHh0DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIA0KPj4+Pj4+IEludGVybmV0LURyYWZ0cw0KPj4+ PiBkaXJlY3Rvcmllcy4NCj4+Pj4+PiAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg Q29tbW9uIENvbnRyb2wgYW5kIE1lYXN1cmVtZW50DQo+Pj4+IFBsYW5lIFdvcmtpbmcgR3JvdXAg b2YgdGhlIElFVEYuDQo+Pj4+Pj4NCj4+Pj4+PiAgICBUaXRsZSAgICAgICAgICAgOiBSU1ZQLVRF IEV4dGVuc2lvbnMgZm9yIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbA0KPj4+PiBMU1BzDQo+Pj4+ Pj4gICAgQXV0aG9yKHMpICAgICAgIDogRmVpIFpoYW5nDQo+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICBSdWlxdWFuIEppbmcNCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg IFJha2VzaCBHYW5kaGkNCj4+Pj4+PiAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWNj YW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLQ0KPj4+PiBsc3AtMDQudHh0DQo+Pj4+ Pj4gICAgUGFnZXMgICAgICAgICAgIDogMTcNCj4+Pj4+PiAgICBEYXRlICAgICAgICAgICAgOiAy MDEyLTA4LTE1DQo+Pj4+Pj4NCj4+Pj4+PiBBYnN0cmFjdDoNCj4+Pj4+PiAgICBUaGUgTVBMUyBU cmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgcmVxdWlyZW1lbnRzIGRvY3VtZW50DQo+Pj4+IFtS RkM1NjU0XSwNCj4+Pj4+PiAgICBkZXNjcmliZXMgdGhhdCBNUExTLVRQIE1VU1Qgc3VwcG9ydCBh c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCj4+Pj4gcG9pbnQtDQo+Pj4+Pj4gICAgdG8tcG9pbnQg TFNQcy4NCj4+Pj4+Pg0KPj4+Pj4+ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBtZXRob2Qg dG8gYmluZCB0d28gdW5pZGlyZWN0aW9uYWwgTGFiZWwNCj4+Pj4+PiAgICBTd2l0Y2hlZCBQYXRo cyAoTFNQcykgaW50byBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLiAgVGhlDQo+Pj4+ Pj4gICAgYXNzb2NpYXRpb24gaXMgYWNoaWV2ZWQgYnkgZGVmaW5pbmcgdGhlIG5ldyBBc3NvY2lh dGlvbiBUeXBlIA0KPj4+Pj4+IGluDQo+Pj4+IHRoZQ0KPj4+Pj4+ICAgIEV4dGVuZGVkIEFTU09D SUFUSU9OIG9iamVjdC4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS0NCj4+Pj4g ZXh0LQ0KPj4+Pj4+IGENCj4+Pj4+PiBzc29jaWF0ZWQtbHNwDQo+Pj4+Pj4NCj4+Pj4+PiBUaGVy ZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+Pj4+PiBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC0N Cj4+Pj4gYXNzb2NpDQo+Pj4+Pj4gYQ0KPj4+Pj4+IHRlZC1sc3AtMDQNCj4+Pj4+Pg0KPj4+Pj4+ IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+Pj4+ PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNjYW1wLW1wbHMt dHAtcnN2cHRlLQ0KPj4+PiBleHQtDQo+Pj4+Pj4gYQ0KPj4+Pj4+IHNzb2NpYXRlZC1sc3AtMDQN Cj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+Pj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvDQo+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4+Pj4+IENDQU1Q QGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j Y2FtcA0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+DQo+Pj4NCj4+ Pg0KPj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+PiBDQ0FNUEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiANCj4gDQo+IA0KPiANCg== From gregory.mirsky@ericsson.com Fri Aug 17 10:44:53 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B335421E8044; Fri, 17 Aug 2012 10:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.439 X-Spam-Level: X-Spam-Status: No, score=-4.439 tagged_above=-999 required=5 tests=[AWL=-2.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drjteztXmwet; Fri, 17 Aug 2012 10:44:52 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id D6E6211E809B; Fri, 17 Aug 2012 10:44:51 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q7HHio6P028250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Aug 2012 12:44:50 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 17 Aug 2012 13:44:49 -0400 From: Gregory Mirsky To: "zhang.fei3@zte.com.cn" , Francesco Fondelli Date: Fri, 17 Aug 2012 13:44:48 -0400 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac18WywuTwceW9iGT+632DdYaCQraQAQ5yQw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF139268CBE68EUSAACMS0715e_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "ccamp-bounces@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 17:44:53 -0000 --_000_FE60A4E52763E84B935532D7D9294FF139268CBE68EUSAACMS0715e_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBGZWksDQppZiB3ZSB0byBjb21wYXJlLCB1c2luZyBGcmFuY2VzY28ncyBlbnVtZXJhdGlv biwgY2FzZXMgYikgYW5kIGMyKSwgdGhlbiwgaW4gbXkgdmlldywgZGlmZmVyZW5jZXMgd291bGQg YmUgaW46DQoNCiAqDQppZGVudGlmaWVycw0KICoNCmNvb3JkaW5hdGVkIHZzLiBpbmRlcGVuZGVu dCBtb25pdG9yaW5nIGFuZCBwcm90ZWN0aW9uDQoNCkJ1dCBJIHdvdWxkIHF1ZXN0aW9uIHdoZXRo ZXIgb3BlcmF0b3JzIHdpbGwgdXNlIGluZGVwZW5kZW50IG1vbml0b3JpbmcgYW5kIHByb3RlY3Rp b24gb24sIHdoYXQgbG9va3MgZXhhY3RseSBsaWtlLCBiaS1kaXJlY3Rpb25hbCBjby1yb3V0ZWQg TFNQLiBJIHRoaW5rIHRoYXQgYzIpIGlzIG5vdCBhIHNlcGFyYXRlIGNhc2UsIGJ1dCByYXRoZXIg ImFuIGFjY2lkZW50Ii4gSWYgYW4gb3BlcmF0b3Igd2FudHMgdG8gYnVpbGQgYzIpIGhlL3NoZSBu ZWVkcyB0byB1c2UgcHJvY2VkdXJlcyBkZWZpbmVkIGZvciBiKS4NCg0KICAgIFJlZ2FyZHMsDQog ICAgICAgIEdyZWcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IGNj YW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgemhhbmcuZmVpM0B6dGUuY29tLmNuDQpTZW50OiBGcmlkYXksIEF1Z3VzdCAxNywg MjAxMiAyOjMxIEFNDQpUbzogRnJhbmNlc2NvIEZvbmRlbGxpDQpDYzogY2NhbXBAaWV0Zi5vcmc7 IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4 dA0KDQoNCkhpIEZyYW5jZXNjbywgc25pcHBlZA0KDQpJcyBzZWN0aW9uIDMuMi41IChTaWduYWxp bmcgb2YgQ28tcm91dGVkIExTUHMpIG9mDQptcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1s c3AgYWJvdXQgYikgb3IgaXQgaXMgYWJvdXQgYzIpPw0KDQo8ZmVpPiBJdCBpcyBhYm91dCBjMiks IGluIG90aGVyIHdvcmRzLCBpdCBpcyBTaWduYWxpbmcgb2YgYXNzb2NpYXRlZCBjb25ncnVlbnQg TFNQcy4NCg0KQmVzdA0KDQpGZWkNCg0KDQpGcmFuY2VzY28gRm9uZGVsbGkgPGZyYW5jZXNjby5m b25kZWxsaUBnbWFpbC5jb20+DQq3orz+yMs6ICBjY2FtcC1ib3VuY2VzQGlldGYub3JnDQoNCjIw MTItMDgtMTcgMTY6NDgNCg0KytW8/sjLDQoiUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkiIDxyZ2Fu ZGhpQGNpc2NvLmNvbT4NCrOty80NCiJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPg0K 1vfM4g0KUmU6IFtDQ0FNUF0gSS1EIEFjdGlvbjogICAgICAgIGRyYWZ0LWlldGYtY2NhbXAtbXBs cy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KDQoNCg0KDQoNCkhpIEFsbCwN Cg0KSSB0aGluayBJJ20gbG9zdCwgcGxlYXNlIGhlbHAuDQoNClJha2VzaCBpcyB0YWxraW5nIGFi b3V0ICJjby1yb3V0ZWQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQpMU1AiLi4uIGZvciB0aGUg c2FrZSBvZiBjbGFyaXR5LCBsZXQgbWUgdHJ5IHRvIGNhdGVnb3JpemUNCkxTUHMgZnJvbSBhIGNv bnRyb2wgcGxhbmUgdmlldyBwb2ludDoNCg0KIGEpIFBvaW50LXRvLXBvaW50IHVuaWRpcmVjdGlv bmFsDQogYikgUG9pbnQtdG8tcG9pbnQgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwNCiBjKSBQb2lu dC10by1wb2ludCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCiAgYzEpIGZ3ZCBhbmQgcmV2IExT UCBmb2xsb3cgZGlmZmVyZW50IHBhdGhzDQogIGMyKSBmd2QgYW5kIHJldiBMU1AgZm9sbG93IHNh bWUgcGF0aA0KIGQpIFBvaW50LXRvLW11bHRpcG9pbnQgdW5pZGlyZWN0aW9uYWwNCiBlKSBNdWx0 aXBvaW50LXRvLXBvaW50IHVuaWRpcmVjdGlvbmFsDQoNCklzIHNlY3Rpb24gMy4yLjUgKFNpZ25h bGluZyBvZiBDby1yb3V0ZWQgTFNQcykgb2YNCm1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVk LWxzcCBhYm91dCBiKSBvciBpdCBpcyBhYm91dCBjMik/DQoNCkluIG15IG9waW5pb246DQoNCi0g Yikgc2hvdWxkIGJlIHNpZ25hbGVkIHdpdGggMzQ3Mw0KLSBjKSBhcmUgYWRkcmVzc2VkIGJ5IHRo aXMgSS1EIChtcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3ApDQoNCkFtIEkgbWlzc2lu ZyBzb21ldGhpbmc/DQoNCnRoYW5rIHlvdQ0KY2lhbw0KZnJhDQoNClBTDQpmcm9tIGEgZGF0YS1w bGFuZSB2aWV3IHBvaW50IGIpIGFuZCBjMikgYXJlIHRoZSBzYW1lIHRoaW5nLg0KDQpPbiBGcmks IEF1ZyAxNywgMjAxMiBhdCAxMjoxNiBBTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCjxyZ2Fu ZGhpQGNpc2NvLmNvbT4gd3JvdGU6DQo+IEhpIExvdSwNCj4NCj4gVGhhbmtzIGZvciBpbml0aWF0 aW5nIGRpc2N1c3Npb25zIG9uIHRoZSBjaGFuZ2VzIGluIHRoZSBkcmFmdC4NCj4NCj4gQWdyZWUg d2l0aCB5b3UgaGVyZSwgaWYgd2UvV0cgZG8gbm90IGFncmVlIG9uIHRoZSAiY28tcm91dGVkIGFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AiIHBhcnQsIHdlIGFyZSBvayB0byByZW1vdmUgaXQg ZnJvbSB0aGlzIGRyYWZ0IGFuZCBjYW4gYWx3YXlzIHN1Ym1pdCBhIG5ldyBkcmFmdCBqdXN0IGZv ciB0aGF0LiBXZSByZXNwZWN0IHlvdXIvV0cgZGVjaXNpb24uDQo+DQo+IFRoYW5rcywNCj4gUmFr ZXNoDQo+DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExvdSBC ZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0 IDE2LCAyMDEyIDY6MDggUE0NCj4gVG86IEpvaG4gRSBEcmFrZQ0KPiBDYzogUmFrZXNoIEdhbmRo aSAocmdhbmRoaSk7IGNjYW1wQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNw LTA0LnR4dA0KPg0KPiBKb2huLA0KPiAgICAgICAgIFdoaWxlIHN0cmljdGx5IHNwZWFraW5nIFdH IGRyYWZ0cyBzaG91bGQgb25seSByZWZsZWN0IGN1cnJlbnQgV0cgY29uc2Vuc3VzLCBhbmQgaXQg aXMgdGhlIFdHIGRyYWZ0IGVkaXRvcidzIGpvYiB0byBlbnN1cmUgdGhpcywgaW4gcHJhY3RpY2Ug YXV0aG9ycy9lZGl0b3JzIGFyZSBnaXZlbiBhIGxvdCBvZiBsYXRpdHVkZSBpbiB0aW1pbmcgLyBv cmRlcmluZyBpbiBpbnRyb2R1Y3Rpb24gdG8gY2hhbmdlcy4gIEkgcGVyc29uYWxseSB0aGluayB0 aGlzIGlzIGEgcHJhY3RpY2FsIHdheSBvZiBrZWVwaW5nIHRoZSBwcm9jZXNzIG1vdmluZy4gIEFs c28gaWYgdGhlIFdHIGRpc2FncmVlcyB3aXRoIGEgY2hhbmdlLCBpdCBjYW4gYWx3YXlzIGJlIGJh Y2tlZCBvdXQuDQo+DQo+IFNvLCB5ZXMsIHRoZSBXRyBjb3VsZCBkbyBleGFjdGx5IGFzIHlvdSBz YXkgaWYgaXQgY29tZXMgdG8gaXQuICAoVGhlIGNoYWlycyBjYW4gZXZlbiBhcHBvaW50IGRpZmZl cmVudCBlZGl0b3IgaWYgbmVlZGVkLCBlLmcuLCB0byBtYWtlIHRoaXMNCj4gaGFwcGVuLikgIFdo aWxlIEknbSBub3QgaGFwcHkgd2l0aCBob3cgdGhpcyByZXZpc2lvbiBjYW1lIGFib3V0LCBhcyBJ IGNvdmVyZWQgaW4gZWFybGllciBtYWlsLCBteSBmZWVsaW5nIGlzIHRvIGxldCB0aGUgZGlzY3Vz c2lvbiB0YWtlIHBsYWNlIG9uIHRoZSBsaXN0IChhbmQgYXQgdGhlIG5leHQgSUVURiwgaWYgbmVl ZGVkKSBhbmQgdGhlbiBoYXZlIHRoZSBkcmFmdCB1cGRhdGVkIHRvIHJlZmxlY3QgdGhlIFdHIGRp c2N1c3Npb24vY29uc2Vuc3VzLg0KPg0KPiBMb3UNCj4NCj4gT24gOC8xNi8yMDEyIDU6MzUgUE0s IEpvaG4gRSBEcmFrZSB3cm90ZToNCj4+IExvdSwNCj4+DQo+PiBTaW5jZSB0aGUgV0cgZGlkIG5v dCBhZ3JlZSB0byB0aGlzIGNoYW5nZXMsIGxldCBhbG9uZSBkaXNjdXNzIHRoZW0sDQo+PiB3b3Vs ZCBpdCBiZSBwb3NzaWJsZSB0byBzaW1wbHkgcm9sbGJhY2sgdGhlc2UgY2hhbmdlcyBhbmQgYXNr IHRoZQ0KPj4gYXV0aG9ycyB0byB3cml0ZSBhIGRyYWZ0IGFkZHJlc3NpbmcgdGhlIHRvcGljcyB5 b3UgbGlzdCBpbiB5b3VyIGVtYWlsLA0KPj4gYmVsb3c/DQo+Pg0KPj4gVGhhbmtzLA0KPj4NCj4+ IEpvaG4NCj4+DQo+PiBTZW50IGZyb20gbXkgaVBob25lDQo+Pg0KPj4NCj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+IEJlaGFsZiBPZiBMb3UgQmVyZ2VyDQo+ Pj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxNiwgMjAxMiAyOjEwIFBNDQo+Pj4gVG86IFJha2Vz aCBHYW5kaGkgKHJnYW5kaGkpDQo+Pj4gQ2M6IGNjYW1wQGlldGYub3JnDQo+Pj4gU3ViamVjdDog UmU6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1l eHQtDQo+Pj4gYXNzb2NpYXRlZC1sc3AtMDQudHh0DQo+Pj4NCj4+PiBSYWtlc2gsDQo+Pj4gICAg ICBTdWNoIG1ham9yIGNoYW5nZXMgKGluIHNjb3BlIGFuZCBmdW5jdGlvbmFsaXR5KSB0byBXRyBk cmFmdHMgYXJlDQo+Pj4gdXN1YWxseSBkaXNjdXNzZWQgd2l0aCB0aGUgV0cgcHJpb3IgdG8gdGhl IGF1dGhvcnMvZWRpdG9ycyBqdXN0DQo+Pj4gcHVibGlzaGluZyB0aGUgY2hhbmdlcy4gIEJ1dCwg dGhpcyBpcyBhIGp1ZGdtZW50IGNhbGwgYnkgdGhlIGRvY3VtZW50DQo+Pj4gZWRpdG9ycyBpbiBo b3csIHF1b3RpbmcgcmZjMjQxOCwgdGhleSAiZW5zdXJbZV0gdGhhdCB0aGUgY29udGVudHMgb2YN Cj4+PiB0aGUgZG9jdW1lbnQgYWNjdXJhdGVseSByZWZsZWN0IHRoZSBkZWNpc2lvbnMgdGhhdCBo YXZlIGJlZW4gbWFkZSBieQ0KPj4+IHRoZSB3b3JraW5nIGdyb3VwLiINCj4+Pg0KPj4+IFNvIGxl dCdzIGp1bXAgaW50byBkaXNjdXNzaW5nIHRoZSBjaGFuZ2VzLg0KPj4+DQo+Pj4gQXMgSSBzZWUg aXQgdGhpcyBkcmFmdCBpbnRyb2R1Y2VzIHNldmVyYWwgbWFqb3IgZnVuY3Rpb25hbCBjaGFuZ2Vz DQo+Pj4gdGhhdCBoYXZlIG5vdCBiZWVuIGRpc2N1c3NlZCBieSB0aGUgV0cuICBDb3JyZWN0IG1l IGlmIEkgZ2V0IHRoZW0NCj4+PiB3cm9uZywgYnV0IEkgYmVsaWV2ZSB0aGV5IGluY2x1ZGU6DQo+ Pj4gMSkgSW50cm9kdWN0aW9uIG9mIGEgc2Vjb25kIG1ldGhvZCBmb3Igc2lnbmFsaW5nIENvLXJv dXRlZCBMU1BzDQo+Pj4gMikgU3VwcG9ydCBmb3IgRlJSIGJ5cGFzcyB0dW5uZWxzIGZvciBwaWdn eWJhY2tlZCBvbiB0aGUgVFANCj4+PiBiaWRpcmVjdGlvbmFsIExTUCBtZWNoYW5pc21zLg0KPj4+ DQo+Pj4gICAgVGhlcmUgYXJlIGFsc28gb3RoZXIgY2hhbmdlcywgYnV0IEknbGwgZGVmZXIgZGlz Y3Vzc2luZyB0aGVtDQo+Pj4gICAgdW50aWwgdGhlIGRpc2N1c3Npb24gb24gdGhlIGFib3ZlIGlz IGNvbmNsdWRlZC4NCj4+Pg0KPj4+IElzIHRoaXMgY29ycmVjdD8NCj4+Pg0KPj4+IEFzc3VtaW5n IHllcywgSSBoYXZlIHF1ZXN0aW9ucyBhYm91dCBib3RoIHJhdGlvbmFsIGFuZCBzcGVjaWZpYw0K Pj4+IG1lY2hhbmlzbXMuICBGb3Igbm93IGxldCdzIGxvb2sgYXQgdGhlIGZvcm1lciwgc28gcGxl YXNlOg0KPj4+DQo+Pj4gQSkgQXJ0aWN1bGF0ZSB0aGUgaXNzdWVzL2xpbWl0YXRpb25zIHdpdGgg dXNpbmcgdGhlIFJGQzM0NzMgZGVmaW5lZA0KPj4+IG1lY2hhbmlzbXMgZm9yIChjby1yb3V0ZWQp IGJpZGlyZWN0aW9uYWwgTFNQcyB0aGF0IHlvdSdkIGxpa2UgdG8gc2VlDQo+Pj4gYWRkcmVzc2Vk Lg0KPj4+DQo+Pj4gQi4xKSBBcnRpY3VsYXRlIHRoZSBGUlIvR01QTFMtcmVsYXRlZCBpc3N1ZSB5 b3UnZCBsaWtlIHRvIGFkZHJlc3M/DQo+Pj4NCj4+PiBCLjIpIEFydGljdWxhdGUgd2h5IHRoaXMg aXNzdWUgc2hvdWxkIGJlIHNvbHZlZCBpbiBhIFRQLXNwZWNpZmljIGFuZA0KPj4+IG5vdCBHTVBM UyBnZW5lcmljIGZhc2hpb24/DQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gTG91DQo+Pj4NCj4+PiBP biA4LzE2LzIwMTIgNDoyNiBQTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6DQo+Pj4+ IEhpIExvdSwNCj4+Pj4NCj4+Pj4gWWVzLg0KPj4+Pg0KPj4+PiBQbGVhc2UgYWR2aXNlIGlmIHlv dSB0aGluayBkZXRhaWxlZCBlbWFpbCBpcyByZXF1aXJlZC4NCj4+Pj4gV2UgYmVsaWV2ZSBsYXRl c3QgZHJhZnQgc3VtbWFyaXplcyB0aGUgY2hhbmdlcyB3ZWxsIGFuZCB3ZSBjb3VsZA0KPj4+IHN0 YXJ0IHJldmlldy9kaXNjdXNzaW9ucyBmcm9tIHRoZXJlLg0KPj4+Pg0KPj4+PiBUaGFua3MsDQo+ Pj4+IFJha2VzaA0KPj4+Pg0KPj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCj4+Pj4gU2Vu dDogVGh1cnNkYXksIEF1Z3VzdCAxNiwgMjAxMiA0OjAwIFBNDQo+Pj4+IFRvOiBSYWtlc2ggR2Fu ZGhpIChyZ2FuZGhpKQ0KPj4+PiBDYzogY2NhbXBAaWV0Zi5vcmc7IHpoYW5nLmZlaTNAenRlLmNv bS5jbg0KPj4+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBJLUQgQWN0aW9uOg0KPj4+PiBkcmFmdC1p ZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCj4+Pj4N Cj4+Pj4gUmFrZXNoLA0KPj4+PiAgICAgSXMgdGhpcyB0aGUgc3RhcnQgb2YgdGhlIHRocmVhZCB0 aGF0IEkgcmVxdWVzdGVkIGluDQo+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9jY2FtcC9jdXJyZW50L21zZzEzNzI5Lmh0bWwNCj4+Pj4NCj4+Pj4gSW4gcGFydGljdWxh ciwgaXMgaXQgdGhlIHJlc3BvbnNlIHRvOg0KPj4+Pj4gSSdkIGxpa2UgdG8gYXNrIHRoYXQgc29t ZW9uZSAoUmFrZXNoLCBGZWksIGV0Yy4pIHJldmlldyBlYWNoIG9mIHRoZQ0KPj4+Pj4gcHJvcG9z ZWQgY2hhbmdlIGFuZCB0aGUgcmF0aW9uYWwgZm9yIGVhY2ggY2hhbmdlIChpbiBvbmUgb3IgaW4N Cj4+Pj4+IHNlcGFyYXRlIGUtbWFpbHMpLiBUaGUgV0cgZGlzY3Vzc2lvbiBjYW4gdGhlbiByZWFs bHkgYmVnaW4gb24gdGhlDQo+Pj4+PiBwcm9wb3NlZCBjaGFuZ2VzLiAoV2hpY2ggYXJlIHF1aXRl IHN1YnN0YW50aWFsIGJvdGggaW4gc2NvcGUgYW5kDQo+Pj4+PiBpbXBsaWNhdGlvbi4pDQo+Pj4+ DQo+Pj4+IExvdQ0KPj4+Pg0KPj4+PiBPbiA4LzE2LzIwMTIgMzoxOSBQTSwgUmFrZXNoIEdhbmRo aSAocmdhbmRoaSkgd3JvdGU6DQo+Pj4+PiBIaSBBbGwsDQo+Pj4+Pg0KPj4+Pj4gV2UgaGF2ZSB1 cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgd2l0aCBmb2xsb3dpbmcgY2hhbmdl czoNCj4+Pj4NCj4+Pj4gMS4gIEFkZGVkIGEgc2VjdGlvbiBvbiBTaWduYWxpbmcgb2YgQ28tcm91 dGVkIExTUHMNCj4+Pj4NCj4+Pj4gMi4gIEFkZGVkIGNsYXJpZmljYXRpb24gb24gU2lnbmFsaW5n IG9mIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbA0KPj4+PiBQcm90ZWN0aW9uIExTUHMNCj4+Pj4N Cj4+Pj4gMy4gIEFkZGVkIGEgc2VjdGlvbiBvbiBTaWduYWxpbmcgb2YgQXV0by10dW5uZWwgTWVz aC1ncm91cCBMU1BzDQo+Pj4+DQo+Pj4+IDQuICAgQWRkZWQgY2xhcmlmaWNhdGlvbiBvbiBTaWdu YWxpbmcgb2YgSW50ZXItZG9tYWluIEFzc29jaWF0ZWQNCj4+PiBCaWRpcmVjdGlvbmFsIExTUHMN Cj4+Pj4NCj4+Pj4gNS4gIFRoZSBFeHRlbmRlZCBBU1NPQ0lBVElPTiBvYmplY3QgZm9ybWF0IHdp dGggQXNzb2NpYXRpb24gVHlwZQ0KPj4+ICJBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQIi4g Q2xhcmlmaWVkIG9uIGhvdyB0byBwb3B1bGF0ZQ0KPj4+IGRpZmZlcmVudCBmaWVsZHMgaW4gdGhp cyBvYmplY3QuDQo+Pj4+DQo+Pj4+DQo+Pj4+PiBXZSBiZWxpZXZlIHRoYXQgc29tZSBvZiB0aGVz ZSBjaGFuZ2VzIHdlcmUgbmVjZXNzYXJ5IHRvIGF2b2lkIHRoZQ0KPj4+IGludGVyb3BlcmFiaWxp dHkgaXNzdWVzIGR1ZSB0byBwb3RlbnRpYWxseSBkaWZmZXJlbnQgaW50ZXJwcmV0YXRpb25zLg0K Pj4+Pj4NCj4+Pj4+IFlvdXIgcmV2aWV3IGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KPj4+Pj4NCj4+ Pj4+IFRoYW5rcywNCj4+Pj4+IFJha2VzaA0KPj4+Pj4NCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2Nh bXAtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+Pj4+IEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcNCj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE1LCAyMDEyIDEwOjUzIEFN DQo+Pj4+PiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+Pj4+PiBDYzogY2NhbXBAaWV0Zi5v cmcNCj4+Pj4+IFN1YmplY3Q6IFtDQ0FNUF0gSS1EIEFjdGlvbjoNCj4+Pj4+IGRyYWZ0LWlldGYt Y2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KPj4+Pj4NCj4+ Pj4+DQo+Pj4+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMNCj4+PiBkaXJlY3Rvcmllcy4NCj4+Pj4+ICBUaGlzIGRyYWZ0 IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb21tb24gQ29udHJvbCBhbmQgTWVhc3VyZW1lbnQNCj4+ PiBQbGFuZSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPj4+Pj4NCj4+Pj4+ICAgIFRpdGxl ICAgICAgICAgICA6IFJTVlAtVEUgRXh0ZW5zaW9ucyBmb3IgQXNzb2NpYXRlZCBCaWRpcmVjdGlv bmFsDQo+Pj4gTFNQcw0KPj4+Pj4gICAgQXV0aG9yKHMpICAgICAgIDogRmVpIFpoYW5nDQo+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFJ1aXF1YW4gSmluZw0KPj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICBSYWtlc2ggR2FuZGhpDQo+Pj4+PiAgICBGaWxlbmFtZSAgICAgICAg OiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLQ0KPj4+IGxz cC0wNC50eHQNCj4+Pj4+ICAgIFBhZ2VzICAgICAgICAgICA6IDE3DQo+Pj4+PiAgICBEYXRlICAg ICAgICAgICAgOiAyMDEyLTA4LTE1DQo+Pj4+Pg0KPj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+PiAgICBU aGUgTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgcmVxdWlyZW1lbnRzIGRvY3VtZW50 DQo+Pj4gW1JGQzU2NTRdLA0KPj4+Pj4gICAgZGVzY3JpYmVzIHRoYXQgTVBMUy1UUCBNVVNUIHN1 cHBvcnQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQo+Pj4gcG9pbnQtDQo+Pj4+PiAgICB0by1w b2ludCBMU1BzLg0KPj4+Pj4NCj4+Pj4+ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBtZXRo b2QgdG8gYmluZCB0d28gdW5pZGlyZWN0aW9uYWwgTGFiZWwNCj4+Pj4+ICAgIFN3aXRjaGVkIFBh dGhzIChMU1BzKSBpbnRvIGFuIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuICBUaGUNCj4+ Pj4+ICAgIGFzc29jaWF0aW9uIGlzIGFjaGlldmVkIGJ5IGRlZmluaW5nIHRoZSBuZXcgQXNzb2Np YXRpb24gVHlwZSBpbg0KPj4+IHRoZQ0KPj4+Pj4gICAgRXh0ZW5kZWQgQVNTT0NJQVRJT04gb2Jq ZWN0Lg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtDQo+Pj4gZXh0LQ0KPj4+Pj4gYQ0K Pj4+Pj4gc3NvY2lhdGVkLWxzcA0KPj4+Pj4NCj4+Pj4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVk IHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtDQo+Pj4gYXNzb2NpDQo+Pj4+PiBh DQo+Pj4+PiB0ZWQtbHNwLTA0DQo+Pj4+Pg0KPj4+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3Vz IHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS0NCj4+PiBleHQtDQo+Pj4+ PiBhDQo+Pj4+PiBzc29jaWF0ZWQtbHNwLTA0DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IEludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+Pj4+IGZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IENDQU1QIG1haWxp bmcgbGlzdA0KPj4+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+ DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+PiBDQ0FNUEBpZXRmLm9y Zw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+DQo+ Pg0KPj4NCj4+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IENDQU1QIG1haWxpbmcgbGlzdA0KPiBDQ0FNUEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQoNCg== --_000_FE60A4E52763E84B935532D7D9294FF139268CBE68EUSAACMS0715e_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear Fei,
if we to compare, using Francesco's enumeration, c= ases b)=20 and c2), then, in my view, differences would be in:
  • identifiers
  • coordinated vs. independent monitoring and=20 protection
But I would question whether operators will use in= dependent=20 monitoring and protection on, what looks exactly like, bi-directional co-ro= uted=20 LSP. I think that c2) is not a separate case, but rather "an accident". If = an=20 operator wants to build c2) he/she needs to use procedures defined for=20 b).
 
  &n= bsp; Regards,
        Greg

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of=20 zhang.fei3@zte.com.cn
Sent: Friday, August 17, 2012 2:31=20 AM
To: Francesco Fondelli
Cc: ccamp@ietf.org;=20 ccamp-bounces@ietf.org
Subject: Re: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt


Hi Francesco, snipped=20

Is section 3.2.5 (Signaling of Co-routed LSPs)=20 of
mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)?= =20

<fei> It is abo= ut c2), in=20 other words, it is Signaling of asso= ciated=20 congruent LSPs.

Best=20

Fei


Francesco Fondell= i=20 <francesco.fondelli@gmail.com>
=B7=A2=BC=FE=C8=CB:  ccamp-bounces@ietf.org=20

2012-08-17 16:48

=CA=D5=BC= =FE=C8=CB
"Rakesh Gandhi (rgandhi)"=20 <rgandhi@cisco.com>=20
=B3=AD=CB= =CD
"ccamp@ietf.org"=20 <ccamp@ietf.org>=20
=D6=F7=CC= =E2
Re: [CCAMP] I-D Action: &nbs= p;=20    =20  draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=





Hi All,

I think I'm lost, please help.

Rakesh is tal= king=20 about "co-routed associated bidirectional
LSP"... for the sake of clarit= y,=20 let me try to categorize
LSPs from a control plane view=20 point:

 a) Point-to-point unidirectional
 b) Point-to-p= oint=20 co-routed bidirectional
 c) Point-to-point associated=20 bidirectional
  c1) fwd and rev LSP follow different paths
 = ; c2)=20 fwd and rev LSP follow same path
 d) Point-to-multipoint=20 unidirectional
 e) Multipoint-to-point unidirectional

Is sec= tion=20 3.2.5 (Signaling of Co-routed LSPs) of
mpls-tp-rsvpte-ext-associated-lsp= =20 about b) or it is about c2)?

In my opinion:

- b) should be=20 signaled with 3473
- c) are addressed by this I-D=20 (mpls-tp-rsvpte-ext-associated-lsp)

Am I missing something?

t= hank=20 you
ciao
fra

PS
from a data-plane view point b) and c2) are= the=20 same thing.

On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi=20 (rgandhi)
<rgandhi@cisco.com> wrote:
> Hi Lou,
>
&g= t;=20 Thanks for initiating discussions on the changes in the draft.
>
&= gt;=20 Agree with you here, if we/WG do not agree on the "co-routed associated=20 bidirectional LSP" part, we are ok to remove it from this draft and can alw= ays=20 submit a new draft just for that. We respect your/WG decision.
>
&= gt;=20 Thanks,
> Rakesh
>
>
>
> -----Original=20 Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sen= t:=20 Thursday, August 16, 2012 6:08 PM
> To: John E Drake
> Cc: Rake= sh=20 Gandhi (rgandhi); ccamp@ietf.org
> Subject: Re: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>
>=20 John,
>         While strictly speaking WG drafts= =20 should only reflect current WG consensus, and it is the WG draft editor's j= ob to=20 ensure this, in practice authors/editors are given a lot of latitude in tim= ing /=20 ordering in introduction to changes.  I personally think this is a=20 practical way of keeping the process moving.  Also if the WG disagrees= with=20 a change, it can always be backed out.
>
> So, yes, the WG coul= d do=20 exactly as you say if it comes to it.  (The chairs can even appoint=20 different editor if needed, e.g., to make this
> happen.)  While= I'm=20 not happy with how this revision came about, as I covered in earlier mail, = my=20 feeling is to let the discussion take place on the list (and at the next IE= TF,=20 if needed) and then have the draft updated to reflect the WG=20 discussion/consensus.
>
> Lou
>
> On 8/16/2012 5:35= PM,=20 John E Drake wrote:
>> Lou,
>>
>> Since the WG d= id=20 not agree to this changes, let alone discuss them,
>> would it be= =20 possible to simply rollback these changes and ask the
>> authors t= o=20 write a draft addressing the topics you list in your email,
>>=20 below?
>>
>> Thanks,
>>
>>=20 John
>>
>> Sent from my=20 iPhone
>>
>>
>>> -----Original=20 Message-----
>>> From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On
>>> Behalf Of Lou=20 Berger
>>> Sent: Thursday, August 16, 2012 2:10 PM
>>&= gt;=20 To: Rakesh Gandhi (rgandhi)
>>> Cc: ccamp@ietf.org
>>&= gt;=20 Subject: Re: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>>=20 associated-lsp-04.txt
>>>
>>> Rakesh,
>>&g= t;=20      Such major changes (in scope and functionality) to WG d= rafts=20 are
>>> usually discussed with the WG prior to the authors/edit= ors=20 just
>>> publishing the changes.  But, this is a judgment = call=20 by the document
>>> editors in how, quoting rfc2418, they "ensu= r[e]=20 that the contents of
>>> the document accurately reflect the=20 decisions that have been made by
>>> the working=20 group."
>>>
>>> So let's jump into discussing the=20 changes.
>>>
>>> As I see it this draft introduces= =20 several major functional changes
>>> that have not been discuss= ed by=20 the WG.  Correct me if I get them
>>> wrong, but I believe= they=20 include:
>>> 1) Introduction of a second method for signaling=20 Co-routed LSPs
>>> 2) Support for FRR bypass tunnels for piggyb= acked=20 on the TP
>>> bidirectional LSP=20 mechanisms.
>>>
>>>    There are also oth= er=20 changes, but I'll defer discussing them
>>>    until = the=20 discussion on the above is concluded.
>>>
>>> Is th= is=20 correct?
>>>
>>> Assuming yes, I have questions abo= ut=20 both rational and specific
>>> mechanisms.  For now let's = look=20 at the former, so please:
>>>
>>> A) Articulate the= =20 issues/limitations with using the RFC3473 defined
>>> mechanism= s for=20 (co-routed) bidirectional LSPs that you'd like to see
>>>=20 addressed.
>>>
>>> B.1) Articulate the FRR/GMPLS-re= lated=20 issue you'd like to address?
>>>
>>> B.2) Articulat= e why=20 this issue should be solved in a TP-specific and
>>> not GMPLS= =20 generic fashion?
>>>
>>> Thanks,
>>>=20 Lou
>>>
>>> On 8/16/2012 4:26 PM, Rakesh Gandhi=20 (rgandhi) wrote:
>>>> Hi=20 Lou,
>>>>
>>>>=20 Yes.
>>>>
>>>> Please advise if you think det= ailed=20 email is required.
>>>> We believe latest draft summarizes t= he=20 changes well and we could
>>> start review/discussions from=20 there.
>>>>
>>>> Thanks,
>>>>= =20 Rakesh
>>>>
>>>>
>>>> -----Ori= ginal=20 Message-----
>>>> From: Lou Berger=20 [mailto:lberger@labn.net]
>>>> Sent: Thursday, August 16, 20= 12=20 4:00 PM
>>>> To: Rakesh Gandhi (rgandhi)
>>>>= Cc:=20 ccamp@ietf.org; zhang.fei3@zte.com.cn
>>>> Subject: Re: [CCA= MP]=20 I-D Action:
>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;
>>>>=20 Rakesh,
>>>>     Is this the start of the thread t= hat I=20 requested in
>>>>=20 http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html
>>= ;>>
>>>>=20 In particular, is it the response to:
>>>>> I'd like to a= sk=20 that someone (Rakesh, Fei, etc.) review each of the
>>>>>= =20 proposed change and the rational for each change (in one or=20 in
>>>>> separate e-mails). The WG discussion can then re= ally=20 begin on the
>>>>> proposed changes. (Which are quite=20 substantial both in scope and
>>>>>=20 implication.)
>>>>
>>>>=20 Lou
>>>>
>>>> On 8/16/2012 3:19 PM, Rakesh Ga= ndhi=20 (rgandhi) wrote:
>>>>> Hi=20 All,
>>>>>
>>>>> We have uploaded a new= =20 version of this draft with following=20 changes:
>>>>
>>>> 1.  Added a section o= n=20 Signaling of Co-routed LSPs
>>>>
>>>> 2.=20  Added clarification on Signaling of Associated=20 Bidirectional
>>>> Protection=20 LSPs
>>>>
>>>> 3.  Added a section on=20 Signaling of Auto-tunnel Mesh-group LSPs
>>>>
>>>= ;>=20 4.   Added clarification on Signaling of Inter-domain=20 Associated
>>> Bidirectional=20 LSPs
>>>>
>>>> 5.  The Extended ASSOCIAT= ION=20 object format with Association Type
>>> "Associated Bidirection= al=20 LSP". Clarified on how to populate
>>> different fields in this= =20 object.
>>>>
>>>>
>>>>> We= =20 believe that some of these changes were necessary to avoid the
>>&= gt;=20 interoperability issues due to potentially different=20 interpretations.
>>>>>
>>>>> Your revie= w=20 comments are welcome.
>>>>>
>>>>>=20 Thanks,
>>>>>=20 Rakesh
>>>>>
>>>>> -----Original=20 Message-----
>>>>> From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On
>>>>> Behalf Of=20 internet-drafts@ietf.org
>>>>> Sent: Wednesday, August 15= ,=20 2012 10:53 AM
>>>>> To:=20 i-d-announce@ietf.org
>>>>> Cc:=20 ccamp@ietf.org
>>>>> Subject: [CCAMP] I-D=20 Action:
>>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;>
>>>>>
>>>>>=20 A New Internet-Draft is available from the on-line=20 Internet-Drafts
>>> directories.
>>>>>  = This=20 draft is a work item of the Common Control and Measurement
>>> = Plane=20 Working Group of the IETF.
>>>>>
>>>>>= =20    Title           : RSVP-TE Extensions = for=20 Associated Bidirectional
>>> LSPs
>>>>>  = ;=20  Author(s)       : Fei Zhang
>>>>> &n= bsp;=20                      = ;=20   Ruiquan Jing
>>>>>         &nb= sp;=20                 Rakesh=20 Gandhi
>>>>>    Filename      =20  : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-
>>>=20 lsp-04.txt
>>>>>    Pages      = =20     : 17
>>>>>    Date    = =20        :=20 2012-08-15
>>>>>
>>>>>=20 Abstract:
>>>>>    The MPLS Transport Profile=20 (MPLS-TP) requirements document
>>>=20 [RFC5654],
>>>>>    describes that MPLS-TP MUST= =20 support associated bidirectional
>>> point-
>>>>= >=20    to-point LSPs.
>>>>>
>>>>>= =20    This document provides a method to bind two unidirectional=20 Label
>>>>>    Switched Paths (LSPs) into an=20 associated bidirectional LSP.  The
>>>>>  =20  association is achieved by defining the new Association Type=20 in
>>> the
>>>>>    Extended ASSOCI= ATION=20 object.
>>>>>
>>>>>
>>>>= >=20 The IETF datatracker status page for this draft is:
>>>>>= =20 https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-
>&g= t;>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp
>>>>>
>>>>> There's also = a=20 htmlized version available at:
>>>>>=20 http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>= >=20 associ
>>>>> a
>>>>>=20 ted-lsp-04
>>>>>
>>>>> A diff from the= =20 previous version is available at:
>>>>>=20 http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte-
>= >>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp-04
>>>>>
>>>>>
>>= ;>>>=20 Internet-Drafts are also available by anonymous FTP at:
>>>>= >=20 ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>= >>=20 _______________________________________________
>>>>> CCA= MP=20 mailing list
>>>>> CCAMP@ietf.org
>>>>>= =20 https://www.ietf.org/mailman/listinfo/ccamp
>>>>>
>= >>>>
>>>>>
>>>>>
>>= ;>>
>>>>
>>>>
>>>>
&g= t;>>=20 _______________________________________________
>>> CCAMP maili= ng=20 list
>>> CCAMP@ietf.org
>>>=20 https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>= >
>>
>=20 _______________________________________________
> CCAMP mailing=20 list
> CCAMP@ietf.org
>=20 https://www.ietf.org/mailman/listinfo/ccamp
____________________________= ___________________
CCAMP=20 mailing=20 list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

--_000_FE60A4E52763E84B935532D7D9294FF139268CBE68EUSAACMS0715e_-- From jdrake@juniper.net Fri Aug 17 10:53:21 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEBA11E80D1 for ; Fri, 17 Aug 2012 10:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.675 X-Spam-Level: X-Spam-Status: No, score=-5.675 tagged_above=-999 required=5 tests=[AWL=0.924, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfNE8BdfaG0V for ; Fri, 17 Aug 2012 10:53:20 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 81A6F11E809B for ; Fri, 17 Aug 2012 10:53:18 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUC6FDP2RQ0KLXQhCsOL4eB3LE8lBHDcl@postini.com; Fri, 17 Aug 2012 10:53:18 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 17 Aug 2012 10:52:07 -0700 From: John E Drake To: "Rakesh Gandhi (rgandhi)" , Lou Berger , Francesco Fondelli Date: Fri, 17 Aug 2012 10:52:05 -0700 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: AQHNfFUlLNlyxvO8A0+szRTdhFvnqpdeZvsA///YPBCAAAYw8A== Message-ID: <5E893DB832F57341992548CDBB333163A631A84C84@EMBX01-HQ.jnpr.net> References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <502E574E.90405@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 17:53:21 -0000 UmFrZXNoLA0KDQoxKSAgSW4gdGhlIGNvbnRleHQgb2YgTVBMUy1UUCwgdGhlIGNvbnRyb2wgcGxh bmUgaXMgR01QTFMgbm90IE1QTFMuDQoNCjIpICBUaGUgZGlzdGluY3Rpb24gYmV0d2VlbiBhbiBN UExTIGNvbnRyb2wgcGxhbmUgYW5kIGEgR01QTFMgY29udHJvbCBwbGFuZSBpcyBsYXJnZWx5IG1v b3Q7ICBpLmUuLCBpdCdzIGp1c3QgUlNWUCBzaWduYWxpbmcgd2l0aCBzb21lIGRpZmZlcmVudCBv YmplY3RzIGFuZCBib3RoIGNhbiBjby1leGlzdCB3aXRob3V0IGFueSBpc3N1ZXMgaW4gYSBzZW5z aWJsZSBpbXBsZW1lbnRhdGlvbi4NCg0KMykgIFdoZXRoZXIgeW91IGFkZCB0aGUgb2JqZWN0cyBk ZWZpbmVkIGluIFJGQyAzNDczIG9yIHlvdSBhZGQgdGhlIG9iamVjdHMgaW4gdGhpcyBwcm9wb3Nh bCwgeW91IGFyZSBhZGRpbmcgbmV3IG9iamVjdHMgYW5kIHRoZWlyIGFzc29jaWF0ZWQgcHJvY2Vk dXJlcy4NCg0KNCkgIFRoaXMgcHJvcG9zYWwgd2FzIGNvbnNpZGVyZWQgdHdlbHZlIHllYXJzIGFn byBhbmQgcmVqZWN0ZWQgaW4gZmF2b3Igb2YgdGhlIGFwcHJvYWNoIGluIFJGQyAzNDczLg0KDQo1 KSAgSW4gdGhlIGNvbnRleHQgb2YgTVBMUy1UUCwgd2UgaGF2ZSBzcGVudCB0aGUgcGFzdCB0aHJl ZSB5ZWFycyBhcmd1aW5nIHRoYXQgZG9pbmcgdGhlIHNhbWUgZnVuY3Rpb24gaW4gZGlmZmVyZW50 IHdheXMgaXMgYSBCYWQgSWRlYSh0bSkuICBXaHkgd291bGQgd2Ugd2FudCB0byBzdWRkZW5seSBl bWJyYWNlIHR3byBtZXRob2RzIG9mIGVzdGFibGlzaGluZyBjby1yb3V0ZWQgYmlkaXJlY3Rpb25h bCBwYWNrZXQgTFNQcywgZXNwZWNpYWxseSB3aGVuIHRoZSBuZXcgcHJvcG9zYWwgaXMga25vd24g dG8gYmUgc3ViLW9wdGltYWwgcmVsYXRpdmUgdG8gdGhlIGV4aXN0aW5nIG1ldGhvZD8NCg0KVGhh bmtzLA0KDQpKb2huDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSBbbWFpbHRvOnJnYW5k aGlAY2lzY28uY29tXQ0KPiBTZW50OiBGcmlkYXksIEF1Z3VzdCAxNywgMjAxMiAxMDoyOSBBTQ0K PiBUbzogTG91IEJlcmdlcjsgRnJhbmNlc2NvIEZvbmRlbGxpDQo+IENjOiBKb2huIEUgRHJha2U7 IGNjYW1wQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LQ0KPiBhc3NvY2lhdGVkLWxzcC0wNC50eHQN Cj4gDQo+IFRoYW5rcyBGcmFuY2VzY28gYW5kIExvdS4NCj4gDQo+IEp1c3QgbGlrZSBjMSBpbiB0 aGUgaW5pdGlhbCBwcm9wb3NhbCBvZiB0aGUgZHJhZnQgZm9yIHRoZSBhc3NvY2lhdGVkDQo+IGJp ZGlyZWN0aW9uYWwgTFNQLCBjMiBhbGxvd3MgdGhlIE1QTFMtVEUgcGFja2V0IGNvbnRyb2wgcGxh bmUgY3VycmVudGx5DQo+IGRlcGxveWVkIGluIHRoZSBuZXR3b3JrIChub24gR01QTFMpIHRvIGJl IHVzZWQgdG8gcHJvdmlkZSBjby1yb3V0ZWQNCj4gKGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCkg TFNQIGZ1bmN0aW9uYWxpdHkgd2l0aG91dCBoYXZpbmcgdG8gbWlncmF0ZQ0KPiB0byBHTVBMUyBw cm90b2NvbCBpbiBSRkMgMzQ3My4NCj4gDQo+IEkgZG8gYWdyZWUgd2l0aCB5b3UgTG91IG9uIHNv bWUgb2YgdGhlIGNvbXBsZXhpdHkgdGhhdCBtYXkgY29tZSB3aXRoIGl0DQo+IChNQkIsIHJlcm91 dGluZywgcmVjb3ZlcnksIGV0Yy4pLg0KPiANCj4gVGhhbmtzLA0KPiBSYWtlc2gNCj4gDQo+IA0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86 bGJlcmdlckBsYWJuLm5ldF0NCj4gU2VudDogRnJpZGF5LCBBdWd1c3QgMTcsIDIwMTIgMTA6Mzgg QU0NCj4gVG86IEZyYW5jZXNjbyBGb25kZWxsaQ0KPiBDYzogUmFrZXNoIEdhbmRoaSAocmdhbmRo aSk7IEpvaG4gRSBEcmFrZTsgY2NhbXBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtDQ0FNUF0g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtDQo+IGFzc29j aWF0ZWQtbHNwLTA0LnR4dA0KPiANCj4gRnJhbmNlc2NvLA0KPiANCj4gCU5pY2Ugc3VtbWFyeS4g IEkgdGhpbmsgeW91ciBsYXN0IG9ic2VydmF0aW9uLCBhYm91dCBiIGFuZCBjMg0KPiBiZWluZyB0 aGUgc2FtZSBpbiB0aGUgZGF0YSBwbGFuZSwgaXMgdGhlIGtleSBvbmUuICBVcCB0byBub3csIEkg ZG9uJ3QNCj4ga25vdyBvZiBhbnlvbmUgb3IgYW55IGRyYWZ0IHRoYXQgaGFzIHN1Z2dlc3RlZCBh bnl0aGluZyBidXQgdXNpbmcgYiBmb3INCj4gdGhlIGNvbnRyb2wgcGxhbmUgcmVwcmVzZW50YXRp b24gb2YgY28tcm91dGVkIFRQIHBhdGhzLiAgVGhlIEpXVCBldmVuDQo+IGNhbGxlZCBvdXQgdXNp bmcgYi4NCj4gDQo+IFdlIGhhZCBhIGxvdCBvZiBkaXNjdXNzaW9uIChva2F5LCBhcmd1bWVudHMp IGFib3V0IHRoaXMgaW4gdGhlIGVhcmx5DQo+IGRheXMgb2YgR01QTFMgd2hlcmUgd2UgZGViYXRl ZCBqdXN0IHVzaW5nIHRoZSB0aGVuIHByYWN0aWNlIG9mIHVzaW5nDQo+IEVST3MgdG8gcHJvdmlk ZSBhIGJpZGlyZWN0aW9uYWwgY28tcm91dGVkIGRhdGEgcGF0aCB1c2luZyAyDQo+IHVuaWRpcmVj dGlvbmFsIGNvbnRyb2wgcGxhbmUgTFNQcy4gIE9idmlvdXNseSB0aGUgcG9zaXRpb24gb2YgdXNp bmcgKGIpDQo+IHdvbiBvdXQuICBMYXJnZWx5IGJlY2F1c2UgdGhlIGIgYXBwcm9hY2ggZ3JlYXRs eSBzaW1wbGlmaWVkIHRoZSBjb250cm9sDQo+IHBsYW5lIGZvciBjb21wbGV4IGJlaGF2aW9ycyBz dWNoIGFzIE1CQiwgcmVyb3V0aW5nLCByZWNvdmVyeSwgZXRjLg0KPiANCj4gSXQgZG9lcyBzZWVt IHRoYXQgdGhlIGRyYWZ0L3Byb3Bvc2FsIGlzIGluIGZhY3QgZm9yIGMyLCBhcyBjb25maXJtZWQg YnkNCj4gRmVpJ3MgbWFpbC4gIEkgd2FzIGhvcGluZyB0aGF0IHdlIGNvdWxkIGdldCBzb21lb25l IHRvIGRlc2NyaWJlIHRoZQ0KPiBpc3N1ZSB0aGV5IGFyZSB0cnlpbmcgdG8gYWRkcmVzcyAocGVy aGFwcyBhcyBhbiBpbnRlbmRlZCB1c2FnZQ0KPiBzY2VuYXJpbykgYXMgd2VsbCBhcyB3aHkgdGhl IGFkZGVkIGNvbnRyb2wgcGxhbmUgY29tcGxleGl0eSBpcyBhIGdvb2QNCj4gaWRlYS4NCj4gUGFy dGljdWxhcmx5IGFzIGFsbCB0aGUgY29ybmVyIGNhc2VzIG5lZWQgdG8gYmUgYWRkcmVzc2VkLg0K PiANCj4gTG91DQo+IA0KPiBPbiA4LzE3LzIwMTIgNDo0OCBBTSwgRnJhbmNlc2NvIEZvbmRlbGxp IHdyb3RlOg0KPiA+IEhpIEFsbCwNCj4gPg0KPiA+IEkgdGhpbmsgSSdtIGxvc3QsIHBsZWFzZSBo ZWxwLg0KPiA+DQo+ID4gUmFrZXNoIGlzIHRhbGtpbmcgYWJvdXQgImNvLXJvdXRlZCBhc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgTFNQIi4uLg0KPiA+IGZvciB0aGUgc2FrZSBvZiBjbGFyaXR5LCBs ZXQgbWUgdHJ5IHRvIGNhdGVnb3JpemUgTFNQcyBmcm9tIGEgY29udHJvbA0KPiA+IHBsYW5lIHZp ZXcgcG9pbnQ6DQo+ID4NCj4gPiAgIGEpIFBvaW50LXRvLXBvaW50IHVuaWRpcmVjdGlvbmFsDQo+ ID4gICBiKSBQb2ludC10by1wb2ludCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KPiA+ICAgYykg UG9pbnQtdG8tcG9pbnQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQo+ID4gICAgYzEpIGZ3ZCBh bmQgcmV2IExTUCBmb2xsb3cgZGlmZmVyZW50IHBhdGhzDQo+ID4gICAgYzIpIGZ3ZCBhbmQgcmV2 IExTUCBmb2xsb3cgc2FtZSBwYXRoDQo+ID4gICBkKSBQb2ludC10by1tdWx0aXBvaW50IHVuaWRp cmVjdGlvbmFsDQo+ID4gICBlKSBNdWx0aXBvaW50LXRvLXBvaW50IHVuaWRpcmVjdGlvbmFsDQo+ ID4NCj4gPiBJcyBzZWN0aW9uIDMuMi41IChTaWduYWxpbmcgb2YgQ28tcm91dGVkIExTUHMpIG9m DQo+ID4gbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwIGFib3V0IGIpIG9yIGl0IGlz IGFib3V0IGMyKT8NCj4gPg0KPiA+IEluIG15IG9waW5pb246DQo+ID4NCj4gPiAtIGIpIHNob3Vs ZCBiZSBzaWduYWxlZCB3aXRoIDM0NzMNCj4gPiAtIGMpIGFyZSBhZGRyZXNzZWQgYnkgdGhpcyBJ LUQgKG1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcCkNCj4gPg0KPiA+IEFtIEkgbWlz c2luZyBzb21ldGhpbmc/DQo+ID4NCj4gPiB0aGFuayB5b3UNCj4gPiBjaWFvDQo+ID4gZnJhDQo+ ID4NCj4gPiBQUw0KPiA+IGZyb20gYSBkYXRhLXBsYW5lIHZpZXcgcG9pbnQgYikgYW5kIGMyKSBh cmUgdGhlIHNhbWUgdGhpbmcuDQo+ID4NCj4gPiBPbiBGcmksIEF1ZyAxNywgMjAxMiBhdCAxMjox NiBBTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCj4gPiA8cmdhbmRoaUBjaXNjby5jb20+IHdy b3RlOg0KPiA+PiBIaSBMb3UsDQo+ID4+DQo+ID4+IFRoYW5rcyBmb3IgaW5pdGlhdGluZyBkaXNj dXNzaW9ucyBvbiB0aGUgY2hhbmdlcyBpbiB0aGUgZHJhZnQuDQo+ID4+DQo+ID4+IEFncmVlIHdp dGggeW91IGhlcmUsIGlmIHdlL1dHIGRvIG5vdCBhZ3JlZSBvbiB0aGUgImNvLXJvdXRlZA0KPiBh c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQIiBwYXJ0LCB3ZSBhcmUgb2sgdG8gcmVtb3ZlIGl0 IGZyb20gdGhpcw0KPiBkcmFmdCBhbmQgY2FuIGFsd2F5cyBzdWJtaXQgYSBuZXcgZHJhZnQganVz dCBmb3IgdGhhdC4gV2UgcmVzcGVjdA0KPiB5b3VyL1dHIGRlY2lzaW9uLg0KPiA+Pg0KPiA+PiBU aGFua3MsDQo+ID4+IFJha2VzaA0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJu Lm5ldF0NCj4gPj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxNiwgMjAxMiA2OjA4IFBNDQo+ID4+ IFRvOiBKb2huIEUgRHJha2UNCj4gPj4gQ2M6IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpOyBjY2Ft cEBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBJLUQgQWN0aW9uOg0KPiA+PiBk cmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQN Cj4gPj4NCj4gPj4gSm9obiwNCj4gPj4gICAgICAgICBXaGlsZSBzdHJpY3RseSBzcGVha2luZyBX RyBkcmFmdHMgc2hvdWxkIG9ubHkgcmVmbGVjdA0KPiBjdXJyZW50IFdHIGNvbnNlbnN1cywgYW5k IGl0IGlzIHRoZSBXRyBkcmFmdCBlZGl0b3IncyBqb2IgdG8gZW5zdXJlDQo+IHRoaXMsIGluIHBy YWN0aWNlIGF1dGhvcnMvZWRpdG9ycyBhcmUgZ2l2ZW4gYSBsb3Qgb2YgbGF0aXR1ZGUgaW4gdGlt aW5nDQo+IC8gb3JkZXJpbmcgaW4gaW50cm9kdWN0aW9uIHRvIGNoYW5nZXMuICBJIHBlcnNvbmFs bHkgdGhpbmsgdGhpcyBpcyBhDQo+IHByYWN0aWNhbCB3YXkgb2Yga2VlcGluZyB0aGUgcHJvY2Vz cyBtb3ZpbmcuICBBbHNvIGlmIHRoZSBXRyBkaXNhZ3JlZXMNCj4gd2l0aCBhIGNoYW5nZSwgaXQg Y2FuIGFsd2F5cyBiZSBiYWNrZWQgb3V0Lg0KPiA+Pg0KPiA+PiBTbywgeWVzLCB0aGUgV0cgY291 bGQgZG8gZXhhY3RseSBhcyB5b3Ugc2F5IGlmIGl0IGNvbWVzIHRvIGl0LiAgKFRoZQ0KPiA+PiBj aGFpcnMgY2FuIGV2ZW4gYXBwb2ludCBkaWZmZXJlbnQgZWRpdG9yIGlmIG5lZWRlZCwgZS5nLiwg dG8gbWFrZQ0KPiA+PiB0aGlzDQo+ID4+IGhhcHBlbi4pICBXaGlsZSBJJ20gbm90IGhhcHB5IHdp dGggaG93IHRoaXMgcmV2aXNpb24gY2FtZSBhYm91dCwgYXMNCj4gSSBjb3ZlcmVkIGluIGVhcmxp ZXIgbWFpbCwgbXkgZmVlbGluZyBpcyB0byBsZXQgdGhlIGRpc2N1c3Npb24gdGFrZQ0KPiBwbGFj ZSBvbiB0aGUgbGlzdCAoYW5kIGF0IHRoZSBuZXh0IElFVEYsIGlmIG5lZWRlZCkgYW5kIHRoZW4g aGF2ZSB0aGUNCj4gZHJhZnQgdXBkYXRlZCB0byByZWZsZWN0IHRoZSBXRyBkaXNjdXNzaW9uL2Nv bnNlbnN1cy4NCj4gPj4NCj4gPj4gTG91DQo+ID4+DQo+ID4+IE9uIDgvMTYvMjAxMiA1OjM1IFBN LCBKb2huIEUgRHJha2Ugd3JvdGU6DQo+ID4+PiBMb3UsDQo+ID4+Pg0KPiA+Pj4gU2luY2UgdGhl IFdHIGRpZCBub3QgYWdyZWUgdG8gdGhpcyBjaGFuZ2VzLCBsZXQgYWxvbmUgZGlzY3VzcyB0aGVt LA0KPiA+Pj4gd291bGQgaXQgYmUgcG9zc2libGUgdG8gc2ltcGx5IHJvbGxiYWNrIHRoZXNlIGNo YW5nZXMgYW5kIGFzayB0aGUNCj4gPj4+IGF1dGhvcnMgdG8gd3JpdGUgYSBkcmFmdCBhZGRyZXNz aW5nIHRoZSB0b3BpY3MgeW91IGxpc3QgaW4geW91cg0KPiA+Pj4gZW1haWwsIGJlbG93Pw0KPiA+ Pj4NCj4gPj4+IFRoYW5rcywNCj4gPj4+DQo+ID4+PiBKb2huDQo+ID4+Pg0KPiA+Pj4gU2VudCBm cm9tIG15IGlQaG9uZQ0KPiA+Pj4NCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4+PiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAt Ym91bmNlc0BpZXRmLm9yZ10gT24NCj4gPj4+PiBCZWhhbGYgT2YgTG91IEJlcmdlcg0KPiA+Pj4+ IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTYsIDIwMTIgMjoxMCBQTQ0KPiA+Pj4+IFRvOiBSYWtl c2ggR2FuZGhpIChyZ2FuZGhpKQ0KPiA+Pj4+IENjOiBjY2FtcEBpZXRmLm9yZw0KPiA+Pj4+IFN1 YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBBY3Rpb246DQo+ID4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1t cGxzLXRwLXJzdnB0ZS1leHQtDQo+ID4+Pj4gYXNzb2NpYXRlZC1sc3AtMDQudHh0DQo+ID4+Pj4N Cj4gPj4+PiBSYWtlc2gsDQo+ID4+Pj4gICAgICBTdWNoIG1ham9yIGNoYW5nZXMgKGluIHNjb3Bl IGFuZCBmdW5jdGlvbmFsaXR5KSB0byBXRyBkcmFmdHMNCj4gPj4+PiBhcmUgdXN1YWxseSBkaXNj dXNzZWQgd2l0aCB0aGUgV0cgcHJpb3IgdG8gdGhlIGF1dGhvcnMvZWRpdG9ycw0KPiBqdXN0DQo+ ID4+Pj4gcHVibGlzaGluZyB0aGUgY2hhbmdlcy4gIEJ1dCwgdGhpcyBpcyBhIGp1ZGdtZW50IGNh bGwgYnkgdGhlDQo+ID4+Pj4gZG9jdW1lbnQgZWRpdG9ycyBpbiBob3csIHF1b3RpbmcgcmZjMjQx OCwgdGhleSAiZW5zdXJbZV0gdGhhdCB0aGUNCj4gPj4+PiBjb250ZW50cyBvZiB0aGUgZG9jdW1l bnQgYWNjdXJhdGVseSByZWZsZWN0IHRoZSBkZWNpc2lvbnMgdGhhdA0KPiBoYXZlDQo+ID4+Pj4g YmVlbiBtYWRlIGJ5IHRoZSB3b3JraW5nIGdyb3VwLiINCj4gPj4+Pg0KPiA+Pj4+IFNvIGxldCdz IGp1bXAgaW50byBkaXNjdXNzaW5nIHRoZSBjaGFuZ2VzLg0KPiA+Pj4+DQo+ID4+Pj4gQXMgSSBz ZWUgaXQgdGhpcyBkcmFmdCBpbnRyb2R1Y2VzIHNldmVyYWwgbWFqb3IgZnVuY3Rpb25hbCBjaGFu Z2VzDQo+ID4+Pj4gdGhhdCBoYXZlIG5vdCBiZWVuIGRpc2N1c3NlZCBieSB0aGUgV0cuICBDb3Jy ZWN0IG1lIGlmIEkgZ2V0IHRoZW0NCj4gPj4+PiB3cm9uZywgYnV0IEkgYmVsaWV2ZSB0aGV5IGlu Y2x1ZGU6DQo+ID4+Pj4gMSkgSW50cm9kdWN0aW9uIG9mIGEgc2Vjb25kIG1ldGhvZCBmb3Igc2ln bmFsaW5nIENvLXJvdXRlZCBMU1BzDQo+ID4+Pj4gMikgU3VwcG9ydCBmb3IgRlJSIGJ5cGFzcyB0 dW5uZWxzIGZvciBwaWdneWJhY2tlZCBvbiB0aGUgVFANCj4gPj4+PiBiaWRpcmVjdGlvbmFsIExT UCBtZWNoYW5pc21zLg0KPiA+Pj4+DQo+ID4+Pj4gICAgVGhlcmUgYXJlIGFsc28gb3RoZXIgY2hh bmdlcywgYnV0IEknbGwgZGVmZXIgZGlzY3Vzc2luZyB0aGVtDQo+ID4+Pj4gICAgdW50aWwgdGhl IGRpc2N1c3Npb24gb24gdGhlIGFib3ZlIGlzIGNvbmNsdWRlZC4NCj4gPj4+Pg0KPiA+Pj4+IElz IHRoaXMgY29ycmVjdD8NCj4gPj4+Pg0KPiA+Pj4+IEFzc3VtaW5nIHllcywgSSBoYXZlIHF1ZXN0 aW9ucyBhYm91dCBib3RoIHJhdGlvbmFsIGFuZCBzcGVjaWZpYw0KPiA+Pj4+IG1lY2hhbmlzbXMu ICBGb3Igbm93IGxldCdzIGxvb2sgYXQgdGhlIGZvcm1lciwgc28gcGxlYXNlOg0KPiA+Pj4+DQo+ ID4+Pj4gQSkgQXJ0aWN1bGF0ZSB0aGUgaXNzdWVzL2xpbWl0YXRpb25zIHdpdGggdXNpbmcgdGhl IFJGQzM0NzMNCj4gZGVmaW5lZA0KPiA+Pj4+IG1lY2hhbmlzbXMgZm9yIChjby1yb3V0ZWQpIGJp ZGlyZWN0aW9uYWwgTFNQcyB0aGF0IHlvdSdkIGxpa2UgdG8NCj4gPj4+PiBzZWUgYWRkcmVzc2Vk Lg0KPiA+Pj4+DQo+ID4+Pj4gQi4xKSBBcnRpY3VsYXRlIHRoZSBGUlIvR01QTFMtcmVsYXRlZCBp c3N1ZSB5b3UnZCBsaWtlIHRvIGFkZHJlc3M/DQo+ID4+Pj4NCj4gPj4+PiBCLjIpIEFydGljdWxh dGUgd2h5IHRoaXMgaXNzdWUgc2hvdWxkIGJlIHNvbHZlZCBpbiBhIFRQLXNwZWNpZmljDQo+ID4+ Pj4gYW5kIG5vdCBHTVBMUyBnZW5lcmljIGZhc2hpb24/DQo+ID4+Pj4NCj4gPj4+PiBUaGFua3Ms DQo+ID4+Pj4gTG91DQo+ID4+Pj4NCj4gPj4+PiBPbiA4LzE2LzIwMTIgNDoyNiBQTSwgUmFrZXNo IEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6DQo+ID4+Pj4+IEhpIExvdSwNCj4gPj4+Pj4NCj4gPj4+ Pj4gWWVzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBQbGVhc2UgYWR2aXNlIGlmIHlvdSB0aGluayBkZXRh aWxlZCBlbWFpbCBpcyByZXF1aXJlZC4NCj4gPj4+Pj4gV2UgYmVsaWV2ZSBsYXRlc3QgZHJhZnQg c3VtbWFyaXplcyB0aGUgY2hhbmdlcyB3ZWxsIGFuZCB3ZSBjb3VsZA0KPiA+Pj4+IHN0YXJ0IHJl dmlldy9kaXNjdXNzaW9ucyBmcm9tIHRoZXJlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGFua3MsDQo+ ID4+Pj4+IFJha2VzaA0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+Pj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJu Lm5ldF0NCj4gPj4+Pj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxNiwgMjAxMiA0OjAwIFBNDQo+ ID4+Pj4+IFRvOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KPiA+Pj4+PiBDYzogY2NhbXBAaWV0 Zi5vcmc7IHpoYW5nLmZlaTNAenRlLmNvbS5jbg0KPiA+Pj4+PiBTdWJqZWN0OiBSZTogW0NDQU1Q XSBJLUQgQWN0aW9uOg0KPiA+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4 dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCj4gPj4+Pj4NCj4gPj4+Pj4gUmFrZXNoLA0KPiA+Pj4+ PiAgICAgSXMgdGhpcyB0aGUgc3RhcnQgb2YgdGhlIHRocmVhZCB0aGF0IEkgcmVxdWVzdGVkIGlu DQo+ID4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9jY2FtcC9jdXJy ZW50L21zZzEzNzI5Lmh0bWwNCj4gPj4+Pj4NCj4gPj4+Pj4gSW4gcGFydGljdWxhciwgaXMgaXQg dGhlIHJlc3BvbnNlIHRvOg0KPiA+Pj4+Pj4gSSdkIGxpa2UgdG8gYXNrIHRoYXQgc29tZW9uZSAo UmFrZXNoLCBGZWksIGV0Yy4pIHJldmlldyBlYWNoIG9mDQo+ID4+Pj4+PiB0aGUgcHJvcG9zZWQg Y2hhbmdlIGFuZCB0aGUgcmF0aW9uYWwgZm9yIGVhY2ggY2hhbmdlIChpbiBvbmUgb3INCj4gPj4+ Pj4+IGluIHNlcGFyYXRlIGUtbWFpbHMpLiBUaGUgV0cgZGlzY3Vzc2lvbiBjYW4gdGhlbiByZWFs bHkgYmVnaW4gb24NCj4gPj4+Pj4+IHRoZSBwcm9wb3NlZCBjaGFuZ2VzLiAoV2hpY2ggYXJlIHF1 aXRlIHN1YnN0YW50aWFsIGJvdGggaW4gc2NvcGUNCj4gPj4+Pj4+IGFuZA0KPiA+Pj4+Pj4gaW1w bGljYXRpb24uKQ0KPiA+Pj4+Pg0KPiA+Pj4+PiBMb3UNCj4gPj4+Pj4NCj4gPj4+Pj4gT24gOC8x Ni8yMDEyIDM6MTkgUE0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIHdyb3RlOg0KPiA+Pj4+Pj4g SGkgQWxsLA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFdlIGhhdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lv biBvZiB0aGlzIGRyYWZ0IHdpdGggZm9sbG93aW5nDQo+IGNoYW5nZXM6DQo+ID4+Pj4+DQo+ID4+ Pj4+IDEuICBBZGRlZCBhIHNlY3Rpb24gb24gU2lnbmFsaW5nIG9mIENvLXJvdXRlZCBMU1BzDQo+ ID4+Pj4+DQo+ID4+Pj4+IDIuICBBZGRlZCBjbGFyaWZpY2F0aW9uIG9uIFNpZ25hbGluZyBvZiBB c3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwNCj4gPj4+Pj4gUHJvdGVjdGlvbiBMU1BzDQo+ID4+Pj4+ DQo+ID4+Pj4+IDMuICBBZGRlZCBhIHNlY3Rpb24gb24gU2lnbmFsaW5nIG9mIEF1dG8tdHVubmVs IE1lc2gtZ3JvdXAgTFNQcw0KPiA+Pj4+Pg0KPiA+Pj4+PiA0LiAgIEFkZGVkIGNsYXJpZmljYXRp b24gb24gU2lnbmFsaW5nIG9mIEludGVyLWRvbWFpbiBBc3NvY2lhdGVkDQo+ID4+Pj4gQmlkaXJl Y3Rpb25hbCBMU1BzDQo+ID4+Pj4+DQo+ID4+Pj4+IDUuICBUaGUgRXh0ZW5kZWQgQVNTT0NJQVRJ T04gb2JqZWN0IGZvcm1hdCB3aXRoIEFzc29jaWF0aW9uIFR5cGUNCj4gPj4+PiAiQXNzb2NpYXRl ZCBCaWRpcmVjdGlvbmFsIExTUCIuIENsYXJpZmllZCBvbiBob3cgdG8gcG9wdWxhdGUNCj4gPj4+ PiBkaWZmZXJlbnQgZmllbGRzIGluIHRoaXMgb2JqZWN0Lg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+ Pj4+Pj4gV2UgYmVsaWV2ZSB0aGF0IHNvbWUgb2YgdGhlc2UgY2hhbmdlcyB3ZXJlIG5lY2Vzc2Fy eSB0byBhdm9pZA0KPiB0aGUNCj4gPj4+PiBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyBkdWUgdG8g cG90ZW50aWFsbHkgZGlmZmVyZW50DQo+IGludGVycHJldGF0aW9ucy4NCj4gPj4+Pj4+DQo+ID4+ Pj4+PiBZb3VyIHJldmlldyBjb21tZW50cyBhcmUgd2VsY29tZS4NCj4gPj4+Pj4+DQo+ID4+Pj4+ PiBUaGFua3MsDQo+ID4+Pj4+PiBSYWtlc2gNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+Pj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4+Pj4+PiBCZWhhbGYgT2YgaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ID4+Pj4+PiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAx NSwgMjAxMiAxMDo1MyBBTQ0KPiA+Pj4+Pj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiA+ Pj4+Pj4gQ2M6IGNjYW1wQGlldGYub3JnDQo+ID4+Pj4+PiBTdWJqZWN0OiBbQ0NBTVBdIEktRCBB Y3Rpb246DQo+ID4+Pj4+PiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3Nv Y2lhdGVkLWxzcC0wNC50eHQNCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQSBOZXcgSW50 ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUNCj4gPj4+Pj4+IEludGVy bmV0LURyYWZ0cw0KPiA+Pj4+IGRpcmVjdG9yaWVzLg0KPiA+Pj4+Pj4gIFRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIENvbW1vbiBDb250cm9sIGFuZCBNZWFzdXJlbWVudA0KPiA+Pj4+ IFBsYW5lIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAg VGl0bGUgICAgICAgICAgIDogUlNWUC1URSBFeHRlbnNpb25zIGZvciBBc3NvY2lhdGVkDQo+IEJp ZGlyZWN0aW9uYWwNCj4gPj4+PiBMU1BzDQo+ID4+Pj4+PiAgICBBdXRob3IocykgICAgICAgOiBG ZWkgWmhhbmcNCj4gPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgUnVpcXVhbiBKaW5n DQo+ID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFJha2VzaCBHYW5kaGkNCj4gPj4+ Pj4+ICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUt ZXh0LQ0KPiBhc3NvY2lhdGVkLQ0KPiA+Pj4+IGxzcC0wNC50eHQNCj4gPj4+Pj4+ICAgIFBhZ2Vz ICAgICAgICAgICA6IDE3DQo+ID4+Pj4+PiAgICBEYXRlICAgICAgICAgICAgOiAyMDEyLTA4LTE1 DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQWJzdHJhY3Q6DQo+ID4+Pj4+PiAgICBUaGUgTVBMUyBUcmFu c3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgcmVxdWlyZW1lbnRzIGRvY3VtZW50DQo+ID4+Pj4gW1JG QzU2NTRdLA0KPiA+Pj4+Pj4gICAgZGVzY3JpYmVzIHRoYXQgTVBMUy1UUCBNVVNUIHN1cHBvcnQg YXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQo+ID4+Pj4gcG9pbnQtDQo+ID4+Pj4+PiAgICB0by1w b2ludCBMU1BzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMg YSBtZXRob2QgdG8gYmluZCB0d28gdW5pZGlyZWN0aW9uYWwNCj4gTGFiZWwNCj4gPj4+Pj4+ICAg IFN3aXRjaGVkIFBhdGhzIChMU1BzKSBpbnRvIGFuIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBM U1AuDQo+IFRoZQ0KPiA+Pj4+Pj4gICAgYXNzb2NpYXRpb24gaXMgYWNoaWV2ZWQgYnkgZGVmaW5p bmcgdGhlIG5ldyBBc3NvY2lhdGlvbiBUeXBlDQo+ID4+Pj4+PiBpbg0KPiA+Pj4+IHRoZQ0KPiA+ Pj4+Pj4gICAgRXh0ZW5kZWQgQVNTT0NJQVRJT04gb2JqZWN0Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ DQo+ID4+Pj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczoNCj4gPj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtY2NhbXAtbXBscy10cC0NCj4gcnN2cHRlLQ0KPiA+Pj4+IGV4dC0NCj4gPj4+Pj4+IGENCj4g Pj4+Pj4+IHNzb2NpYXRlZC1sc3ANCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGVyZSdzIGFsc28gYSBo dG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gPj4+Pj4+IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LQ0KPiA+Pj4+IGFz c29jaQ0KPiA+Pj4+Pj4gYQ0KPiA+Pj4+Pj4gdGVkLWxzcC0wNA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPj4+ Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2NhbXAtbXBs cy10cC0NCj4gcnN2cHRlLQ0KPiA+Pj4+IGV4dC0NCj4gPj4+Pj4+IGENCj4gPj4+Pj4+IHNzb2Np YXRlZC1sc3AtMDQNCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+Pj4+Pj4gZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4gQ0NBTVAg bWFpbGluZyBsaXN0DQo+ID4+Pj4+PiBDQ0FNUEBpZXRmLm9yZw0KPiA+Pj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4g Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ Pj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPiA+Pj4+IENDQU1QQGlldGYub3JnDQo+ID4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiA+Pj4NCj4gPj4+DQo+ ID4+Pg0KPiA+Pj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+ID4+IENDQU1QQGlldGYub3JnDQo+ ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4gPg0KPiA+ DQo+ID4NCj4gPg0K From gregimirsky@gmail.com Fri Aug 17 12:27:32 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A5711E80A5 for ; Fri, 17 Aug 2012 12:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SsQroOGsnm6 for ; Fri, 17 Aug 2012 12:27:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C83821F8432 for ; Fri, 17 Aug 2012 12:27:30 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4219249vbb.31 for ; Fri, 17 Aug 2012 12:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c2V4tAV3UY+BCtvY9hjBUUM7DO3nBdYiaY4VvTkApxo=; b=i5XMwODc3iIVa47C1QXMk0AlcA3ul6FeGuOWvy1/IqSaGHBwjiDJQSW7iJHLYjZkyJ bFSiC09UeLARdDdDbYArEiBO5AV8QswjCgzRJdDlf5dfL6R1LXQdWCDXraaOSO5UtGtA cL+30ZMeGnaiHqnR2ZGKYmqtb2QPDjK1v891Q3puc2PtJt2tIrsuG7db1fFKkc++ljgo G2HZ076txuzoR3BK6KEuwOtyKbjcq7AGXy6X+BKN20hXFvo2nBXa8tV+UbZRTCkw+961 9AHWARb0wK8EzGvywUaPJ66gYJRcQC3YvzQQXdTiji2GjFl+W/HSwHbacwHthyhonnlg kD+w== MIME-Version: 1.0 Received: by 10.220.215.66 with SMTP id hd2mr3490352vcb.55.1345231646245; Fri, 17 Aug 2012 12:27:26 -0700 (PDT) Received: by 10.52.158.36 with HTTP; Fri, 17 Aug 2012 12:27:26 -0700 (PDT) In-Reply-To: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> Date: Fri, 17 Aug 2012 12:27:26 -0700 Message-ID: From: Greg Mirsky To: Francesco Fondelli Content-Type: multipart/alternative; boundary=bcaec54ee72a6a41c604c77b26e4 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 19:27:32 -0000 --bcaec54ee72a6a41c604c77b26e4 Content-Type: text/plain; charset=ISO-8859-1 Hi Francesco, "from a data-plane view point b) and c2) are the same thing" I think that given that c) is associated bi-directional LSP that implies independent OAM and protection for each direction, b) and c2) are not the same in the data plane view. E.g., there will be single CC/CV/RDI session for b) while c2) will have two sessions. And if linear protection requested, b) will be protected by single bi-directional LSP, but c2) - by two unidirectional LSPs. Regards, Greg On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli < francesco.fondelli@gmail.com> wrote: > Hi All, > > I think I'm lost, please help. > > Rakesh is talking about "co-routed associated bidirectional > LSP"... for the sake of clarity, let me try to categorize > LSPs from a control plane view point: > > a) Point-to-point unidirectional > b) Point-to-point co-routed bidirectional > c) Point-to-point associated bidirectional > c1) fwd and rev LSP follow different paths > c2) fwd and rev LSP follow same path > d) Point-to-multipoint unidirectional > e) Multipoint-to-point unidirectional > > Is section 3.2.5 (Signaling of Co-routed LSPs) of > mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? > > In my opinion: > > - b) should be signaled with 3473 > - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) > > Am I missing something? > > thank you > ciao > fra > > PS > from a data-plane view point b) and c2) are the same thing. > > On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: > > Hi Lou, > > > > Thanks for initiating discussions on the changes in the draft. > > > > Agree with you here, if we/WG do not agree on the "co-routed associated > bidirectional LSP" part, we are ok to remove it from this draft and can > always submit a new draft just for that. We respect your/WG decision. > > > > Thanks, > > Rakesh > > > > > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Thursday, August 16, 2012 6:08 PM > > To: John E Drake > > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > > Subject: Re: [CCAMP] I-D Action: > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > > > John, > > While strictly speaking WG drafts should only reflect current WG > consensus, and it is the WG draft editor's job to ensure this, in practice > authors/editors are given a lot of latitude in timing / ordering in > introduction to changes. I personally think this is a practical way of > keeping the process moving. Also if the WG disagrees with a change, it can > always be backed out. > > > > So, yes, the WG could do exactly as you say if it comes to it. (The > chairs can even appoint different editor if needed, e.g., to make this > > happen.) While I'm not happy with how this revision came about, as I > covered in earlier mail, my feeling is to let the discussion take place on > the list (and at the next IETF, if needed) and then have the draft updated > to reflect the WG discussion/consensus. > > > > Lou > > > > On 8/16/2012 5:35 PM, John E Drake wrote: > >> Lou, > >> > >> Since the WG did not agree to this changes, let alone discuss them, > >> would it be possible to simply rollback these changes and ask the > >> authors to write a draft addressing the topics you list in your email, > >> below? > >> > >> Thanks, > >> > >> John > >> > >> Sent from my iPhone > >> > >> > >>> -----Original Message----- > >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >>> Behalf Of Lou Berger > >>> Sent: Thursday, August 16, 2012 2:10 PM > >>> To: Rakesh Gandhi (rgandhi) > >>> Cc: ccamp@ietf.org > >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- > >>> associated-lsp-04.txt > >>> > >>> Rakesh, > >>> Such major changes (in scope and functionality) to WG drafts are > >>> usually discussed with the WG prior to the authors/editors just > >>> publishing the changes. But, this is a judgment call by the document > >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of > >>> the document accurately reflect the decisions that have been made by > >>> the working group." > >>> > >>> So let's jump into discussing the changes. > >>> > >>> As I see it this draft introduces several major functional changes > >>> that have not been discussed by the WG. Correct me if I get them > >>> wrong, but I believe they include: > >>> 1) Introduction of a second method for signaling Co-routed LSPs > >>> 2) Support for FRR bypass tunnels for piggybacked on the TP > >>> bidirectional LSP mechanisms. > >>> > >>> There are also other changes, but I'll defer discussing them > >>> until the discussion on the above is concluded. > >>> > >>> Is this correct? > >>> > >>> Assuming yes, I have questions about both rational and specific > >>> mechanisms. For now let's look at the former, so please: > >>> > >>> A) Articulate the issues/limitations with using the RFC3473 defined > >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see > >>> addressed. > >>> > >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? > >>> > >>> B.2) Articulate why this issue should be solved in a TP-specific and > >>> not GMPLS generic fashion? > >>> > >>> Thanks, > >>> Lou > >>> > >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: > >>>> Hi Lou, > >>>> > >>>> Yes. > >>>> > >>>> Please advise if you think detailed email is required. > >>>> We believe latest draft summarizes the changes well and we could > >>> start review/discussions from there. > >>>> > >>>> Thanks, > >>>> Rakesh > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Lou Berger [mailto:lberger@labn.net] > >>>> Sent: Thursday, August 16, 2012 4:00 PM > >>>> To: Rakesh Gandhi (rgandhi) > >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn > >>>> Subject: Re: [CCAMP] I-D Action: > >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > >>>> > >>>> Rakesh, > >>>> Is this the start of the thread that I requested in > >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html > >>>> > >>>> In particular, is it the response to: > >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the > >>>>> proposed change and the rational for each change (in one or in > >>>>> separate e-mails). The WG discussion can then really begin on the > >>>>> proposed changes. (Which are quite substantial both in scope and > >>>>> implication.) > >>>> > >>>> Lou > >>>> > >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: > >>>>> Hi All, > >>>>> > >>>>> We have uploaded a new version of this draft with following changes: > >>>> > >>>> 1. Added a section on Signaling of Co-routed LSPs > >>>> > >>>> 2. Added clarification on Signaling of Associated Bidirectional > >>>> Protection LSPs > >>>> > >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs > >>>> > >>>> 4. Added clarification on Signaling of Inter-domain Associated > >>> Bidirectional LSPs > >>>> > >>>> 5. The Extended ASSOCIATION object format with Association Type > >>> "Associated Bidirectional LSP". Clarified on how to populate > >>> different fields in this object. > >>>> > >>>> > >>>>> We believe that some of these changes were necessary to avoid the > >>> interoperability issues due to potentially different interpretations. > >>>>> > >>>>> Your review comments are welcome. > >>>>> > >>>>> Thanks, > >>>>> Rakesh > >>>>> > >>>>> -----Original Message----- > >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >>>>> Behalf Of internet-drafts@ietf.org > >>>>> Sent: Wednesday, August 15, 2012 10:53 AM > >>>>> To: i-d-announce@ietf.org > >>>>> Cc: ccamp@ietf.org > >>>>> Subject: [CCAMP] I-D Action: > >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > >>>>> > >>>>> > >>>>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>>>> This draft is a work item of the Common Control and Measurement > >>> Plane Working Group of the IETF. > >>>>> > >>>>> Title : RSVP-TE Extensions for Associated Bidirectional > >>> LSPs > >>>>> Author(s) : Fei Zhang > >>>>> Ruiquan Jing > >>>>> Rakesh Gandhi > >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- > >>> lsp-04.txt > >>>>> Pages : 17 > >>>>> Date : 2012-08-15 > >>>>> > >>>>> Abstract: > >>>>> The MPLS Transport Profile (MPLS-TP) requirements document > >>> [RFC5654], > >>>>> describes that MPLS-TP MUST support associated bidirectional > >>> point- > >>>>> to-point LSPs. > >>>>> > >>>>> This document provides a method to bind two unidirectional Label > >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The > >>>>> association is achieved by defining the new Association Type in > >>> the > >>>>> Extended ASSOCIATION object. > >>>>> > >>>>> > >>>>> The IETF datatracker status page for this draft is: > >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- > >>> ext- > >>>>> a > >>>>> ssociated-lsp > >>>>> > >>>>> There's also a htmlized version available at: > >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- > >>> associ > >>>>> a > >>>>> ted-lsp-04 > >>>>> > >>>>> A diff from the previous version is available at: > >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte- > >>> ext- > >>>>> a > >>>>> ssociated-lsp-04 > >>>>> > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>> > >>>>> _______________________________________________ > >>>>> CCAMP mailing list > >>>>> CCAMP@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> CCAMP mailing list > >>> CCAMP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ccamp > >> > >> > >> > >> > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --bcaec54ee72a6a41c604c77b26e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Francesco,
"from a data-plane view point b) and c2) are the same= thing"
I think that given that c) is associated bi-directional LSP= that implies independent OAM and protection for each direction, b) and c2)= are not the same in the data plane view. E.g., there will be single CC/CV/= RDI session for b) while c2) will have two sessions. And if linear protecti= on requested, b) will be protected by single bi-directional LSP, but c2) - = by two unidirectional LSPs.

Regards,
Greg

On Fri, Aug 17, 2012= at 1:48 AM, Francesco Fondelli <francesco.fondelli@gmail.com> wrote:
Hi All,

I think I'm lost, please help.

Rakesh is talking about "co-routed associated bidirectional
LSP"... for the sake of clarity, let me try to categorize
LSPs from a control plane view point:

=A0 a) Point-to-point unidirectional
=A0 b) Point-to-point co-routed bidirectional
=A0 c) Point-to-point associated bidirectional
=A0 =A0c1) fwd and rev LSP follow different paths
=A0 =A0c2) fwd and rev LSP follow same path
=A0 d) Point-to-multipoint unidirectional
=A0 e) Multipoint-to-point unidirectional

Is section 3.2.5 (Signaling of Co-routed LSPs) of
mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)?

In my opinion:

- b) should be signaled with 3473
- c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp)

Am I missing something?

thank you
ciao
fra

PS
from a data-plane view point b) and c2) are the same thing.

On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi)
<rgandhi@cisco.com> wrote: > Hi Lou,
>
> Thanks for initiating discussions on the changes in the draft.
>
> Agree with you here, if we/WG do not agree on the "co-routed asso= ciated bidirectional LSP" part, we are ok to remove it from this draft= and can always submit a new draft just for that. We respect your/WG decisi= on.
>
> Thanks,
> Rakesh
>
>
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@l= abn.net]
> Sent: Thursday, August 16, 2012 6:08 PM
> To: John E Drake
> Cc: Rakesh Gandhi (rgandhi); ccamp@i= etf.org
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-a= ssociated-lsp-04.txt
>
> John,
> =A0 =A0 =A0 =A0 While strictly speaking WG drafts should only reflect = current WG consensus, and it is the WG draft editor's job to ensure thi= s, in practice authors/editors are given a lot of latitude in timing / orde= ring in introduction to changes. =A0I personally think this is a practical = way of keeping the process moving. =A0Also if the WG disagrees with a chang= e, it can always be backed out.
>
> So, yes, the WG could do exactly as you say if it comes to it. =A0(The= chairs can even appoint different editor if needed, e.g., to make this
> happen.) =A0While I'm not happy with how this revision came about,= as I covered in earlier mail, my feeling is to let the discussion take pla= ce on the list (and at the next IETF, if needed) and then have the draft up= dated to reflect the WG discussion/consensus.
>
> Lou
>
> On 8/16/2012 5:35 PM, John E Drake wrote:
>> Lou,
>>
>> Since the WG did not agree to this changes, let alone discuss them= ,
>> would it be possible to simply rollback these changes and ask the<= br> >> authors to write a draft addressing the topics you list in your em= ail,
>> below?
>>
>> Thanks,
>>
>> John
>>
>> Sent from my iPhone
>>
>>
>>> -----Original Message-----
>>> From: ccamp-bounces@= ietf.org [mailto:ccamp-bounce= s@ietf.org] On
>>> Behalf Of Lou Berger
>>> Sent: Thursday, August 16, 2012 2:10 PM
>>> To: Rakesh Gandhi (rgandhi)
>>> Cc: ccamp@ietf.org
>>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvp= te-ext-
>>> associated-lsp-04.txt
>>>
>>> Rakesh,
>>> =A0 =A0 =A0Such major changes (in scope and functionality) to = WG drafts are
>>> usually discussed with the WG prior to the authors/editors jus= t
>>> publishing the changes. =A0But, this is a judgment call by the= document
>>> editors in how, quoting rfc2418, they "ensur[e] that the = contents of
>>> the document accurately reflect the decisions that have been m= ade by
>>> the working group."
>>>
>>> So let's jump into discussing the changes.
>>>
>>> As I see it this draft introduces several major functional cha= nges
>>> that have not been discussed by the WG. =A0Correct me if I get= them
>>> wrong, but I believe they include:
>>> 1) Introduction of a second method for signaling Co-routed LSP= s
>>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms.
>>>
>>> =A0 =A0There are also other changes, but I'll defer discus= sing them
>>> =A0 =A0until the discussion on the above is concluded.
>>>
>>> Is this correct?
>>>
>>> Assuming yes, I have questions about both rational and specifi= c
>>> mechanisms. =A0For now let's look at the former, so please= :
>>>
>>> A) Articulate the issues/limitations with using the RFC3473 de= fined
>>> mechanisms for (co-routed) bidirectional LSPs that you'd l= ike to see
>>> addressed.
>>>
>>> B.1) Articulate the FRR/GMPLS-related issue you'd like to = address?
>>>
>>> B.2) Articulate why this issue should be solved in a TP-specif= ic and
>>> not GMPLS generic fashion?
>>>
>>> Thanks,
>>> Lou
>>>
>>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote:
>>>> Hi Lou,
>>>>
>>>> Yes.
>>>>
>>>> Please advise if you think detailed email is required.
>>>> We believe latest draft summarizes the changes well and we= could
>>> start review/discussions from there.
>>>>
>>>> Thanks,
>>>> Rakesh
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: Thursday, August 16, 2012 4:00 PM
>>>> To: Rakesh Gandhi (rgandhi)
>>>> Cc: ccamp@ietf.org; = zhang.fei3@zte.com.cn
>>>> Subject: Re: [CCAMP] I-D Action:
>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt<= br> >>>>
>>>> Rakesh,
>>>> =A0 =A0 Is this the start of the thread that I requested i= n
>>>> http://www.ietf.org/mail-archive/web/c= camp/current/msg13729.html
>>>>
>>>> In particular, is it the response to:
>>>>> I'd like to ask that someone (Rakesh, Fei, etc.) r= eview each of the
>>>>> proposed change and the rational for each change (in o= ne or in
>>>>> separate e-mails). The WG discussion can then really b= egin on the
>>>>> proposed changes. (Which are quite substantial both in= scope and
>>>>> implication.)
>>>>
>>>> Lou
>>>>
>>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote:
>>>>> Hi All,
>>>>>
>>>>> We have uploaded a new version of this draft with foll= owing changes:
>>>>
>>>> 1. =A0Added a section on Signaling of Co-routed LSPs
>>>>
>>>> 2. =A0Added clarification on Signaling of Associated Bidir= ectional
>>>> Protection LSPs
>>>>
>>>> 3. =A0Added a section on Signaling of Auto-tunnel Mesh-gro= up LSPs
>>>>
>>>> 4. =A0 Added clarification on Signaling of Inter-domain As= sociated
>>> Bidirectional LSPs
>>>>
>>>> 5. =A0The Extended ASSOCIATION object format with Associat= ion Type
>>> "Associated Bidirectional LSP". Clarified on how to = populate
>>> different fields in this object.
>>>>
>>>>
>>>>> We believe that some of these changes were necessary t= o avoid the
>>> interoperability issues due to potentially different interpret= ations.
>>>>>
>>>>> Your review comments are welcome.
>>>>>
>>>>> Thanks,
>>>>> Rakesh
>>>>>
>>>>> -----Original Message-----
>>>>> From: ccamp-= bounces@ietf.org [mailto:ccam= p-bounces@ietf.org] On
>>>>> Behalf Of = internet-drafts@ietf.org
>>>>> Sent: Wednesday, August 15, 2012 10:53 AM
>>>>> To: i-d-annou= nce@ietf.org
>>>>> Cc: ccamp@ietf.org
>>>>> Subject: [CCAMP] I-D Action:
>>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.= txt
>>>>>
>>>>>
>>>>> A New Internet-Draft is available from the on-line Int= ernet-Drafts
>>> directories.
>>>>> =A0This draft is a work item of the Common Control and= Measurement
>>> Plane Working Group of the IETF.
>>>>>
>>>>> =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : RSVP-TE Extensions = for Associated Bidirectional
>>> LSPs
>>>>> =A0 =A0Author(s) =A0 =A0 =A0 : Fei Zhang
>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ru= iquan Jing
>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ra= kesh Gandhi
>>>>> =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-ccamp-mpls= -tp-rsvpte-ext-associated-
>>> lsp-04.txt
>>>>> =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 17
>>>>> =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-08-15
>>>>>
>>>>> Abstract:
>>>>> =A0 =A0The MPLS Transport Profile (MPLS-TP) requiremen= ts document
>>> [RFC5654],
>>>>> =A0 =A0describes that MPLS-TP MUST support associated = bidirectional
>>> point-
>>>>> =A0 =A0to-point LSPs.
>>>>>
>>>>> =A0 =A0This document provides a method to bind two uni= directional Label
>>>>> =A0 =A0Switched Paths (LSPs) into an associated bidire= ctional LSP. =A0The
>>>>> =A0 =A0association is achieved by defining the new Ass= ociation Type in
>>> the
>>>>> =A0 =A0Extended ASSOCIATION object.
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/= draft-ietf-ccamp-mpls-tp-rsvpte-
>>> ext-
>>>>> a
>>>>> ssociated-lsp
>>>>>
>>>>> There's also a htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ie= tf-ccamp-mpls-tp-rsvpte-ext-
>>> associ
>>>>> a
>>>>> ted-lsp-04
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte-
>>> ext-
>>>>> a
>>>>> ssociated-lsp-04
>>>>>
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at= :
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp

--bcaec54ee72a6a41c604c77b26e4-- From jdrake@juniper.net Fri Aug 17 13:21:22 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288C521F8440 for ; Fri, 17 Aug 2012 13:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.689 X-Spam-Level: X-Spam-Status: No, score=-5.689 tagged_above=-999 required=5 tests=[AWL=0.909, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciVLeQFqsyMV for ; Fri, 17 Aug 2012 13:21:18 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id DACC121F8437 for ; Fri, 17 Aug 2012 13:21:15 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUC6nuuz8JqI3ViSeBt8iy2nCIZHAKk2A@postini.com; Fri, 17 Aug 2012 13:21:15 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 17 Aug 2012 13:18:44 -0700 From: John E Drake To: Greg Mirsky , Francesco Fondelli Date: Fri, 17 Aug 2012 13:18:43 -0700 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac18rlwA4D2YlfZKRGCBpFI+2JZEwgABuVOA Message-ID: <5E893DB832F57341992548CDBB333163A631A84E31@EMBX01-HQ.jnpr.net> References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A631A84E31EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 20:21:22 -0000 --_000_5E893DB832F57341992548CDBB333163A631A84E31EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, According to RFC 6428 the is one CC/CV/RDI session irregardless of whether = the bi-directional packet LSP is co-routed or associated. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G= reg Mirsky Sent: Friday, August 17, 2012 12:27 PM To: Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi Francesco, "from a data-plane view point b) and c2) are the same thing" I think that given that c) is associated bi-directional LSP that implies in= dependent OAM and protection for each direction, b) and c2) are not the sam= e in the data plane view. E.g., there will be single CC/CV/RDI session for = b) while c2) will have two sessions. And if linear protection requested, b)= will be protected by single bi-directional LSP, but c2) - by two unidirect= ional LSPs. Regards, Greg On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: Hi All, I think I'm lost, please help. Rakesh is talking about "co-routed associated bidirectional LSP"... for the sake of clarity, let me try to categorize LSPs from a control plane view point: a) Point-to-point unidirectional b) Point-to-point co-routed bidirectional c) Point-to-point associated bidirectional c1) fwd and rev LSP follow different paths c2) fwd and rev LSP follow same path d) Point-to-multipoint unidirectional e) Multipoint-to-point unidirectional Is section 3.2.5 (Signaling of Co-routed LSPs) of mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? In my opinion: - b) should be signaled with 3473 - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) Am I missing something? thank you ciao fra PS from a data-plane view point b) and c2) are the same thing. On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: > Hi Lou, > > Thanks for initiating discussions on the changes in the draft. > > Agree with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can alwa= ys submit a new draft just for that. We respect your/WG decision. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 6:08 PM > To: John E Drake > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The chai= rs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I cov= ered in earlier mail, my feeling is to let the discussion take place on the= list (and at the next IETF, if needed) and then have the draft updated to = reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your email, >> below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:cca= mp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes >>> that have not been discussed by the WG. Correct me if I get them >>> wrong, but I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate >>> different fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_5E893DB832F57341992548CDBB333163A631A84E31EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg,

 

<= p class=3DMsoNormal>According to RFC 6428 the is one CC/CV/RDI sessi= on irregardless of whether the bi-directional packet LSP is co-routed or as= sociated.

 

Thanks,

 

John

 <= /span>

Sent from my iPhone=

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces= @ietf.org] On Behalf Of Greg Mirsky
Sent: Friday, August 1= 7, 2012 12:27 PM
To: Francesco Fondelli
Cc: ccamp@ietf.= org
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsv= pte-ext-associated-lsp-04.txt

 

Hi Francesco,
"from a data-plane view point b) and c2) are t= he same thing"
I think that given that c) is associated bi-directio= nal LSP that implies independent OAM and protection for each direction, b) = and c2) are not the same in the data plane view. E.g., there will be single= CC/CV/RDI session for b) while c2) will have two sessions. And if linear p= rotection requested, b) will be protected by single bi-directional LSP, but= c2) - by two unidirectional LSPs.

Regards,
Greg

On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli= <fran= cesco.fondelli@gmail.com> wrote:

= Hi All,

I think I'm lost, please help.

Rakesh is talking abou= t "co-routed associated bidirectional
LSP"... for the sake of = clarity, let me try to categorize
LSPs from a control plane view point:<= br>
  a) Point-to-point unidirectional
  b) Point-to-point = co-routed bidirectional
  c) Point-to-point associated bidirectiona= l
   c1) fwd and rev LSP follow different paths
  &nbs= p;c2) fwd and rev LSP follow same path
  d) Point-to-multipoint uni= directional
  e) Multipoint-to-point unidirectional

Is secti= on 3.2.5 (Signaling of Co-routed LSPs) of
mpls-tp-rsvpte-ext-associated-= lsp about b) or it is about c2)?

In my opinion:

- b) should b= e signaled with 3473
- c) are addressed by this I-D (mpls-tp-rsvpte-ext-= associated-lsp)

Am I missing something?

thank you
ciao
= fra

PS
from a data-plane view point b) and c2) are the same thing= .


On Fri, Aug 17, 2012 at = 12:16 AM, Rakesh Gandhi (rgandhi)
<rgandhi@cisco.com> wrote:
> Hi Lou,
>
> Thanks = for initiating discussions on the changes in the draft.
>
> Agr= ee with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can= always submit a new draft just for that. We respect your/WG decision.
&= gt;
> Thanks,
> Rakesh
>
>
>
> -----Ori= ginal Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Thursday, August 16, 2012 = 6:08 PM
> To: John E Drake
> Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org
> Subject: Re: [CCAMP= ] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
= >
> John,
>         While strictly speak= ing WG drafts should only reflect current WG consensus, and it is the WG dr= aft editor's job to ensure this, in practice authors/editors are given a lo= t of latitude in timing / ordering in introduction to changes.  I pers= onally think this is a practical way of keeping the process moving.  A= lso if the WG disagrees with a change, it can always be backed out.
>=
> So, yes, the WG could do exactly as you say if it comes to it. &nb= sp;(The chairs can even appoint different editor if needed, e.g., to make t= his
> happen.)  While I'm not happy with how this revision came = about, as I covered in earlier mail, my feeling is to let the discussion ta= ke place on the list (and at the next IETF, if needed) and then have the dr= aft updated to reflect the WG discussion/consensus.
>
> Lou
= >
> On 8/16/2012 5:35 PM, John E Drake wrote:
>> Lou,
= >>
>> Since the WG did not agree to this changes, let alone = discuss them,
>> would it be possible to simply rollback these cha= nges and ask the
>> authors to write a draft addressing the topics= you list in your email,
>> below?
>>
>> Thanks,=
>>
>> John
>>
>> Sent from my iPhone>>
>>
>>> -----Original Message-----
>&g= t;> From: ccamp-bounces@ietf.o= rg [mailto:ccamp-bounces@ietf= .org] On
>>> Behalf Of Lou Berger
>>> Sent: Thu= rsday, August 16, 2012 2:10 PM
>>> To: Rakesh Gandhi (rgandhi)<= br>>>> Cc: ccamp@ietf.org>>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsv= pte-ext-
>>> associated-lsp-04.txt
>>>
>>&= gt; Rakesh,
>>>      Such major changes (in scop= e and functionality) to WG drafts are
>>> usually discussed wit= h the WG prior to the authors/editors just
>>> publishing the c= hanges.  But, this is a judgment call by the document
>>> = editors in how, quoting rfc2418, they "ensur[e] that the contents of>>> the document accurately reflect the decisions that have been= made by
>>> the working group."
>>>
>&g= t;> So let's jump into discussing the changes.
>>>
>&g= t;> As I see it this draft introduces several major functional changes>>> that have not been discussed by the WG.  Correct me if = I get them
>>> wrong, but I believe they include:
>>&g= t; 1) Introduction of a second method for signaling Co-routed LSPs
>&= gt;> 2) Support for FRR bypass tunnels for piggybacked on the TP
>= >> bidirectional LSP mechanisms.
>>>
>>> &nbs= p;  There are also other changes, but I'll defer discussing them
&g= t;>>    until the discussion on the above is concluded.
= >>>
>>> Is this correct?
>>>
>>&g= t; Assuming yes, I have questions about both rational and specific
>&= gt;> mechanisms.  For now let's look at the former, so please:
&= gt;>>
>>> A) Articulate the issues/limitations with using= the RFC3473 defined
>>> mechanisms for (co-routed) bidirection= al LSPs that you'd like to see
>>> addressed.
>>>>>> B.1) Articulate the FRR/GMPLS-related issue you'd like to ad= dress?
>>>
>>> B.2) Articulate why this issue shoul= d be solved in a TP-specific and
>>> not GMPLS generic fashion?=
>>>
>>> Thanks,
>>> Lou
>>>= ;
>>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote:
&= gt;>>> Hi Lou,
>>>>
>>>> Yes.
>= ;>>>
>>>> Please advise if you think detailed email= is required.
>>>> We believe latest draft summarizes the ch= anges well and we could
>>> start review/discussions from there= .
>>>>
>>>> Thanks,
>>>> Rakes= h
>>>>
>>>>
>>>> -----Original= Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: Thursda= y, August 16, 2012 4:00 PM
>>>> To: Rakesh Gandhi (rgandhi)<= br>>>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
&g= t;>>> Subject: Re: [CCAMP] I-D Action:
>>>> draft-i= etf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>
&= gt;>>> Rakesh,
>>>>     Is this the start= of the thread that I requested in
>>>> = http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html
>= ;>>>
>>>> In particular, is it the response to:
= >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) revie= w each of the
>>>>> proposed change and the rational for = each change (in one or in
>>>>> separate e-mails). The WG= discussion can then really begin on the
>>>>> proposed c= hanges. (Which are quite substantial both in scope and
>>>>&= gt; implication.)
>>>>
>>>> Lou
>>&g= t;>
>>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wr= ote:
>>>>> Hi All,
>>>>>
>>>= ;>> We have uploaded a new version of this draft with following chang= es:
>>>>
>>>> 1.  Added a section on Sig= naling of Co-routed LSPs
>>>>
>>>> 2.  A= dded clarification on Signaling of Associated Bidirectional
>>>= > Protection LSPs
>>>>
>>>> 3.  Added= a section on Signaling of Auto-tunnel Mesh-group LSPs
>>>><= br>>>>> 4.   Added clarification on Signaling of Inter-dom= ain Associated
>>> Bidirectional LSPs
>>>>
&g= t;>>> 5.  The Extended ASSOCIATION object format with Associa= tion Type
>>> "Associated Bidirectional LSP". Clarifi= ed on how to populate
>>> different fields in this object.
&= gt;>>>
>>>>
>>>>> We believe that= some of these changes were necessary to avoid the
>>> interope= rability issues due to potentially different interpretations.
>>&g= t;>>
>>>>> Your review comments are welcome.
>= ;>>>>
>>>>> Thanks,
>>>>> R= akesh
>>>>>
>>>>> -----Original Message= -----
>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>>>>> Behalf Of internet-drafts@ietf.org
>= >>>> Sent: Wednesday, August 15, 2012 10:53 AM
>>>&= gt;> To: i-d-announce@ietf.org<= /a>
>>>>> Cc: ccamp@iet= f.org
>>>>> Subject: [CCAMP] I-D Action:
>>&= gt;>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
&g= t;>>>>
>>>>>
>>>>> A New In= ternet-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 &n= bsp;         : RSVP-TE Extensions for Associated Bidire= ctional
>>> LSPs
>>>>>    Author(s)=       : Fei Zhang
>>>>>     &nb= sp;                     R= uiquan Jing
>>>>>           &nbs= p;               Rakesh Gandhi
>&g= t;>>>    Filename        : draft-iet= f-ccamp-mpls-tp-rsvpte-ext-associated-
>>> lsp-04.txt
>&g= t;>>>    Pages           : 17>>>>>    Date          =  : 2012-08-15
>>>>>
>>>>> Abstrac= t:
>>>>>    The MPLS Transport Profile (MPLS-TP= ) requirements document
>>> [RFC5654],
>>>>> =    describes that MPLS-TP MUST support associated bidirectional>>> point-
>>>>>    to-point LSPs.>>>>>
>>>>>    This document p= rovides a method to bind two unidirectional Label
>>>>> &= nbsp;  Switched Paths (LSPs) into an associated bidirectional LSP. &nb= sp;The
>>>>>    association is achieved by defi= ning the new Association Type in
>>> the
>>>>>= ;    Extended ASSOCIATION object.
>>>>>
>= >>>>
>>>>> The IETF datatracker status page f= or this draft is:
>>>>> https://data= tracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-
>>> e= xt-
>>>>> a
>>>>> ssociated-lsp
>= >>>>
>>>>> There's also a htmlized version av= ailable at:
>>>>> http://tools.ietf.or= g/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>> associ
&= gt;>>>> a
>>>>> ted-lsp-04
>>>>= ;>
>>>>> A diff from the previous version is available= at:
>>>>> http://www.ietf.org/rfc= diff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte-
>>> ext-
&g= t;>>>> a
>>>>> ssociated-lsp-04
>>&g= t;>>
>>>>>
>>>>> Internet-Drafts = are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/i= nternet-drafts/
>>>>>
>>>>> _______= ________________________________________
>>>>> CCAMP mail= ing list
>>>>> CCAMP@ie= tf.org
>>>>> https://www.ietf.org/mailman/listinfo/cca= mp
>>>>>
>>>>>
>>>>&= gt;
>>>>>
>>>>
>>>>
>= >>>
>>>>
>>> __________________________= _____________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://= www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>=
>>
> _______________________________________________
>= ; CCAMP mailing list
> CCAMP@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/ccamp
__________= _____________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/lis= tinfo/ccamp

&= nbsp;

= --_000_5E893DB832F57341992548CDBB333163A631A84E31EMBX01HQjnprn_-- From gregory.mirsky@ericsson.com Fri Aug 17 13:28:32 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A972321E8055 for ; Fri, 17 Aug 2012 13:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KidUNlbVWR35 for ; Fri, 17 Aug 2012 13:28:30 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id BDC9D21E804B for ; Fri, 17 Aug 2012 13:28:30 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q7HKT3Z2015645; Fri, 17 Aug 2012 15:29:07 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 17 Aug 2012 16:28:12 -0400 From: Gregory Mirsky To: John E Drake , Greg Mirsky , Francesco Fondelli Date: Fri, 17 Aug 2012 16:28:10 -0400 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac18rlwA4D2YlfZKRGCBpFI+2JZEwgABuVOAAAA1SUA= Message-ID: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <5E893DB832F57341992548CDBB333163A631A84E31@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A631A84E31@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF139268CBFA6EUSAACMS0715e_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 20:28:32 -0000 --_000_FE60A4E52763E84B935532D7D9294FF139268CBFA6EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, I think that bi-directional associated p2p LSP, regardless of how many comm= on LSRs forward and reverse directions have, implies use of independent mod= e of RFC 6428, then there will be two sessions to monitor each direction in= dependently. Coordinated mode of RFC 6428, in my understanding, applies to = bidirectional co-routed p2p LSP. Regards, Greg ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of J= ohn E Drake Sent: Friday, August 17, 2012 1:19 PM To: Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, According to RFC 6428 the is one CC/CV/RDI session irregardless of whether = the bi-directional packet LSP is co-routed or associated. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G= reg Mirsky Sent: Friday, August 17, 2012 12:27 PM To: Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi Francesco, "from a data-plane view point b) and c2) are the same thing" I think that given that c) is associated bi-directional LSP that implies in= dependent OAM and protection for each direction, b) and c2) are not the sam= e in the data plane view. E.g., there will be single CC/CV/RDI session for = b) while c2) will have two sessions. And if linear protection requested, b)= will be protected by single bi-directional LSP, but c2) - by two unidirect= ional LSPs. Regards, Greg On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: Hi All, I think I'm lost, please help. Rakesh is talking about "co-routed associated bidirectional LSP"... for the sake of clarity, let me try to categorize LSPs from a control plane view point: a) Point-to-point unidirectional b) Point-to-point co-routed bidirectional c) Point-to-point associated bidirectional c1) fwd and rev LSP follow different paths c2) fwd and rev LSP follow same path d) Point-to-multipoint unidirectional e) Multipoint-to-point unidirectional Is section 3.2.5 (Signaling of Co-routed LSPs) of mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? In my opinion: - b) should be signaled with 3473 - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) Am I missing something? thank you ciao fra PS from a data-plane view point b) and c2) are the same thing. On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: > Hi Lou, > > Thanks for initiating discussions on the changes in the draft. > > Agree with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can alwa= ys submit a new draft just for that. We respect your/WG decision. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 6:08 PM > To: John E Drake > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The chai= rs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I cov= ered in earlier mail, my feeling is to let the discussion take place on the= list (and at the next IETF, if needed) and then have the draft updated to = reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your email, >> below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:cca= mp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes >>> that have not been discussed by the WG. Correct me if I get them >>> wrong, but I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate >>> different fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_FE60A4E52763E84B935532D7D9294FF139268CBFA6EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi John,
I think that bi-directional associated p2p LS= P,=20 regardless of how many common LSRs forward and reverse directions=20 have, implies use of independent mode of RFC 6428, then there will be = two=20 sessions to monitor each direction independently. Coordinated mode of RFC 6= 428,=20 in my understanding, applies to bidirectional co-routed p2p=20 LSP.
 
  &n= bsp; Regards,
        Greg

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of John E Drake
Sent= :=20 Friday, August 17, 2012 1:19 PM
To: Greg Mirsky; Francesco=20 Fondelli
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] I-D Ac= tion:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Greg,

 

According=20 to RFC 6428 the is one CC/CV/RDI session irregardless of whether the=20 bi-directional packet LSP is co-routed or associated.

 

Thanks,

 

John

 

Sent=20 from my iPhone

 

From:<= /B>=20 ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = Greg=20 Mirsky
Sent: Friday, August 17, 2012 12:27 PM
To: Franc= esco=20 Fondelli
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] I-D Ac= tion:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

Hi Francesco,
"from a= =20 data-plane view point b) and c2) are the same thing"
I think that given = that=20 c) is associated bi-directional LSP that implies independent OAM and protec= tion=20 for each direction, b) and c2) are not the same in the data plane view. E.g= .,=20 there will be single CC/CV/RDI session for b) while c2) will have two sessi= ons.=20 And if linear protection requested, b) will be protected by single=20 bi-directional LSP, but c2) - by two unidirectional=20 LSPs.

Regards,
Greg

On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli &l= t;francesco.fondelli@gmail.com> wrote:

Hi All,

I think I'm lost, please help.

R= akesh=20 is talking about "co-routed associated bidirectional
LSP"... for the sak= e of=20 clarity, let me try to categorize
LSPs from a control plane view=20 point:

  a) Point-to-point unidirectional
  b)=20 Point-to-point co-routed bidirectional
  c) Point-to-point associat= ed=20 bidirectional
   c1) fwd and rev LSP follow different=20 paths
   c2) fwd and rev LSP follow same path
  d)=20 Point-to-multipoint unidirectional
  e) Multipoint-to-point=20 unidirectional

Is section 3.2.5 (Signaling of Co-routed LSPs)=20 of
mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)?
In=20 my opinion:

- b) should be signaled with 3473
- c) are addressed = by=20 this I-D (mpls-tp-rsvpte-ext-associated-lsp)

Am I missing=20 something?

thank you
ciao
fra

PS
from a data-plane v= iew=20 point b) and c2) are the same thing.


On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi=20 (rgandhi)
<rgandhi@cisco.com= >=20 wrote:
> Hi Lou,
>
> Thanks for initiating discussions on= the=20 changes in the draft.
>
> Agree with you here, if we/WG do not = agree=20 on the "co-routed associated bidirectional LSP" part, we are ok to remove i= t=20 from this draft and can always submit a new draft just for that. We respect= =20 your/WG decision.
>
> Thanks,
>=20 Rakesh
>
>
>
> -----Original Message-----
> F= rom:=20 Lou Berger [mailto:lberger@labn.net]
> Sent: Thursd= ay,=20 August 16, 2012 6:08 PM
> To: John E Drake
> Cc: Rakesh Gandhi= =20 (rgandhi); ccamp@ietf.org
> Sub= ject:=20 Re: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>
>=20 John,
>         While strictly speaking WG drafts= =20 should only reflect current WG consensus, and it is the WG draft editor's j= ob to=20 ensure this, in practice authors/editors are given a lot of latitude in tim= ing /=20 ordering in introduction to changes.  I personally think this is a=20 practical way of keeping the process moving.  Also if the WG disagrees= with=20 a change, it can always be backed out.
>
> So, yes, the WG coul= d do=20 exactly as you say if it comes to it.  (The chairs can even appoint=20 different editor if needed, e.g., to make this
> happen.)  While= I'm=20 not happy with how this revision came about, as I covered in earlier mail, = my=20 feeling is to let the discussion take place on the list (and at the next IE= TF,=20 if needed) and then have the draft updated to reflect the WG=20 discussion/consensus.
>
> Lou
>
> On 8/16/2012 5:35= PM,=20 John E Drake wrote:
>> Lou,
>>
>> Since the WG d= id=20 not agree to this changes, let alone discuss them,
>> would it be= =20 possible to simply rollback these changes and ask the
>> authors t= o=20 write a draft addressing the topics you list in your email,
>>=20 below?
>>
>> Thanks,
>>
>>=20 John
>>
>> Sent from my=20 iPhone
>>
>>
>>> -----Original=20 Message-----
>>> From: ccamp-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org]=20 On
>>> Behalf Of Lou Berger
>>> Sent: Thursday, Aug= ust=20 16, 2012 2:10 PM
>>> To: Rakesh Gandhi (rgandhi)
>>>= ; Cc:=20 ccamp@ietf.org
>>> Subjec= t: Re:=20 [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>>=20 associated-lsp-04.txt
>>>
>>> Rakesh,
>>&g= t;=20      Such major changes (in scope and functionality) to WG d= rafts=20 are
>>> usually discussed with the WG prior to the authors/edit= ors=20 just
>>> publishing the changes.  But, this is a judgment = call=20 by the document
>>> editors in how, quoting rfc2418, they "ensu= r[e]=20 that the contents of
>>> the document accurately reflect the=20 decisions that have been made by
>>> the working=20 group."
>>>
>>> So let's jump into discussing the=20 changes.
>>>
>>> As I see it this draft introduces= =20 several major functional changes
>>> that have not been discuss= ed by=20 the WG.  Correct me if I get them
>>> wrong, but I believe= they=20 include:
>>> 1) Introduction of a second method for signaling=20 Co-routed LSPs
>>> 2) Support for FRR bypass tunnels for piggyb= acked=20 on the TP
>>> bidirectional LSP=20 mechanisms.
>>>
>>>    There are also oth= er=20 changes, but I'll defer discussing them
>>>    until = the=20 discussion on the above is concluded.
>>>
>>> Is th= is=20 correct?
>>>
>>> Assuming yes, I have questions abo= ut=20 both rational and specific
>>> mechanisms.  For now let's = look=20 at the former, so please:
>>>
>>> A) Articulate the= =20 issues/limitations with using the RFC3473 defined
>>> mechanism= s for=20 (co-routed) bidirectional LSPs that you'd like to see
>>>=20 addressed.
>>>
>>> B.1) Articulate the FRR/GMPLS-re= lated=20 issue you'd like to address?
>>>
>>> B.2) Articulat= e why=20 this issue should be solved in a TP-specific and
>>> not GMPLS= =20 generic fashion?
>>>
>>> Thanks,
>>>=20 Lou
>>>
>>> On 8/16/2012 4:26 PM, Rakesh Gandhi=20 (rgandhi) wrote:
>>>> Hi=20 Lou,
>>>>
>>>>=20 Yes.
>>>>
>>>> Please advise if you think det= ailed=20 email is required.
>>>> We believe latest draft summarizes t= he=20 changes well and we could
>>> start review/discussions from=20 there.
>>>>
>>>> Thanks,
>>>>= =20 Rakesh
>>>>
>>>>
>>>> -----Ori= ginal=20 Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> = Sent:=20 Thursday, August 16, 2012 4:00 PM
>>>> To: Rakesh Gandhi=20 (rgandhi)
>>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>>= >>=20 Subject: Re: [CCAMP] I-D Action:
>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;
>>>>=20 Rakesh,
>>>>     Is this the start of the thread t= hat I=20 requested in
>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729= .html
>>>>
>>>>=20 In particular, is it the response to:
>>>>> I'd like to a= sk=20 that someone (Rakesh, Fei, etc.) review each of the
>>>>>= =20 proposed change and the rational for each change (in one or=20 in
>>>>> separate e-mails). The WG discussion can then re= ally=20 begin on the
>>>>> proposed changes. (Which are quite=20 substantial both in scope and
>>>>>=20 implication.)
>>>>
>>>>=20 Lou
>>>>
>>>> On 8/16/2012 3:19 PM, Rakesh Ga= ndhi=20 (rgandhi) wrote:
>>>>> Hi=20 All,
>>>>>
>>>>> We have uploaded a new= =20 version of this draft with following=20 changes:
>>>>
>>>> 1.  Added a section o= n=20 Signaling of Co-routed LSPs
>>>>
>>>> 2.=20  Added clarification on Signaling of Associated=20 Bidirectional
>>>> Protection=20 LSPs
>>>>
>>>> 3.  Added a section on=20 Signaling of Auto-tunnel Mesh-group LSPs
>>>>
>>>= ;>=20 4.   Added clarification on Signaling of Inter-domain=20 Associated
>>> Bidirectional=20 LSPs
>>>>
>>>> 5.  The Extended ASSOCIAT= ION=20 object format with Association Type
>>> "Associated Bidirection= al=20 LSP". Clarified on how to populate
>>> different fields in this= =20 object.
>>>>
>>>>
>>>>> We= =20 believe that some of these changes were necessary to avoid the
>>&= gt;=20 interoperability issues due to potentially different=20 interpretations.
>>>>>
>>>>> Your revie= w=20 comments are welcome.
>>>>>
>>>>>=20 Thanks,
>>>>>=20 Rakesh
>>>>>
>>>>> -----Original=20 Message-----
>>>>> From: ccamp-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org]=20 On
>>>>> Behalf Of internet-drafts@ietf.org
&g= t;>>>>=20 Sent: Wednesday, August 15, 2012 10:53 AM
>>>>> To: i-d-announce@ietf.org
>>= >>>=20 Cc: ccamp@ietf.org
>>>>= ;>=20 Subject: [CCAMP] I-D Action:
>>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;>
>>>>>
>>>>>=20 A New Internet-Draft is available from the on-line=20 Internet-Drafts
>>> directories.
>>>>>  = This=20 draft is a work item of the Common Control and Measurement
>>> = Plane=20 Working Group of the IETF.
>>>>>
>>>>>= =20    Title           : RSVP-TE Extensions = for=20 Associated Bidirectional
>>> LSPs
>>>>>  = ;=20  Author(s)       : Fei Zhang
>>>>> &n= bsp;=20                      = ;=20   Ruiquan Jing
>>>>>         &nb= sp;=20                 Rakesh=20 Gandhi
>>>>>    Filename      =20  : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-
>>>=20 lsp-04.txt
>>>>>    Pages      = =20     : 17
>>>>>    Date    = =20        :=20 2012-08-15
>>>>>
>>>>>=20 Abstract:
>>>>>    The MPLS Transport Profile=20 (MPLS-TP) requirements document
>>>=20 [RFC5654],
>>>>>    describes that MPLS-TP MUST= =20 support associated bidirectional
>>> point-
>>>>= >=20    to-point LSPs.
>>>>>
>>>>>= =20    This document provides a method to bind two unidirectional=20 Label
>>>>>    Switched Paths (LSPs) into an=20 associated bidirectional LSP.  The
>>>>>  =20  association is achieved by defining the new Association Type=20 in
>>> the
>>>>>    Extended ASSOCI= ATION=20 object.
>>>>>
>>>>>
>>>>= >=20 The IETF datatracker status page for this draft is:
>>>>>= https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-r= svpte-
>>>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp
>>>>>
>>>>> There's also = a=20 htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-= ext-
>>>=20 associ
>>>>> a
>>>>>=20 ted-lsp-04
>>>>>
>>>>> A diff from the= =20 previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp= -rsvpte-
>>>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp-04
>>>>>
>>>>>
>>= ;>>>=20 Internet-Drafts are also available by anonymous FTP at:
>>>>= >=20 ftp://ftp.ietf.org/internet-drafts/
>>>>= >
>>>>>=20 _______________________________________________
>>>>> CCA= MP=20 mailing list
>>>>> CCAMP@ietf.org
>>>>> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ccamp"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ccamp
>>= >>>
>>>>>
>>>>>
>>>= ;>>
>>>>
>>>>
>>>>
&g= t;>>>
>>>=20 _______________________________________________
>>> CCAMP maili= ng=20 list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>=
>>
>>
>>
>=20 _______________________________________________
> CCAMP mailing=20 list
> CCAMP@ietf.org
> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ccamp"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ccamp
________= _______________________________________
CCAMP=20 mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp<= /P>

 

--_000_FE60A4E52763E84B935532D7D9294FF139268CBFA6EUSAACMS0715e_-- From jdrake@juniper.net Fri Aug 17 13:53:24 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A2211E80DC for ; Fri, 17 Aug 2012 13:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.704 X-Spam-Level: X-Spam-Status: No, score=-5.704 tagged_above=-999 required=5 tests=[AWL=0.894, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXA-lnuyFRoD for ; Fri, 17 Aug 2012 13:53:19 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id B656B11E80D1 for ; Fri, 17 Aug 2012 13:53:12 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUC6vMns+OFal/KFku7GMxvVmgxm2LQa7@postini.com; Fri, 17 Aug 2012 13:53:12 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 17 Aug 2012 13:49:35 -0700 From: John E Drake To: Gregory Mirsky , Greg Mirsky , Francesco Fondelli Date: Fri, 17 Aug 2012 13:49:34 -0700 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac18rlwA4D2YlfZKRGCBpFI+2JZEwgABuVOAAAA1SUAAAN63wA== Message-ID: <5E893DB832F57341992548CDBB333163A631A84E97@EMBX01-HQ.jnpr.net> References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <5E893DB832F57341992548CDBB333163A631A84E31@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A631A84E97EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 20:53:24 -0000 --_000_5E893DB832F57341992548CDBB333163A631A84E97EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, That certainly wasn't the intent. With a bidirectional LSP of either type = you have one forward and one return path and BFD does not care whether they= are congruent. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 1:28 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, I think that bi-directional associated p2p LSP, regardless of how many comm= on LSRs forward and reverse directions have, implies use of independent mod= e of RFC 6428, then there will be two sessions to monitor each direction in= dependently. Coordinated mode of RFC 6428, in my understanding, applies to = bidirectional co-routed p2p LSP. Regards, Greg ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of John E Drake Sent: Friday, August 17, 2012 1:19 PM To: Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, According to RFC 6428 the is one CC/CV/RDI session irregardless of whether = the bi-directional packet LSP is co-routed or associated. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky Sent: Friday, August 17, 2012 12:27 PM To: Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi Francesco, "from a data-plane view point b) and c2) are the same thing" I think that given that c) is associated bi-directional LSP that implies in= dependent OAM and protection for each direction, b) and c2) are not the sam= e in the data plane view. E.g., there will be single CC/CV/RDI session for = b) while c2) will have two sessions. And if linear protection requested, b)= will be protected by single bi-directional LSP, but c2) - by two unidirect= ional LSPs. Regards, Greg On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: Hi All, I think I'm lost, please help. Rakesh is talking about "co-routed associated bidirectional LSP"... for the sake of clarity, let me try to categorize LSPs from a control plane view point: a) Point-to-point unidirectional b) Point-to-point co-routed bidirectional c) Point-to-point associated bidirectional c1) fwd and rev LSP follow different paths c2) fwd and rev LSP follow same path d) Point-to-multipoint unidirectional e) Multipoint-to-point unidirectional Is section 3.2.5 (Signaling of Co-routed LSPs) of mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? In my opinion: - b) should be signaled with 3473 - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) Am I missing something? thank you ciao fra PS from a data-plane view point b) and c2) are the same thing. On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: > Hi Lou, > > Thanks for initiating discussions on the changes in the draft. > > Agree with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can alwa= ys submit a new draft just for that. We respect your/WG decision. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 6:08 PM > To: John E Drake > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The chai= rs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I cov= ered in earlier mail, my feeling is to let the discussion take place on the= list (and at the next IETF, if needed) and then have the draft updated to = reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your email, >> below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:cca= mp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes >>> that have not been discussed by the WG. Correct me if I get them >>> wrong, but I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate >>> different fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_5E893DB832F57341992548CDBB333163A631A84E97EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg,

 

<= p class=3DMsoNormal>That certainly wasn’t the intent.  Wi= th a bidirectional LSP of either type you have one forward and one return p= ath and BFD does not care whether they are congruent.

=

 

Thanks,

&nbs= p;

John

 

Sent from my iPhone

 

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent:= Friday, August 17, 2012 1:28 PM
To: John E Drake; Greg Mirsk= y; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [= CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.tx= t

 

Hi John,

I think that bi-directional associated p2p LSP, regardless of how m= any common LSRs forward and reverse directions have, implies use of in= dependent mode of RFC 6428, then there will be two sessions to monitor each= direction independently. Coordinated mode of RFC 6428, in my understanding= , applies to bidirectional co-routed p2p LSP.

 

    <= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:blue'= >Regards,

    = ;    Greg

&= nbsp;

From: ccamp-bounces@ietf.org [ma= ilto:ccamp-bounces@ietf.org] On Behalf Of John E Drake
Sen= t: Friday, August 17, 2012 1:19 PM
To: Greg Mirsky; Francesco= Fondelli
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpt= e-ext-associated-lsp-04.txt

Greg,

 <= /span>

According to RFC 6428 the is one CC/C= V/RDI session irregardless of whether the bi-directional packet LSP is co-r= outed or associated.

 

Thanks,

 

John

 

Sent from my iPhone

 

<= div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4= .0pt'>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg MirskySent: Friday, August 17, 2012 12:27 PM
To: Francesco Fon= delli
Cc: ccamp@ietf.orgSubject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ex= t-associated-lsp-04.txt

 

Hi Francesco,
"from a data-plane view point b) and c2) are the sam= e thing"
I think that given that c) is associated bi-directional LS= P that implies independent OAM and protection for each direction, b) and c2= ) are not the same in the data plane view. E.g., there will be single CC/CV= /RDI session for b) while c2) will have two sessions. And if linear protect= ion requested, b) will be protected by single bi-directional LSP, but c2) -= by two unidirectional LSPs.

Regards,
Greg

On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli <<= a href=3D"mailto:francesco.fondelli@gmail.com" target=3D"_blank">francesco.= fondelli@gmail.com> wrote:

Hi All= ,

I think I'm lost, please help.

Rakesh is talking about &quo= t;co-routed associated bidirectional
LSP"... for the sake of clarit= y, let me try to categorize
LSPs from a control plane view point:
  a) Point-to-point unidirectional
  b) Point-to-point co-rou= ted bidirectional
  c) Point-to-point associated bidirectional
&= nbsp;  c1) fwd and rev LSP follow different paths
   c2) = fwd and rev LSP follow same path
  d) Point-to-multipoint unidirect= ional
  e) Multipoint-to-point unidirectional

Is section 3.2= .5 (Signaling of Co-routed LSPs) of
mpls-tp-rsvpte-ext-associated-lsp ab= out b) or it is about c2)?

In my opinion:

- b) should be sign= aled with 3473
- c) are addressed by this I-D (mpls-tp-rsvpte-ext-associ= ated-lsp)

Am I missing something?

thank you
ciao
fra
PS
from a data-plane view point b) and c2) are the same thing.=


On Fri, Aug 17, 2012 at 12:16 = AM, Rakesh Gandhi (rgandhi)
<rga= ndhi@cisco.com> wrote:
> Hi Lou,
>
> Thanks for in= itiating discussions on the changes in the draft.
>
> Agree wit= h you here, if we/WG do not agree on the "co-routed associated bidirec= tional LSP" part, we are ok to remove it from this draft and can alway= s submit a new draft just for that. We respect your/WG decision.
>> Thanks,
> Rakesh
>
>
>
> -----Original = Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Thursday, August 16, 2012 6:08 P= M
> To: John E Drake
> Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org
> Subject: Re: [CCAMP] I-D = Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>> John,
>         While strictly speaking WG= drafts should only reflect current WG consensus, and it is the WG draft ed= itor's job to ensure this, in practice authors/editors are given a lot of l= atitude in timing / ordering in introduction to changes.  I personally= think this is a practical way of keeping the process moving.  Also if= the WG disagrees with a change, it can always be backed out.
>
&g= t; So, yes, the WG could do exactly as you say if it comes to it.  (Th= e chairs can even appoint different editor if needed, e.g., to make this> happen.)  While I'm not happy with how this revision came about,= as I covered in earlier mail, my feeling is to let the discussion take pla= ce on the list (and at the next IETF, if needed) and then have the draft up= dated to reflect the WG discussion/consensus.
>
> Lou
>> On 8/16/2012 5:35 PM, John E Drake wrote:
>> Lou,
>&g= t;
>> Since the WG did not agree to this changes, let alone discus= s them,
>> would it be possible to simply rollback these changes a= nd ask the
>> authors to write a draft addressing the topics you l= ist in your email,
>> below?
>>
>> Thanks,
&g= t;>
>> John
>>
>> Sent from my iPhone
>= >
>>
>>> -----Original Message-----
>>>= From: ccamp-bounces@ietf.org= [mailto:ccamp-bounces@ietf.org] On
>>> Behalf Of Lou Berger
>>> Sent: Thursday,= August 16, 2012 2:10 PM
>>> To: Rakesh Gandhi (rgandhi)
>= ;>> Cc: ccamp@ietf.org
>&= gt;> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ex= t-
>>> associated-lsp-04.txt
>>>
>>> Ra= kesh,
>>>      Such major changes (in scope and = functionality) to WG drafts are
>>> usually discussed with the = WG prior to the authors/editors just
>>> publishing the changes= .  But, this is a judgment call by the document
>>> editor= s in how, quoting rfc2418, they "ensur[e] that the contents of
>= >> the document accurately reflect the decisions that have been made = by
>>> the working group."
>>>
>>>= So let's jump into discussing the changes.
>>>
>>>= As I see it this draft introduces several major functional changes
>= >> that have not been discussed by the WG.  Correct me if I get = them
>>> wrong, but I believe they include:
>>> 1) = Introduction of a second method for signaling Co-routed LSPs
>>>= ; 2) Support for FRR bypass tunnels for piggybacked on the TP
>>&g= t; bidirectional LSP mechanisms.
>>>
>>>   &nb= sp;There are also other changes, but I'll defer discussing them
>>= >    until the discussion on the above is concluded.
>&g= t;>
>>> Is this correct?
>>>
>>> Ass= uming yes, I have questions about both rational and specific
>>>= ; mechanisms.  For now let's look at the former, so please:
>>= ;>
>>> A) Articulate the issues/limitations with using the R= FC3473 defined
>>> mechanisms for (co-routed) bidirectional LSP= s that you'd like to see
>>> addressed.
>>>
>= >> B.1) Articulate the FRR/GMPLS-related issue you'd like to address?=
>>>
>>> B.2) Articulate why this issue should be s= olved in a TP-specific and
>>> not GMPLS generic fashion?
&g= t;>>
>>> Thanks,
>>> Lou
>>>
&= gt;>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote:
>>= ;>> Hi Lou,
>>>>
>>>> Yes.
>>&= gt;>
>>>> Please advise if you think detailed email is re= quired.
>>>> We believe latest draft summarizes the changes = well and we could
>>> start review/discussions from there.
&= gt;>>>
>>>> Thanks,
>>>> Rakesh
&= gt;>>>
>>>>
>>>> -----Original Messa= ge-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: Thursday, Aug= ust 16, 2012 4:00 PM
>>>> To: Rakesh Gandhi (rgandhi)
>= ;>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>>= >> Subject: Re: [CCAMP] I-D Action:
>>>> draft-ietf-cc= amp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>
>>= ;>> Rakesh,
>>>>     Is this the start of th= e thread that I requested in
>>>> http:/= /www.ietf.org/mail-archive/web/ccamp/current/msg13729.html
>>&= gt;>
>>>> In particular, is it the response to:
>&g= t;>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each= of the
>>>>> proposed change and the rational for each c= hange (in one or in
>>>>> separate e-mails). The WG discu= ssion can then really begin on the
>>>>> proposed changes= . (Which are quite substantial both in scope and
>>>>> im= plication.)
>>>>
>>>> Lou
>>>>=
>>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote:>>>>> Hi All,
>>>>>
>>>>&= gt; We have uploaded a new version of this draft with following changes:>>>>
>>>> 1.  Added a section on Signaling= of Co-routed LSPs
>>>>
>>>> 2.  Added c= larification on Signaling of Associated Bidirectional
>>>> P= rotection LSPs
>>>>
>>>> 3.  Added a sec= tion on Signaling of Auto-tunnel Mesh-group LSPs
>>>>
>= ;>>> 4.   Added clarification on Signaling of Inter-domain As= sociated
>>> Bidirectional LSPs
>>>>
>>= >> 5.  The Extended ASSOCIATION object format with Association T= ype
>>> "Associated Bidirectional LSP". Clarified on = how to populate
>>> different fields in this object.
>>= ;>>
>>>>
>>>>> We believe that some = of these changes were necessary to avoid the
>>> interoperabili= ty issues due to potentially different interpretations.
>>>>= >
>>>>> Your review comments are welcome.
>>&= gt;>>
>>>>> Thanks,
>>>>> Rakesh<= br>>>>>>
>>>>> -----Original Message-----<= br>>>>>> From: cca= mp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On
>>>>> Behalf Of internet-drafts@ietf.org
>>&g= t;>> Sent: Wednesday, August 15, 2012 10:53 AM
>>>>>= ; To: i-d-announce@ietf.org>>>>> Cc: ccamp@ietf.org<= /a>
>>>>> Subject: [CCAMP] I-D Action:
>>>>= ;> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>= >>>
>>>>>
>>>>> A New Internet= -Draft is available from the on-line Internet-Drafts
>>> direct= ories.
>>>>>  This draft is a work item of the Commo= n Control and Measurement
>>> Plane Working Group of the IETF.<= br>>>>>>
>>>>>    Title   &= nbsp;       : RSVP-TE Extensions for Associated Bidirectiona= l
>>> LSPs
>>>>>    Author(s)  = ;     : Fei Zhang
>>>>>       &n= bsp;                   Ruiquan= Jing
>>>>>             &nb= sp;             Rakesh Gandhi
>>>= >>    Filename        : draft-ietf-ccam= p-mpls-tp-rsvpte-ext-associated-
>>> lsp-04.txt
>>>= >>    Pages           : 17
>= >>>>    Date            = ;: 2012-08-15
>>>>>
>>>>> Abstract:
= >>>>>    The MPLS Transport Profile (MPLS-TP) requ= irements document
>>> [RFC5654],
>>>>>  =  describes that MPLS-TP MUST support associated bidirectional
>= >> point-
>>>>>    to-point LSPs.
>= >>>>
>>>>>    This document provide= s a method to bind two unidirectional Label
>>>>>   =  Switched Paths (LSPs) into an associated bidirectional LSP.  The=
>>>>>    association is achieved by defining t= he new Association Type in
>>> the
>>>>> &nbs= p;  Extended ASSOCIATION object.
>>>>>
>>&g= t;>>
>>>>> The IETF datatracker status page for thi= s draft is:
>>>>> https://datatracke= r.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-
>>> ext->>>>> a
>>>>> ssociated-lsp
>>&g= t;>>
>>>>> There's also a htmlized version availabl= e at:
>>>>> http://tools.ietf.org/html= /draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>> associ
>>= ;>>> a
>>>>> ted-lsp-04
>>>>><= br>>>>>> A diff from the previous version is available at:>>>>> http://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte-
>>> ext-
>>= >>> a
>>>>> ssociated-lsp-04
>>>>= >
>>>>>
>>>>> Internet-Drafts are al= so available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/interne= t-drafts/
>>>>>
>>>>> _____________= __________________________________
>>>>> CCAMP mailing li= st
>>>>> CCAMP@ietf.org=
>>>>> https://www.ietf.org/mailman/listinfo/ccamp=
>>>>>
>>>>>
>>>>>>>>>>
>>>>
>>>>
>>&g= t;>
>>>>
>>> ________________________________= _______________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ie= tf.org/mailman/listinfo/ccamp
>>
>>
>>
&g= t;>
> _______________________________________________
> CCAM= P mailing list
> CCAMP@ietf.org=
> https://www.ietf.org/mailman/listinfo/ccamp
________________= _______________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/= ccamp

 <= /o:p>

= --_000_5E893DB832F57341992548CDBB333163A631A84E97EMBX01HQjnprn_-- From gregory.mirsky@ericsson.com Fri Aug 17 14:12:10 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F61911E80D1 for ; Fri, 17 Aug 2012 14:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip9A7VqIO9z5 for ; Fri, 17 Aug 2012 14:12:06 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2C26221E804C for ; Fri, 17 Aug 2012 14:12:06 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q7HLBaSx015982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Aug 2012 16:12:04 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 17 Aug 2012 17:11:35 -0400 From: Gregory Mirsky To: John E Drake , Greg Mirsky , Francesco Fondelli Date: Fri, 17 Aug 2012 17:11:34 -0400 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac18rlwA4D2YlfZKRGCBpFI+2JZEwgABuVOAAAA1SUAAAN63wAAAvlnA Message-ID: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <5E893DB832F57341992548CDBB333163A631A84E31@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84E97@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A631A84E97@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF139268CC000EUSAACMS0715e_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 21:12:10 -0000 --_000_FE60A4E52763E84B935532D7D9294FF139268CC000EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, in independent mode CC/CV control messages been sent only in one direction.= Thus there are two CC/CV sessions - one for each independently monitored d= irection. That, AFAIK, was intentional. Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 1:50 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, That certainly wasn't the intent. With a bidirectional LSP of either type = you have one forward and one return path and BFD does not care whether they= are congruent. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 1:28 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, I think that bi-directional associated p2p LSP, regardless of how many comm= on LSRs forward and reverse directions have, implies use of independent mod= e of RFC 6428, then there will be two sessions to monitor each direction in= dependently. Coordinated mode of RFC 6428, in my understanding, applies to = bidirectional co-routed p2p LSP. Regards, Greg ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of John E Drake Sent: Friday, August 17, 2012 1:19 PM To: Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, According to RFC 6428 the is one CC/CV/RDI session irregardless of whether = the bi-directional packet LSP is co-routed or associated. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky Sent: Friday, August 17, 2012 12:27 PM To: Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi Francesco, "from a data-plane view point b) and c2) are the same thing" I think that given that c) is associated bi-directional LSP that implies in= dependent OAM and protection for each direction, b) and c2) are not the sam= e in the data plane view. E.g., there will be single CC/CV/RDI session for = b) while c2) will have two sessions. And if linear protection requested, b)= will be protected by single bi-directional LSP, but c2) - by two unidirect= ional LSPs. Regards, Greg On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: Hi All, I think I'm lost, please help. Rakesh is talking about "co-routed associated bidirectional LSP"... for the sake of clarity, let me try to categorize LSPs from a control plane view point: a) Point-to-point unidirectional b) Point-to-point co-routed bidirectional c) Point-to-point associated bidirectional c1) fwd and rev LSP follow different paths c2) fwd and rev LSP follow same path d) Point-to-multipoint unidirectional e) Multipoint-to-point unidirectional Is section 3.2.5 (Signaling of Co-routed LSPs) of mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? In my opinion: - b) should be signaled with 3473 - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) Am I missing something? thank you ciao fra PS from a data-plane view point b) and c2) are the same thing. On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: > Hi Lou, > > Thanks for initiating discussions on the changes in the draft. > > Agree with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can alwa= ys submit a new draft just for that. We respect your/WG decision. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 6:08 PM > To: John E Drake > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The chai= rs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I cov= ered in earlier mail, my feeling is to let the discussion take place on the= list (and at the next IETF, if needed) and then have the draft updated to = reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your email, >> below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:cca= mp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes >>> that have not been discussed by the WG. Correct me if I get them >>> wrong, but I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate >>> different fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_FE60A4E52763E84B935532D7D9294FF139268CC000EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi John,
in independent mode CC/CV control messages been se= nt only=20 in one direction. Thus there are two CC/CV sessions - one for each independ= ently=20 monitored direction. That, AFAIK, was intentional.
 
  &n= bsp; Regards,
        Greg

From: John E Drake [mailto:jdrake@junip= er.net]=20
Sent: Friday, August 17, 2012 1:50 PM
To: Gregory Mirs= ky;=20 Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject:= =20 RE: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Greg,

 

That=20 certainly wasn’t the intent.  With a bidirectional LSP of either= type you=20 have one forward and one return path and BFD does not care whether they are= =20 congruent.

 

Thanks,

 

John

 

Sent=20 from my iPhone

 

From:<= /B> Gregory Mirs= ky=20 [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, August 17, 20= 12=20 1:28 PM
To: John E Drake; Greg Mirsky; Francesco=20 Fondelli
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D Ac= tion:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

H= i=20 John,

I= think=20 that bi-directional associated p2p LSP, regardless of how many common = LSRs=20 forward and reverse directions have, implies use of independent mode o= f RFC=20 6428, then there will be two sessions to monitor each direction independent= ly.=20 Coordinated mode of RFC 6428, in my understanding, applies to bidirectional= =20 co-routed p2p LSP.

 

    R= egards,

        G= reg

 

From:<= /B> ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <= B>On=20 Behalf Of John E Drake
Sent: Friday, August 17, 2012 1:19=20 PM
To: Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: Re: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

Greg,

 

According=20 to RFC 6428 the is one CC/CV/RDI session irregardless of whether the=20 bi-directional packet LSP is co-routed or associated.

 

Thanks,

 

John

 

Sent=20 from my iPhone

 

From:<= /B> ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <= B>On=20 Behalf Of Greg Mirsky
Sent: Friday, August 17, 2012 12:27=20 PM
To: Francesco Fondelli
Cc: ccamp@ietf.org
Subject: Re: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

Hi Francesco,
"from a= =20 data-plane view point b) and c2) are the same thing"
I think that given = that=20 c) is associated bi-directional LSP that implies independent OAM and protec= tion=20 for each direction, b) and c2) are not the same in the data plane view. E.g= .,=20 there will be single CC/CV/RDI session for b) while c2) will have two sessi= ons.=20 And if linear protection requested, b) will be protected by single=20 bi-directional LSP, but c2) - by two unidirectional=20 LSPs.

Regards,
Greg

On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli &l= t;francesco.fondelli@gmail.com> wrote:

Hi All,

I think I'm lost, please help.

R= akesh=20 is talking about "co-routed associated bidirectional
LSP"... for the sak= e of=20 clarity, let me try to categorize
LSPs from a control plane view=20 point:

  a) Point-to-point unidirectional
  b)=20 Point-to-point co-routed bidirectional
  c) Point-to-point associat= ed=20 bidirectional
   c1) fwd and rev LSP follow different=20 paths
   c2) fwd and rev LSP follow same path
  d)=20 Point-to-multipoint unidirectional
  e) Multipoint-to-point=20 unidirectional

Is section 3.2.5 (Signaling of Co-routed LSPs)=20 of
mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)?
In=20 my opinion:

- b) should be signaled with 3473
- c) are addressed = by=20 this I-D (mpls-tp-rsvpte-ext-associated-lsp)

Am I missing=20 something?

thank you
ciao
fra

PS
from a data-plane v= iew=20 point b) and c2) are the same thing.


On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi=20 (rgandhi)
<rgandhi@cisco.com= >=20 wrote:
> Hi Lou,
>
> Thanks for initiating discussions on= the=20 changes in the draft.
>
> Agree with you here, if we/WG do not = agree=20 on the "co-routed associated bidirectional LSP" part, we are ok to remove i= t=20 from this draft and can always submit a new draft just for that. We respect= =20 your/WG decision.
>
> Thanks,
>=20 Rakesh
>
>
>
> -----Original Message-----
> F= rom:=20 Lou Berger [mailto:lberger@labn.net]
> Sent: Thursd= ay,=20 August 16, 2012 6:08 PM
> To: John E Drake
> Cc: Rakesh Gandhi= =20 (rgandhi); ccamp@ietf.org
> Sub= ject:=20 Re: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>
>=20 John,
>         While strictly speaking WG drafts= =20 should only reflect current WG consensus, and it is the WG draft editor's j= ob to=20 ensure this, in practice authors/editors are given a lot of latitude in tim= ing /=20 ordering in introduction to changes.  I personally think this is a=20 practical way of keeping the process moving.  Also if the WG disagrees= with=20 a change, it can always be backed out.
>
> So, yes, the WG coul= d do=20 exactly as you say if it comes to it.  (The chairs can even appoint=20 different editor if needed, e.g., to make this
> happen.)  While= I'm=20 not happy with how this revision came about, as I covered in earlier mail, = my=20 feeling is to let the discussion take place on the list (and at the next IE= TF,=20 if needed) and then have the draft updated to reflect the WG=20 discussion/consensus.
>
> Lou
>
> On 8/16/2012 5:35= PM,=20 John E Drake wrote:
>> Lou,
>>
>> Since the WG d= id=20 not agree to this changes, let alone discuss them,
>> would it be= =20 possible to simply rollback these changes and ask the
>> authors t= o=20 write a draft addressing the topics you list in your email,
>>=20 below?
>>
>> Thanks,
>>
>>=20 John
>>
>> Sent from my=20 iPhone
>>
>>
>>> -----Original=20 Message-----
>>> From: ccamp-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org]=20 On
>>> Behalf Of Lou Berger
>>> Sent: Thursday, Aug= ust=20 16, 2012 2:10 PM
>>> To: Rakesh Gandhi (rgandhi)
>>>= ; Cc:=20 ccamp@ietf.org
>>> Subjec= t: Re:=20 [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>>=20 associated-lsp-04.txt
>>>
>>> Rakesh,
>>&g= t;=20      Such major changes (in scope and functionality) to WG d= rafts=20 are
>>> usually discussed with the WG prior to the authors/edit= ors=20 just
>>> publishing the changes.  But, this is a judgment = call=20 by the document
>>> editors in how, quoting rfc2418, they "ensu= r[e]=20 that the contents of
>>> the document accurately reflect the=20 decisions that have been made by
>>> the working=20 group."
>>>
>>> So let's jump into discussing the=20 changes.
>>>
>>> As I see it this draft introduces= =20 several major functional changes
>>> that have not been discuss= ed by=20 the WG.  Correct me if I get them
>>> wrong, but I believe= they=20 include:
>>> 1) Introduction of a second method for signaling=20 Co-routed LSPs
>>> 2) Support for FRR bypass tunnels for piggyb= acked=20 on the TP
>>> bidirectional LSP=20 mechanisms.
>>>
>>>    There are also oth= er=20 changes, but I'll defer discussing them
>>>    until = the=20 discussion on the above is concluded.
>>>
>>> Is th= is=20 correct?
>>>
>>> Assuming yes, I have questions abo= ut=20 both rational and specific
>>> mechanisms.  For now let's = look=20 at the former, so please:
>>>
>>> A) Articulate the= =20 issues/limitations with using the RFC3473 defined
>>> mechanism= s for=20 (co-routed) bidirectional LSPs that you'd like to see
>>>=20 addressed.
>>>
>>> B.1) Articulate the FRR/GMPLS-re= lated=20 issue you'd like to address?
>>>
>>> B.2) Articulat= e why=20 this issue should be solved in a TP-specific and
>>> not GMPLS= =20 generic fashion?
>>>
>>> Thanks,
>>>=20 Lou
>>>
>>> On 8/16/2012 4:26 PM, Rakesh Gandhi=20 (rgandhi) wrote:
>>>> Hi=20 Lou,
>>>>
>>>>=20 Yes.
>>>>
>>>> Please advise if you think det= ailed=20 email is required.
>>>> We believe latest draft summarizes t= he=20 changes well and we could
>>> start review/discussions from=20 there.
>>>>
>>>> Thanks,
>>>>= =20 Rakesh
>>>>
>>>>
>>>> -----Ori= ginal=20 Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> = Sent:=20 Thursday, August 16, 2012 4:00 PM
>>>> To: Rakesh Gandhi=20 (rgandhi)
>>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>>= >>=20 Subject: Re: [CCAMP] I-D Action:
>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;
>>>>=20 Rakesh,
>>>>     Is this the start of the thread t= hat I=20 requested in
>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729= .html
>>>>
>>>>=20 In particular, is it the response to:
>>>>> I'd like to a= sk=20 that someone (Rakesh, Fei, etc.) review each of the
>>>>>= =20 proposed change and the rational for each change (in one or=20 in
>>>>> separate e-mails). The WG discussion can then re= ally=20 begin on the
>>>>> proposed changes. (Which are quite=20 substantial both in scope and
>>>>>=20 implication.)
>>>>
>>>>=20 Lou
>>>>
>>>> On 8/16/2012 3:19 PM, Rakesh Ga= ndhi=20 (rgandhi) wrote:
>>>>> Hi=20 All,
>>>>>
>>>>> We have uploaded a new= =20 version of this draft with following=20 changes:
>>>>
>>>> 1.  Added a section o= n=20 Signaling of Co-routed LSPs
>>>>
>>>> 2.=20  Added clarification on Signaling of Associated=20 Bidirectional
>>>> Protection=20 LSPs
>>>>
>>>> 3.  Added a section on=20 Signaling of Auto-tunnel Mesh-group LSPs
>>>>
>>>= ;>=20 4.   Added clarification on Signaling of Inter-domain=20 Associated
>>> Bidirectional=20 LSPs
>>>>
>>>> 5.  The Extended ASSOCIAT= ION=20 object format with Association Type
>>> "Associated Bidirection= al=20 LSP". Clarified on how to populate
>>> different fields in this= =20 object.
>>>>
>>>>
>>>>> We= =20 believe that some of these changes were necessary to avoid the
>>&= gt;=20 interoperability issues due to potentially different=20 interpretations.
>>>>>
>>>>> Your revie= w=20 comments are welcome.
>>>>>
>>>>>=20 Thanks,
>>>>>=20 Rakesh
>>>>>
>>>>> -----Original=20 Message-----
>>>>> From: ccamp-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org]=20 On
>>>>> Behalf Of internet-drafts@ietf.org
&g= t;>>>>=20 Sent: Wednesday, August 15, 2012 10:53 AM
>>>>> To: i-d-announce@ietf.org
>>= >>>=20 Cc: ccamp@ietf.org
>>>>= ;>=20 Subject: [CCAMP] I-D Action:
>>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;>
>>>>>
>>>>>=20 A New Internet-Draft is available from the on-line=20 Internet-Drafts
>>> directories.
>>>>>  = This=20 draft is a work item of the Common Control and Measurement
>>> = Plane=20 Working Group of the IETF.
>>>>>
>>>>>= =20    Title           : RSVP-TE Extensions = for=20 Associated Bidirectional
>>> LSPs
>>>>>  = ;=20  Author(s)       : Fei Zhang
>>>>> &n= bsp;=20                      = ;=20   Ruiquan Jing
>>>>>         &nb= sp;=20                 Rakesh=20 Gandhi
>>>>>    Filename      =20  : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-
>>>=20 lsp-04.txt
>>>>>    Pages      = =20     : 17
>>>>>    Date    = =20        :=20 2012-08-15
>>>>>
>>>>>=20 Abstract:
>>>>>    The MPLS Transport Profile=20 (MPLS-TP) requirements document
>>>=20 [RFC5654],
>>>>>    describes that MPLS-TP MUST= =20 support associated bidirectional
>>> point-
>>>>= >=20    to-point LSPs.
>>>>>
>>>>>= =20    This document provides a method to bind two unidirectional=20 Label
>>>>>    Switched Paths (LSPs) into an=20 associated bidirectional LSP.  The
>>>>>  =20  association is achieved by defining the new Association Type=20 in
>>> the
>>>>>    Extended ASSOCI= ATION=20 object.
>>>>>
>>>>>
>>>>= >=20 The IETF datatracker status page for this draft is:
>>>>>= https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-r= svpte-
>>>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp
>>>>>
>>>>> There's also = a=20 htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-= ext-
>>>=20 associ
>>>>> a
>>>>>=20 ted-lsp-04
>>>>>
>>>>> A diff from the= =20 previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp= -rsvpte-
>>>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp-04
>>>>>
>>>>>
>>= ;>>>=20 Internet-Drafts are also available by anonymous FTP at:
>>>>= >=20 ftp://ftp.ietf.org/internet-drafts/
>>>>= >
>>>>>=20 _______________________________________________
>>>>> CCA= MP=20 mailing list
>>>>> CCAMP@ietf.org
>>>>> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ccamp"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ccamp
>>= >>>
>>>>>
>>>>>
>>>= ;>>
>>>>
>>>>
>>>>
&g= t;>>>
>>>=20 _______________________________________________
>>> CCAMP maili= ng=20 list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>=
>>
>>
>>
>=20 _______________________________________________
> CCAMP mailing=20 list
> CCAMP@ietf.org
> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ccamp"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ccamp
________= _______________________________________
CCAMP=20 mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp<= /P>

 

--_000_FE60A4E52763E84B935532D7D9294FF139268CC000EUSAACMS0715e_-- From jdrake@juniper.net Fri Aug 17 14:22:20 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C84111E80F0 for ; Fri, 17 Aug 2012 14:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-xV8ZVlkat8 for ; Fri, 17 Aug 2012 14:22:15 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2571411E80D1 for ; Fri, 17 Aug 2012 14:22:15 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUC62BHfcsdPrB4L0O1BFZIqsyGaOcvk/@postini.com; Fri, 17 Aug 2012 14:22:15 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 17 Aug 2012 14:19:34 -0700 From: John E Drake To: Gregory Mirsky , Greg Mirsky , Francesco Fondelli Date: Fri, 17 Aug 2012 14:19:32 -0700 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac18rlwA4D2YlfZKRGCBpFI+2JZEwgABuVOAAAA1SUAAAN63wAAAvlnAAAAigwA= Message-ID: <5E893DB832F57341992548CDBB333163A631A84EF3@EMBX01-HQ.jnpr.net> References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <5E893DB832F57341992548CDBB333163A631A84E31@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84E97@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A631A84EF3EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 21:22:20 -0000 --_000_5E893DB832F57341992548CDBB333163A631A84EF3EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, For both modes there is bidirectional flow of control packets. For Indepen= dent mode the CC/CV packets flow in only one direction. There never was a coupling between modes and associated/co-routed and if yo= u can point me to any text that says the contrary I would appreciate it as = a bis to remove that text would be required. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 2:12 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, in independent mode CC/CV control messages been sent only in one direction.= Thus there are two CC/CV sessions - one for each independently monitored d= irection. That, AFAIK, was intentional. Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 1:50 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, That certainly wasn't the intent. With a bidirectional LSP of either type = you have one forward and one return path and BFD does not care whether they= are congruent. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 1:28 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, I think that bi-directional associated p2p LSP, regardless of how many comm= on LSRs forward and reverse directions have, implies use of independent mod= e of RFC 6428, then there will be two sessions to monitor each direction in= dependently. Coordinated mode of RFC 6428, in my understanding, applies to = bidirectional co-routed p2p LSP. Regards, Greg ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of John E Drake Sent: Friday, August 17, 2012 1:19 PM To: Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, According to RFC 6428 the is one CC/CV/RDI session irregardless of whether = the bi-directional packet LSP is co-routed or associated. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky Sent: Friday, August 17, 2012 12:27 PM To: Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi Francesco, "from a data-plane view point b) and c2) are the same thing" I think that given that c) is associated bi-directional LSP that implies in= dependent OAM and protection for each direction, b) and c2) are not the sam= e in the data plane view. E.g., there will be single CC/CV/RDI session for = b) while c2) will have two sessions. And if linear protection requested, b)= will be protected by single bi-directional LSP, but c2) - by two unidirect= ional LSPs. Regards, Greg On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: Hi All, I think I'm lost, please help. Rakesh is talking about "co-routed associated bidirectional LSP"... for the sake of clarity, let me try to categorize LSPs from a control plane view point: a) Point-to-point unidirectional b) Point-to-point co-routed bidirectional c) Point-to-point associated bidirectional c1) fwd and rev LSP follow different paths c2) fwd and rev LSP follow same path d) Point-to-multipoint unidirectional e) Multipoint-to-point unidirectional Is section 3.2.5 (Signaling of Co-routed LSPs) of mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? In my opinion: - b) should be signaled with 3473 - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) Am I missing something? thank you ciao fra PS from a data-plane view point b) and c2) are the same thing. On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: > Hi Lou, > > Thanks for initiating discussions on the changes in the draft. > > Agree with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can alwa= ys submit a new draft just for that. We respect your/WG decision. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 6:08 PM > To: John E Drake > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The chai= rs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I cov= ered in earlier mail, my feeling is to let the discussion take place on the= list (and at the next IETF, if needed) and then have the draft updated to = reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your email, >> below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:cca= mp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes >>> that have not been discussed by the WG. Correct me if I get them >>> wrong, but I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate >>> different fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_5E893DB832F57341992548CDBB333163A631A84EF3EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg,

 

<= p class=3DMsoNormal> For both modes there is bidirectional flow of c= ontrol packets.  For Independent mode the CC/CV packets flow in only o= ne direction.

 <= /o:p>

There never was a coupling betw= een modes and associated/co-routed and if you can point me to any text that= says the contrary I would appreciate it as a bis to remove that text would= be required.

 <= /o:p>

Thanks,

 

= John

 

Sent from my iPhone

 

From: Gregory Mirsky [mailto:grego= ry.mirsky@ericsson.com]
Sent: Friday, August 17, 2012 2:12 PMTo: John E Drake; Greg Mirsky; Francesco Fondelli
Cc: cca= mp@ietf.org
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpl= s-tp-rsvpte-ext-associated-lsp-04.txt

 

Hi John,

in independent mode CC/CV control me= ssages been sent only in one direction. Thus there are two CC/CV sessions -= one for each independently monitored direction. That, AFAIK, was intention= al.

 

    Regards,

        Greg

 

From: John E= Drake [mailto:jdrake@juniper.net= ]
Sent: Friday, August 17, 2012 1:50 PM
To: Gregory Mi= rsky; Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D Action: dr= aft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Greg,

 

That cert= ainly wasn’t the intent.  With a bidirectional LSP of either typ= e you have one forward and one return path and BFD does not care whether th= ey are congruent.

&nb= sp;

Thanks,

 

John

 = ;

Sent from my iPhone=

 =

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com<= /a>]
Sent: Friday, August 17, 2012 1:28 PM
To: John E = Drake; Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D Action: d= raft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt<= /p>

 

Hi John,

I think that = ;bi-directional associated p2p LSP, regardless of how many common LSRs forw= ard and reverse directions have, implies use of independent mode of RF= C 6428, then there will be two sessions to monitor each direction independe= ntly. Coordinated mode of RFC 6428, in my understanding, applies to bidirec= tional co-routed p2p LSP.

 <= o:p>

    Regards,

        = Greg

 

From: ccamp-bounces@iet= f.org [mailto:ccamp-bounces@i= etf.org] On Behalf Of John E Drake
Sent: Friday, Augus= t 17, 2012 1:19 PM
To: Greg Mirsky; Francesco Fondelli
Cc:<= /b> ccamp@ietf.org
Subject:= Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp= -04.txt

Greg,

 

According to RFC 6428 the is one CC/CV/RDI session irre= gardless of whether the bi-directional packet LSP is co-routed or associate= d.

 

Thanks,

 

John=

 <= /p>

Sent from my iPhone

 

<= p class=3DMsoNormal>From: ccamp-bou= nces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Friday= , August 17, 2012 12:27 PM
To: Francesco Fondelli
Cc: <= a href=3D"mailto:ccamp@ietf.org">ccamp@ietf.org
Subject: Re: = [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.t= xt

 <= /p>

Hi Francesco,
&qu= ot;from a data-plane view point b) and c2) are the same thing"
I th= ink that given that c) is associated bi-directional LSP that implies indepe= ndent OAM and protection for each direction, b) and c2) are not the same in= the data plane view. E.g., there will be single CC/CV/RDI session for b) w= hile c2) will have two sessions. And if linear protection requested, b) wil= l be protected by single bi-directional LSP, but c2) - by two unidirectiona= l LSPs.

Regards,
Greg

On = Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli <francesco.fondelli@gmail.com> wrote:

Hi All,

I think I'm = lost, please help.

Rakesh is talking about "co-routed associate= d bidirectional
LSP"... for the sake of clarity, let me try to cate= gorize
LSPs from a control plane view point:

  a) Point-to-p= oint unidirectional
  b) Point-to-point co-routed bidirectional
=   c) Point-to-point associated bidirectional
   c1) fwd a= nd rev LSP follow different paths
   c2) fwd and rev LSP follo= w same path
  d) Point-to-multipoint unidirectional
  e) Mu= ltipoint-to-point unidirectional

Is section 3.2.5 (Signaling of Co-r= outed LSPs) of
mpls-tp-rsvpte-ext-associated-lsp about b) or it is about= c2)?

In my opinion:

- b) should be signaled with 3473
- c= ) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp)

Am I= missing something?

thank you
ciao
fra

PS
from a dat= a-plane view point b) and c2) are the same thing.

<= p class=3DMsoNormal>
On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rg= andhi)
<rgandhi@cisco.com>= ; wrote:
> Hi Lou,
>
> Thanks for initiating discussions = on the changes in the draft.
>
> Agree with you here, if we/WG = do not agree on the "co-routed associated bidirectional LSP" part= , we are ok to remove it from this draft and can always submit a new draft = just for that. We respect your/WG decision.
>
> Thanks,
>= Rakesh
>
>
>
> -----Original Message-----
> = From: Lou Berger [mailto:lberger@labn.n= et]
> Sent: Thursday, August 16, 2012 6:08 PM
> To: John E = Drake
> Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org
> Subject: Re: [CCAMP] I-D Action: draft-ietf-cc= amp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>
> John,
> =         While strictly speaking WG drafts should only r= eflect current WG consensus, and it is the WG draft editor's job to ensure = this, in practice authors/editors are given a lot of latitude in timing / o= rdering in introduction to changes.  I personally think this is a prac= tical way of keeping the process moving.  Also if the WG disagrees wit= h a change, it can always be backed out.
>
> So, yes, the WG co= uld do exactly as you say if it comes to it.  (The chairs can even app= oint different editor if needed, e.g., to make this
> happen.)  = While I'm not happy with how this revision came about, as I covered in earl= ier mail, my feeling is to let the discussion take place on the list (and a= t the next IETF, if needed) and then have the draft updated to reflect the = WG discussion/consensus.
>
> Lou
>
> On 8/16/2012 5= :35 PM, John E Drake wrote:
>> Lou,
>>
>> Since = the WG did not agree to this changes, let alone discuss them,
>> w= ould it be possible to simply rollback these changes and ask the
>>= ; authors to write a draft addressing the topics you list in your email,>> below?
>>
>> Thanks,
>>
>> Jo= hn
>>
>> Sent from my iPhone
>>
>>
&= gt;>> -----Original Message-----
>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>>>= ; Behalf Of Lou Berger
>>> Sent: Thursday, August 16, 2012 2:10= PM
>>> To: Rakesh Gandhi (rgandhi)
>>> Cc: ccamp@ietf.org
>>> Subject: Re: = [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>> as= sociated-lsp-04.txt
>>>
>>> Rakesh,
>>>=      Such major changes (in scope and functionality) to WG = drafts are
>>> usually discussed with the WG prior to the autho= rs/editors just
>>> publishing the changes.  But, this is = a judgment call by the document
>>> editors in how, quoting rfc= 2418, they "ensur[e] that the contents of
>>> the document= accurately reflect the decisions that have been made by
>>> th= e working group."
>>>
>>> So let's jump into d= iscussing the changes.
>>>
>>> As I see it this dra= ft introduces several major functional changes
>>> that have no= t been discussed by the WG.  Correct me if I get them
>>> = wrong, but I believe they include:
>>> 1) Introduction of a sec= ond method for signaling Co-routed LSPs
>>> 2) Support for FRR = bypass tunnels for piggybacked on the TP
>>> bidirectional LSP = mechanisms.
>>>
>>>    There are also oth= er changes, but I'll defer discussing them
>>>    unt= il the discussion on the above is concluded.
>>>
>>>= ; Is this correct?
>>>
>>> Assuming yes, I have que= stions about both rational and specific
>>> mechanisms.  F= or now let's look at the former, so please:
>>>
>>>= A) Articulate the issues/limitations with using the RFC3473 defined
>= ;>> mechanisms for (co-routed) bidirectional LSPs that you'd like to = see
>>> addressed.
>>>
>>> B.1) Articul= ate the FRR/GMPLS-related issue you'd like to address?
>>>
&= gt;>> B.2) Articulate why this issue should be solved in a TP-specifi= c and
>>> not GMPLS generic fashion?
>>>
>>= ;> Thanks,
>>> Lou
>>>
>>> On 8/16/2= 012 4:26 PM, Rakesh Gandhi (rgandhi) wrote:
>>>> Hi Lou,
= >>>>
>>>> Yes.
>>>>
>>&g= t;> Please advise if you think detailed email is required.
>>&g= t;> We believe latest draft summarizes the changes well and we could
= >>> start review/discussions from there.
>>>>
&g= t;>>> Thanks,
>>>> Rakesh
>>>>
&g= t;>>>
>>>> -----Original Message-----
>>&g= t;> From: Lou Berger [mailto:lberger= @labn.net]
>>>> Sent: Thursday, August 16, 2012 4:00 PM<= br>>>>> To: Rakesh Gandhi (rgandhi)
>>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>>>> Subject: Re:= [CCAMP] I-D Action:
>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ex= t-associated-lsp-04.txt
>>>>
>>>> Rakesh,
= >>>>     Is this the start of the thread that I reque= sted in
>>>> http://www.ietf.org/mail-ar= chive/web/ccamp/current/msg13729.html
>>>>
>>&g= t;> In particular, is it the response to:
>>>>> I'd li= ke to ask that someone (Rakesh, Fei, etc.) review each of the
>>&g= t;>> proposed change and the rational for each change (in one or in>>>>> separate e-mails). The WG discussion can then really= begin on the
>>>>> proposed changes. (Which are quite su= bstantial both in scope and
>>>>> implication.)
>&g= t;>>
>>>> Lou
>>>>
>>>> = On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote:
>>>>>= ; Hi All,
>>>>>
>>>>> We have uploaded = a new version of this draft with following changes:
>>>>
= >>>> 1.  Added a section on Signaling of Co-routed LSPs>>>>
>>>> 2.  Added clarification on Signa= ling of Associated Bidirectional
>>>> Protection LSPs
>= ;>>>
>>>> 3.  Added a section on Signaling of = Auto-tunnel Mesh-group LSPs
>>>>
>>>> 4. &nbs= p; Added clarification on Signaling of Inter-domain Associated
>>&= gt; Bidirectional LSPs
>>>>
>>>> 5.  The= Extended ASSOCIATION object format with Association Type
>>> &= quot;Associated Bidirectional LSP". Clarified on how to populate
&g= t;>> different fields in this object.
>>>>
>>= >>
>>>>> We believe that some of these changes were= necessary to avoid the
>>> interoperability issues due to pote= ntially different interpretations.
>>>>>
>>>&= gt;> Your review comments are welcome.
>>>>>
>&g= t;>>> Thanks,
>>>>> Rakesh
>>>>&g= t;
>>>>> -----Original Message-----
>>>>&g= t; From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org= ] On
>>>>> Behalf Of internet-drafts@ietf.org
>>>>> Sent: Wedn= esday, August 15, 2012 10:53 AM
>>>>> To: i-d-announce@ietf.org
>>>>>= Cc: ccamp@ietf.org
>>>&g= t;> Subject: [CCAMP] I-D Action:
>>>>> draft-ietf-ccam= p-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>>
>&= gt;>>>
>>>>> A New Internet-Draft is available f= rom the on-line Internet-Drafts
>>> directories.
>>>= ;>>  This draft is a work item of the Common Control and Measure= ment
>>> Plane Working Group of the IETF.
>>>>&g= t;
>>>>>    Title         &= nbsp; : RSVP-TE Extensions for Associated Bidirectional
>>> LSP= s
>>>>>    Author(s)       : Fei= Zhang
>>>>>             &n= bsp;             Ruiquan Jing
>>>= >>                   &nb= sp;       Rakesh Gandhi
>>>>>    = ;Filename        : draft-ietf-ccamp-mpls-tp-rsvpte-ext-= associated-
>>> lsp-04.txt
>>>>>    = ;Pages           : 17
>>>>> &nbs= p;  Date            : 2012-08-15
>= >>>>
>>>>> Abstract:
>>>>> =    The MPLS Transport Profile (MPLS-TP) requirements document
= >>> [RFC5654],
>>>>>    describes that= MPLS-TP MUST support associated bidirectional
>>> point-
&g= t;>>>>    to-point LSPs.
>>>>>
&= gt;>>>>    This document provides a method to bind tw= o unidirectional Label
>>>>>    Switched Paths = (LSPs) into an associated bidirectional LSP.  The
>>>>&= gt;    association is achieved by defining the new Association Ty= pe in
>>> the
>>>>>    Extended ASS= OCIATION object.
>>>>>
>>>>>
>>= ;>>> The IETF datatracker status page for this draft is:
>&g= t;>>> https://datatracker.ietf.org/doc/draft-= ietf-ccamp-mpls-tp-rsvpte-
>>> ext-
>>>>>= a
>>>>> ssociated-lsp
>>>>>
>>= ;>>> There's also a htmlized version available at:
>>>= >> http://tools.ietf.org/html/draft-ietf-ccamp-mpl= s-tp-rsvpte-ext-
>>> associ
>>>>> a
&g= t;>>>> ted-lsp-04
>>>>>
>>>>&g= t; A diff from the previous version is available at:
>>>>>= ; http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccam= p-mpls-tp-rsvpte-
>>> ext-
>>>>> a
>= ;>>>> ssociated-lsp-04
>>>>>
>>>&= gt;>
>>>>> Internet-Drafts are also available by anony= mous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>= >>>>
>>>>> __________________________________= _____________
>>>>> CCAMP mailing list
>>>>= ;> CCAMP@ietf.org
>>>&= gt;> https://www.ietf.org/mailman/listinfo/ccamp
>>>>&= gt;
>>>>>
>>>>>
>>>>>=
>>>>
>>>>
>>>>
>>>= ;>
>>> _______________________________________________
&g= t;>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinf= o/ccamp
>>
>>
>>
>>
> _______= ________________________________________
> CCAMP mailing list
>= CCAMP@ietf.org
> https://www.ie= tf.org/mailman/listinfo/ccamp
______________________________________= _________
CCAMP mailing list
CCAMP@= ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

 

<= /div>
= --_000_5E893DB832F57341992548CDBB333163A631A84EF3EMBX01HQjnprn_-- From david.i.allan@ericsson.com Fri Aug 17 14:25:01 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A10011E80F1 for ; Fri, 17 Aug 2012 14:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRucS2q7QMiZ for ; Fri, 17 Aug 2012 14:24:56 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2BC11E80D1 for ; Fri, 17 Aug 2012 14:24:56 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q7HLPWj5027859; Fri, 17 Aug 2012 16:25:33 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 17 Aug 2012 17:24:48 -0400 From: David Allan I To: John E Drake , Gregory Mirsky , Greg Mirsky , Francesco Fondelli Date: Fri, 17 Aug 2012 17:24:46 -0400 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac18rlwA4D2YlfZKRGCBpFI+2JZEwgABuVOAAAA1SUAAAN63wAAAvlnAAAAigwAAAF8JMA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD5668113046@EUSAACMS0703.eamcs.ericsson.se> References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <5E893DB832F57341992548CDBB333163A631A84E31@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84E97@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84EF3@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A631A84EF3@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD5668113046EUSAACMS0703e_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 21:25:01 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD5668113046EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the observation is that coordinated has the most utility in co-rout= ed, and independent has more utility for associated. This is not actually m= andated, but true nontheless... Dave ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of J= ohn E Drake Sent: Friday, August 17, 2012 2:20 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, For both modes there is bidirectional flow of control packets. For Indepen= dent mode the CC/CV packets flow in only one direction. There never was a coupling between modes and associated/co-routed and if yo= u can point me to any text that says the contrary I would appreciate it as = a bis to remove that text would be required. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 2:12 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, in independent mode CC/CV control messages been sent only in one direction.= Thus there are two CC/CV sessions - one for each independently monitored d= irection. That, AFAIK, was intentional. Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 1:50 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, That certainly wasn't the intent. With a bidirectional LSP of either type = you have one forward and one return path and BFD does not care whether they= are congruent. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 1:28 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, I think that bi-directional associated p2p LSP, regardless of how many comm= on LSRs forward and reverse directions have, implies use of independent mod= e of RFC 6428, then there will be two sessions to monitor each direction in= dependently. Coordinated mode of RFC 6428, in my understanding, applies to = bidirectional co-routed p2p LSP. Regards, Greg ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of John E Drake Sent: Friday, August 17, 2012 1:19 PM To: Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, According to RFC 6428 the is one CC/CV/RDI session irregardless of whether = the bi-directional packet LSP is co-routed or associated. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky Sent: Friday, August 17, 2012 12:27 PM To: Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi Francesco, "from a data-plane view point b) and c2) are the same thing" I think that given that c) is associated bi-directional LSP that implies in= dependent OAM and protection for each direction, b) and c2) are not the sam= e in the data plane view. E.g., there will be single CC/CV/RDI session for = b) while c2) will have two sessions. And if linear protection requested, b)= will be protected by single bi-directional LSP, but c2) - by two unidirect= ional LSPs. Regards, Greg On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: Hi All, I think I'm lost, please help. Rakesh is talking about "co-routed associated bidirectional LSP"... for the sake of clarity, let me try to categorize LSPs from a control plane view point: a) Point-to-point unidirectional b) Point-to-point co-routed bidirectional c) Point-to-point associated bidirectional c1) fwd and rev LSP follow different paths c2) fwd and rev LSP follow same path d) Point-to-multipoint unidirectional e) Multipoint-to-point unidirectional Is section 3.2.5 (Signaling of Co-routed LSPs) of mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? In my opinion: - b) should be signaled with 3473 - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) Am I missing something? thank you ciao fra PS from a data-plane view point b) and c2) are the same thing. On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: > Hi Lou, > > Thanks for initiating discussions on the changes in the draft. > > Agree with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can alwa= ys submit a new draft just for that. We respect your/WG decision. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 6:08 PM > To: John E Drake > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The chai= rs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I cov= ered in earlier mail, my feeling is to let the discussion take place on the= list (and at the next IETF, if needed) and then have the draft updated to = reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your email, >> below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:cca= mp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes >>> that have not been discussed by the WG. Correct me if I get them >>> wrong, but I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate >>> different fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_60C093A41B5E45409A19D42CF7786DFD5668113046EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 think the observation is that coordinated has the most utility in co-routed= , and=20 independent has more utility for associated. This is not actually mandated,= but=20 true nontheless...
 
Dave

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of John E Drake
Sent= :=20 Friday, August 17, 2012 2:20 PM
To: Gregory Mirsky; Greg Mirsky;= =20 Francesco Fondelli
Cc: ccamp@ietf.org
Subject: Re: [CCA= MP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Greg,

 

For=20 both modes there is bidirectional flow of control packets.  For Indepe= ndent=20 mode the CC/CV packets flow in only one direction.

 

There=20 never was a coupling between modes and associated/co-routed and if you can = point=20 me to any text that says the contrary I would appreciate it as a bis to rem= ove=20 that text would be required.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B> Gregory Mirs= ky=20 [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, August 17, 20= 12=20 2:12 PM
To: John E Drake; Greg Mirsky; Francesco=20 Fondelli
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D Ac= tion:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

H= i=20 John,

i= n=20 independent mode CC/CV control messages been sent only in one direction. Th= us=20 there are two CC/CV sessions - one for each independently monitored directi= on.=20 That, AFAIK, was intentional.

 

    R= egards,

        G= reg

 

From:<= /B> John E Drake= [mailto:jdrake@juniper.net]
Se= nt:=20 Friday, August 17, 2012 1:50 PM
To: Gregory Mirsky; Greg Mirsky;= =20 Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

Greg,

 

That=20 certainly wasn’t the intent.  With a bidirectional LSP of either= type you=20 have one forward and one return path and BFD does not care whether they are= =20 congruent.

 

Thanks,

 

John

 

Sent=20 from my iPhone

 

From:<= /B> Gregory Mirs= ky [mailto:gregory.mirsky@ericsson.= com]=20
Sent: Friday, August 17, 2012 1:28 PM
To: John E Drake= ;=20 Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

H= i=20 John,

I= think=20 that bi-directional associated p2p LSP, regardless of how many common = LSRs=20 forward and reverse directions have, implies use of independent mode o= f RFC=20 6428, then there will be two sessions to monitor each direction independent= ly.=20 Coordinated mode of RFC 6428, in my understanding, applies to bidirectional= =20 co-routed p2p LSP.

 

    R= egards,

        G= reg

 

From:<= /B> ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <= B>On=20 Behalf Of John E Drake
Sent: Friday, August 17, 2012 1:19=20 PM
To: Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: Re: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

Greg,

 

According=20 to RFC 6428 the is one CC/CV/RDI session irregardless of whether the=20 bi-directional packet LSP is co-routed or associated.

 

Thanks,

 

John

 

Sent=20 from my iPhone

 

From:<= /B> ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <= B>On=20 Behalf Of Greg Mirsky
Sent: Friday, August 17, 2012 12:27=20 PM
To: Francesco Fondelli
Cc: ccamp@ietf.org
Subject: Re: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

Hi Francesco,
"from a= =20 data-plane view point b) and c2) are the same thing"
I think that given = that=20 c) is associated bi-directional LSP that implies independent OAM and protec= tion=20 for each direction, b) and c2) are not the same in the data plane view. E.g= .,=20 there will be single CC/CV/RDI session for b) while c2) will have two sessi= ons.=20 And if linear protection requested, b) will be protected by single=20 bi-directional LSP, but c2) - by two unidirectional=20 LSPs.

Regards,
Greg

On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli &l= t;francesco.fondelli@gmail.com> wrote:

Hi All,

I think I'm lost, please help.

R= akesh=20 is talking about "co-routed associated bidirectional
LSP"... for the sak= e of=20 clarity, let me try to categorize
LSPs from a control plane view=20 point:

  a) Point-to-point unidirectional
  b)=20 Point-to-point co-routed bidirectional
  c) Point-to-point associat= ed=20 bidirectional
   c1) fwd and rev LSP follow different=20 paths
   c2) fwd and rev LSP follow same path
  d)=20 Point-to-multipoint unidirectional
  e) Multipoint-to-point=20 unidirectional

Is section 3.2.5 (Signaling of Co-routed LSPs)=20 of
mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)?
In=20 my opinion:

- b) should be signaled with 3473
- c) are addressed = by=20 this I-D (mpls-tp-rsvpte-ext-associated-lsp)

Am I missing=20 something?

thank you
ciao
fra

PS
from a data-plane v= iew=20 point b) and c2) are the same thing.


On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi=20 (rgandhi)
<rgandhi@cisco.com= >=20 wrote:
> Hi Lou,
>
> Thanks for initiating discussions on= the=20 changes in the draft.
>
> Agree with you here, if we/WG do not = agree=20 on the "co-routed associated bidirectional LSP" part, we are ok to remove i= t=20 from this draft and can always submit a new draft just for that. We respect= =20 your/WG decision.
>
> Thanks,
>=20 Rakesh
>
>
>
> -----Original Message-----
> F= rom:=20 Lou Berger [mailto:lberger@labn.net]
> Sent: Thursd= ay,=20 August 16, 2012 6:08 PM
> To: John E Drake
> Cc: Rakesh Gandhi= =20 (rgandhi); ccamp@ietf.org
> Sub= ject:=20 Re: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>
>=20 John,
>         While strictly speaking WG drafts= =20 should only reflect current WG consensus, and it is the WG draft editor's j= ob to=20 ensure this, in practice authors/editors are given a lot of latitude in tim= ing /=20 ordering in introduction to changes.  I personally think this is a=20 practical way of keeping the process moving.  Also if the WG disagrees= with=20 a change, it can always be backed out.
>
> So, yes, the WG coul= d do=20 exactly as you say if it comes to it.  (The chairs can even appoint=20 different editor if needed, e.g., to make this
> happen.)  While= I'm=20 not happy with how this revision came about, as I covered in earlier mail, = my=20 feeling is to let the discussion take place on the list (and at the next IE= TF,=20 if needed) and then have the draft updated to reflect the WG=20 discussion/consensus.
>
> Lou
>
> On 8/16/2012 5:35= PM,=20 John E Drake wrote:
>> Lou,
>>
>> Since the WG d= id=20 not agree to this changes, let alone discuss them,
>> would it be= =20 possible to simply rollback these changes and ask the
>> authors t= o=20 write a draft addressing the topics you list in your email,
>>=20 below?
>>
>> Thanks,
>>
>>=20 John
>>
>> Sent from my=20 iPhone
>>
>>
>>> -----Original=20 Message-----
>>> From: ccamp-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org]=20 On
>>> Behalf Of Lou Berger
>>> Sent: Thursday, Aug= ust=20 16, 2012 2:10 PM
>>> To: Rakesh Gandhi (rgandhi)
>>>= ; Cc:=20 ccamp@ietf.org
>>> Subjec= t: Re:=20 [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>>=20 associated-lsp-04.txt
>>>
>>> Rakesh,
>>&g= t;=20      Such major changes (in scope and functionality) to WG d= rafts=20 are
>>> usually discussed with the WG prior to the authors/edit= ors=20 just
>>> publishing the changes.  But, this is a judgment = call=20 by the document
>>> editors in how, quoting rfc2418, they "ensu= r[e]=20 that the contents of
>>> the document accurately reflect the=20 decisions that have been made by
>>> the working=20 group."
>>>
>>> So let's jump into discussing the=20 changes.
>>>
>>> As I see it this draft introduces= =20 several major functional changes
>>> that have not been discuss= ed by=20 the WG.  Correct me if I get them
>>> wrong, but I believe= they=20 include:
>>> 1) Introduction of a second method for signaling=20 Co-routed LSPs
>>> 2) Support for FRR bypass tunnels for piggyb= acked=20 on the TP
>>> bidirectional LSP=20 mechanisms.
>>>
>>>    There are also oth= er=20 changes, but I'll defer discussing them
>>>    until = the=20 discussion on the above is concluded.
>>>
>>> Is th= is=20 correct?
>>>
>>> Assuming yes, I have questions abo= ut=20 both rational and specific
>>> mechanisms.  For now let's = look=20 at the former, so please:
>>>
>>> A) Articulate the= =20 issues/limitations with using the RFC3473 defined
>>> mechanism= s for=20 (co-routed) bidirectional LSPs that you'd like to see
>>>=20 addressed.
>>>
>>> B.1) Articulate the FRR/GMPLS-re= lated=20 issue you'd like to address?
>>>
>>> B.2) Articulat= e why=20 this issue should be solved in a TP-specific and
>>> not GMPLS= =20 generic fashion?
>>>
>>> Thanks,
>>>=20 Lou
>>>
>>> On 8/16/2012 4:26 PM, Rakesh Gandhi=20 (rgandhi) wrote:
>>>> Hi=20 Lou,
>>>>
>>>>=20 Yes.
>>>>
>>>> Please advise if you think det= ailed=20 email is required.
>>>> We believe latest draft summarizes t= he=20 changes well and we could
>>> start review/discussions from=20 there.
>>>>
>>>> Thanks,
>>>>= =20 Rakesh
>>>>
>>>>
>>>> -----Ori= ginal=20 Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> = Sent:=20 Thursday, August 16, 2012 4:00 PM
>>>> To: Rakesh Gandhi=20 (rgandhi)
>>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>>= >>=20 Subject: Re: [CCAMP] I-D Action:
>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;
>>>>=20 Rakesh,
>>>>     Is this the start of the thread t= hat I=20 requested in
>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729= .html
>>>>
>>>>=20 In particular, is it the response to:
>>>>> I'd like to a= sk=20 that someone (Rakesh, Fei, etc.) review each of the
>>>>>= =20 proposed change and the rational for each change (in one or=20 in
>>>>> separate e-mails). The WG discussion can then re= ally=20 begin on the
>>>>> proposed changes. (Which are quite=20 substantial both in scope and
>>>>>=20 implication.)
>>>>
>>>>=20 Lou
>>>>
>>>> On 8/16/2012 3:19 PM, Rakesh Ga= ndhi=20 (rgandhi) wrote:
>>>>> Hi=20 All,
>>>>>
>>>>> We have uploaded a new= =20 version of this draft with following=20 changes:
>>>>
>>>> 1.  Added a section o= n=20 Signaling of Co-routed LSPs
>>>>
>>>> 2.=20  Added clarification on Signaling of Associated=20 Bidirectional
>>>> Protection=20 LSPs
>>>>
>>>> 3.  Added a section on=20 Signaling of Auto-tunnel Mesh-group LSPs
>>>>
>>>= ;>=20 4.   Added clarification on Signaling of Inter-domain=20 Associated
>>> Bidirectional=20 LSPs
>>>>
>>>> 5.  The Extended ASSOCIAT= ION=20 object format with Association Type
>>> "Associated Bidirection= al=20 LSP". Clarified on how to populate
>>> different fields in this= =20 object.
>>>>
>>>>
>>>>> We= =20 believe that some of these changes were necessary to avoid the
>>&= gt;=20 interoperability issues due to potentially different=20 interpretations.
>>>>>
>>>>> Your revie= w=20 comments are welcome.
>>>>>
>>>>>=20 Thanks,
>>>>>=20 Rakesh
>>>>>
>>>>> -----Original=20 Message-----
>>>>> From: ccamp-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org]=20 On
>>>>> Behalf Of internet-drafts@ietf.org
&g= t;>>>>=20 Sent: Wednesday, August 15, 2012 10:53 AM
>>>>> To: i-d-announce@ietf.org
>>= >>>=20 Cc: ccamp@ietf.org
>>>>= ;>=20 Subject: [CCAMP] I-D Action:
>>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;>
>>>>>
>>>>>=20 A New Internet-Draft is available from the on-line=20 Internet-Drafts
>>> directories.
>>>>>  = This=20 draft is a work item of the Common Control and Measurement
>>> = Plane=20 Working Group of the IETF.
>>>>>
>>>>>= =20    Title           : RSVP-TE Extensions = for=20 Associated Bidirectional
>>> LSPs
>>>>>  = ;=20  Author(s)       : Fei Zhang
>>>>> &n= bsp;=20                      = ;=20   Ruiquan Jing
>>>>>         &nb= sp;=20                 Rakesh=20 Gandhi
>>>>>    Filename      =20  : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-
>>>=20 lsp-04.txt
>>>>>    Pages      = =20     : 17
>>>>>    Date    = =20        :=20 2012-08-15
>>>>>
>>>>>=20 Abstract:
>>>>>    The MPLS Transport Profile=20 (MPLS-TP) requirements document
>>>=20 [RFC5654],
>>>>>    describes that MPLS-TP MUST= =20 support associated bidirectional
>>> point-
>>>>= >=20    to-point LSPs.
>>>>>
>>>>>= =20    This document provides a method to bind two unidirectional=20 Label
>>>>>    Switched Paths (LSPs) into an=20 associated bidirectional LSP.  The
>>>>>  =20  association is achieved by defining the new Association Type=20 in
>>> the
>>>>>    Extended ASSOCI= ATION=20 object.
>>>>>
>>>>>
>>>>= >=20 The IETF datatracker status page for this draft is:
>>>>>= https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-r= svpte-
>>>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp
>>>>>
>>>>> There's also = a=20 htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-= ext-
>>>=20 associ
>>>>> a
>>>>>=20 ted-lsp-04
>>>>>
>>>>> A diff from the= =20 previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp= -rsvpte-
>>>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp-04
>>>>>
>>>>>
>>= ;>>>=20 Internet-Drafts are also available by anonymous FTP at:
>>>>= >=20 ftp://ftp.ietf.org/internet-drafts/
>>>>= >
>>>>>=20 _______________________________________________
>>>>> CCA= MP=20 mailing list
>>>>> CCAMP@ietf.org
>>>>> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ccamp"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ccamp
>>= >>>
>>>>>
>>>>>
>>>= ;>>
>>>>
>>>>
>>>>
&g= t;>>>
>>>=20 _______________________________________________
>>> CCAMP maili= ng=20 list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>=
>>
>>
>>
>=20 _______________________________________________
> CCAMP mailing=20 list
> CCAMP@ietf.org
> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ccamp"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ccamp
________= _______________________________________
CCAMP=20 mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp<= /P>

 

--_000_60C093A41B5E45409A19D42CF7786DFD5668113046EUSAACMS0703e_-- From gregory.mirsky@ericsson.com Fri Aug 17 14:34:24 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F2F21E8045 for ; Fri, 17 Aug 2012 14:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmOLp2Ia0ujV for ; Fri, 17 Aug 2012 14:34:18 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCD421E8089 for ; Fri, 17 Aug 2012 14:34:05 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q7HLXbRu017830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Aug 2012 16:34:03 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 17 Aug 2012 17:34:00 -0400 From: Gregory Mirsky To: John E Drake , Greg Mirsky , Francesco Fondelli Date: Fri, 17 Aug 2012 17:33:58 -0400 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac18rlwA4D2YlfZKRGCBpFI+2JZEwgABuVOAAAA1SUAAAN63wAAAvlnAAAAigwAAAIUx8A== Message-ID: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <5E893DB832F57341992548CDBB333163A631A84E31@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84E97@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84EF3@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A631A84EF3@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF139268CC01FEUSAACMS0715e_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 21:34:24 -0000 --_000_FE60A4E52763E84B935532D7D9294FF139268CC01FEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John, as Dave Allan pointed, RFC 6428 does not mandate how coordinated and indepe= ndent modes should be used. But the very first sentence of Section 3.1 of t= he document we're discussing says "The associated bidirectional LSP's forward and backward directions are set= up, monitored, and protected independently as required by [RFC5654]." And in RFC 5654, section 1.2.2 I indeed f= ind "Associated bidirectional path: A path that supports traffic flow in both d= irections but that is constructed from a pair of unidirectional paths (one = for each direction) that are associated with one another at the path's ingr= ess/egress points. The forward and backward directions are setup, monitore= d, and protected independently. As a consequence, they may or may not foll= ow the same route (links and nodes) across the network." I think there's no need for RFC 6428bis. Do you think there's need to revis= e RFC 5654? Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 2:20 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, For both modes there is bidirectional flow of control packets. For Indepen= dent mode the CC/CV packets flow in only one direction. There never was a coupling between modes and associated/co-routed and if yo= u can point me to any text that says the contrary I would appreciate it as = a bis to remove that text would be required. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 2:12 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, in independent mode CC/CV control messages been sent only in one direction.= Thus there are two CC/CV sessions - one for each independently monitored d= irection. That, AFAIK, was intentional. Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 1:50 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, That certainly wasn't the intent. With a bidirectional LSP of either type = you have one forward and one return path and BFD does not care whether they= are congruent. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 1:28 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, I think that bi-directional associated p2p LSP, regardless of how many comm= on LSRs forward and reverse directions have, implies use of independent mod= e of RFC 6428, then there will be two sessions to monitor each direction in= dependently. Coordinated mode of RFC 6428, in my understanding, applies to = bidirectional co-routed p2p LSP. Regards, Greg ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of John E Drake Sent: Friday, August 17, 2012 1:19 PM To: Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, According to RFC 6428 the is one CC/CV/RDI session irregardless of whether = the bi-directional packet LSP is co-routed or associated. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky Sent: Friday, August 17, 2012 12:27 PM To: Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi Francesco, "from a data-plane view point b) and c2) are the same thing" I think that given that c) is associated bi-directional LSP that implies in= dependent OAM and protection for each direction, b) and c2) are not the sam= e in the data plane view. E.g., there will be single CC/CV/RDI session for = b) while c2) will have two sessions. And if linear protection requested, b)= will be protected by single bi-directional LSP, but c2) - by two unidirect= ional LSPs. Regards, Greg On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: Hi All, I think I'm lost, please help. Rakesh is talking about "co-routed associated bidirectional LSP"... for the sake of clarity, let me try to categorize LSPs from a control plane view point: a) Point-to-point unidirectional b) Point-to-point co-routed bidirectional c) Point-to-point associated bidirectional c1) fwd and rev LSP follow different paths c2) fwd and rev LSP follow same path d) Point-to-multipoint unidirectional e) Multipoint-to-point unidirectional Is section 3.2.5 (Signaling of Co-routed LSPs) of mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? In my opinion: - b) should be signaled with 3473 - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) Am I missing something? thank you ciao fra PS from a data-plane view point b) and c2) are the same thing. On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: > Hi Lou, > > Thanks for initiating discussions on the changes in the draft. > > Agree with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can alwa= ys submit a new draft just for that. We respect your/WG decision. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 6:08 PM > To: John E Drake > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The chai= rs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I cov= ered in earlier mail, my feeling is to let the discussion take place on the= list (and at the next IETF, if needed) and then have the draft updated to = reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your email, >> below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:cca= mp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes >>> that have not been discussed by the WG. Correct me if I get them >>> wrong, but I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate >>> different fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_FE60A4E52763E84B935532D7D9294FF139268CC01FEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
John,
as Dave Allan pointed, RFC 6428 does not mandate h= ow=20 coordinated and independent modes should be used. But the very first senten= ce of=20 Section 3.1 of the document we're discussing says
"The associated bidirectional LSP's forward and ba= ckward=20 directions are set up, monitored, and protected independently as requi= red=20 by   [RFC5654]." And in RFC 5654, section 1.2.2 I inde= ed=20 find
"Associated bidirectional path: A path that suppor= ts=20 traffic flow in both directions but that is constructed from a pair of= =20 unidirectional paths (one for each direction) that are associated with= one=20 another at the path's ingress/egress points.  The forward and=20 backward directions are setup, monitored, and protected=20 independently.  As a consequence, they may or may not follow the = same=20 route (links and nodes) across the network."
 
I think there's no need for RFC 6428bis. Do you th= ink=20 there's need to revise RFC 5654?
 
  &n= bsp; Regards,
        Greg
 

From: John E Drake [mailto:jdrake@junip= er.net]=20
Sent: Friday, August 17, 2012 2:20 PM
To: Gregory Mirs= ky;=20 Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject:= =20 RE: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Greg,

 

For=20 both modes there is bidirectional flow of control packets.  For Indepe= ndent=20 mode the CC/CV packets flow in only one direction.

 

There=20 never was a coupling between modes and associated/co-routed and if you can = point=20 me to any text that says the contrary I would appreciate it as a bis to rem= ove=20 that text would be required.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B> Gregory Mirs= ky=20 [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, August 17, 20= 12=20 2:12 PM
To: John E Drake; Greg Mirsky; Francesco=20 Fondelli
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D Ac= tion:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

H= i=20 John,

i= n=20 independent mode CC/CV control messages been sent only in one direction. Th= us=20 there are two CC/CV sessions - one for each independently monitored directi= on.=20 That, AFAIK, was intentional.

 

    R= egards,

        G= reg

 

From:<= /B> John E Drake= [mailto:jdrake@juniper.net]
Se= nt:=20 Friday, August 17, 2012 1:50 PM
To: Gregory Mirsky; Greg Mirsky;= =20 Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

Greg,

 

That=20 certainly wasn’t the intent.  With a bidirectional LSP of either= type you=20 have one forward and one return path and BFD does not care whether they are= =20 congruent.

 

Thanks,

 

John

 

Sent=20 from my iPhone

 

From:<= /B> Gregory Mirs= ky [mailto:gregory.mirsky@ericsson.= com]=20
Sent: Friday, August 17, 2012 1:28 PM
To: John E Drake= ;=20 Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

H= i=20 John,

I= think=20 that bi-directional associated p2p LSP, regardless of how many common = LSRs=20 forward and reverse directions have, implies use of independent mode o= f RFC=20 6428, then there will be two sessions to monitor each direction independent= ly.=20 Coordinated mode of RFC 6428, in my understanding, applies to bidirectional= =20 co-routed p2p LSP.

 

    R= egards,

        G= reg

 

From:<= /B> ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <= B>On=20 Behalf Of John E Drake
Sent: Friday, August 17, 2012 1:19=20 PM
To: Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: Re: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

Greg,

 

According=20 to RFC 6428 the is one CC/CV/RDI session irregardless of whether the=20 bi-directional packet LSP is co-routed or associated.

 

Thanks,

 

John

 

Sent=20 from my iPhone

 

From:<= /B> ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <= B>On=20 Behalf Of Greg Mirsky
Sent: Friday, August 17, 2012 12:27=20 PM
To: Francesco Fondelli
Cc: ccamp@ietf.org
Subject: Re: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

Hi Francesco,
"from a= =20 data-plane view point b) and c2) are the same thing"
I think that given = that=20 c) is associated bi-directional LSP that implies independent OAM and protec= tion=20 for each direction, b) and c2) are not the same in the data plane view. E.g= .,=20 there will be single CC/CV/RDI session for b) while c2) will have two sessi= ons.=20 And if linear protection requested, b) will be protected by single=20 bi-directional LSP, but c2) - by two unidirectional=20 LSPs.

Regards,
Greg

On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli &l= t;francesco.fondelli@gmail.com> wrote:

Hi All,

I think I'm lost, please help.

R= akesh=20 is talking about "co-routed associated bidirectional
LSP"... for the sak= e of=20 clarity, let me try to categorize
LSPs from a control plane view=20 point:

  a) Point-to-point unidirectional
  b)=20 Point-to-point co-routed bidirectional
  c) Point-to-point associat= ed=20 bidirectional
   c1) fwd and rev LSP follow different=20 paths
   c2) fwd and rev LSP follow same path
  d)=20 Point-to-multipoint unidirectional
  e) Multipoint-to-point=20 unidirectional

Is section 3.2.5 (Signaling of Co-routed LSPs)=20 of
mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)?
In=20 my opinion:

- b) should be signaled with 3473
- c) are addressed = by=20 this I-D (mpls-tp-rsvpte-ext-associated-lsp)

Am I missing=20 something?

thank you
ciao
fra

PS
from a data-plane v= iew=20 point b) and c2) are the same thing.


On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi=20 (rgandhi)
<rgandhi@cisco.com= >=20 wrote:
> Hi Lou,
>
> Thanks for initiating discussions on= the=20 changes in the draft.
>
> Agree with you here, if we/WG do not = agree=20 on the "co-routed associated bidirectional LSP" part, we are ok to remove i= t=20 from this draft and can always submit a new draft just for that. We respect= =20 your/WG decision.
>
> Thanks,
>=20 Rakesh
>
>
>
> -----Original Message-----
> F= rom:=20 Lou Berger [mailto:lberger@labn.net]
> Sent: Thursd= ay,=20 August 16, 2012 6:08 PM
> To: John E Drake
> Cc: Rakesh Gandhi= =20 (rgandhi); ccamp@ietf.org
> Sub= ject:=20 Re: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>
>=20 John,
>         While strictly speaking WG drafts= =20 should only reflect current WG consensus, and it is the WG draft editor's j= ob to=20 ensure this, in practice authors/editors are given a lot of latitude in tim= ing /=20 ordering in introduction to changes.  I personally think this is a=20 practical way of keeping the process moving.  Also if the WG disagrees= with=20 a change, it can always be backed out.
>
> So, yes, the WG coul= d do=20 exactly as you say if it comes to it.  (The chairs can even appoint=20 different editor if needed, e.g., to make this
> happen.)  While= I'm=20 not happy with how this revision came about, as I covered in earlier mail, = my=20 feeling is to let the discussion take place on the list (and at the next IE= TF,=20 if needed) and then have the draft updated to reflect the WG=20 discussion/consensus.
>
> Lou
>
> On 8/16/2012 5:35= PM,=20 John E Drake wrote:
>> Lou,
>>
>> Since the WG d= id=20 not agree to this changes, let alone discuss them,
>> would it be= =20 possible to simply rollback these changes and ask the
>> authors t= o=20 write a draft addressing the topics you list in your email,
>>=20 below?
>>
>> Thanks,
>>
>>=20 John
>>
>> Sent from my=20 iPhone
>>
>>
>>> -----Original=20 Message-----
>>> From: ccamp-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org]=20 On
>>> Behalf Of Lou Berger
>>> Sent: Thursday, Aug= ust=20 16, 2012 2:10 PM
>>> To: Rakesh Gandhi (rgandhi)
>>>= ; Cc:=20 ccamp@ietf.org
>>> Subjec= t: Re:=20 [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>>=20 associated-lsp-04.txt
>>>
>>> Rakesh,
>>&g= t;=20      Such major changes (in scope and functionality) to WG d= rafts=20 are
>>> usually discussed with the WG prior to the authors/edit= ors=20 just
>>> publishing the changes.  But, this is a judgment = call=20 by the document
>>> editors in how, quoting rfc2418, they "ensu= r[e]=20 that the contents of
>>> the document accurately reflect the=20 decisions that have been made by
>>> the working=20 group."
>>>
>>> So let's jump into discussing the=20 changes.
>>>
>>> As I see it this draft introduces= =20 several major functional changes
>>> that have not been discuss= ed by=20 the WG.  Correct me if I get them
>>> wrong, but I believe= they=20 include:
>>> 1) Introduction of a second method for signaling=20 Co-routed LSPs
>>> 2) Support for FRR bypass tunnels for piggyb= acked=20 on the TP
>>> bidirectional LSP=20 mechanisms.
>>>
>>>    There are also oth= er=20 changes, but I'll defer discussing them
>>>    until = the=20 discussion on the above is concluded.
>>>
>>> Is th= is=20 correct?
>>>
>>> Assuming yes, I have questions abo= ut=20 both rational and specific
>>> mechanisms.  For now let's = look=20 at the former, so please:
>>>
>>> A) Articulate the= =20 issues/limitations with using the RFC3473 defined
>>> mechanism= s for=20 (co-routed) bidirectional LSPs that you'd like to see
>>>=20 addressed.
>>>
>>> B.1) Articulate the FRR/GMPLS-re= lated=20 issue you'd like to address?
>>>
>>> B.2) Articulat= e why=20 this issue should be solved in a TP-specific and
>>> not GMPLS= =20 generic fashion?
>>>
>>> Thanks,
>>>=20 Lou
>>>
>>> On 8/16/2012 4:26 PM, Rakesh Gandhi=20 (rgandhi) wrote:
>>>> Hi=20 Lou,
>>>>
>>>>=20 Yes.
>>>>
>>>> Please advise if you think det= ailed=20 email is required.
>>>> We believe latest draft summarizes t= he=20 changes well and we could
>>> start review/discussions from=20 there.
>>>>
>>>> Thanks,
>>>>= =20 Rakesh
>>>>
>>>>
>>>> -----Ori= ginal=20 Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> = Sent:=20 Thursday, August 16, 2012 4:00 PM
>>>> To: Rakesh Gandhi=20 (rgandhi)
>>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>>= >>=20 Subject: Re: [CCAMP] I-D Action:
>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;
>>>>=20 Rakesh,
>>>>     Is this the start of the thread t= hat I=20 requested in
>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729= .html
>>>>
>>>>=20 In particular, is it the response to:
>>>>> I'd like to a= sk=20 that someone (Rakesh, Fei, etc.) review each of the
>>>>>= =20 proposed change and the rational for each change (in one or=20 in
>>>>> separate e-mails). The WG discussion can then re= ally=20 begin on the
>>>>> proposed changes. (Which are quite=20 substantial both in scope and
>>>>>=20 implication.)
>>>>
>>>>=20 Lou
>>>>
>>>> On 8/16/2012 3:19 PM, Rakesh Ga= ndhi=20 (rgandhi) wrote:
>>>>> Hi=20 All,
>>>>>
>>>>> We have uploaded a new= =20 version of this draft with following=20 changes:
>>>>
>>>> 1.  Added a section o= n=20 Signaling of Co-routed LSPs
>>>>
>>>> 2.=20  Added clarification on Signaling of Associated=20 Bidirectional
>>>> Protection=20 LSPs
>>>>
>>>> 3.  Added a section on=20 Signaling of Auto-tunnel Mesh-group LSPs
>>>>
>>>= ;>=20 4.   Added clarification on Signaling of Inter-domain=20 Associated
>>> Bidirectional=20 LSPs
>>>>
>>>> 5.  The Extended ASSOCIAT= ION=20 object format with Association Type
>>> "Associated Bidirection= al=20 LSP". Clarified on how to populate
>>> different fields in this= =20 object.
>>>>
>>>>
>>>>> We= =20 believe that some of these changes were necessary to avoid the
>>&= gt;=20 interoperability issues due to potentially different=20 interpretations.
>>>>>
>>>>> Your revie= w=20 comments are welcome.
>>>>>
>>>>>=20 Thanks,
>>>>>=20 Rakesh
>>>>>
>>>>> -----Original=20 Message-----
>>>>> From: ccamp-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org]=20 On
>>>>> Behalf Of internet-drafts@ietf.org
&g= t;>>>>=20 Sent: Wednesday, August 15, 2012 10:53 AM
>>>>> To: i-d-announce@ietf.org
>>= >>>=20 Cc: ccamp@ietf.org
>>>>= ;>=20 Subject: [CCAMP] I-D Action:
>>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;>
>>>>>
>>>>>=20 A New Internet-Draft is available from the on-line=20 Internet-Drafts
>>> directories.
>>>>>  = This=20 draft is a work item of the Common Control and Measurement
>>> = Plane=20 Working Group of the IETF.
>>>>>
>>>>>= =20    Title           : RSVP-TE Extensions = for=20 Associated Bidirectional
>>> LSPs
>>>>>  = ;=20  Author(s)       : Fei Zhang
>>>>> &n= bsp;=20                      = ;=20   Ruiquan Jing
>>>>>         &nb= sp;=20                 Rakesh=20 Gandhi
>>>>>    Filename      =20  : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-
>>>=20 lsp-04.txt
>>>>>    Pages      = =20     : 17
>>>>>    Date    = =20        :=20 2012-08-15
>>>>>
>>>>>=20 Abstract:
>>>>>    The MPLS Transport Profile=20 (MPLS-TP) requirements document
>>>=20 [RFC5654],
>>>>>    describes that MPLS-TP MUST= =20 support associated bidirectional
>>> point-
>>>>= >=20    to-point LSPs.
>>>>>
>>>>>= =20    This document provides a method to bind two unidirectional=20 Label
>>>>>    Switched Paths (LSPs) into an=20 associated bidirectional LSP.  The
>>>>>  =20  association is achieved by defining the new Association Type=20 in
>>> the
>>>>>    Extended ASSOCI= ATION=20 object.
>>>>>
>>>>>
>>>>= >=20 The IETF datatracker status page for this draft is:
>>>>>= https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-r= svpte-
>>>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp
>>>>>
>>>>> There's also = a=20 htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-= ext-
>>>=20 associ
>>>>> a
>>>>>=20 ted-lsp-04
>>>>>
>>>>> A diff from the= =20 previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp= -rsvpte-
>>>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp-04
>>>>>
>>>>>
>>= ;>>>=20 Internet-Drafts are also available by anonymous FTP at:
>>>>= >=20 ftp://ftp.ietf.org/internet-drafts/
>>>>= >
>>>>>=20 _______________________________________________
>>>>> CCA= MP=20 mailing list
>>>>> CCAMP@ietf.org
>>>>> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ccamp"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ccamp
>>= >>>
>>>>>
>>>>>
>>>= ;>>
>>>>
>>>>
>>>>
&g= t;>>>
>>>=20 _______________________________________________
>>> CCAMP maili= ng=20 list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>=
>>
>>
>>
>=20 _______________________________________________
> CCAMP mailing=20 list
> CCAMP@ietf.org
> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ccamp"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ccamp
________= _______________________________________
CCAMP=20 mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp<= /P>

 

--_000_FE60A4E52763E84B935532D7D9294FF139268CC01FEUSAACMS0715e_-- From jdrake@juniper.net Fri Aug 17 14:37:09 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC2321E8063 for ; Fri, 17 Aug 2012 14:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.731 X-Spam-Level: X-Spam-Status: No, score=-5.731 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hd0GrGEKLBWg for ; Fri, 17 Aug 2012 14:37:05 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8875021E805F for ; Fri, 17 Aug 2012 14:37:04 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUC65fMguJAdig2M7bztb8BsA3HYGmU/o@postini.com; Fri, 17 Aug 2012 14:37:04 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 17 Aug 2012 14:33:44 -0700 From: John E Drake To: David Allan I , Gregory Mirsky , Greg Mirsky , Francesco Fondelli Date: Fri, 17 Aug 2012 14:33:43 -0700 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac18rlwA4D2YlfZKRGCBpFI+2JZEwgABuVOAAAA1SUAAAN63wAAAvlnAAAAigwAAAF8JMAAANN2g Message-ID: <5E893DB832F57341992548CDBB333163A631A84F26@EMBX01-HQ.jnpr.net> References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <5E893DB832F57341992548CDBB333163A631A84E31@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84E97@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84EF3@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD5668113046@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5668113046@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A631A84F26EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 21:37:09 -0000 --_000_5E893DB832F57341992548CDBB333163A631A84F26EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, Utility in what sense and are we dealing with an observation or an assertio= n? Thanks, John Sent from my iPhone From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Friday, August 17, 2012 2:25 PM To: John E Drake; Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt I think the observation is that coordinated has the most utility in co-rout= ed, and independent has more utility for associated. This is not actually m= andated, but true nontheless... Dave ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of John E Drake Sent: Friday, August 17, 2012 2:20 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, For both modes there is bidirectional flow of control packets. For Indepen= dent mode the CC/CV packets flow in only one direction. There never was a coupling between modes and associated/co-routed and if yo= u can point me to any text that says the contrary I would appreciate it as = a bis to remove that text would be required. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 2:12 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, in independent mode CC/CV control messages been sent only in one direction.= Thus there are two CC/CV sessions - one for each independently monitored d= irection. That, AFAIK, was intentional. Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 1:50 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, That certainly wasn't the intent. With a bidirectional LSP of either type = you have one forward and one return path and BFD does not care whether they= are congruent. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 1:28 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, I think that bi-directional associated p2p LSP, regardless of how many comm= on LSRs forward and reverse directions have, implies use of independent mod= e of RFC 6428, then there will be two sessions to monitor each direction in= dependently. Coordinated mode of RFC 6428, in my understanding, applies to = bidirectional co-routed p2p LSP. Regards, Greg ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of John E Drake Sent: Friday, August 17, 2012 1:19 PM To: Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, According to RFC 6428 the is one CC/CV/RDI session irregardless of whether = the bi-directional packet LSP is co-routed or associated. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky Sent: Friday, August 17, 2012 12:27 PM To: Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi Francesco, "from a data-plane view point b) and c2) are the same thing" I think that given that c) is associated bi-directional LSP that implies in= dependent OAM and protection for each direction, b) and c2) are not the sam= e in the data plane view. E.g., there will be single CC/CV/RDI session for = b) while c2) will have two sessions. And if linear protection requested, b)= will be protected by single bi-directional LSP, but c2) - by two unidirect= ional LSPs. Regards, Greg On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: Hi All, I think I'm lost, please help. Rakesh is talking about "co-routed associated bidirectional LSP"... for the sake of clarity, let me try to categorize LSPs from a control plane view point: a) Point-to-point unidirectional b) Point-to-point co-routed bidirectional c) Point-to-point associated bidirectional c1) fwd and rev LSP follow different paths c2) fwd and rev LSP follow same path d) Point-to-multipoint unidirectional e) Multipoint-to-point unidirectional Is section 3.2.5 (Signaling of Co-routed LSPs) of mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? In my opinion: - b) should be signaled with 3473 - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) Am I missing something? thank you ciao fra PS from a data-plane view point b) and c2) are the same thing. On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: > Hi Lou, > > Thanks for initiating discussions on the changes in the draft. > > Agree with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can alwa= ys submit a new draft just for that. We respect your/WG decision. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 6:08 PM > To: John E Drake > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The chai= rs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I cov= ered in earlier mail, my feeling is to let the discussion take place on the= list (and at the next IETF, if needed) and then have the draft updated to = reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your email, >> below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:cca= mp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes >>> that have not been discussed by the WG. Correct me if I get them >>> wrong, but I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate >>> different fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_5E893DB832F57341992548CDBB333163A631A84F26EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

 

<= p class=3DMsoNormal>Utility in what sense and are we dealing with an= observation or an assertion?

 

Thanks,

 

John

 

Sent from my= iPhone

 <= /o:p>

From: David Allan I= [mailto:david.i.allan@ericsson.com]
Sent: Friday, August 17, 20= 12 2:25 PM
To: John E Drake; Gregory Mirsky; Greg Mirsky; Frances= co Fondelli
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D= Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

 

I think the observation is that coordinated has the mos= t utility in co-routed, and independent has more utility for associated. Th= is is not actually mandated, but true nontheless...

 

Dave

 <= /o:p>

=

From: cca= mp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On Behalf Of John E Drake
Sent:= Friday, August 17, 2012 2:20 PM
To: Gregory Mirsky; Greg Mirsky;= Francesco Fondelli
Cc: ccamp@i= etf.org
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpl= s-tp-rsvpte-ext-associated-lsp-04.txt

Greg,

&nb= sp;

For both modes there is bid= irectional flow of control packets.  For Independent mode the CC/CV pa= ckets flow in only one direction.

 

There never= was a coupling between modes and associated/co-routed and if you can point= me to any text that says the contrary I would appreciate it as a bis to re= move that text would be required.

 

Thanks,

 

<= p class=3DMsoNormal>John

=  

Sent fr= om my iPhone

&n= bsp;

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Gregory = Mirsky [mailto:gregory.mirsk= y@ericsson.com]
Sent: Friday, August 17, 2012 2:12 PM
= To: John E Drake; Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [CCAMP= ] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

 

Hi John,

in= independent mode CC/CV control messages been sent only in one direction. T= hus there are two CC/CV sessions - one for each independently monitored dir= ection. That, AFAIK, was intentional.

 

    Regards= ,

     &= nbsp;  Greg

 

From: John E Drake [mailto:jdrake@juniper.net]
Sent: Friday, August 17, 2= 012 1:50 PM
To: Gregory Mirsky; Greg Mirsky; Francesco FondelliCc: ccamp@ietf.org
Sub= ject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-assoc= iated-lsp-04.txt

Greg,

 

<= p class=3DMsoNormal>That certainly wasn’t the intent.  Wi= th a bidirectional LSP of either type you have one forward and one return p= ath and BFD does not care whether they are congruent.

=

 

Thanks,

&nbs= p;

John

 

Sent from my iPhone

 

From: Gregory Mirsky [m= ailto:gregory.mirsky@ericsson.com]
Sent: Friday, August 17, = 2012 1:28 PM
To: John E Drake; Greg Mirsky; Francesco FondelliCc: ccamp@ietf.org
Subj= ect: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt

=  

Hi John,

I think that bi-directional associated p2p LSP, regar= dless of how many common LSRs forward and reverse directions have, imp= lies use of independent mode of RFC 6428, then there will be two sessions t= o monitor each direction independently. Coordinated mode of RFC 6428, in my= understanding, applies to bidirectional co-routed p2p LSP.

 

 =    Regards,

 &nb= sp;      Greg

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of John E D= rake
Sent: Friday, August 17, 2012 1:19 PM
To: Greg Mir= sky; Francesco Fondelli
Cc: cca= mp@ietf.org
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp= -mpls-tp-rsvpte-ext-associated-lsp-04.txt

Greg,

 

According to RFC 6428 t= he is one CC/CV/RDI session irregardless of whether the bi-directional pack= et LSP is co-routed or associated.

 

Thanks,

 

=

John

=  

Sent from my= iPhone

 <= /span>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G= reg Mirsky
Sent: Friday, August 17, 2012 12:27 PM
To: F= rancesco Fondelli
Cc: ccamp@iet= f.org
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-= tp-rsvpte-ext-associated-lsp-04.txt

 

Hi Francesco,
"from a data-plane view point b) and c2)= are the same thing"
I think that given that c) is associated bi-di= rectional LSP that implies independent OAM and protection for each directio= n, b) and c2) are not the same in the data plane view. E.g., there will be = single CC/CV/RDI session for b) while c2) will have two sessions. And if li= near protection requested, b) will be protected by single bi-directional LS= P, but c2) - by two unidirectional LSPs.

Regards,
Greg=

On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fo= ndelli <francesco.fondelli@gmail.com> wrote:

Hi All,

I think I'm lost, please help.

Rakesh is talkin= g about "co-routed associated bidirectional
LSP"... for the sa= ke of clarity, let me try to categorize
LSPs from a control plane view p= oint:

  a) Point-to-point unidirectional
  b) Point-to-= point co-routed bidirectional
  c) Point-to-point associated bidire= ctional
   c1) fwd and rev LSP follow different paths
 = ;  c2) fwd and rev LSP follow same path
  d) Point-to-multipoi= nt unidirectional
  e) Multipoint-to-point unidirectional

Is= section 3.2.5 (Signaling of Co-routed LSPs) of
mpls-tp-rsvpte-ext-assoc= iated-lsp about b) or it is about c2)?

In my opinion:

- b) sh= ould be signaled with 3473
- c) are addressed by this I-D (mpls-tp-rsvpt= e-ext-associated-lsp)

Am I missing something?

thank you
ci= ao
fra

PS
from a data-plane view point b) and c2) are the same= thing.


On Fri, Aug 17, 20= 12 at 12:16 AM, Rakesh Gandhi (rgandhi)
<rgandhi@cisco.com> wrote:
> Hi Lou,
>
> T= hanks for initiating discussions on the changes in the draft.
>
&g= t; Agree with you here, if we/WG do not agree on the "co-routed associ= ated bidirectional LSP" part, we are ok to remove it from this draft a= nd can always submit a new draft just for that. We respect your/WG decision= .
>
> Thanks,
> Rakesh
>
>
>
> --= ---Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Thursday, August 16,= 2012 6:08 PM
> To: John E Drake
> Cc: Rakesh Gandhi (rgandhi);= ccamp@ietf.org
> Subject: Re: = [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.t= xt
>
> John,
>         While strictly= speaking WG drafts should only reflect current WG consensus, and it is the= WG draft editor's job to ensure this, in practice authors/editors are give= n a lot of latitude in timing / ordering in introduction to changes.  = I personally think this is a practical way of keeping the process moving. &= nbsp;Also if the WG disagrees with a change, it can always be backed out.>
> So, yes, the WG could do exactly as you say if it comes to i= t.  (The chairs can even appoint different editor if needed, e.g., to = make this
> happen.)  While I'm not happy with how this revision= came about, as I covered in earlier mail, my feeling is to let the discuss= ion take place on the list (and at the next IETF, if needed) and then have = the draft updated to reflect the WG discussion/consensus.
>
> L= ou
>
> On 8/16/2012 5:35 PM, John E Drake wrote:
>> Lo= u,
>>
>> Since the WG did not agree to this changes, let = alone discuss them,
>> would it be possible to simply rollback the= se changes and ask the
>> authors to write a draft addressing the = topics you list in your email,
>> below?
>>
>> T= hanks,
>>
>> John
>>
>> Sent from my iP= hone
>>
>>
>>> -----Original Message-----
= >>> From: ccamp-bounces@= ietf.org [mailto:ccamp-bounce= s@ietf.org] On
>>> Behalf Of Lou Berger
>>> Sen= t: Thursday, August 16, 2012 2:10 PM
>>> To: Rakesh Gandhi (rga= ndhi)
>>> Cc: ccamp@ietf.org<= /a>
>>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-= tp-rsvpte-ext-
>>> associated-lsp-04.txt
>>>
>= ;>> Rakesh,
>>>      Such major changes (i= n scope and functionality) to WG drafts are
>>> usually discuss= ed with the WG prior to the authors/editors just
>>> publishing= the changes.  But, this is a judgment call by the document
>>= ;> editors in how, quoting rfc2418, they "ensur[e] that the content= s of
>>> the document accurately reflect the decisions that hav= e been made by
>>> the working group."
>>>
= >>> So let's jump into discussing the changes.
>>>
= >>> As I see it this draft introduces several major functional cha= nges
>>> that have not been discussed by the WG.  Correct = me if I get them
>>> wrong, but I believe they include:
>= >> 1) Introduction of a second method for signaling Co-routed LSPs>>> 2) Support for FRR bypass tunnels for piggybacked on the TP>>> bidirectional LSP mechanisms.
>>>
>>>= ;    There are also other changes, but I'll defer discussing them=
>>>    until the discussion on the above is conclude= d.
>>>
>>> Is this correct?
>>>
>= >> Assuming yes, I have questions about both rational and specific>>> mechanisms.  For now let's look at the former, so please= :
>>>
>>> A) Articulate the issues/limitations with= using the RFC3473 defined
>>> mechanisms for (co-routed) bidir= ectional LSPs that you'd like to see
>>> addressed.
>>= >
>>> B.1) Articulate the FRR/GMPLS-related issue you'd like= to address?
>>>
>>> B.2) Articulate why this issue= should be solved in a TP-specific and
>>> not GMPLS generic fa= shion?
>>>
>>> Thanks,
>>> Lou
>&= gt;>
>>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote= :
>>>> Hi Lou,
>>>>
>>>> Yes.<= br>>>>>
>>>> Please advise if you think detailed= email is required.
>>>> We believe latest draft summarizes = the changes well and we could
>>> start review/discussions from= there.
>>>>
>>>> Thanks,
>>>>= Rakesh
>>>>
>>>>
>>>> -----Or= iginal Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: T= hursday, August 16, 2012 4:00 PM
>>>> To: Rakesh Gandhi (rga= ndhi)
>>>> Cc: ccamp@ietf.= org; zhang.fei3@zte.com.cn=
>>>> Subject: Re: [CCAMP] I-D Action:
>>>> d= raft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>= ;
>>>> Rakesh,
>>>>     Is this the= start of the thread that I requested in
>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html<= br>>>>>
>>>> In particular, is it the response t= o:
>>>>> I'd like to ask that someone (Rakesh, Fei, etc.)= review each of the
>>>>> proposed change and the rationa= l for each change (in one or in
>>>>> separate e-mails). = The WG discussion can then really begin on the
>>>>> prop= osed changes. (Which are quite substantial both in scope and
>>>= ;>> implication.)
>>>>
>>>> Lou
>= >>>
>>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgand= hi) wrote:
>>>>> Hi All,
>>>>>
>&= gt;>>> We have uploaded a new version of this draft with following= changes:
>>>>
>>>> 1.  Added a section = on Signaling of Co-routed LSPs
>>>>
>>>> 2. &= nbsp;Added clarification on Signaling of Associated Bidirectional
>&g= t;>> Protection LSPs
>>>>
>>>> 3.  = ;Added a section on Signaling of Auto-tunnel Mesh-group LSPs
>>>= ;>
>>>> 4.   Added clarification on Signaling of Int= er-domain Associated
>>> Bidirectional LSPs
>>>>=
>>>> 5.  The Extended ASSOCIATION object format with A= ssociation Type
>>> "Associated Bidirectional LSP". C= larified on how to populate
>>> different fields in this object= .
>>>>
>>>>
>>>>> We believ= e that some of these changes were necessary to avoid the
>>> in= teroperability issues due to potentially different interpretations.
>= >>>>
>>>>> Your review comments are welcome.<= br>>>>>>
>>>>> Thanks,
>>>>= > Rakesh
>>>>>
>>>>> -----Original M= essage-----
>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>>>>> Behalf Of= internet-drafts@ietf.org>>>>> Sent: Wednesday, August 15, 2012 10:53 AM
>>= ;>>> To: i-d-announce@iet= f.org
>>>>> Cc: cca= mp@ietf.org
>>>>> Subject: [CCAMP] I-D Action:
>= ;>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=
>>>>>
>>>>>
>>>>> A = New Internet-Draft is available from the on-line Internet-Drafts
>>= ;> directories.
>>>>>  This draft is a work item = of the Common Control and Measurement
>>> Plane Working Group o= f the IETF.
>>>>>
>>>>>    Ti= tle           : RSVP-TE Extensions for Associated = Bidirectional
>>> LSPs
>>>>>    Aut= hor(s)       : Fei Zhang
>>>>>   &nbs= p;                     &n= bsp; Ruiquan Jing
>>>>>          = ;                 Rakesh Gandhi
= >>>>>    Filename        : dra= ft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-
>>> lsp-04.txt
= >>>>>    Pages           = : 17
>>>>>    Date         =    : 2012-08-15
>>>>>
>>>>> A= bstract:
>>>>>    The MPLS Transport Profile (M= PLS-TP) requirements document
>>> [RFC5654],
>>>>= ;>    describes that MPLS-TP MUST support associated bidirecti= onal
>>> point-
>>>>>    to-point L= SPs.
>>>>>
>>>>>    This docu= ment provides a method to bind two unidirectional Label
>>>>= >    Switched Paths (LSPs) into an associated bidirectional LS= P.  The
>>>>>    association is achieved b= y defining the new Association Type in
>>> the
>>>&= gt;>    Extended ASSOCIATION object.
>>>>>>>>>>
>>>>> The IETF datatracker status = page for this draft is:
>>>>> https:= //datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-
>>= > ext-
>>>>> a
>>>>> ssociated-lsp>>>>>
>>>>> There's also a htmlized vers= ion available at:
>>>>> http://tools.i= etf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>> assoc= i
>>>>> a
>>>>> ted-lsp-04
>>&= gt;>>
>>>>> A diff from the previous version is ava= ilable at:
>>>>> http://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte-
>>> ext-=
>>>>> a
>>>>> ssociated-lsp-04
>= >>>>
>>>>>
>>>>> Internet-D= rafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf= .org/internet-drafts/
>>>>>
>>>>> _= ______________________________________________
>>>>> CCAM= P mailing list
>>>>> CC= AMP@ietf.org
>>>>> https://www.ietf.org/mailman/listin= fo/ccamp
>>>>>
>>>>>
>>>= ;>>
>>>>>
>>>>
>>>>>>>>
>>>>
>>> ____________________= ___________________________
>>> CCAMP mailing list
>>&= gt; CCAMP@ietf.org
>>> htt= ps://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>= ;>
>>
> _______________________________________________> CCAMP mailing list
> CCAMP@i= etf.org
> https://www.ietf.org/mailman/listinfo/ccamp
_____= __________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailma= n/listinfo/ccamp

<= o:p> 

= --_000_5E893DB832F57341992548CDBB333163A631A84F26EMBX01HQjnprn_-- From david.i.allan@ericsson.com Fri Aug 17 14:48:55 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AE311E80E2 for ; Fri, 17 Aug 2012 14:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40o-hhQ11FfI for ; Fri, 17 Aug 2012 14:48:50 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB9F11E80D1 for ; Fri, 17 Aug 2012 14:48:49 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q7HLnCkB031740; Fri, 17 Aug 2012 16:49:26 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 17 Aug 2012 17:48:30 -0400 From: David Allan I To: John E Drake , Gregory Mirsky , Greg Mirsky , Francesco Fondelli Date: Fri, 17 Aug 2012 17:48:29 -0400 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac18rlwA4D2YlfZKRGCBpFI+2JZEwgABuVOAAAA1SUAAAN63wAAAvlnAAAAigwAAAF8JMAAANN2gAABdnlA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD5668113079@EUSAACMS0703.eamcs.ericsson.se> References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <5E893DB832F57341992548CDBB333163A631A84E31@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84E97@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84EF3@EMBX01-HQ.jnpr.net> <60C093A41B5E45409A19D42CF7786DFD5668113046@EUSAACMS0703.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A631A84F26@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A631A84F26@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD5668113079EUSAACMS0703e_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 21:48:55 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD5668113079EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK, assertion it is.... If I am on a co-routed path, and I have a bi-directional failure, they are = effectively coordinated. If I have a unidirectional failure it is best to take one hit and switch bo= th directions at the time of failure as some common component in the path n= eeds to be serviced. On that basis many operators would want coordinated mo= de for co-routed. That is not necessarily true for bi-directional associated. Coordinated mod= e is desirable if what the pair of LSPs is carrying will escalate a unidire= ctional fault to bi-directional anyway (e.g. a router adjacency), but not a= ll associated bi-directional LSPs carry router adjacencies. my 2 cents Dave ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 2:34 PM To: David Allan I; Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Dave, Utility in what sense and are we dealing with an observation or an assertio= n? Thanks, John Sent from my iPhone From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Friday, August 17, 2012 2:25 PM To: John E Drake; Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt I think the observation is that coordinated has the most utility in co-rout= ed, and independent has more utility for associated. This is not actually m= andated, but true nontheless... Dave ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of John E Drake Sent: Friday, August 17, 2012 2:20 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, For both modes there is bidirectional flow of control packets. For Indepen= dent mode the CC/CV packets flow in only one direction. There never was a coupling between modes and associated/co-routed and if yo= u can point me to any text that says the contrary I would appreciate it as = a bis to remove that text would be required. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 2:12 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, in independent mode CC/CV control messages been sent only in one direction.= Thus there are two CC/CV sessions - one for each independently monitored d= irection. That, AFAIK, was intentional. Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 1:50 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, That certainly wasn't the intent. With a bidirectional LSP of either type = you have one forward and one return path and BFD does not care whether they= are congruent. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 1:28 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, I think that bi-directional associated p2p LSP, regardless of how many comm= on LSRs forward and reverse directions have, implies use of independent mod= e of RFC 6428, then there will be two sessions to monitor each direction in= dependently. Coordinated mode of RFC 6428, in my understanding, applies to = bidirectional co-routed p2p LSP. Regards, Greg ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of John E Drake Sent: Friday, August 17, 2012 1:19 PM To: Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, According to RFC 6428 the is one CC/CV/RDI session irregardless of whether = the bi-directional packet LSP is co-routed or associated. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky Sent: Friday, August 17, 2012 12:27 PM To: Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi Francesco, "from a data-plane view point b) and c2) are the same thing" I think that given that c) is associated bi-directional LSP that implies in= dependent OAM and protection for each direction, b) and c2) are not the sam= e in the data plane view. E.g., there will be single CC/CV/RDI session for = b) while c2) will have two sessions. And if linear protection requested, b)= will be protected by single bi-directional LSP, but c2) - by two unidirect= ional LSPs. Regards, Greg On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: Hi All, I think I'm lost, please help. Rakesh is talking about "co-routed associated bidirectional LSP"... for the sake of clarity, let me try to categorize LSPs from a control plane view point: a) Point-to-point unidirectional b) Point-to-point co-routed bidirectional c) Point-to-point associated bidirectional c1) fwd and rev LSP follow different paths c2) fwd and rev LSP follow same path d) Point-to-multipoint unidirectional e) Multipoint-to-point unidirectional Is section 3.2.5 (Signaling of Co-routed LSPs) of mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? In my opinion: - b) should be signaled with 3473 - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) Am I missing something? thank you ciao fra PS from a data-plane view point b) and c2) are the same thing. On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: > Hi Lou, > > Thanks for initiating discussions on the changes in the draft. > > Agree with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can alwa= ys submit a new draft just for that. We respect your/WG decision. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 6:08 PM > To: John E Drake > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The chai= rs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I cov= ered in earlier mail, my feeling is to let the discussion take place on the= list (and at the next IETF, if needed) and then have the draft updated to = reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your email, >> below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:cca= mp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes >>> that have not been discussed by the WG. Correct me if I get them >>> wrong, but I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate >>> different fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_60C093A41B5E45409A19D42CF7786DFD5668113079EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
OK,=20 assertion it is....
 
If I=20 am on a co-routed path, and I have a bi-directional failure, they are=20 effectively coordinated.
If I=20 have a unidirectional failure it is best to take one hit and switch both=20 directions at the time of failure as some common component in the= path=20 needs to be serviced. On that basis many operators would want coordinated m= ode=20 for co-routed.
 
That=20 is not necessarily true for bi-directional associated. Coordinated mode is= =20 desirable if what the pair of LSPs is carrying will escalate a=20 unidirectional fault to bi-directional anyway (e.g. a router adjacency= ),=20 but not all associated bi-directional LSPs carry router=20 adjacencies.
 
my 2=20 cents
Dave

From: John E Drake [mailto:jdrake@junip= er.net]=20
Sent: Friday, August 17, 2012 2:34 PM
To: David Allan = I;=20 Gregory Mirsky; Greg Mirsky; Francesco Fondelli
Cc:=20 ccamp@ietf.org
Subject: RE: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Dave,

 

Utility=20 in what sense and are we dealing with an observation or an=20 assertion?

 

Thanks,

 

John

 

Sent=20 from my iPhone

 

From:<= /B> David Allan = I=20 [mailto:david.i.allan@ericsson.com]
Sent: Friday, August 17, 201= 2=20 2:25 PM
To: John E Drake; Gregory Mirsky; Greg Mirsky; Francesco= =20 Fondelli
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D Ac= tion:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

I= think=20 the observation is that coordinated has the most utility in co-routed, and= =20 independent has more utility for associated. This is not actually mandated,= but=20 true nontheless...

 

D= ave

 

From:<= /B> ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <= B>On=20 Behalf Of John E Drake
Sent: Friday, August 17, 2012 2:20=20 PM
To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli
Cc:<= /B>=20 ccamp@ietf.org
Subject: Re:= =20 [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

Greg,

 

For=20 both modes there is bidirectional flow of control packets.  For Indepe= ndent=20 mode the CC/CV packets flow in only one direction.

 

There=20 never was a coupling between modes and associated/co-routed and if you can = point=20 me to any text that says the contrary I would appreciate it as a bis to rem= ove=20 that text would be required.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B> Gregory Mirs= ky [mailto:gregory.mirsky@ericsson.= com]=20
Sent: Friday, August 17, 2012 2:12 PM
To: John E Drake= ;=20 Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

H= i=20 John,

i= n=20 independent mode CC/CV control messages been sent only in one direction. Th= us=20 there are two CC/CV sessions - one for each independently monitored directi= on.=20 That, AFAIK, was intentional.

 

    R= egards,

        G= reg

 

From:<= /B> John E Drake= [mailto:jdrake@juniper.net]
Se= nt:=20 Friday, August 17, 2012 1:50 PM
To: Gregory Mirsky; Greg Mirsky;= =20 Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

Greg,

 

That=20 certainly wasn’t the intent.  With a bidirectional LSP of either= type you=20 have one forward and one return path and BFD does not care whether they are= =20 congruent.

 

Thanks,

 

John

 

Sent=20 from my iPhone

 

From:<= /B> Gregory Mirs= ky [mailto:gregory.mirsky@ericsson.= com]=20
Sent: Friday, August 17, 2012 1:28 PM
To: John E Drake= ;=20 Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

H= i=20 John,

I= think=20 that bi-directional associated p2p LSP, regardless of how many common = LSRs=20 forward and reverse directions have, implies use of independent mode o= f RFC=20 6428, then there will be two sessions to monitor each direction independent= ly.=20 Coordinated mode of RFC 6428, in my understanding, applies to bidirectional= =20 co-routed p2p LSP.

 

    R= egards,

        G= reg

 

From:<= /B> ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <= B>On=20 Behalf Of John E Drake
Sent: Friday, August 17, 2012 1:19=20 PM
To: Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: Re: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

Greg,

 

According=20 to RFC 6428 the is one CC/CV/RDI session irregardless of whether the=20 bi-directional packet LSP is co-routed or associated.

 

Thanks,

 

John

 

Sent=20 from my iPhone

 

From:<= /B> ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <= B>On=20 Behalf Of Greg Mirsky
Sent: Friday, August 17, 2012 12:27=20 PM
To: Francesco Fondelli
Cc: ccamp@ietf.org
Subject: Re: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

Hi Francesco,
"from a= =20 data-plane view point b) and c2) are the same thing"
I think that given = that=20 c) is associated bi-directional LSP that implies independent OAM and protec= tion=20 for each direction, b) and c2) are not the same in the data plane view. E.g= .,=20 there will be single CC/CV/RDI session for b) while c2) will have two sessi= ons.=20 And if linear protection requested, b) will be protected by single=20 bi-directional LSP, but c2) - by two unidirectional=20 LSPs.

Regards,
Greg

On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli &l= t;francesco.fondelli@gmail.com> wrote:

Hi All,

I think I'm lost, please help.

R= akesh=20 is talking about "co-routed associated bidirectional
LSP"... for the sak= e of=20 clarity, let me try to categorize
LSPs from a control plane view=20 point:

  a) Point-to-point unidirectional
  b)=20 Point-to-point co-routed bidirectional
  c) Point-to-point associat= ed=20 bidirectional
   c1) fwd and rev LSP follow different=20 paths
   c2) fwd and rev LSP follow same path
  d)=20 Point-to-multipoint unidirectional
  e) Multipoint-to-point=20 unidirectional

Is section 3.2.5 (Signaling of Co-routed LSPs)=20 of
mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)?
In=20 my opinion:

- b) should be signaled with 3473
- c) are addressed = by=20 this I-D (mpls-tp-rsvpte-ext-associated-lsp)

Am I missing=20 something?

thank you
ciao
fra

PS
from a data-plane v= iew=20 point b) and c2) are the same thing.


On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi=20 (rgandhi)
<rgandhi@cisco.com= >=20 wrote:
> Hi Lou,
>
> Thanks for initiating discussions on= the=20 changes in the draft.
>
> Agree with you here, if we/WG do not = agree=20 on the "co-routed associated bidirectional LSP" part, we are ok to remove i= t=20 from this draft and can always submit a new draft just for that. We respect= =20 your/WG decision.
>
> Thanks,
>=20 Rakesh
>
>
>
> -----Original Message-----
> F= rom:=20 Lou Berger [mailto:lberger@labn.net]
> Sent: Thursd= ay,=20 August 16, 2012 6:08 PM
> To: John E Drake
> Cc: Rakesh Gandhi= =20 (rgandhi); ccamp@ietf.org
> Sub= ject:=20 Re: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>
>=20 John,
>         While strictly speaking WG drafts= =20 should only reflect current WG consensus, and it is the WG draft editor's j= ob to=20 ensure this, in practice authors/editors are given a lot of latitude in tim= ing /=20 ordering in introduction to changes.  I personally think this is a=20 practical way of keeping the process moving.  Also if the WG disagrees= with=20 a change, it can always be backed out.
>
> So, yes, the WG coul= d do=20 exactly as you say if it comes to it.  (The chairs can even appoint=20 different editor if needed, e.g., to make this
> happen.)  While= I'm=20 not happy with how this revision came about, as I covered in earlier mail, = my=20 feeling is to let the discussion take place on the list (and at the next IE= TF,=20 if needed) and then have the draft updated to reflect the WG=20 discussion/consensus.
>
> Lou
>
> On 8/16/2012 5:35= PM,=20 John E Drake wrote:
>> Lou,
>>
>> Since the WG d= id=20 not agree to this changes, let alone discuss them,
>> would it be= =20 possible to simply rollback these changes and ask the
>> authors t= o=20 write a draft addressing the topics you list in your email,
>>=20 below?
>>
>> Thanks,
>>
>>=20 John
>>
>> Sent from my=20 iPhone
>>
>>
>>> -----Original=20 Message-----
>>> From: ccamp-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org]=20 On
>>> Behalf Of Lou Berger
>>> Sent: Thursday, Aug= ust=20 16, 2012 2:10 PM
>>> To: Rakesh Gandhi (rgandhi)
>>>= ; Cc:=20 ccamp@ietf.org
>>> Subjec= t: Re:=20 [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>>=20 associated-lsp-04.txt
>>>
>>> Rakesh,
>>&g= t;=20      Such major changes (in scope and functionality) to WG d= rafts=20 are
>>> usually discussed with the WG prior to the authors/edit= ors=20 just
>>> publishing the changes.  But, this is a judgment = call=20 by the document
>>> editors in how, quoting rfc2418, they "ensu= r[e]=20 that the contents of
>>> the document accurately reflect the=20 decisions that have been made by
>>> the working=20 group."
>>>
>>> So let's jump into discussing the=20 changes.
>>>
>>> As I see it this draft introduces= =20 several major functional changes
>>> that have not been discuss= ed by=20 the WG.  Correct me if I get them
>>> wrong, but I believe= they=20 include:
>>> 1) Introduction of a second method for signaling=20 Co-routed LSPs
>>> 2) Support for FRR bypass tunnels for piggyb= acked=20 on the TP
>>> bidirectional LSP=20 mechanisms.
>>>
>>>    There are also oth= er=20 changes, but I'll defer discussing them
>>>    until = the=20 discussion on the above is concluded.
>>>
>>> Is th= is=20 correct?
>>>
>>> Assuming yes, I have questions abo= ut=20 both rational and specific
>>> mechanisms.  For now let's = look=20 at the former, so please:
>>>
>>> A) Articulate the= =20 issues/limitations with using the RFC3473 defined
>>> mechanism= s for=20 (co-routed) bidirectional LSPs that you'd like to see
>>>=20 addressed.
>>>
>>> B.1) Articulate the FRR/GMPLS-re= lated=20 issue you'd like to address?
>>>
>>> B.2) Articulat= e why=20 this issue should be solved in a TP-specific and
>>> not GMPLS= =20 generic fashion?
>>>
>>> Thanks,
>>>=20 Lou
>>>
>>> On 8/16/2012 4:26 PM, Rakesh Gandhi=20 (rgandhi) wrote:
>>>> Hi=20 Lou,
>>>>
>>>>=20 Yes.
>>>>
>>>> Please advise if you think det= ailed=20 email is required.
>>>> We believe latest draft summarizes t= he=20 changes well and we could
>>> start review/discussions from=20 there.
>>>>
>>>> Thanks,
>>>>= =20 Rakesh
>>>>
>>>>
>>>> -----Ori= ginal=20 Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> = Sent:=20 Thursday, August 16, 2012 4:00 PM
>>>> To: Rakesh Gandhi=20 (rgandhi)
>>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>>= >>=20 Subject: Re: [CCAMP] I-D Action:
>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;
>>>>=20 Rakesh,
>>>>     Is this the start of the thread t= hat I=20 requested in
>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729= .html
>>>>
>>>>=20 In particular, is it the response to:
>>>>> I'd like to a= sk=20 that someone (Rakesh, Fei, etc.) review each of the
>>>>>= =20 proposed change and the rational for each change (in one or=20 in
>>>>> separate e-mails). The WG discussion can then re= ally=20 begin on the
>>>>> proposed changes. (Which are quite=20 substantial both in scope and
>>>>>=20 implication.)
>>>>
>>>>=20 Lou
>>>>
>>>> On 8/16/2012 3:19 PM, Rakesh Ga= ndhi=20 (rgandhi) wrote:
>>>>> Hi=20 All,
>>>>>
>>>>> We have uploaded a new= =20 version of this draft with following=20 changes:
>>>>
>>>> 1.  Added a section o= n=20 Signaling of Co-routed LSPs
>>>>
>>>> 2.=20  Added clarification on Signaling of Associated=20 Bidirectional
>>>> Protection=20 LSPs
>>>>
>>>> 3.  Added a section on=20 Signaling of Auto-tunnel Mesh-group LSPs
>>>>
>>>= ;>=20 4.   Added clarification on Signaling of Inter-domain=20 Associated
>>> Bidirectional=20 LSPs
>>>>
>>>> 5.  The Extended ASSOCIAT= ION=20 object format with Association Type
>>> "Associated Bidirection= al=20 LSP". Clarified on how to populate
>>> different fields in this= =20 object.
>>>>
>>>>
>>>>> We= =20 believe that some of these changes were necessary to avoid the
>>&= gt;=20 interoperability issues due to potentially different=20 interpretations.
>>>>>
>>>>> Your revie= w=20 comments are welcome.
>>>>>
>>>>>=20 Thanks,
>>>>>=20 Rakesh
>>>>>
>>>>> -----Original=20 Message-----
>>>>> From: ccamp-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org]=20 On
>>>>> Behalf Of internet-drafts@ietf.org
&g= t;>>>>=20 Sent: Wednesday, August 15, 2012 10:53 AM
>>>>> To: i-d-announce@ietf.org
>>= >>>=20 Cc: ccamp@ietf.org
>>>>= ;>=20 Subject: [CCAMP] I-D Action:
>>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;>
>>>>>
>>>>>=20 A New Internet-Draft is available from the on-line=20 Internet-Drafts
>>> directories.
>>>>>  = This=20 draft is a work item of the Common Control and Measurement
>>> = Plane=20 Working Group of the IETF.
>>>>>
>>>>>= =20    Title           : RSVP-TE Extensions = for=20 Associated Bidirectional
>>> LSPs
>>>>>  = ;=20  Author(s)       : Fei Zhang
>>>>> &n= bsp;=20                      = ;=20   Ruiquan Jing
>>>>>         &nb= sp;=20                 Rakesh=20 Gandhi
>>>>>    Filename      =20  : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-
>>>=20 lsp-04.txt
>>>>>    Pages      = =20     : 17
>>>>>    Date    = =20        :=20 2012-08-15
>>>>>
>>>>>=20 Abstract:
>>>>>    The MPLS Transport Profile=20 (MPLS-TP) requirements document
>>>=20 [RFC5654],
>>>>>    describes that MPLS-TP MUST= =20 support associated bidirectional
>>> point-
>>>>= >=20    to-point LSPs.
>>>>>
>>>>>= =20    This document provides a method to bind two unidirectional=20 Label
>>>>>    Switched Paths (LSPs) into an=20 associated bidirectional LSP.  The
>>>>>  =20  association is achieved by defining the new Association Type=20 in
>>> the
>>>>>    Extended ASSOCI= ATION=20 object.
>>>>>
>>>>>
>>>>= >=20 The IETF datatracker status page for this draft is:
>>>>>= https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-r= svpte-
>>>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp
>>>>>
>>>>> There's also = a=20 htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-= ext-
>>>=20 associ
>>>>> a
>>>>>=20 ted-lsp-04
>>>>>
>>>>> A diff from the= =20 previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp= -rsvpte-
>>>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp-04
>>>>>
>>>>>
>>= ;>>>=20 Internet-Drafts are also available by anonymous FTP at:
>>>>= >=20 ftp://ftp.ietf.org/internet-drafts/
>>>>= >
>>>>>=20 _______________________________________________
>>>>> CCA= MP=20 mailing list
>>>>> CCAMP@ietf.org
>>>>> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ccamp"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ccamp
>>= >>>
>>>>>
>>>>>
>>>= ;>>
>>>>
>>>>
>>>>
&g= t;>>>
>>>=20 _______________________________________________
>>> CCAMP maili= ng=20 list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>=
>>
>>
>>
>=20 _______________________________________________
> CCAMP mailing=20 list
> CCAMP@ietf.org
> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ccamp"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ccamp
________= _______________________________________
CCAMP=20 mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp<= /P>

 

--_000_60C093A41B5E45409A19D42CF7786DFD5668113079EUSAACMS0703e_-- From jdrake@juniper.net Fri Aug 17 14:53:38 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761AB11E80E2 for ; Fri, 17 Aug 2012 14:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.744 X-Spam-Level: X-Spam-Status: No, score=-5.744 tagged_above=-999 required=5 tests=[AWL=0.854, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jz5YFVx8WAN for ; Fri, 17 Aug 2012 14:53:33 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id E685B11E80D1 for ; Fri, 17 Aug 2012 14:53:32 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUC69WdBjuNr5+H9geg7LP36yShKZhSkE@postini.com; Fri, 17 Aug 2012 14:53:32 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 17 Aug 2012 14:48:40 -0700 From: John E Drake To: Gregory Mirsky , Greg Mirsky , Francesco Fondelli Date: Fri, 17 Aug 2012 14:48:38 -0700 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac18rlwA4D2YlfZKRGCBpFI+2JZEwgABuVOAAAA1SUAAAN63wAAAvlnAAAAigwAAAIUx8AAAYKSA Message-ID: <5E893DB832F57341992548CDBB333163A631A84F48@EMBX01-HQ.jnpr.net> References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <5E893DB832F57341992548CDBB333163A631A84E31@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84E97@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84EF3@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A631A84F48EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 21:53:38 -0000 --_000_5E893DB832F57341992548CDBB333163A631A84F48EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, It's not clear what 'monitored independently' means and whether it edicts c= oordinated or independent mode. It really can't, because as I indicated previously, in both modes there is = a bidirectional flow of control packets and in both modes there is a stream= of CC/CV packets in each direction. The only difference is whether if one= direction fails, the other direction is forced to fail. I always thought independent mode was suspect and that requirement for it w= as derived from the way Y.1731 worked, but I think it is equally suspect fo= r both associated and co-routed. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 2:34 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt John, as Dave Allan pointed, RFC 6428 does not mandate how coordinated and indepe= ndent modes should be used. But the very first sentence of Section 3.1 of t= he document we're discussing says "The associated bidirectional LSP's forward and backward directions are set= up, monitored, and protected independently as required by [RFC5654]." And in RFC 5654, section 1.2.2 I indeed f= ind "Associated bidirectional path: A path that supports traffic flow in both d= irections but that is constructed from a pair of unidirectional paths (one = for each direction) that are associated with one another at the path's ingr= ess/egress points. The forward and backward directions are setup, monitore= d, and protected independently. As a consequence, they may or may not foll= ow the same route (links and nodes) across the network." I think there's no need for RFC 6428bis. Do you think there's need to revis= e RFC 5654? Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 2:20 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, For both modes there is bidirectional flow of control packets. For Indepen= dent mode the CC/CV packets flow in only one direction. There never was a coupling between modes and associated/co-routed and if yo= u can point me to any text that says the contrary I would appreciate it as = a bis to remove that text would be required. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 2:12 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, in independent mode CC/CV control messages been sent only in one direction.= Thus there are two CC/CV sessions - one for each independently monitored d= irection. That, AFAIK, was intentional. Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 1:50 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, That certainly wasn't the intent. With a bidirectional LSP of either type = you have one forward and one return path and BFD does not care whether they= are congruent. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 1:28 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, I think that bi-directional associated p2p LSP, regardless of how many comm= on LSRs forward and reverse directions have, implies use of independent mod= e of RFC 6428, then there will be two sessions to monitor each direction in= dependently. Coordinated mode of RFC 6428, in my understanding, applies to = bidirectional co-routed p2p LSP. Regards, Greg ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of John E Drake Sent: Friday, August 17, 2012 1:19 PM To: Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, According to RFC 6428 the is one CC/CV/RDI session irregardless of whether = the bi-directional packet LSP is co-routed or associated. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky Sent: Friday, August 17, 2012 12:27 PM To: Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi Francesco, "from a data-plane view point b) and c2) are the same thing" I think that given that c) is associated bi-directional LSP that implies in= dependent OAM and protection for each direction, b) and c2) are not the sam= e in the data plane view. E.g., there will be single CC/CV/RDI session for = b) while c2) will have two sessions. And if linear protection requested, b)= will be protected by single bi-directional LSP, but c2) - by two unidirect= ional LSPs. Regards, Greg On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: Hi All, I think I'm lost, please help. Rakesh is talking about "co-routed associated bidirectional LSP"... for the sake of clarity, let me try to categorize LSPs from a control plane view point: a) Point-to-point unidirectional b) Point-to-point co-routed bidirectional c) Point-to-point associated bidirectional c1) fwd and rev LSP follow different paths c2) fwd and rev LSP follow same path d) Point-to-multipoint unidirectional e) Multipoint-to-point unidirectional Is section 3.2.5 (Signaling of Co-routed LSPs) of mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? In my opinion: - b) should be signaled with 3473 - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) Am I missing something? thank you ciao fra PS from a data-plane view point b) and c2) are the same thing. On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: > Hi Lou, > > Thanks for initiating discussions on the changes in the draft. > > Agree with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can alwa= ys submit a new draft just for that. We respect your/WG decision. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 6:08 PM > To: John E Drake > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The chai= rs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I cov= ered in earlier mail, my feeling is to let the discussion take place on the= list (and at the next IETF, if needed) and then have the draft updated to = reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your email, >> below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:cca= mp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes >>> that have not been discussed by the WG. Correct me if I get them >>> wrong, but I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate >>> different fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_5E893DB832F57341992548CDBB333163A631A84F48EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg,

 

<= p class=3DMsoNormal>It’s not clear what ‘monitored indep= endently’ means and whether it edicts coordinated  or independen= t mode.

 <= /span>

It really can’t, because as I i= ndicated previously, in both modes there is a bidirectional flow of control= packets and in both modes there is a stream of CC/CV packets in each direc= tion.  The only difference is whether if one direction fails, the othe= r direction is forced to fail.

 

I always thoug= ht independent mode was suspect and that requirement for it was derived fro= m the way Y.1731 worked, but I think it is equally suspect for both associa= ted and co-routed.

&n= bsp;

Thanks,<= /p>

 

John   

 

Sent from = my iPhone

 = ;

From: Gregory Mi= rsky [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, August 1= 7, 2012 2:34 PM
To: John E Drake; Greg Mirsky; Francesco Fondelli=
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D Action: dr= aft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

 

John,

as Dave Allan pointed= , RFC 6428 does not mandate how coordinated and independent modes should be= used. But the very first sentence of Section 3.1 of the document we're dis= cussing says

"The associat= ed bidirectional LSP's forward and backward directions are set up, mon= itored, and protected independently as required by   [RFC5654].= " And in RFC 5654, section 1.2.2 I indeed find

"Associated bidirectional path: A path that suppo= rts traffic flow in both directions but that is constructed from a pai= r of unidirectional paths (one for each direction) that are associated= with one another at the path's ingress/egress points.  The forwa= rd and backward directions are setup, monitored, and protected indepen= dently.  As a consequence, they may or may not follow the same ro= ute (links and nodes) across the network."

<= p class=3DMsoNormal> 

I think t= here's no need for RFC 6428bis. Do you think there's need to revise RFC 565= 4?

 

    Regards,

        Greg

 

&= nbsp;

From: John E Drake [mailto:jdrake@juniper.net]
Sent: Friday, August= 17, 2012 2:20 PM
To: Gregory Mirsky; Greg Mirsky; Francesco Fond= elli
Cc: ccamp@ietf.org
= Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext= -associated-lsp-04.txt

Gre= g,

 

For both modes there is bidirectional flow= of control packets.  For Independent mode the CC/CV packets flow in o= nly one direction.

&n= bsp;

There never was a coupling= between modes and associated/co-routed and if you can point me to any text= that says the contrary I would appreciate it as a bis to remove that text = would be required.

&n= bsp;

Thanks,<= /p>

 

John

&nb= sp;

Sent from my iPhone

 

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com<= /a>]
Sent: Friday, August 17, 2012 2:12 PM
To: John E = Drake; Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D Action: d= raft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt<= /p>

 

Hi John,

in independent mo= de CC/CV control messages been sent only in one direction. Thus there are t= wo CC/CV sessions - one for each independently monitored direction. That, A= FAIK, was intentional.

 

    Regards,

        G= reg

 

From: John E Drake [mailto:jdr= ake@juniper.net]
Sent: Friday, August 17, 2012 1:50 PM
To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [CC= AMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt<= /span>

Greg,

 

That certainly wasn’t the intent.  With a bidirectiona= l LSP of either type you have one forward and one return path and BFD does = not care whether they are congruent.

 

Thanks,<= o:p>

 

John

 

Sent= from my iPhone

 

From: Grego= ry Mirsky [mailto:gregory.mi= rsky@ericsson.com]
Sent: Friday, August 17, 2012 1:28 PM
= To: John E Drake; Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [CC= AMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt<= o:p>

 

=

Hi John,

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:blue'= >I think that bi-directional associated p2p LSP, regardless of how man= y common LSRs forward and reverse directions have, implies use of inde= pendent mode of RFC 6428, then there will be two sessions to monitor each d= irection independently. Coordinated mode of RFC 6428, in my understanding, = applies to bidirectional co-routed p2p LSP.

 

    <= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:blue'= >Regards,

    = ;    Greg

&= nbsp;

From: ccamp-bounces@ietf.org [ma= ilto:ccamp-bounces@ietf.org] On Behalf Of John E Drake
Sen= t: Friday, August 17, 2012 1:19 PM
To: Greg Mirsky; Francesco= Fondelli
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpt= e-ext-associated-lsp-04.txt

Greg,

 <= /span>

According to RFC 6428 the is one CC/C= V/RDI session irregardless of whether the bi-directional packet LSP is co-r= outed or associated.

 

Thanks,

 

John

 

Sent from my iPhone

 

<= div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4= .0pt'>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg MirskySent: Friday, August 17, 2012 12:27 PM
To: Francesco Fon= delli
Cc: ccamp@ietf.orgSubject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ex= t-associated-lsp-04.txt

 

Hi Francesco,
"from a data-plane view point b) and c2) are the sam= e thing"
I think that given that c) is associated bi-directional LS= P that implies independent OAM and protection for each direction, b) and c2= ) are not the same in the data plane view. E.g., there will be single CC/CV= /RDI session for b) while c2) will have two sessions. And if linear protect= ion requested, b) will be protected by single bi-directional LSP, but c2) -= by two unidirectional LSPs.

Regards,
Greg

On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli <<= a href=3D"mailto:francesco.fondelli@gmail.com" target=3D"_blank">francesco.= fondelli@gmail.com> wrote:

Hi All= ,

I think I'm lost, please help.

Rakesh is talking about &quo= t;co-routed associated bidirectional
LSP"... for the sake of clarit= y, let me try to categorize
LSPs from a control plane view point:
  a) Point-to-point unidirectional
  b) Point-to-point co-rou= ted bidirectional
  c) Point-to-point associated bidirectional
&= nbsp;  c1) fwd and rev LSP follow different paths
   c2) = fwd and rev LSP follow same path
  d) Point-to-multipoint unidirect= ional
  e) Multipoint-to-point unidirectional

Is section 3.2= .5 (Signaling of Co-routed LSPs) of
mpls-tp-rsvpte-ext-associated-lsp ab= out b) or it is about c2)?

In my opinion:

- b) should be sign= aled with 3473
- c) are addressed by this I-D (mpls-tp-rsvpte-ext-associ= ated-lsp)

Am I missing something?

thank you
ciao
fra
PS
from a data-plane view point b) and c2) are the same thing.=


On Fri, Aug 17, 2012 at 12:16 = AM, Rakesh Gandhi (rgandhi)
<rga= ndhi@cisco.com> wrote:
> Hi Lou,
>
> Thanks for in= itiating discussions on the changes in the draft.
>
> Agree wit= h you here, if we/WG do not agree on the "co-routed associated bidirec= tional LSP" part, we are ok to remove it from this draft and can alway= s submit a new draft just for that. We respect your/WG decision.
>> Thanks,
> Rakesh
>
>
>
> -----Original = Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Thursday, August 16, 2012 6:08 P= M
> To: John E Drake
> Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org
> Subject: Re: [CCAMP] I-D = Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>> John,
>         While strictly speaking WG= drafts should only reflect current WG consensus, and it is the WG draft ed= itor's job to ensure this, in practice authors/editors are given a lot of l= atitude in timing / ordering in introduction to changes.  I personally= think this is a practical way of keeping the process moving.  Also if= the WG disagrees with a change, it can always be backed out.
>
&g= t; So, yes, the WG could do exactly as you say if it comes to it.  (Th= e chairs can even appoint different editor if needed, e.g., to make this> happen.)  While I'm not happy with how this revision came about,= as I covered in earlier mail, my feeling is to let the discussion take pla= ce on the list (and at the next IETF, if needed) and then have the draft up= dated to reflect the WG discussion/consensus.
>
> Lou
>> On 8/16/2012 5:35 PM, John E Drake wrote:
>> Lou,
>&g= t;
>> Since the WG did not agree to this changes, let alone discus= s them,
>> would it be possible to simply rollback these changes a= nd ask the
>> authors to write a draft addressing the topics you l= ist in your email,
>> below?
>>
>> Thanks,
&g= t;>
>> John
>>
>> Sent from my iPhone
>= >
>>
>>> -----Original Message-----
>>>= From: ccamp-bounces@ietf.org= [mailto:ccamp-bounces@ietf.org] On
>>> Behalf Of Lou Berger
>>> Sent: Thursday,= August 16, 2012 2:10 PM
>>> To: Rakesh Gandhi (rgandhi)
>= ;>> Cc: ccamp@ietf.org
>&= gt;> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ex= t-
>>> associated-lsp-04.txt
>>>
>>> Ra= kesh,
>>>      Such major changes (in scope and = functionality) to WG drafts are
>>> usually discussed with the = WG prior to the authors/editors just
>>> publishing the changes= .  But, this is a judgment call by the document
>>> editor= s in how, quoting rfc2418, they "ensur[e] that the contents of
>= >> the document accurately reflect the decisions that have been made = by
>>> the working group."
>>>
>>>= So let's jump into discussing the changes.
>>>
>>>= As I see it this draft introduces several major functional changes
>= >> that have not been discussed by the WG.  Correct me if I get = them
>>> wrong, but I believe they include:
>>> 1) = Introduction of a second method for signaling Co-routed LSPs
>>>= ; 2) Support for FRR bypass tunnels for piggybacked on the TP
>>&g= t; bidirectional LSP mechanisms.
>>>
>>>   &nb= sp;There are also other changes, but I'll defer discussing them
>>= >    until the discussion on the above is concluded.
>&g= t;>
>>> Is this correct?
>>>
>>> Ass= uming yes, I have questions about both rational and specific
>>>= ; mechanisms.  For now let's look at the former, so please:
>>= ;>
>>> A) Articulate the issues/limitations with using the R= FC3473 defined
>>> mechanisms for (co-routed) bidirectional LSP= s that you'd like to see
>>> addressed.
>>>
>= >> B.1) Articulate the FRR/GMPLS-related issue you'd like to address?=
>>>
>>> B.2) Articulate why this issue should be s= olved in a TP-specific and
>>> not GMPLS generic fashion?
&g= t;>>
>>> Thanks,
>>> Lou
>>>
&= gt;>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote:
>>= ;>> Hi Lou,
>>>>
>>>> Yes.
>>&= gt;>
>>>> Please advise if you think detailed email is re= quired.
>>>> We believe latest draft summarizes the changes = well and we could
>>> start review/discussions from there.
&= gt;>>>
>>>> Thanks,
>>>> Rakesh
&= gt;>>>
>>>>
>>>> -----Original Messa= ge-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: Thursday, Aug= ust 16, 2012 4:00 PM
>>>> To: Rakesh Gandhi (rgandhi)
>= ;>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>>= >> Subject: Re: [CCAMP] I-D Action:
>>>> draft-ietf-cc= amp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>
>>= ;>> Rakesh,
>>>>     Is this the start of th= e thread that I requested in
>>>> http:/= /www.ietf.org/mail-archive/web/ccamp/current/msg13729.html
>>&= gt;>
>>>> In particular, is it the response to:
>&g= t;>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each= of the
>>>>> proposed change and the rational for each c= hange (in one or in
>>>>> separate e-mails). The WG discu= ssion can then really begin on the
>>>>> proposed changes= . (Which are quite substantial both in scope and
>>>>> im= plication.)
>>>>
>>>> Lou
>>>>=
>>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote:>>>>> Hi All,
>>>>>
>>>>&= gt; We have uploaded a new version of this draft with following changes:>>>>
>>>> 1.  Added a section on Signaling= of Co-routed LSPs
>>>>
>>>> 2.  Added c= larification on Signaling of Associated Bidirectional
>>>> P= rotection LSPs
>>>>
>>>> 3.  Added a sec= tion on Signaling of Auto-tunnel Mesh-group LSPs
>>>>
>= ;>>> 4.   Added clarification on Signaling of Inter-domain As= sociated
>>> Bidirectional LSPs
>>>>
>>= >> 5.  The Extended ASSOCIATION object format with Association T= ype
>>> "Associated Bidirectional LSP". Clarified on = how to populate
>>> different fields in this object.
>>= ;>>
>>>>
>>>>> We believe that some = of these changes were necessary to avoid the
>>> interoperabili= ty issues due to potentially different interpretations.
>>>>= >
>>>>> Your review comments are welcome.
>>&= gt;>>
>>>>> Thanks,
>>>>> Rakesh<= br>>>>>>
>>>>> -----Original Message-----<= br>>>>>> From: cca= mp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On
>>>>> Behalf Of internet-drafts@ietf.org
>>&g= t;>> Sent: Wednesday, August 15, 2012 10:53 AM
>>>>>= ; To: i-d-announce@ietf.org>>>>> Cc: ccamp@ietf.org<= /a>
>>>>> Subject: [CCAMP] I-D Action:
>>>>= ;> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>= >>>
>>>>>
>>>>> A New Internet= -Draft is available from the on-line Internet-Drafts
>>> direct= ories.
>>>>>  This draft is a work item of the Commo= n Control and Measurement
>>> Plane Working Group of the IETF.<= br>>>>>>
>>>>>    Title   &= nbsp;       : RSVP-TE Extensions for Associated Bidirectiona= l
>>> LSPs
>>>>>    Author(s)  = ;     : Fei Zhang
>>>>>       &n= bsp;                   Ruiquan= Jing
>>>>>             &nb= sp;             Rakesh Gandhi
>>>= >>    Filename        : draft-ietf-ccam= p-mpls-tp-rsvpte-ext-associated-
>>> lsp-04.txt
>>>= >>    Pages           : 17
>= >>>>    Date            = ;: 2012-08-15
>>>>>
>>>>> Abstract:
= >>>>>    The MPLS Transport Profile (MPLS-TP) requ= irements document
>>> [RFC5654],
>>>>>  =  describes that MPLS-TP MUST support associated bidirectional
>= >> point-
>>>>>    to-point LSPs.
>= >>>>
>>>>>    This document provide= s a method to bind two unidirectional Label
>>>>>   =  Switched Paths (LSPs) into an associated bidirectional LSP.  The=
>>>>>    association is achieved by defining t= he new Association Type in
>>> the
>>>>> &nbs= p;  Extended ASSOCIATION object.
>>>>>
>>&g= t;>>
>>>>> The IETF datatracker status page for thi= s draft is:
>>>>> https://datatracke= r.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-
>>> ext->>>>> a
>>>>> ssociated-lsp
>>&g= t;>>
>>>>> There's also a htmlized version availabl= e at:
>>>>> http://tools.ietf.org/html= /draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>> associ
>>= ;>>> a
>>>>> ted-lsp-04
>>>>><= br>>>>>> A diff from the previous version is available at:>>>>> http://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte-
>>> ext-
>>= >>> a
>>>>> ssociated-lsp-04
>>>>= >
>>>>>
>>>>> Internet-Drafts are al= so available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/interne= t-drafts/
>>>>>
>>>>> _____________= __________________________________
>>>>> CCAMP mailing li= st
>>>>> CCAMP@ietf.org=
>>>>> https://www.ietf.org/mailman/listinfo/ccamp=
>>>>>
>>>>>
>>>>>>>>>>
>>>>
>>>>
>>&g= t;>
>>>>
>>> ________________________________= _______________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ie= tf.org/mailman/listinfo/ccamp
>>
>>
>>
&g= t;>
> _______________________________________________
> CCAM= P mailing list
> CCAMP@ietf.org=
> https://www.ietf.org/mailman/listinfo/ccamp
________________= _______________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/= ccamp

 <= /o:p>

= --_000_5E893DB832F57341992548CDBB333163A631A84F48EMBX01HQjnprn_-- From gregory.mirsky@ericsson.com Fri Aug 17 16:42:19 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F53811E8097; Fri, 17 Aug 2012 16:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFhZ9VWTbQye; Fri, 17 Aug 2012 16:42:13 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9C85B21F847A; Fri, 17 Aug 2012 16:42:12 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q7HNg9bO024938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Aug 2012 18:42:10 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 17 Aug 2012 19:42:09 -0400 From: Gregory Mirsky To: John E Drake , Greg Mirsky , Francesco Fondelli Date: Fri, 17 Aug 2012 19:42:04 -0400 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac18rlwA4D2YlfZKRGCBpFI+2JZEwgABuVOAAAA1SUAAAN63wAAAvlnAAAAigwAAAIUx8AAAYKSAAAMO/NA= Message-ID: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <5E893DB832F57341992548CDBB333163A631A84E31@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84E97@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84EF3@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A631A84F48@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A631A84F48@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF139268CC08EEUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 23:42:19 -0000 --_000_FE60A4E52763E84B935532D7D9294FF139268CC08EEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, "The only difference is whether if one direction fails, the other direction= is forced to fail." Yes. And whether associated bidirectional LSP requires protection as single= bidirectional p2p construct or protection applies to each direction indepe= ndently. But what happens to association in that case? Should protecting un= idirectional LSPs be associated with working and protecting unidirectional = LSPs of reverse direction before switchover? Consider working L1 A-Z and L2= Z-A are protected by L3 A-Z and L4 Z-A accordingly. L1 and L2 form associa= ted bidirectional p2p LSP. What about L3 and L2, L1 and L4, L3 and L4 - are= these the same associated bi-directional LSP or not? Regards, Greg PS. Even though most of MPLS WG is likely subscribed to CCAMP list, I'll ad= d MPLS WG to have opinions and comments from it. ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 2:49 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, It's not clear what 'monitored independently' means and whether it edicts c= oordinated or independent mode. It really can't, because as I indicated previously, in both modes there is = a bidirectional flow of control packets and in both modes there is a stream= of CC/CV packets in each direction. The only difference is whether if one= direction fails, the other direction is forced to fail. I always thought independent mode was suspect and that requirement for it w= as derived from the way Y.1731 worked, but I think it is equally suspect fo= r both associated and co-routed. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 2:34 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt John, as Dave Allan pointed, RFC 6428 does not mandate how coordinated and indepe= ndent modes should be used. But the very first sentence of Section 3.1 of t= he document we're discussing says "The associated bidirectional LSP's forward and backward directions are set= up, monitored, and protected independently as required by [RFC5654]." And in RFC 5654, section 1.2.2 I indeed f= ind "Associated bidirectional path: A path that supports traffic flow in both d= irections but that is constructed from a pair of unidirectional paths (one = for each direction) that are associated with one another at the path's ingr= ess/egress points. The forward and backward directions are setup, monitore= d, and protected independently. As a consequence, they may or may not foll= ow the same route (links and nodes) across the network." I think there's no need for RFC 6428bis. Do you think there's need to revis= e RFC 5654? Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 2:20 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, For both modes there is bidirectional flow of control packets. For Indepen= dent mode the CC/CV packets flow in only one direction. There never was a coupling between modes and associated/co-routed and if yo= u can point me to any text that says the contrary I would appreciate it as = a bis to remove that text would be required. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 2:12 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, in independent mode CC/CV control messages been sent only in one direction.= Thus there are two CC/CV sessions - one for each independently monitored d= irection. That, AFAIK, was intentional. Regards, Greg ________________________________ From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, August 17, 2012 1:50 PM To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, That certainly wasn't the intent. With a bidirectional LSP of either type = you have one forward and one return path and BFD does not care whether they= are congruent. Thanks, John Sent from my iPhone From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, August 17, 2012 1:28 PM To: John E Drake; Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi John, I think that bi-directional associated p2p LSP, regardless of how many comm= on LSRs forward and reverse directions have, implies use of independent mod= e of RFC 6428, then there will be two sessions to monitor each direction in= dependently. Coordinated mode of RFC 6428, in my understanding, applies to = bidirectional co-routed p2p LSP. Regards, Greg ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of John E Drake Sent: Friday, August 17, 2012 1:19 PM To: Greg Mirsky; Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Greg, According to RFC 6428 the is one CC/CV/RDI session irregardless of whether = the bi-directional packet LSP is co-routed or associated. Thanks, John Sent from my iPhone From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky Sent: Friday, August 17, 2012 12:27 PM To: Francesco Fondelli Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ= ated-lsp-04.txt Hi Francesco, "from a data-plane view point b) and c2) are the same thing" I think that given that c) is associated bi-directional LSP that implies in= dependent OAM and protection for each direction, b) and c2) are not the sam= e in the data plane view. E.g., there will be single CC/CV/RDI session for = b) while c2) will have two sessions. And if linear protection requested, b)= will be protected by single bi-directional LSP, but c2) - by two unidirect= ional LSPs. Regards, Greg On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: Hi All, I think I'm lost, please help. Rakesh is talking about "co-routed associated bidirectional LSP"... for the sake of clarity, let me try to categorize LSPs from a control plane view point: a) Point-to-point unidirectional b) Point-to-point co-routed bidirectional c) Point-to-point associated bidirectional c1) fwd and rev LSP follow different paths c2) fwd and rev LSP follow same path d) Point-to-multipoint unidirectional e) Multipoint-to-point unidirectional Is section 3.2.5 (Signaling of Co-routed LSPs) of mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? In my opinion: - b) should be signaled with 3473 - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) Am I missing something? thank you ciao fra PS from a data-plane view point b) and c2) are the same thing. On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) > wrote: > Hi Lou, > > Thanks for initiating discussions on the changes in the draft. > > Agree with you here, if we/WG do not agree on the "co-routed associated b= idirectional LSP" part, we are ok to remove it from this draft and can alwa= ys submit a new draft just for that. We respect your/WG decision. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, August 16, 2012 6:08 PM > To: John E Drake > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso= ciated-lsp-04.txt > > John, > While strictly speaking WG drafts should only reflect current WG = consensus, and it is the WG draft editor's job to ensure this, in practice = authors/editors are given a lot of latitude in timing / ordering in introdu= ction to changes. I personally think this is a practical way of keeping th= e process moving. Also if the WG disagrees with a change, it can always be= backed out. > > So, yes, the WG could do exactly as you say if it comes to it. (The chai= rs can even appoint different editor if needed, e.g., to make this > happen.) While I'm not happy with how this revision came about, as I cov= ered in earlier mail, my feeling is to let the discussion take place on the= list (and at the next IETF, if needed) and then have the draft updated to = reflect the WG discussion/consensus. > > Lou > > On 8/16/2012 5:35 PM, John E Drake wrote: >> Lou, >> >> Since the WG did not agree to this changes, let alone discuss them, >> would it be possible to simply rollback these changes and ask the >> authors to write a draft addressing the topics you list in your email, >> below? >> >> Thanks, >> >> John >> >> Sent from my iPhone >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:cca= mp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Thursday, August 16, 2012 2:10 PM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associated-lsp-04.txt >>> >>> Rakesh, >>> Such major changes (in scope and functionality) to WG drafts are >>> usually discussed with the WG prior to the authors/editors just >>> publishing the changes. But, this is a judgment call by the document >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>> the document accurately reflect the decisions that have been made by >>> the working group." >>> >>> So let's jump into discussing the changes. >>> >>> As I see it this draft introduces several major functional changes >>> that have not been discussed by the WG. Correct me if I get them >>> wrong, but I believe they include: >>> 1) Introduction of a second method for signaling Co-routed LSPs >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>> bidirectional LSP mechanisms. >>> >>> There are also other changes, but I'll defer discussing them >>> until the discussion on the above is concluded. >>> >>> Is this correct? >>> >>> Assuming yes, I have questions about both rational and specific >>> mechanisms. For now let's look at the former, so please: >>> >>> A) Articulate the issues/limitations with using the RFC3473 defined >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>> addressed. >>> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>> >>> B.2) Articulate why this issue should be solved in a TP-specific and >>> not GMPLS generic fashion? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>> Hi Lou, >>>> >>>> Yes. >>>> >>>> Please advise if you think detailed email is required. >>>> We believe latest draft summarizes the changes well and we could >>> start review/discussions from there. >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Thursday, August 16, 2012 4:00 PM >>>> To: Rakesh Gandhi (rgandhi) >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>> Subject: Re: [CCAMP] I-D Action: >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>> >>>> Rakesh, >>>> Is this the start of the thread that I requested in >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>> >>>> In particular, is it the response to: >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>> proposed change and the rational for each change (in one or in >>>>> separate e-mails). The WG discussion can then really begin on the >>>>> proposed changes. (Which are quite substantial both in scope and >>>>> implication.) >>>> >>>> Lou >>>> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>> Hi All, >>>>> >>>>> We have uploaded a new version of this draft with following changes: >>>> >>>> 1. Added a section on Signaling of Co-routed LSPs >>>> >>>> 2. Added clarification on Signaling of Associated Bidirectional >>>> Protection LSPs >>>> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>> >>>> 4. Added clarification on Signaling of Inter-domain Associated >>> Bidirectional LSPs >>>> >>>> 5. The Extended ASSOCIATION object format with Association Type >>> "Associated Bidirectional LSP". Clarified on how to populate >>> different fields in this object. >>>> >>>> >>>>> We believe that some of these changes were necessary to avoid the >>> interoperability issues due to potentially different interpretations. >>>>> >>>>> Your review comments are welcome. >>>>> >>>>> Thanks, >>>>> Rakesh >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:c= camp-bounces@ietf.org] On >>>>> Behalf Of internet-drafts@ietf.org >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: ccamp@ietf.org >>>>> Subject: [CCAMP] I-D Action: >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>>>> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >>> LSPs >>>>> Author(s) : Fei Zhang >>>>> Ruiquan Jing >>>>> Rakesh Gandhi >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >>> lsp-04.txt >>>>> Pages : 17 >>>>> Date : 2012-08-15 >>>>> >>>>> Abstract: >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>> [RFC5654], >>>>> describes that MPLS-TP MUST support associated bidirectional >>> point- >>>>> to-point LSPs. >>>>> >>>>> This document provides a method to bind two unidirectional Label >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>> association is achieved by defining the new Association Type in >>> the >>>>> Extended ASSOCIATION object. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>> associ >>>>> a >>>>> ted-lsp-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>> ext- >>>>> a >>>>> ssociated-lsp-04 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_FE60A4E52763E84B935532D7D9294FF139268CC08EEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi John,
"The only difference is whether if one direction f= ails, the=20 other direction is forced to fail."
Yes. And whether associated bidirectional LSP requ= ires=20 protection as single bidirectional p2p construct or protection applies to e= ach=20 direction independently. But what happens to association in that case? Shou= ld=20 protecting unidirectional LSPs be associated with working and protecting=20 unidirectional LSPs of reverse direction before switchover? Consider=20 working L1 A-Z and L2 Z-A are protected by L3 A-Z and L4 Z-A according= ly.=20 L1 and L2 form associated bidirectional p2p LSP. What about L3 and L2, L1 a= nd=20 L4, L3 and L4 - are these the same associated bi-directional LSP or=20 not?
 
  &n= bsp; Regards,
        Greg
 
PS. Even though most of MPLS WG is likely subscrib= ed to=20 CCAMP list, I'll add MPLS WG to have opinions and comments from=20 it.

From: John E Drake [mailto:jdrake@junip= er.net]=20
Sent: Friday, August 17, 2012 2:49 PM
To: Gregory Mirs= ky;=20 Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject:= =20 RE: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Greg,

 

It’s=20 not clear what ‘monitored independently’ means and whether it e= dicts=20 coordinated  or independent mode.

 

It=20 really can’t, because as I indicated previously, in both modes there = is a=20 bidirectional flow of control packets and in both modes there is a stream o= f=20 CC/CV packets in each direction.  The only difference is whether if on= e=20 direction fails, the other direction is forced to fail.

 

I=20 always thought independent mode was suspect and that requirement for it was= =20 derived from the way Y.1731 worked, but I think it is equally suspect for b= oth=20 associated and co-routed.

 

Thanks,

 

John =20  

 

Sent=20 from my iPhone

 

From:<= /B> Gregory Mirs= ky=20 [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, August 17, 20= 12=20 2:34 PM
To: John E Drake; Greg Mirsky; Francesco=20 Fondelli
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D Ac= tion:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

J= ohn,

a= s Dave=20 Allan pointed, RFC 6428 does not mandate how coordinated and independent mo= des=20 should be used. But the very first sentence of Section 3.1 of the document = we're=20 discussing says

"= The=20 associated bidirectional LSP's forward and backward directions are set= up,=20 monitored, and protected independently as required by   [RFC5654]." And in RFC 5654, section 1.2= .2 I=20 indeed find

"= Associated=20 bidirectional path: A path that supports traffic flow in both directio= ns=20 but that is constructed from a pair of unidirectional paths (one for e= ach=20 direction) that are associated with one another at the path's=20 ingress/egress points.  The forward and backward directions are s= etup,=20 monitored, and protected independently.  As a consequence, they m= ay or=20 may not follow the same route (links and nodes) across the=20 network."

 

I= think=20 there's no need for RFC 6428bis. Do you think there's need to revise RFC=20 5654?

 

    R= egards,

        G= reg

 

 

From:<= /B> John E Drake= [mailto:jdrake@juniper.net]
Se= nt:=20 Friday, August 17, 2012 2:20 PM
To: Gregory Mirsky; Greg Mirsky;= =20 Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

Greg,

 

For=20 both modes there is bidirectional flow of control packets.  For Indepe= ndent=20 mode the CC/CV packets flow in only one direction.

 

There=20 never was a coupling between modes and associated/co-routed and if you can = point=20 me to any text that says the contrary I would appreciate it as a bis to rem= ove=20 that text would be required.

 

Thanks,

 

John=20

 

Sent=20 from my iPhone

 

From:<= /B> Gregory Mirs= ky [mailto:gregory.mirsky@ericsson.= com]=20
Sent: Friday, August 17, 2012 2:12 PM
To: John E Drake= ;=20 Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

H= i=20 John,

i= n=20 independent mode CC/CV control messages been sent only in one direction. Th= us=20 there are two CC/CV sessions - one for each independently monitored directi= on.=20 That, AFAIK, was intentional.

 

    R= egards,

        G= reg

 

From:<= /B> John E Drake= [mailto:jdrake@juniper.net]
Se= nt:=20 Friday, August 17, 2012 1:50 PM
To: Gregory Mirsky; Greg Mirsky;= =20 Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

Greg,

 

That=20 certainly wasn’t the intent.  With a bidirectional LSP of either= type you=20 have one forward and one return path and BFD does not care whether they are= =20 congruent.

 

Thanks,

 

John

 

Sent=20 from my iPhone

 

From:<= /B> Gregory Mirs= ky [mailto:gregory.mirsky@ericsson.= com]=20
Sent: Friday, August 17, 2012 1:28 PM
To: John E Drake= ;=20 Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

H= i=20 John,

I= think=20 that bi-directional associated p2p LSP, regardless of how many common = LSRs=20 forward and reverse directions have, implies use of independent mode o= f RFC=20 6428, then there will be two sessions to monitor each direction independent= ly.=20 Coordinated mode of RFC 6428, in my understanding, applies to bidirectional= =20 co-routed p2p LSP.

 

    R= egards,

        G= reg

 

From:<= /B> ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <= B>On=20 Behalf Of John E Drake
Sent: Friday, August 17, 2012 1:19=20 PM
To: Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: Re: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

Greg,

 

According=20 to RFC 6428 the is one CC/CV/RDI session irregardless of whether the=20 bi-directional packet LSP is co-routed or associated.

 

Thanks,

 

John

 

Sent=20 from my iPhone

 

From:<= /B> ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <= B>On=20 Behalf Of Greg Mirsky
Sent: Friday, August 17, 2012 12:27=20 PM
To: Francesco Fondelli
Cc: ccamp@ietf.org
Subject: Re: [C= CAMP]=20 I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=

 

Hi Francesco,
"from a= =20 data-plane view point b) and c2) are the same thing"
I think that given = that=20 c) is associated bi-directional LSP that implies independent OAM and protec= tion=20 for each direction, b) and c2) are not the same in the data plane view. E.g= .,=20 there will be single CC/CV/RDI session for b) while c2) will have two sessi= ons.=20 And if linear protection requested, b) will be protected by single=20 bi-directional LSP, but c2) - by two unidirectional=20 LSPs.

Regards,
Greg

On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli &l= t;francesco.fondelli@gmail.com> wrote:

Hi All,

I think I'm lost, please help.

R= akesh=20 is talking about "co-routed associated bidirectional
LSP"... for the sak= e of=20 clarity, let me try to categorize
LSPs from a control plane view=20 point:

  a) Point-to-point unidirectional
  b)=20 Point-to-point co-routed bidirectional
  c) Point-to-point associat= ed=20 bidirectional
   c1) fwd and rev LSP follow different=20 paths
   c2) fwd and rev LSP follow same path
  d)=20 Point-to-multipoint unidirectional
  e) Multipoint-to-point=20 unidirectional

Is section 3.2.5 (Signaling of Co-routed LSPs)=20 of
mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)?
In=20 my opinion:

- b) should be signaled with 3473
- c) are addressed = by=20 this I-D (mpls-tp-rsvpte-ext-associated-lsp)

Am I missing=20 something?

thank you
ciao
fra

PS
from a data-plane v= iew=20 point b) and c2) are the same thing.


On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi=20 (rgandhi)
<rgandhi@cisco.com= >=20 wrote:
> Hi Lou,
>
> Thanks for initiating discussions on= the=20 changes in the draft.
>
> Agree with you here, if we/WG do not = agree=20 on the "co-routed associated bidirectional LSP" part, we are ok to remove i= t=20 from this draft and can always submit a new draft just for that. We respect= =20 your/WG decision.
>
> Thanks,
>=20 Rakesh
>
>
>
> -----Original Message-----
> F= rom:=20 Lou Berger [mailto:lberger@labn.net]
> Sent: Thursd= ay,=20 August 16, 2012 6:08 PM
> To: John E Drake
> Cc: Rakesh Gandhi= =20 (rgandhi); ccamp@ietf.org
> Sub= ject:=20 Re: [CCAMP] I-D Action:=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>
>=20 John,
>         While strictly speaking WG drafts= =20 should only reflect current WG consensus, and it is the WG draft editor's j= ob to=20 ensure this, in practice authors/editors are given a lot of latitude in tim= ing /=20 ordering in introduction to changes.  I personally think this is a=20 practical way of keeping the process moving.  Also if the WG disagrees= with=20 a change, it can always be backed out.
>
> So, yes, the WG coul= d do=20 exactly as you say if it comes to it.  (The chairs can even appoint=20 different editor if needed, e.g., to make this
> happen.)  While= I'm=20 not happy with how this revision came about, as I covered in earlier mail, = my=20 feeling is to let the discussion take place on the list (and at the next IE= TF,=20 if needed) and then have the draft updated to reflect the WG=20 discussion/consensus.
>
> Lou
>
> On 8/16/2012 5:35= PM,=20 John E Drake wrote:
>> Lou,
>>
>> Since the WG d= id=20 not agree to this changes, let alone discuss them,
>> would it be= =20 possible to simply rollback these changes and ask the
>> authors t= o=20 write a draft addressing the topics you list in your email,
>>=20 below?
>>
>> Thanks,
>>
>>=20 John
>>
>> Sent from my=20 iPhone
>>
>>
>>> -----Original=20 Message-----
>>> From: ccamp-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org]=20 On
>>> Behalf Of Lou Berger
>>> Sent: Thursday, Aug= ust=20 16, 2012 2:10 PM
>>> To: Rakesh Gandhi (rgandhi)
>>>= ; Cc:=20 ccamp@ietf.org
>>> Subjec= t: Re:=20 [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>>=20 associated-lsp-04.txt
>>>
>>> Rakesh,
>>&g= t;=20      Such major changes (in scope and functionality) to WG d= rafts=20 are
>>> usually discussed with the WG prior to the authors/edit= ors=20 just
>>> publishing the changes.  But, this is a judgment = call=20 by the document
>>> editors in how, quoting rfc2418, they "ensu= r[e]=20 that the contents of
>>> the document accurately reflect the=20 decisions that have been made by
>>> the working=20 group."
>>>
>>> So let's jump into discussing the=20 changes.
>>>
>>> As I see it this draft introduces= =20 several major functional changes
>>> that have not been discuss= ed by=20 the WG.  Correct me if I get them
>>> wrong, but I believe= they=20 include:
>>> 1) Introduction of a second method for signaling=20 Co-routed LSPs
>>> 2) Support for FRR bypass tunnels for piggyb= acked=20 on the TP
>>> bidirectional LSP=20 mechanisms.
>>>
>>>    There are also oth= er=20 changes, but I'll defer discussing them
>>>    until = the=20 discussion on the above is concluded.
>>>
>>> Is th= is=20 correct?
>>>
>>> Assuming yes, I have questions abo= ut=20 both rational and specific
>>> mechanisms.  For now let's = look=20 at the former, so please:
>>>
>>> A) Articulate the= =20 issues/limitations with using the RFC3473 defined
>>> mechanism= s for=20 (co-routed) bidirectional LSPs that you'd like to see
>>>=20 addressed.
>>>
>>> B.1) Articulate the FRR/GMPLS-re= lated=20 issue you'd like to address?
>>>
>>> B.2) Articulat= e why=20 this issue should be solved in a TP-specific and
>>> not GMPLS= =20 generic fashion?
>>>
>>> Thanks,
>>>=20 Lou
>>>
>>> On 8/16/2012 4:26 PM, Rakesh Gandhi=20 (rgandhi) wrote:
>>>> Hi=20 Lou,
>>>>
>>>>=20 Yes.
>>>>
>>>> Please advise if you think det= ailed=20 email is required.
>>>> We believe latest draft summarizes t= he=20 changes well and we could
>>> start review/discussions from=20 there.
>>>>
>>>> Thanks,
>>>>= =20 Rakesh
>>>>
>>>>
>>>> -----Ori= ginal=20 Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> = Sent:=20 Thursday, August 16, 2012 4:00 PM
>>>> To: Rakesh Gandhi=20 (rgandhi)
>>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>>= >>=20 Subject: Re: [CCAMP] I-D Action:
>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;
>>>>=20 Rakesh,
>>>>     Is this the start of the thread t= hat I=20 requested in
>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729= .html
>>>>
>>>>=20 In particular, is it the response to:
>>>>> I'd like to a= sk=20 that someone (Rakesh, Fei, etc.) review each of the
>>>>>= =20 proposed change and the rational for each change (in one or=20 in
>>>>> separate e-mails). The WG discussion can then re= ally=20 begin on the
>>>>> proposed changes. (Which are quite=20 substantial both in scope and
>>>>>=20 implication.)
>>>>
>>>>=20 Lou
>>>>
>>>> On 8/16/2012 3:19 PM, Rakesh Ga= ndhi=20 (rgandhi) wrote:
>>>>> Hi=20 All,
>>>>>
>>>>> We have uploaded a new= =20 version of this draft with following=20 changes:
>>>>
>>>> 1.  Added a section o= n=20 Signaling of Co-routed LSPs
>>>>
>>>> 2.=20  Added clarification on Signaling of Associated=20 Bidirectional
>>>> Protection=20 LSPs
>>>>
>>>> 3.  Added a section on=20 Signaling of Auto-tunnel Mesh-group LSPs
>>>>
>>>= ;>=20 4.   Added clarification on Signaling of Inter-domain=20 Associated
>>> Bidirectional=20 LSPs
>>>>
>>>> 5.  The Extended ASSOCIAT= ION=20 object format with Association Type
>>> "Associated Bidirection= al=20 LSP". Clarified on how to populate
>>> different fields in this= =20 object.
>>>>
>>>>
>>>>> We= =20 believe that some of these changes were necessary to avoid the
>>&= gt;=20 interoperability issues due to potentially different=20 interpretations.
>>>>>
>>>>> Your revie= w=20 comments are welcome.
>>>>>
>>>>>=20 Thanks,
>>>>>=20 Rakesh
>>>>>
>>>>> -----Original=20 Message-----
>>>>> From: ccamp-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:ccamp-bounces@ietf.org">ccamp-bounces@ietf.org]=20 On
>>>>> Behalf Of internet-drafts@ietf.org
&g= t;>>>>=20 Sent: Wednesday, August 15, 2012 10:53 AM
>>>>> To: i-d-announce@ietf.org
>>= >>>=20 Cc: ccamp@ietf.org
>>>>= ;>=20 Subject: [CCAMP] I-D Action:
>>>>>=20 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>&g= t;>
>>>>>
>>>>>=20 A New Internet-Draft is available from the on-line=20 Internet-Drafts
>>> directories.
>>>>>  = This=20 draft is a work item of the Common Control and Measurement
>>> = Plane=20 Working Group of the IETF.
>>>>>
>>>>>= =20    Title           : RSVP-TE Extensions = for=20 Associated Bidirectional
>>> LSPs
>>>>>  = ;=20  Author(s)       : Fei Zhang
>>>>> &n= bsp;=20                      = ;=20   Ruiquan Jing
>>>>>         &nb= sp;=20                 Rakesh=20 Gandhi
>>>>>    Filename      =20  : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-
>>>=20 lsp-04.txt
>>>>>    Pages      = =20     : 17
>>>>>    Date    = =20        :=20 2012-08-15
>>>>>
>>>>>=20 Abstract:
>>>>>    The MPLS Transport Profile=20 (MPLS-TP) requirements document
>>>=20 [RFC5654],
>>>>>    describes that MPLS-TP MUST= =20 support associated bidirectional
>>> point-
>>>>= >=20    to-point LSPs.
>>>>>
>>>>>= =20    This document provides a method to bind two unidirectional=20 Label
>>>>>    Switched Paths (LSPs) into an=20 associated bidirectional LSP.  The
>>>>>  =20  association is achieved by defining the new Association Type=20 in
>>> the
>>>>>    Extended ASSOCI= ATION=20 object.
>>>>>
>>>>>
>>>>= >=20 The IETF datatracker status page for this draft is:
>>>>>= https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-r= svpte-
>>>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp
>>>>>
>>>>> There's also = a=20 htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-= ext-
>>>=20 associ
>>>>> a
>>>>>=20 ted-lsp-04
>>>>>
>>>>> A diff from the= =20 previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp= -rsvpte-
>>>=20 ext-
>>>>> a
>>>>>=20 ssociated-lsp-04
>>>>>
>>>>>
>>= ;>>>=20 Internet-Drafts are also available by anonymous FTP at:
>>>>= >=20 ftp://ftp.ietf.org/internet-drafts/
>>>>= >
>>>>>=20 _______________________________________________
>>>>> CCA= MP=20 mailing list
>>>>> CCAMP@ietf.org
>>>>> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ccamp"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ccamp
>>= >>>
>>>>>
>>>>>
>>>= ;>>
>>>>
>>>>
>>>>
&g= t;>>>
>>>=20 _______________________________________________
>>> CCAMP maili= ng=20 list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>=
>>
>>
>>
>=20 _______________________________________________
> CCAMP mailing=20 list
> CCAMP@ietf.org
> <= A=20 href=3D"https://www.ietf.org/mailman/listinfo/ccamp"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/ccamp
________= _______________________________________
CCAMP=20 mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp<= /P>

 

--_000_FE60A4E52763E84B935532D7D9294FF139268CC08EEUSAACMS0715e_-- From francesco.fondelli@gmail.com Sat Aug 18 09:33:11 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B473221F846E for ; Sat, 18 Aug 2012 09:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EaPNAlFO4Ir for ; Sat, 18 Aug 2012 09:33:10 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E78B21F846D for ; Sat, 18 Aug 2012 09:33:10 -0700 (PDT) Received: by dakr19 with SMTP id r19so1403768dak.31 for ; Sat, 18 Aug 2012 09:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iY7aLg4ih6ud5PFANTZwnwNCct5TIA/rAuvbk9IYpOA=; b=k9+pffPT+x7WHjAr6R2qen1sc8Qvop0xcwgy5Lx9BT2ePN0aV085UlM2o5exUeUrS4 fwyJIai8rz1+abGqiaNNiCbh3RM1fDyZXAEtl27/hlSpPD7gMnNzI0n4AygqgHxAolff AT8Ge8vHKPd5FByy9ct7BXVL/IU3rrUIhy5Zgof9JzpCkIUSyteBGUJVpwvUUCw1fyHB lQK2yj16i9Fa5O2UqVBFd9IejCYblMC2q/3sJRuQEJ9UCGJwniiMKuGcftDN8nsJW0JN wID9tT+/i2eDZcjh4MqM2E/NX67wupejXbm3o4YHvu71Gf1AtWaXDV165BN3k2bmW+UK QbWQ== MIME-Version: 1.0 Received: by 10.68.197.136 with SMTP id iu8mr13404303pbc.151.1345307590170; Sat, 18 Aug 2012 09:33:10 -0700 (PDT) Received: by 10.66.249.135 with HTTP; Sat, 18 Aug 2012 09:33:10 -0700 (PDT) In-Reply-To: References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> Date: Sat, 18 Aug 2012 18:33:10 +0200 Message-ID: From: Francesco Fondelli To: Greg Mirsky Content-Type: text/plain; charset=UTF-8 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 16:33:11 -0000 Hi Greg, "from a data-plane view point b) and c2) are the same thing" well, s/data-plane/ILM\\/NHLFE/ :-) Actually, I meant the forwarding component of the data-plane ... and whether CC/CV is part of the data-plane or not I'm sure is another point for debate... BTW, I'm following the interesting discussion about BFD modes and LSP types. thank you ciao FF On Fri, Aug 17, 2012 at 9:27 PM, Greg Mirsky wrote: > Hi Francesco, > "from a data-plane view point b) and c2) are the same thing" > I think that given that c) is associated bi-directional LSP that implies > independent OAM and protection for each direction, b) and c2) are not the > same in the data plane view. E.g., there will be single CC/CV/RDI session > for b) while c2) will have two sessions. And if linear protection requested, > b) will be protected by single bi-directional LSP, but c2) - by two > unidirectional LSPs. > > Regards, > Greg > > On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli > wrote: >> >> Hi All, >> >> I think I'm lost, please help. >> >> Rakesh is talking about "co-routed associated bidirectional >> LSP"... for the sake of clarity, let me try to categorize >> LSPs from a control plane view point: >> >> a) Point-to-point unidirectional >> b) Point-to-point co-routed bidirectional >> c) Point-to-point associated bidirectional >> c1) fwd and rev LSP follow different paths >> c2) fwd and rev LSP follow same path >> d) Point-to-multipoint unidirectional >> e) Multipoint-to-point unidirectional >> >> Is section 3.2.5 (Signaling of Co-routed LSPs) of >> mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? >> >> In my opinion: >> >> - b) should be signaled with 3473 >> - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) >> >> Am I missing something? >> >> thank you >> ciao >> fra >> >> PS >> from a data-plane view point b) and c2) are the same thing. >> >> On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) >> wrote: >> > Hi Lou, >> > >> > Thanks for initiating discussions on the changes in the draft. >> > >> > Agree with you here, if we/WG do not agree on the "co-routed associated >> > bidirectional LSP" part, we are ok to remove it from this draft and can >> > always submit a new draft just for that. We respect your/WG decision. >> > >> > Thanks, >> > Rakesh >> > >> > >> > >> > -----Original Message----- >> > From: Lou Berger [mailto:lberger@labn.net] >> > Sent: Thursday, August 16, 2012 6:08 PM >> > To: John E Drake >> > Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org >> > Subject: Re: [CCAMP] I-D Action: >> > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> > >> > John, >> > While strictly speaking WG drafts should only reflect current WG >> > consensus, and it is the WG draft editor's job to ensure this, in practice >> > authors/editors are given a lot of latitude in timing / ordering in >> > introduction to changes. I personally think this is a practical way of >> > keeping the process moving. Also if the WG disagrees with a change, it can >> > always be backed out. >> > >> > So, yes, the WG could do exactly as you say if it comes to it. (The >> > chairs can even appoint different editor if needed, e.g., to make this >> > happen.) While I'm not happy with how this revision came about, as I >> > covered in earlier mail, my feeling is to let the discussion take place on >> > the list (and at the next IETF, if needed) and then have the draft updated >> > to reflect the WG discussion/consensus. >> > >> > Lou >> > >> > On 8/16/2012 5:35 PM, John E Drake wrote: >> >> Lou, >> >> >> >> Since the WG did not agree to this changes, let alone discuss them, >> >> would it be possible to simply rollback these changes and ask the >> >> authors to write a draft addressing the topics you list in your email, >> >> below? >> >> >> >> Thanks, >> >> >> >> John >> >> >> >> Sent from my iPhone >> >> >> >> >> >>> -----Original Message----- >> >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >> >>> Behalf Of Lou Berger >> >>> Sent: Thursday, August 16, 2012 2:10 PM >> >>> To: Rakesh Gandhi (rgandhi) >> >>> Cc: ccamp@ietf.org >> >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >> >>> associated-lsp-04.txt >> >>> >> >>> Rakesh, >> >>> Such major changes (in scope and functionality) to WG drafts are >> >>> usually discussed with the WG prior to the authors/editors just >> >>> publishing the changes. But, this is a judgment call by the document >> >>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >> >>> the document accurately reflect the decisions that have been made by >> >>> the working group." >> >>> >> >>> So let's jump into discussing the changes. >> >>> >> >>> As I see it this draft introduces several major functional changes >> >>> that have not been discussed by the WG. Correct me if I get them >> >>> wrong, but I believe they include: >> >>> 1) Introduction of a second method for signaling Co-routed LSPs >> >>> 2) Support for FRR bypass tunnels for piggybacked on the TP >> >>> bidirectional LSP mechanisms. >> >>> >> >>> There are also other changes, but I'll defer discussing them >> >>> until the discussion on the above is concluded. >> >>> >> >>> Is this correct? >> >>> >> >>> Assuming yes, I have questions about both rational and specific >> >>> mechanisms. For now let's look at the former, so please: >> >>> >> >>> A) Articulate the issues/limitations with using the RFC3473 defined >> >>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >> >>> addressed. >> >>> >> >>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >> >>> >> >>> B.2) Articulate why this issue should be solved in a TP-specific and >> >>> not GMPLS generic fashion? >> >>> >> >>> Thanks, >> >>> Lou >> >>> >> >>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >> >>>> Hi Lou, >> >>>> >> >>>> Yes. >> >>>> >> >>>> Please advise if you think detailed email is required. >> >>>> We believe latest draft summarizes the changes well and we could >> >>> start review/discussions from there. >> >>>> >> >>>> Thanks, >> >>>> Rakesh >> >>>> >> >>>> >> >>>> -----Original Message----- >> >>>> From: Lou Berger [mailto:lberger@labn.net] >> >>>> Sent: Thursday, August 16, 2012 4:00 PM >> >>>> To: Rakesh Gandhi (rgandhi) >> >>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >> >>>> Subject: Re: [CCAMP] I-D Action: >> >>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >>>> >> >>>> Rakesh, >> >>>> Is this the start of the thread that I requested in >> >>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >> >>>> >> >>>> In particular, is it the response to: >> >>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >> >>>>> proposed change and the rational for each change (in one or in >> >>>>> separate e-mails). The WG discussion can then really begin on the >> >>>>> proposed changes. (Which are quite substantial both in scope and >> >>>>> implication.) >> >>>> >> >>>> Lou >> >>>> >> >>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >> >>>>> Hi All, >> >>>>> >> >>>>> We have uploaded a new version of this draft with following changes: >> >>>> >> >>>> 1. Added a section on Signaling of Co-routed LSPs >> >>>> >> >>>> 2. Added clarification on Signaling of Associated Bidirectional >> >>>> Protection LSPs >> >>>> >> >>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >> >>>> >> >>>> 4. Added clarification on Signaling of Inter-domain Associated >> >>> Bidirectional LSPs >> >>>> >> >>>> 5. The Extended ASSOCIATION object format with Association Type >> >>> "Associated Bidirectional LSP". Clarified on how to populate >> >>> different fields in this object. >> >>>> >> >>>> >> >>>>> We believe that some of these changes were necessary to avoid the >> >>> interoperability issues due to potentially different interpretations. >> >>>>> >> >>>>> Your review comments are welcome. >> >>>>> >> >>>>> Thanks, >> >>>>> Rakesh >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >> >>>>> Behalf Of internet-drafts@ietf.org >> >>>>> Sent: Wednesday, August 15, 2012 10:53 AM >> >>>>> To: i-d-announce@ietf.org >> >>>>> Cc: ccamp@ietf.org >> >>>>> Subject: [CCAMP] I-D Action: >> >>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >>>>> >> >>>>> >> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >> >>> directories. >> >>>>> This draft is a work item of the Common Control and Measurement >> >>> Plane Working Group of the IETF. >> >>>>> >> >>>>> Title : RSVP-TE Extensions for Associated Bidirectional >> >>> LSPs >> >>>>> Author(s) : Fei Zhang >> >>>>> Ruiquan Jing >> >>>>> Rakesh Gandhi >> >>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- >> >>> lsp-04.txt >> >>>>> Pages : 17 >> >>>>> Date : 2012-08-15 >> >>>>> >> >>>>> Abstract: >> >>>>> The MPLS Transport Profile (MPLS-TP) requirements document >> >>> [RFC5654], >> >>>>> describes that MPLS-TP MUST support associated bidirectional >> >>> point- >> >>>>> to-point LSPs. >> >>>>> >> >>>>> This document provides a method to bind two unidirectional Label >> >>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >> >>>>> association is achieved by defining the new Association Type in >> >>> the >> >>>>> Extended ASSOCIATION object. >> >>>>> >> >>>>> >> >>>>> The IETF datatracker status page for this draft is: >> >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >> >>> ext- >> >>>>> a >> >>>>> ssociated-lsp >> >>>>> >> >>>>> There's also a htmlized version available at: >> >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >> >>> associ >> >>>>> a >> >>>>> ted-lsp-04 >> >>>>> >> >>>>> A diff from the previous version is available at: >> >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte- >> >>> ext- >> >>>>> a >> >>>>> ssociated-lsp-04 >> >>>>> >> >>>>> >> >>>>> Internet-Drafts are also available by anonymous FTP at: >> >>>>> ftp://ftp.ietf.org/internet-drafts/ >> >>>>> >> >>>>> _______________________________________________ >> >>>>> CCAMP mailing list >> >>>>> CCAMP@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/ccamp >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>> _______________________________________________ >> >>> CCAMP mailing list >> >>> CCAMP@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> >> >> >> >> >> > _______________________________________________ >> > CCAMP mailing list >> > CCAMP@ietf.org >> > https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > From francesco.fondelli@gmail.com Sat Aug 18 09:54:13 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E7521F84AF for ; Sat, 18 Aug 2012 09:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUK1CydqOH9E for ; Sat, 18 Aug 2012 09:54:12 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8F321F84A6 for ; Sat, 18 Aug 2012 09:54:12 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so5098793pbb.31 for ; Sat, 18 Aug 2012 09:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+fvnFH1sVeGUHByvV0gXOpiB7HZRE6qDSySEU0pfrno=; b=Gsa8KlgbClrb922nCQJf93kLcWknvqedgcHTstzdwdWb2940PDSmPJHzSWtqxkxeMl Vt/nZwyO7ZhSWWghnfawcn2XqbWJ+y5BsIinhR/trDK286Fz2HODQa784Jpl7Lxg3fv9 n1kCUQ69LVc+Zfa7rSzzH+F9eQh3q4DnNI0zZYlbHyMbOHnpyGoexZJsZmHqjd8yfvqb zSKFG/VIl+kLyWNsWapmZzsHjM4utaXiG/dKPUn6/GsfcJRvEL/qftjz30/jIHYq37X1 yw1HmGMg39VkrPrNLrScrsX/PFJt7sHOTn8lImguxgwyJyHYJeGOUGF2vb6URDeDean4 /fTA== MIME-Version: 1.0 Received: by 10.68.229.228 with SMTP id st4mr13397282pbc.106.1345308851315; Sat, 18 Aug 2012 09:54:11 -0700 (PDT) Received: by 10.66.249.135 with HTTP; Sat, 18 Aug 2012 09:54:11 -0700 (PDT) In-Reply-To: <502E574E.90405@labn.net> References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <502D5125.6000105@labn.net> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <502E574E.90405@labn.net> Date: Sat, 18 Aug 2012 18:54:11 +0200 Message-ID: From: Francesco Fondelli To: Lou Berger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 16:54:13 -0000 Thank you. I think we are on the same page. Ciao Fra On Fri, Aug 17, 2012 at 4:38 PM, Lou Berger wrote: > Francesco, > > Nice summary. I think your last observation, about b and c2 bein= g the > same in the data plane, is the key one. Up to now, I don't know of > anyone or any draft that has suggested anything but using b for the > control plane representation of co-routed TP paths. The JWT even called > out using b. > > We had a lot of discussion (okay, arguments) about this in the early > days of GMPLS where we debated just using the then practice of using > EROs to provide a bidirectional co-routed data path using 2 > unidirectional control plane LSPs. Obviously the position of using (b) > won out. Largely because the b approach greatly simplified the control > plane for complex behaviors such as MBB, rerouting, recovery, etc. > > It does seem that the draft/proposal is in fact for c2, as confirmed by > Fei's mail. I was hoping that we could get someone to describe the > issue they are trying to address (perhaps as an intended usage scenario) > as well as why the added control plane complexity is a good idea. > Particularly as all the corner cases need to be addressed. > > Lou > > On 8/17/2012 4:48 AM, Francesco Fondelli wrote: >> Hi All, >> >> I think I'm lost, please help. >> >> Rakesh is talking about "co-routed associated bidirectional >> LSP"... for the sake of clarity, let me try to categorize >> LSPs from a control plane view point: >> >> a) Point-to-point unidirectional >> b) Point-to-point co-routed bidirectional >> c) Point-to-point associated bidirectional >> c1) fwd and rev LSP follow different paths >> c2) fwd and rev LSP follow same path >> d) Point-to-multipoint unidirectional >> e) Multipoint-to-point unidirectional >> >> Is section 3.2.5 (Signaling of Co-routed LSPs) of >> mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)? >> >> In my opinion: >> >> - b) should be signaled with 3473 >> - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp) >> >> Am I missing something? >> >> thank you >> ciao >> fra >> >> PS >> from a data-plane view point b) and c2) are the same thing. >> >> On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi) >> wrote: >>> Hi Lou, >>> >>> Thanks for initiating discussions on the changes in the draft. >>> >>> Agree with you here, if we/WG do not agree on the "co-routed associated= bidirectional LSP" part, we are ok to remove it from this draft and can al= ways submit a new draft just for that. We respect your/WG decision. >>> >>> Thanks, >>> Rakesh >>> >>> >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Thursday, August 16, 2012 6:08 PM >>> To: John E Drake >>> Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-as= sociated-lsp-04.txt >>> >>> John, >>> While strictly speaking WG drafts should only reflect current W= G consensus, and it is the WG draft editor's job to ensure this, in practic= e authors/editors are given a lot of latitude in timing / ordering in intro= duction to changes. I personally think this is a practical way of keeping = the process moving. Also if the WG disagrees with a change, it can always = be backed out. >>> >>> So, yes, the WG could do exactly as you say if it comes to it. (The ch= airs can even appoint different editor if needed, e.g., to make this >>> happen.) While I'm not happy with how this revision came about, as I c= overed in earlier mail, my feeling is to let the discussion take place on t= he list (and at the next IETF, if needed) and then have the draft updated t= o reflect the WG discussion/consensus. >>> >>> Lou >>> >>> On 8/16/2012 5:35 PM, John E Drake wrote: >>>> Lou, >>>> >>>> Since the WG did not agree to this changes, let alone discuss them, >>>> would it be possible to simply rollback these changes and ask the >>>> authors to write a draft addressing the topics you list in your email, >>>> below? >>>> >>>> Thanks, >>>> >>>> John >>>> >>>> Sent from my iPhone >>>> >>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf Of Lou Berger >>>>> Sent: Thursday, August 16, 2012 2:10 PM >>>>> To: Rakesh Gandhi (rgandhi) >>>>> Cc: ccamp@ietf.org >>>>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>>>> associated-lsp-04.txt >>>>> >>>>> Rakesh, >>>>> Such major changes (in scope and functionality) to WG drafts are >>>>> usually discussed with the WG prior to the authors/editors just >>>>> publishing the changes. But, this is a judgment call by the document >>>>> editors in how, quoting rfc2418, they "ensur[e] that the contents of >>>>> the document accurately reflect the decisions that have been made by >>>>> the working group." >>>>> >>>>> So let's jump into discussing the changes. >>>>> >>>>> As I see it this draft introduces several major functional changes >>>>> that have not been discussed by the WG. Correct me if I get them >>>>> wrong, but I believe they include: >>>>> 1) Introduction of a second method for signaling Co-routed LSPs >>>>> 2) Support for FRR bypass tunnels for piggybacked on the TP >>>>> bidirectional LSP mechanisms. >>>>> >>>>> There are also other changes, but I'll defer discussing them >>>>> until the discussion on the above is concluded. >>>>> >>>>> Is this correct? >>>>> >>>>> Assuming yes, I have questions about both rational and specific >>>>> mechanisms. For now let's look at the former, so please: >>>>> >>>>> A) Articulate the issues/limitations with using the RFC3473 defined >>>>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see >>>>> addressed. >>>>> >>>>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address? >>>>> >>>>> B.2) Articulate why this issue should be solved in a TP-specific and >>>>> not GMPLS generic fashion? >>>>> >>>>> Thanks, >>>>> Lou >>>>> >>>>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote: >>>>>> Hi Lou, >>>>>> >>>>>> Yes. >>>>>> >>>>>> Please advise if you think detailed email is required. >>>>>> We believe latest draft summarizes the changes well and we could >>>>> start review/discussions from there. >>>>>> >>>>>> Thanks, >>>>>> Rakesh >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>> Sent: Thursday, August 16, 2012 4:00 PM >>>>>> To: Rakesh Gandhi (rgandhi) >>>>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn >>>>>> Subject: Re: [CCAMP] I-D Action: >>>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>>> >>>>>> Rakesh, >>>>>> Is this the start of the thread that I requested in >>>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html >>>>>> >>>>>> In particular, is it the response to: >>>>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the >>>>>>> proposed change and the rational for each change (in one or in >>>>>>> separate e-mails). The WG discussion can then really begin on the >>>>>>> proposed changes. (Which are quite substantial both in scope and >>>>>>> implication.) >>>>>> >>>>>> Lou >>>>>> >>>>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> We have uploaded a new version of this draft with following changes= : >>>>>> >>>>>> 1. Added a section on Signaling of Co-routed LSPs >>>>>> >>>>>> 2. Added clarification on Signaling of Associated Bidirectional >>>>>> Protection LSPs >>>>>> >>>>>> 3. Added a section on Signaling of Auto-tunnel Mesh-group LSPs >>>>>> >>>>>> 4. Added clarification on Signaling of Inter-domain Associated >>>>> Bidirectional LSPs >>>>>> >>>>>> 5. The Extended ASSOCIATION object format with Association Type >>>>> "Associated Bidirectional LSP". Clarified on how to populate >>>>> different fields in this object. >>>>>> >>>>>> >>>>>>> We believe that some of these changes were necessary to avoid the >>>>> interoperability issues due to potentially different interpretations. >>>>>>> >>>>>>> Your review comments are welcome. >>>>>>> >>>>>>> Thanks, >>>>>>> Rakesh >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>>> Behalf Of internet-drafts@ietf.org >>>>>>> Sent: Wednesday, August 15, 2012 10:53 AM >>>>>>> To: i-d-announce@ietf.org >>>>>>> Cc: ccamp@ietf.org >>>>>>> Subject: [CCAMP] I-D Action: >>>>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>>>> This draft is a work item of the Common Control and Measurement >>>>> Plane Working Group of the IETF. >>>>>>> >>>>>>> Title : RSVP-TE Extensions for Associated Bidirectiona= l >>>>> LSPs >>>>>>> Author(s) : Fei Zhang >>>>>>> Ruiquan Jing >>>>>>> Rakesh Gandhi >>>>>>> Filename : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated= - >>>>> lsp-04.txt >>>>>>> Pages : 17 >>>>>>> Date : 2012-08-15 >>>>>>> >>>>>>> Abstract: >>>>>>> The MPLS Transport Profile (MPLS-TP) requirements document >>>>> [RFC5654], >>>>>>> describes that MPLS-TP MUST support associated bidirectional >>>>> point- >>>>>>> to-point LSPs. >>>>>>> >>>>>>> This document provides a method to bind two unidirectional Label >>>>>>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>>>>>> association is achieved by defining the new Association Type in >>>>> the >>>>>>> Extended ASSOCIATION object. >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte- >>>>> ext- >>>>>>> a >>>>>>> ssociated-lsp >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext- >>>>> associ >>>>>>> a >>>>>>> ted-lsp-04 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte- >>>>> ext- >>>>>>> a >>>>>>> ssociated-lsp-04 >>>>>>> >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> From zhang.fei3@zte.com.cn Mon Aug 20 04:32:32 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BC721F8605; Mon, 20 Aug 2012 04:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.255 X-Spam-Level: X-Spam-Status: No, score=-97.255 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AcBVlIhCtKy; Mon, 20 Aug 2012 04:32:30 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 59CBA21F8606; Mon, 20 Aug 2012 04:32:29 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 107231461793122; Mon, 20 Aug 2012 19:17:53 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 52685.7265085224; Mon, 20 Aug 2012 19:32:24 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7KBWLwK061980; Mon, 20 Aug 2012 19:32:21 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Gregory Mirsky , "Rakesh Gandhi (rgandhi)" MIME-Version: 1.0 X-KeepSent: 0485DDEE:87AAD383-48257A60:003E4523; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Mon, 20 Aug 2012 19:32:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-20 19:32:23, Serialize complete at 2012-08-20 19:32:23 Content-Type: multipart/alternative; boundary="=_alternative 003F50B348257A60_=" X-MAIL: mse02.zte.com.cn q7KBWLwK061980 Cc: "ccamp@ietf.org" , "ccamp-bounces@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 11:32:32 -0000 This is a multipart message in MIME format. --=_alternative 003F50B348257A60_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR3JlZw0KDQpTZWUgaW4gbGluZSB3aXRoIDxmZWk+DQoNClRoYW5rcw0KDQpGZWkNCg0KDQoN CkdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+IA0KMjAxMi0wOC0x OCAwMTo0NA0KDQrK1bz+yMsNCiJ6aGFuZy5mZWkzQHp0ZS5jb20uY24iIDx6aGFuZy5mZWkzQHp0 ZS5jb20uY24+LCBGcmFuY2VzY28gRm9uZGVsbGkgDQo8ZnJhbmNlc2NvLmZvbmRlbGxpQGdtYWls LmNvbT4NCrOty80NCiJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPiwgImNjYW1wLWJv dW5jZXNAaWV0Zi5vcmciIA0KPGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+DQrW98ziDQpSRTogW0ND QU1QXSBJLUQgQWN0aW9uOiANCmRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFz c29jaWF0ZWQtbHNwLTA0LnR4dA0KDQoNCg0KDQoNCg0KRGVhciBGZWksDQppZiB3ZSB0byBjb21w YXJlLCB1c2luZyBGcmFuY2VzY28ncyBlbnVtZXJhdGlvbiwgY2FzZXMgYikgYW5kIGMyKSwgdGhl biwgDQppbiBteSB2aWV3LCBkaWZmZXJlbmNlcyB3b3VsZCBiZSBpbjoNCmlkZW50aWZpZXJzDQo8 ZmVpPlllYWgsIHRoZSBpZGVudGlmaWVycyBhcmUgdXNlZCBpbiBjb250cm9sIHBsYW5lIGZvciBh c3NvY2lhdGlvbiBhbmQgDQp0aGUgbGFiZWwgZm9yd2FyZGluZyBpcyB0aGUgc2FtZSBpbiB0aGUg ZGF0YSBwbGFuZS4NCmNvb3JkaW5hdGVkIHZzLiBpbmRlcGVuZGVudCBtb25pdG9yaW5nIGFuZCBw cm90ZWN0aW9uDQo8ZmVpPkFjdHVhbGx5LCBib3RoIG9mIHRoZW0gYXJlIGFkZHJlc3NlZCBpbiB0 aGlzIHZlcnNpb24sIHNlZSBzZWN0aW9uIA0KMy4yLjQgZm9yIGluZGVwZW5kZW50IGFuZCBzZWN0 aW9uIDMuMi42IGZvciBjb29yZGluYXRlZC4NCg0KQnV0IEkgd291bGQgcXVlc3Rpb24gd2hldGhl ciBvcGVyYXRvcnMgd2lsbCB1c2UgaW5kZXBlbmRlbnQgbW9uaXRvcmluZyBhbmQgDQpwcm90ZWN0 aW9uIG9uLCB3aGF0IGxvb2tzIGV4YWN0bHkgbGlrZSwgYmktZGlyZWN0aW9uYWwgY28tcm91dGVk IExTUC4gSSANCnRoaW5rIHRoYXQgYzIpIGlzIG5vdCBhIHNlcGFyYXRlIGNhc2UsIGJ1dCByYXRo ZXIgImFuIGFjY2lkZW50Ii4gSWYgYW4gDQpvcGVyYXRvciB3YW50cyB0byBidWlsZCBjMikgaGUv c2hlIG5lZWRzIHRvIHVzZSBwcm9jZWR1cmVzIGRlZmluZWQgZm9yIGIpLg0KDQo8ZmVpPldlIG5l ZWQgdG8gaGVhcmUgb3BpbmlvbnMgZnJvbSB0aGUgb3BlcmF0b3JzLCBhbmQgb25lIG9mIFJla2Vz aCdzIA0KYXJndW1lbnQgaXMgbGlzdGVkIGJlbG93IGZvciByZWZlcmVuY2U6DQo8UkcxPiBJdCBp cyBmaW5lIHRvIGhhdmUgbm9uIGNvLXJvdXRlZCBhcyBkZWZhdWx0LiBSRkMgMzQ3MyBpcyBhIEdN UExTIA0Kc2lnbmFsaW5nIHByb2NlZHVyZS4gSXQgbWF5IG5vdCBiZSBvcHRpbWFsICB0byBoYXZl IHR3byBkaWZmZXJlbnQgDQpzaWduYWxpbmcgcHJvY2VkdXJlcywgb25lIGZvciBub24gY28tcm91 dGVkIChleHQgYXNzb2NpYXRlZCBvYmplY3QpIGFuZCANCm9uZSBmb3IgY28tcm91dGVkIChSRkMg MzQ3MykgcHJvY2VkdXJlcy4gQnkgYWRkaW5nIGEgZmxhZyBmb3IgY28tcm91dGVkLCANCnNhbWUg c2lnbmFsaW5nIChleHQgYXNzb2NpYXRlZCBvYmplY3QpIGNhbiBiZSB1c2VkIGZvciBib3RoIHdo aWNoIGlzIG5pY2UuIA0KV2UgYmVsaWV2ZSBjb21wYXJpbmcgb2YgUlJPIGNhbiBiZSBtaXNsZWFk aW5nIGJlY2F1c2UgdHdvIExTUHMgY2FuIGJlIG9uIA0KdGhlIHNhbWUgcGF0aCBldmVuIHRob3Vn aCBwcm92aXNpb25lZCB0byBiZSBub24gY28tcm91dGVkLiANCiANCiAgICBSZWdhcmRzLA0KICAg ICAgICBHcmVnDQoNCkZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQp6aGFuZy5mZWkzQHp0ZS5jb20uY24NClNl bnQ6IEZyaWRheSwgQXVndXN0IDE3LCAyMDEyIDI6MzEgQU0NClRvOiBGcmFuY2VzY28gRm9uZGVs bGkNCkNjOiBjY2FtcEBpZXRmLm9yZzsgY2NhbXAtYm91bmNlc0BpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtDQ0FNUF0gSS1EIEFjdGlvbjogDQpkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRl LWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCg0KDQpIaSBGcmFuY2VzY28sIHNuaXBwZWQgDQoN CklzIHNlY3Rpb24gMy4yLjUgKFNpZ25hbGluZyBvZiBDby1yb3V0ZWQgTFNQcykgb2YNCm1wbHMt dHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcCBhYm91dCBiKSBvciBpdCBpcyBhYm91dCBjMik/ IA0KDQo8ZmVpPiBJdCBpcyBhYm91dCBjMiksIGluIG90aGVyIHdvcmRzLCBpdCBpcyBTaWduYWxp bmcgb2YgYXNzb2NpYXRlZCANCmNvbmdydWVudCBMU1BzLiANCg0KQmVzdCANCg0KRmVpIA0KDQoN CkZyYW5jZXNjbyBGb25kZWxsaSA8ZnJhbmNlc2NvLmZvbmRlbGxpQGdtYWlsLmNvbT4gDQq3orz+ yMs6ICBjY2FtcC1ib3VuY2VzQGlldGYub3JnIA0KMjAxMi0wOC0xNyAxNjo0OCANCg0KDQrK1bz+ yMsNCiJSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSIgPHJnYW5kaGlAY2lzY28uY29tPiANCrOty80N CiJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPiANCtb3zOINClJlOiBbQ0NBTVBdIEkt RCBBY3Rpb246IA0KZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRl ZC1sc3AtMDQudHh0DQoNCg0KDQoNCg0KDQoNCg0KSGkgQWxsLA0KDQpJIHRoaW5rIEknbSBsb3N0 LCBwbGVhc2UgaGVscC4NCg0KUmFrZXNoIGlzIHRhbGtpbmcgYWJvdXQgImNvLXJvdXRlZCBhc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwNCkxTUCIuLi4gZm9yIHRoZSBzYWtlIG9mIGNsYXJpdHksIGxl dCBtZSB0cnkgdG8gY2F0ZWdvcml6ZQ0KTFNQcyBmcm9tIGEgY29udHJvbCBwbGFuZSB2aWV3IHBv aW50Og0KDQogYSkgUG9pbnQtdG8tcG9pbnQgdW5pZGlyZWN0aW9uYWwNCiBiKSBQb2ludC10by1w b2ludCBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KIGMpIFBvaW50LXRvLXBvaW50IGFzc29jaWF0 ZWQgYmlkaXJlY3Rpb25hbA0KICBjMSkgZndkIGFuZCByZXYgTFNQIGZvbGxvdyBkaWZmZXJlbnQg cGF0aHMNCiAgYzIpIGZ3ZCBhbmQgcmV2IExTUCBmb2xsb3cgc2FtZSBwYXRoDQogZCkgUG9pbnQt dG8tbXVsdGlwb2ludCB1bmlkaXJlY3Rpb25hbA0KIGUpIE11bHRpcG9pbnQtdG8tcG9pbnQgdW5p ZGlyZWN0aW9uYWwNCg0KSXMgc2VjdGlvbiAzLjIuNSAoU2lnbmFsaW5nIG9mIENvLXJvdXRlZCBM U1BzKSBvZg0KbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwIGFib3V0IGIpIG9yIGl0 IGlzIGFib3V0IGMyKT8NCg0KSW4gbXkgb3BpbmlvbjoNCg0KLSBiKSBzaG91bGQgYmUgc2lnbmFs ZWQgd2l0aCAzNDczDQotIGMpIGFyZSBhZGRyZXNzZWQgYnkgdGhpcyBJLUQgKG1wbHMtdHAtcnN2 cHRlLWV4dC1hc3NvY2lhdGVkLWxzcCkNCg0KQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KdGhh bmsgeW91DQpjaWFvDQpmcmENCg0KUFMNCmZyb20gYSBkYXRhLXBsYW5lIHZpZXcgcG9pbnQgYikg YW5kIGMyKSBhcmUgdGhlIHNhbWUgdGhpbmcuDQoNCk9uIEZyaSwgQXVnIDE3LCAyMDEyIGF0IDEy OjE2IEFNLCBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KPHJnYW5kaGlAY2lzY28uY29tPiB3cm90 ZToNCj4gSGkgTG91LA0KPg0KPiBUaGFua3MgZm9yIGluaXRpYXRpbmcgZGlzY3Vzc2lvbnMgb24g dGhlIGNoYW5nZXMgaW4gdGhlIGRyYWZ0Lg0KPg0KPiBBZ3JlZSB3aXRoIHlvdSBoZXJlLCBpZiB3 ZS9XRyBkbyBub3QgYWdyZWUgb24gdGhlICJjby1yb3V0ZWQgYXNzb2NpYXRlZCANCmJpZGlyZWN0 aW9uYWwgTFNQIiBwYXJ0LCB3ZSBhcmUgb2sgdG8gcmVtb3ZlIGl0IGZyb20gdGhpcyBkcmFmdCBh bmQgY2FuIA0KYWx3YXlzIHN1Ym1pdCBhIG5ldyBkcmFmdCBqdXN0IGZvciB0aGF0LiBXZSByZXNw ZWN0IHlvdXIvV0cgZGVjaXNpb24uDQo+DQo+IFRoYW5rcywNCj4gUmFrZXNoDQo+DQo+DQo+DQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzps YmVyZ2VyQGxhYm4ubmV0XQ0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDE2LCAyMDEyIDY6MDgg UE0NCj4gVG86IEpvaG4gRSBEcmFrZQ0KPiBDYzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSk7IGNj YW1wQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBBY3Rpb246IA0KZHJhZnQt aWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQo+DQo+ IEpvaG4sDQo+ICAgICAgICAgV2hpbGUgc3RyaWN0bHkgc3BlYWtpbmcgV0cgZHJhZnRzIHNob3Vs ZCBvbmx5IHJlZmxlY3QgY3VycmVudCBXRyANCmNvbnNlbnN1cywgYW5kIGl0IGlzIHRoZSBXRyBk cmFmdCBlZGl0b3IncyBqb2IgdG8gZW5zdXJlIHRoaXMsIGluIHByYWN0aWNlIA0KYXV0aG9ycy9l ZGl0b3JzIGFyZSBnaXZlbiBhIGxvdCBvZiBsYXRpdHVkZSBpbiB0aW1pbmcgLyBvcmRlcmluZyBp biANCmludHJvZHVjdGlvbiB0byBjaGFuZ2VzLiAgSSBwZXJzb25hbGx5IHRoaW5rIHRoaXMgaXMg YSBwcmFjdGljYWwgd2F5IG9mIA0Ka2VlcGluZyB0aGUgcHJvY2VzcyBtb3ZpbmcuICBBbHNvIGlm IHRoZSBXRyBkaXNhZ3JlZXMgd2l0aCBhIGNoYW5nZSwgaXQgDQpjYW4gYWx3YXlzIGJlIGJhY2tl ZCBvdXQuDQo+DQo+IFNvLCB5ZXMsIHRoZSBXRyBjb3VsZCBkbyBleGFjdGx5IGFzIHlvdSBzYXkg aWYgaXQgY29tZXMgdG8gaXQuICAoVGhlIA0KY2hhaXJzIGNhbiBldmVuIGFwcG9pbnQgZGlmZmVy ZW50IGVkaXRvciBpZiBuZWVkZWQsIGUuZy4sIHRvIG1ha2UgdGhpcw0KPiBoYXBwZW4uKSAgV2hp bGUgSSdtIG5vdCBoYXBweSB3aXRoIGhvdyB0aGlzIHJldmlzaW9uIGNhbWUgYWJvdXQsIGFzIEkg DQpjb3ZlcmVkIGluIGVhcmxpZXIgbWFpbCwgbXkgZmVlbGluZyBpcyB0byBsZXQgdGhlIGRpc2N1 c3Npb24gdGFrZSBwbGFjZSBvbiANCnRoZSBsaXN0IChhbmQgYXQgdGhlIG5leHQgSUVURiwgaWYg bmVlZGVkKSBhbmQgdGhlbiBoYXZlIHRoZSBkcmFmdCB1cGRhdGVkIA0KdG8gcmVmbGVjdCB0aGUg V0cgZGlzY3Vzc2lvbi9jb25zZW5zdXMuDQo+DQo+IExvdQ0KPg0KPiBPbiA4LzE2LzIwMTIgNToz NSBQTSwgSm9obiBFIERyYWtlIHdyb3RlOg0KPj4gTG91LA0KPj4NCj4+IFNpbmNlIHRoZSBXRyBk aWQgbm90IGFncmVlIHRvIHRoaXMgY2hhbmdlcywgbGV0IGFsb25lIGRpc2N1c3MgdGhlbSwNCj4+ IHdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIHNpbXBseSByb2xsYmFjayB0aGVzZSBjaGFuZ2VzIGFu ZCBhc2sgdGhlDQo+PiBhdXRob3JzIHRvIHdyaXRlIGEgZHJhZnQgYWRkcmVzc2luZyB0aGUgdG9w aWNzIHlvdSBsaXN0IGluIHlvdXIgZW1haWwsDQo+PiBiZWxvdz8NCj4+DQo+PiBUaGFua3MsDQo+ Pg0KPj4gSm9obg0KPj4NCj4+IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4+DQo+Pg0KPj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj4gQmVoYWxmIE9mIExvdSBCZXJn ZXINCj4+PiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDE2LCAyMDEyIDI6MTAgUE0NCj4+PiBUbzog UmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCj4+PiBDYzogY2NhbXBAaWV0Zi5vcmcNCj4+PiBTdWJq ZWN0OiBSZTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2 cHRlLWV4dC0NCj4+PiBhc3NvY2lhdGVkLWxzcC0wNC50eHQNCj4+Pg0KPj4+IFJha2VzaCwNCj4+ PiAgICAgIFN1Y2ggbWFqb3IgY2hhbmdlcyAoaW4gc2NvcGUgYW5kIGZ1bmN0aW9uYWxpdHkpIHRv IFdHIGRyYWZ0cyBhcmUNCj4+PiB1c3VhbGx5IGRpc2N1c3NlZCB3aXRoIHRoZSBXRyBwcmlvciB0 byB0aGUgYXV0aG9ycy9lZGl0b3JzIGp1c3QNCj4+PiBwdWJsaXNoaW5nIHRoZSBjaGFuZ2VzLiAg QnV0LCB0aGlzIGlzIGEganVkZ21lbnQgY2FsbCBieSB0aGUgZG9jdW1lbnQNCj4+PiBlZGl0b3Jz IGluIGhvdywgcXVvdGluZyByZmMyNDE4LCB0aGV5ICJlbnN1cltlXSB0aGF0IHRoZSBjb250ZW50 cyBvZg0KPj4+IHRoZSBkb2N1bWVudCBhY2N1cmF0ZWx5IHJlZmxlY3QgdGhlIGRlY2lzaW9ucyB0 aGF0IGhhdmUgYmVlbiBtYWRlIGJ5DQo+Pj4gdGhlIHdvcmtpbmcgZ3JvdXAuIg0KPj4+DQo+Pj4g U28gbGV0J3MganVtcCBpbnRvIGRpc2N1c3NpbmcgdGhlIGNoYW5nZXMuDQo+Pj4NCj4+PiBBcyBJ IHNlZSBpdCB0aGlzIGRyYWZ0IGludHJvZHVjZXMgc2V2ZXJhbCBtYWpvciBmdW5jdGlvbmFsIGNo YW5nZXMNCj4+PiB0aGF0IGhhdmUgbm90IGJlZW4gZGlzY3Vzc2VkIGJ5IHRoZSBXRy4gIENvcnJl Y3QgbWUgaWYgSSBnZXQgdGhlbQ0KPj4+IHdyb25nLCBidXQgSSBiZWxpZXZlIHRoZXkgaW5jbHVk ZToNCj4+PiAxKSBJbnRyb2R1Y3Rpb24gb2YgYSBzZWNvbmQgbWV0aG9kIGZvciBzaWduYWxpbmcg Q28tcm91dGVkIExTUHMNCj4+PiAyKSBTdXBwb3J0IGZvciBGUlIgYnlwYXNzIHR1bm5lbHMgZm9y IHBpZ2d5YmFja2VkIG9uIHRoZSBUUA0KPj4+IGJpZGlyZWN0aW9uYWwgTFNQIG1lY2hhbmlzbXMu DQo+Pj4NCj4+PiAgICBUaGVyZSBhcmUgYWxzbyBvdGhlciBjaGFuZ2VzLCBidXQgSSdsbCBkZWZl ciBkaXNjdXNzaW5nIHRoZW0NCj4+PiAgICB1bnRpbCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgYWJv dmUgaXMgY29uY2x1ZGVkLg0KPj4+DQo+Pj4gSXMgdGhpcyBjb3JyZWN0Pw0KPj4+DQo+Pj4gQXNz dW1pbmcgeWVzLCBJIGhhdmUgcXVlc3Rpb25zIGFib3V0IGJvdGggcmF0aW9uYWwgYW5kIHNwZWNp ZmljDQo+Pj4gbWVjaGFuaXNtcy4gIEZvciBub3cgbGV0J3MgbG9vayBhdCB0aGUgZm9ybWVyLCBz byBwbGVhc2U6DQo+Pj4NCj4+PiBBKSBBcnRpY3VsYXRlIHRoZSBpc3N1ZXMvbGltaXRhdGlvbnMg d2l0aCB1c2luZyB0aGUgUkZDMzQ3MyBkZWZpbmVkDQo+Pj4gbWVjaGFuaXNtcyBmb3IgKGNvLXJv dXRlZCkgYmlkaXJlY3Rpb25hbCBMU1BzIHRoYXQgeW91J2QgbGlrZSB0byBzZWUNCj4+PiBhZGRy ZXNzZWQuDQo+Pj4NCj4+PiBCLjEpIEFydGljdWxhdGUgdGhlIEZSUi9HTVBMUy1yZWxhdGVkIGlz c3VlIHlvdSdkIGxpa2UgdG8gYWRkcmVzcz8NCj4+Pg0KPj4+IEIuMikgQXJ0aWN1bGF0ZSB3aHkg dGhpcyBpc3N1ZSBzaG91bGQgYmUgc29sdmVkIGluIGEgVFAtc3BlY2lmaWMgYW5kDQo+Pj4gbm90 IEdNUExTIGdlbmVyaWMgZmFzaGlvbj8NCj4+Pg0KPj4+IFRoYW5rcywNCj4+PiBMb3UNCj4+Pg0K Pj4+IE9uIDgvMTYvMjAxMiA0OjI2IFBNLCBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSB3cm90ZToN Cj4+Pj4gSGkgTG91LA0KPj4+Pg0KPj4+PiBZZXMuDQo+Pj4+DQo+Pj4+IFBsZWFzZSBhZHZpc2Ug aWYgeW91IHRoaW5rIGRldGFpbGVkIGVtYWlsIGlzIHJlcXVpcmVkLg0KPj4+PiBXZSBiZWxpZXZl IGxhdGVzdCBkcmFmdCBzdW1tYXJpemVzIHRoZSBjaGFuZ2VzIHdlbGwgYW5kIHdlIGNvdWxkDQo+ Pj4gc3RhcnQgcmV2aWV3L2Rpc2N1c3Npb25zIGZyb20gdGhlcmUuDQo+Pj4+DQo+Pj4+IFRoYW5r cywNCj4+Pj4gUmFrZXNoDQo+Pj4+DQo+Pj4+DQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPj4+ PiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDE2LCAyMDEyIDQ6MDAgUE0NCj4+Pj4gVG86IFJha2Vz aCBHYW5kaGkgKHJnYW5kaGkpDQo+Pj4+IENjOiBjY2FtcEBpZXRmLm9yZzsgemhhbmcuZmVpM0B6 dGUuY29tLmNuDQo+Pj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBBY3Rpb246DQo+Pj4+IGRy YWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0K Pj4+Pg0KPj4+PiBSYWtlc2gsDQo+Pj4+ICAgICBJcyB0aGlzIHRoZSBzdGFydCBvZiB0aGUgdGhy ZWFkIHRoYXQgSSByZXF1ZXN0ZWQgaW4NCj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL2NjYW1wL2N1cnJlbnQvbXNnMTM3MjkuaHRtbA0KPj4+Pg0KPj4+PiBJbiBwYXJ0 aWN1bGFyLCBpcyBpdCB0aGUgcmVzcG9uc2UgdG86DQo+Pj4+PiBJJ2QgbGlrZSB0byBhc2sgdGhh dCBzb21lb25lIChSYWtlc2gsIEZlaSwgZXRjLikgcmV2aWV3IGVhY2ggb2YgdGhlDQo+Pj4+PiBw cm9wb3NlZCBjaGFuZ2UgYW5kIHRoZSByYXRpb25hbCBmb3IgZWFjaCBjaGFuZ2UgKGluIG9uZSBv ciBpbg0KPj4+Pj4gc2VwYXJhdGUgZS1tYWlscykuIFRoZSBXRyBkaXNjdXNzaW9uIGNhbiB0aGVu IHJlYWxseSBiZWdpbiBvbiB0aGUNCj4+Pj4+IHByb3Bvc2VkIGNoYW5nZXMuIChXaGljaCBhcmUg cXVpdGUgc3Vic3RhbnRpYWwgYm90aCBpbiBzY29wZSBhbmQNCj4+Pj4+IGltcGxpY2F0aW9uLikN Cj4+Pj4NCj4+Pj4gTG91DQo+Pj4+DQo+Pj4+IE9uIDgvMTYvMjAxMiAzOjE5IFBNLCBSYWtlc2gg R2FuZGhpIChyZ2FuZGhpKSB3cm90ZToNCj4+Pj4+IEhpIEFsbCwNCj4+Pj4+DQo+Pj4+PiBXZSBo YXZlIHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gb2YgdGhpcyBkcmFmdCB3aXRoIGZvbGxvd2luZyBj aGFuZ2VzOg0KPj4+Pg0KPj4+PiAxLiAgQWRkZWQgYSBzZWN0aW9uIG9uIFNpZ25hbGluZyBvZiBD by1yb3V0ZWQgTFNQcw0KPj4+Pg0KPj4+PiAyLiAgQWRkZWQgY2xhcmlmaWNhdGlvbiBvbiBTaWdu YWxpbmcgb2YgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsDQo+Pj4+IFByb3RlY3Rpb24gTFNQcw0K Pj4+Pg0KPj4+PiAzLiAgQWRkZWQgYSBzZWN0aW9uIG9uIFNpZ25hbGluZyBvZiBBdXRvLXR1bm5l bCBNZXNoLWdyb3VwIExTUHMNCj4+Pj4NCj4+Pj4gNC4gICBBZGRlZCBjbGFyaWZpY2F0aW9uIG9u IFNpZ25hbGluZyBvZiBJbnRlci1kb21haW4gQXNzb2NpYXRlZA0KPj4+IEJpZGlyZWN0aW9uYWwg TFNQcw0KPj4+Pg0KPj4+PiA1LiAgVGhlIEV4dGVuZGVkIEFTU09DSUFUSU9OIG9iamVjdCBmb3Jt YXQgd2l0aCBBc3NvY2lhdGlvbiBUeXBlDQo+Pj4gIkFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBM U1AiLiBDbGFyaWZpZWQgb24gaG93IHRvIHBvcHVsYXRlDQo+Pj4gZGlmZmVyZW50IGZpZWxkcyBp biB0aGlzIG9iamVjdC4NCj4+Pj4NCj4+Pj4NCj4+Pj4+IFdlIGJlbGlldmUgdGhhdCBzb21lIG9m IHRoZXNlIGNoYW5nZXMgd2VyZSBuZWNlc3NhcnkgdG8gYXZvaWQgdGhlDQo+Pj4gaW50ZXJvcGVy YWJpbGl0eSBpc3N1ZXMgZHVlIHRvIHBvdGVudGlhbGx5IGRpZmZlcmVudCBpbnRlcnByZXRhdGlv bnMuDQo+Pj4+Pg0KPj4+Pj4gWW91ciByZXZpZXcgY29tbWVudHMgYXJlIHdlbGNvbWUuDQo+Pj4+ Pg0KPj4+Pj4gVGhhbmtzLA0KPj4+Pj4gUmFrZXNoDQo+Pj4+Pg0KPj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+Pj4gQmVoYWxmIE9mIGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZw0KPj4+Pj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTUsIDIwMTIgMTA6 NTMgQU0NCj4+Pj4+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+Pj4+IENjOiBjY2FtcEBp ZXRmLm9yZw0KPj4+Pj4gU3ViamVjdDogW0NDQU1QXSBJLUQgQWN0aW9uOg0KPj4+Pj4gZHJhZnQt aWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQo+Pj4+ Pg0KPj4+Pj4NCj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRo ZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPj4+IGRpcmVjdG9yaWVzLg0KPj4+Pj4gIFRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENvbW1vbiBDb250cm9sIGFuZCBNZWFzdXJlbWVu dA0KPj4+IFBsYW5lIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+Pj4+Pg0KPj4+Pj4gICAg VGl0bGUgICAgICAgICAgIDogUlNWUC1URSBFeHRlbnNpb25zIGZvciBBc3NvY2lhdGVkIEJpZGly ZWN0aW9uYWwNCj4+PiBMU1BzDQo+Pj4+PiAgICBBdXRob3IocykgICAgICAgOiBGZWkgWmhhbmcN Cj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgUnVpcXVhbiBKaW5nDQo+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgIFJha2VzaCBHYW5kaGkNCj4+Pj4+ICAgIEZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtDQo+ Pj4gbHNwLTA0LnR4dA0KPj4+Pj4gICAgUGFnZXMgICAgICAgICAgIDogMTcNCj4+Pj4+ICAgIERh dGUgICAgICAgICAgICA6IDIwMTItMDgtMTUNCj4+Pj4+DQo+Pj4+PiBBYnN0cmFjdDoNCj4+Pj4+ ICAgIFRoZSBNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSByZXF1aXJlbWVudHMgZG9j dW1lbnQNCj4+PiBbUkZDNTY1NF0sDQo+Pj4+PiAgICBkZXNjcmliZXMgdGhhdCBNUExTLVRQIE1V U1Qgc3VwcG9ydCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCj4+PiBwb2ludC0NCj4+Pj4+ICAg IHRvLXBvaW50IExTUHMuDQo+Pj4+Pg0KPj4+Pj4gICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBh IG1ldGhvZCB0byBiaW5kIHR3byB1bmlkaXJlY3Rpb25hbCBMYWJlbA0KPj4+Pj4gICAgU3dpdGNo ZWQgUGF0aHMgKExTUHMpIGludG8gYW4gYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUC4gIFRo ZQ0KPj4+Pj4gICAgYXNzb2NpYXRpb24gaXMgYWNoaWV2ZWQgYnkgZGVmaW5pbmcgdGhlIG5ldyBB c3NvY2lhdGlvbiBUeXBlIGluDQo+Pj4gdGhlDQo+Pj4+PiAgICBFeHRlbmRlZCBBU1NPQ0lBVElP TiBvYmplY3QuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1 cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS0NCj4+PiBleHQtDQo+Pj4+ PiBhDQo+Pj4+PiBzc29jaWF0ZWQtbHNwDQo+Pj4+Pg0KPj4+Pj4gVGhlcmUncyBhbHNvIGEgaHRt bGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+Pj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC0NCj4+PiBhc3NvY2kNCj4+ Pj4+IGENCj4+Pj4+IHRlZC1sc3AtMDQNCj4+Pj4+DQo+Pj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJl dmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+Pj4+PiBodHRwOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLQ0KPj4+IGV4dC0N Cj4+Pj4+IGENCj4+Pj4+IHNzb2NpYXRlZC1sc3AtMDQNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gSW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+ Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pj4+DQo+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gQ0NBTVAg bWFpbGluZyBsaXN0DQo+Pj4+PiBDQ0FNUEBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4N Cj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4+IENDQU1QQGll dGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0K Pj4NCj4+DQo+Pg0KPj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+IENDQU1QQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1Q QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoN Cg0KDQo= --=_alternative 003F50B348257A60_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdyZWc8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNlZSBpbiBsaW5lIHdpdGggJmx0 O2ZlaSZndDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlRoYW5rczwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ RmVpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxi PkdyZWdvcnkgTWlyc2t5ICZsdDtncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20mZ3Q7PC9iPg0K PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDgtMTggMDE6 NDQ8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+JnF1b3Q7emhhbmcuZmVpM0B6dGUuY29tLmNuJnF1b3Q7ICZsdDt6aGFuZy5mZWkzQHp0ZS5j b20uY24mZ3Q7LA0KRnJhbmNlc2NvIEZvbmRlbGxpICZsdDtmcmFuY2VzY28uZm9uZGVsbGlAZ21h aWwuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Y2NhbXBAaWV0Zi5vcmcmcXVvdDsg Jmx0O2NjYW1wQGlldGYub3JnJmd0OywNCiZxdW90O2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmcmcXVv dDsgJmx0O2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W 98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTog W0NDQU1QXSBJLUQgQWN0aW9uOiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ZHJhZnQtaWV0 Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0PC9mb250Pjwv dGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxl Pg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT0iQXJpYWwiPkRlYXIgRmVpLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPSJBcmlhbCI+aWYgd2UgdG8gY29tcGFyZSwgdXNpbmcgRnJhbmNlc2NvJ3MNCmVudW1l cmF0aW9uLCBjYXNlcyBiKSBhbmQgYzIpLCB0aGVuLCBpbiBteSB2aWV3LCBkaWZmZXJlbmNlcyB3 b3VsZCBiZSBpbjo8L2ZvbnQ+DQo8dWw+DQo8bGk+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT0iQXJpYWwiPmlkZW50aWZpZXJzPC9mb250PjwvdWw+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZsdDtmZWkmZ3Q7WWVhaCwNCnRoZSBpZGVudGlmaWVycyBhcmUgdXNlZCBpbiBjb250 cm9sIHBsYW5lIGZvciBhc3NvY2lhdGlvbiBhbmQgdGhlIGxhYmVsDQpmb3J3YXJkaW5nIGlzIHRo ZSBzYW1lIGluIHRoZSBkYXRhIHBsYW5lLjwvZm9udD4NCjx1bD4NCjxsaT48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+Y29vcmRpbmF0ZWQgdnMuIGluZGVwZW5kZW50IG1vbml0 b3JpbmcNCmFuZCBwcm90ZWN0aW9uPC9mb250PjwvdWw+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZsdDtmZWkmZ3Q7QWN0dWFsbHksDQpib3RoIG9mIHRoZW0gYXJlIGFkZHJlc3NlZCBp biB0aGlzIHZlcnNpb24sIHNlZSBzZWN0aW9uIDMuMi40IGZvciBpbmRlcGVuZGVudA0KYW5kIHNl Y3Rpb24gMy4yLjYgZm9yIGNvb3JkaW5hdGVkLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+QnV0IEkgd291bGQgcXVlc3Rpb24gd2hldGhlciBv cGVyYXRvcnMNCndpbGwgdXNlIGluZGVwZW5kZW50IG1vbml0b3JpbmcgYW5kIHByb3RlY3Rpb24g b24sIHdoYXQgbG9va3MgZXhhY3RseSBsaWtlLA0KYmktZGlyZWN0aW9uYWwgY28tcm91dGVkIExT UC4gSSB0aGluayB0aGF0IGMyKSBpcyBub3QgYSBzZXBhcmF0ZSBjYXNlLA0KYnV0IHJhdGhlciAm cXVvdDthbiBhY2NpZGVudCZxdW90Oy4gSWYgYW4gb3BlcmF0b3Igd2FudHMgdG8gYnVpbGQgYzIp IGhlL3NoZQ0KbmVlZHMgdG8gdXNlIHByb2NlZHVyZXMgZGVmaW5lZCBmb3IgYikuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7ZmVpJmd0O1dlIG5l ZWQgdG8gaGVhcmUgb3BpbmlvbnMNCmZyb20gdGhlIG9wZXJhdG9ycywgYW5kIG9uZSBvZiBSZWtl c2gncyBhcmd1bWVudCBpcyBsaXN0ZWQgYmVsb3cgZm9yIHJlZmVyZW5jZTo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPSNjMDUwNGQgZmFjZT0iQ2FsaWJyaSI+Jmx0O1JHMSZndDsgSXQg aXMgZmluZSB0bw0KaGF2ZSBub24gY28tcm91dGVkIGFzIGRlZmF1bHQuIFJGQyAzNDczIGlzIGEg R01QTFMgc2lnbmFsaW5nIHByb2NlZHVyZS4NCkl0IG1heSBub3QgYmUgb3B0aW1hbCAmbmJzcDt0 byBoYXZlIHR3byBkaWZmZXJlbnQgc2lnbmFsaW5nIHByb2NlZHVyZXMsDQpvbmUgZm9yIG5vbiBj by1yb3V0ZWQgKGV4dCBhc3NvY2lhdGVkIG9iamVjdCkgYW5kIG9uZSBmb3IgY28tcm91dGVkIChS RkMNCjM0NzMpIHByb2NlZHVyZXMuIEJ5IGFkZGluZyBhIGZsYWcgZm9yIGNvLXJvdXRlZCwgc2Ft ZSBzaWduYWxpbmcgKGV4dCBhc3NvY2lhdGVkDQpvYmplY3QpIGNhbiBiZSB1c2VkIGZvciBib3Ro IHdoaWNoIGlzIG5pY2UuIFdlIGJlbGlldmUgY29tcGFyaW5nIG9mIFJSTw0KY2FuIGJlIG1pc2xl YWRpbmcgYmVjYXVzZSB0d28gTFNQcyBjYW4gYmUgb24gdGhlIHNhbWUgcGF0aCBldmVuIHRob3Vn aA0KcHJvdmlzaW9uZWQgdG8gYmUgbm9uIGNvLXJvdXRlZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyA8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPlJlZ2FyZHMsPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5HcmVnPC9mb250 Pg0KPGJyPg0KPGJyPg0KPGhyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9i PiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+emhhbmcuZmVpM0B6dGUuY29tLmNuPGI+PGJyPg0KU2VudDo8 L2I+IEZyaWRheSwgQXVndXN0IDE3LCAyMDEyIDI6MzEgQU08Yj48YnI+DQpUbzo8L2I+IEZyYW5j ZXNjbyBGb25kZWxsaTxiPjxicj4NCkNjOjwvYj4gY2NhbXBAaWV0Zi5vcmc7IGNjYW1wLWJvdW5j ZXNAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtDQ0FNUF0gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0 PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpIEZyYW5jZXNjbywgc25pcHBl ZDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48dHQ+ PGZvbnQgc2l6ZT0yPjxicj4NCklzIHNlY3Rpb24gMy4yLjUgKFNpZ25hbGluZyBvZiBDby1yb3V0 ZWQgTFNQcykgb2Y8YnI+DQptcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AgYWJvdXQg Yikgb3IgaXQgaXMgYWJvdXQgYzIpPzwvZm9udD48L3R0Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQombHQ7ZmVpJmd0OyBJdCBpcyBhYm91dCBjMiksIGluIG90aGVyIHdvcmRz LCBpdCBpcyA8L2ZvbnQ+PHR0Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPlNpZ25hbGluZw0Kb2Yg YXNzb2NpYXRlZCBjb25ncnVlbnQgTFNQcy48L2ZvbnQ+PC90dD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NCkJlc3QgPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkZlaTwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCjwvZm9udD4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzglPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj48Yj5GcmFuY2VzY28gRm9uZGVsbGkgJmx0O2ZyYW5jZXNjby5mb25k ZWxsaUBnbWFpbC5jb20mZ3Q7PC9iPg0KPGJyPg0Kt6K8/sjLOiAmbmJzcDtjY2FtcC1ib3VuY2Vz QGlldGYub3JnPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4N CjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTA4LTE3IDE2OjQ4PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ZCB3aWR0aD02MSU+ DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTYl Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL PC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTkzJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+JnF1b3Q7UmFrZXNoIEdhbmRoaSAocmdhbmRoaSkmcXVvdDsNCiZsdDtyZ2FuZGhpQGNpc2Nv LmNvbSZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPiZxdW90O2NjYW1wQGlldGYub3JnJnF1b3Q7ICZsdDtjY2FtcEBpZXRmLm9yZyZn dDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5SZTogW0NDQU1QXSBJLUQgQWN0aW9uOiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 ZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0 PC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48L3Rh YmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8L2Zv bnQ+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpIaSBBbGwsPGJyPg0KPGJyPg0KSSB0aGluayBJJ20g bG9zdCwgcGxlYXNlIGhlbHAuPGJyPg0KPGJyPg0KUmFrZXNoIGlzIHRhbGtpbmcgYWJvdXQgJnF1 b3Q7Y28tcm91dGVkIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbDxicj4NCkxTUCZxdW90Oy4uLiBm b3IgdGhlIHNha2Ugb2YgY2xhcml0eSwgbGV0IG1lIHRyeSB0byBjYXRlZ29yaXplPGJyPg0KTFNQ cyBmcm9tIGEgY29udHJvbCBwbGFuZSB2aWV3IHBvaW50Ojxicj4NCjxicj4NCiBhKSBQb2ludC10 by1wb2ludCB1bmlkaXJlY3Rpb25hbDxicj4NCiBiKSBQb2ludC10by1wb2ludCBjby1yb3V0ZWQg YmlkaXJlY3Rpb25hbDxicj4NCiBjKSBQb2ludC10by1wb2ludCBhc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWw8YnI+DQogJm5ic3A7YzEpIGZ3ZCBhbmQgcmV2IExTUCBmb2xsb3cgZGlmZmVyZW50IHBh dGhzPGJyPg0KICZuYnNwO2MyKSBmd2QgYW5kIHJldiBMU1AgZm9sbG93IHNhbWUgcGF0aDxicj4N CiBkKSBQb2ludC10by1tdWx0aXBvaW50IHVuaWRpcmVjdGlvbmFsPGJyPg0KIGUpIE11bHRpcG9p bnQtdG8tcG9pbnQgdW5pZGlyZWN0aW9uYWw8YnI+DQo8YnI+DQpJcyBzZWN0aW9uIDMuMi41IChT aWduYWxpbmcgb2YgQ28tcm91dGVkIExTUHMpIG9mPGJyPg0KbXBscy10cC1yc3ZwdGUtZXh0LWFz c29jaWF0ZWQtbHNwIGFib3V0IGIpIG9yIGl0IGlzIGFib3V0IGMyKT88YnI+DQo8YnI+DQpJbiBt eSBvcGluaW9uOjxicj4NCjxicj4NCi0gYikgc2hvdWxkIGJlIHNpZ25hbGVkIHdpdGggMzQ3Mzxi cj4NCi0gYykgYXJlIGFkZHJlc3NlZCBieSB0aGlzIEktRCAobXBscy10cC1yc3ZwdGUtZXh0LWFz c29jaWF0ZWQtbHNwKTxicj4NCjxicj4NCkFtIEkgbWlzc2luZyBzb21ldGhpbmc/PGJyPg0KPGJy Pg0KdGhhbmsgeW91PGJyPg0KY2lhbzxicj4NCmZyYTxicj4NCjxicj4NClBTPGJyPg0KZnJvbSBh IGRhdGEtcGxhbmUgdmlldyBwb2ludCBiKSBhbmQgYzIpIGFyZSB0aGUgc2FtZSB0aGluZy48YnI+ DQo8YnI+DQpPbiBGcmksIEF1ZyAxNywgMjAxMiBhdCAxMjoxNiBBTSwgUmFrZXNoIEdhbmRoaSAo cmdhbmRoaSk8YnI+DQombHQ7cmdhbmRoaUBjaXNjby5jb20mZ3Q7IHdyb3RlOjxicj4NCiZndDsg SGkgTG91LDxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyBmb3IgaW5pdGlhdGluZyBkaXNjdXNz aW9ucyBvbiB0aGUgY2hhbmdlcyBpbiB0aGUgZHJhZnQuPGJyPg0KJmd0Ozxicj4NCiZndDsgQWdy ZWUgd2l0aCB5b3UgaGVyZSwgaWYgd2UvV0cgZG8gbm90IGFncmVlIG9uIHRoZSAmcXVvdDtjby1y b3V0ZWQNCmFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AmcXVvdDsgcGFydCwgd2UgYXJlIG9r IHRvIHJlbW92ZSBpdCBmcm9tIHRoaXMNCmRyYWZ0IGFuZCBjYW4gYWx3YXlzIHN1Ym1pdCBhIG5l dyBkcmFmdCBqdXN0IGZvciB0aGF0LiBXZSByZXNwZWN0IHlvdXIvV0cNCmRlY2lzaW9uLjxicj4N CiZndDs8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7IFJha2VzaDxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQom Z3Q7IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XTxicj4NCiZndDsg U2VudDogVGh1cnNkYXksIEF1Z3VzdCAxNiwgMjAxMiA2OjA4IFBNPGJyPg0KJmd0OyBUbzogSm9o biBFIERyYWtlPGJyPg0KJmd0OyBDYzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSk7IGNjYW1wQGll dGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQ8YnI+DQom Z3Q7PGJyPg0KJmd0OyBKb2huLDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFdoaWxlIHN0cmljdGx5IHNwZWFraW5nIFdHIGRyYWZ0cyBzaG91bGQNCm9ubHkgcmVmbGVjdCBj dXJyZW50IFdHIGNvbnNlbnN1cywgYW5kIGl0IGlzIHRoZSBXRyBkcmFmdCBlZGl0b3IncyBqb2IN CnRvIGVuc3VyZSB0aGlzLCBpbiBwcmFjdGljZSBhdXRob3JzL2VkaXRvcnMgYXJlIGdpdmVuIGEg bG90IG9mIGxhdGl0dWRlDQppbiB0aW1pbmcgLyBvcmRlcmluZyBpbiBpbnRyb2R1Y3Rpb24gdG8g Y2hhbmdlcy4gJm5ic3A7SSBwZXJzb25hbGx5IHRoaW5rDQp0aGlzIGlzIGEgcHJhY3RpY2FsIHdh eSBvZiBrZWVwaW5nIHRoZSBwcm9jZXNzIG1vdmluZy4gJm5ic3A7QWxzbyBpZiB0aGUNCldHIGRp c2FncmVlcyB3aXRoIGEgY2hhbmdlLCBpdCBjYW4gYWx3YXlzIGJlIGJhY2tlZCBvdXQuPGJyPg0K Jmd0Ozxicj4NCiZndDsgU28sIHllcywgdGhlIFdHIGNvdWxkIGRvIGV4YWN0bHkgYXMgeW91IHNh eSBpZiBpdCBjb21lcyB0byBpdC4gJm5ic3A7KFRoZQ0KY2hhaXJzIGNhbiBldmVuIGFwcG9pbnQg ZGlmZmVyZW50IGVkaXRvciBpZiBuZWVkZWQsIGUuZy4sIHRvIG1ha2UgdGhpczxicj4NCiZndDsg aGFwcGVuLikgJm5ic3A7V2hpbGUgSSdtIG5vdCBoYXBweSB3aXRoIGhvdyB0aGlzIHJldmlzaW9u IGNhbWUgYWJvdXQsDQphcyBJIGNvdmVyZWQgaW4gZWFybGllciBtYWlsLCBteSBmZWVsaW5nIGlz IHRvIGxldCB0aGUgZGlzY3Vzc2lvbiB0YWtlDQpwbGFjZSBvbiB0aGUgbGlzdCAoYW5kIGF0IHRo ZSBuZXh0IElFVEYsIGlmIG5lZWRlZCkgYW5kIHRoZW4gaGF2ZSB0aGUgZHJhZnQNCnVwZGF0ZWQg dG8gcmVmbGVjdCB0aGUgV0cgZGlzY3Vzc2lvbi9jb25zZW5zdXMuPGJyPg0KJmd0Ozxicj4NCiZn dDsgTG91PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gOC8xNi8yMDEyIDU6MzUgUE0sIEpvaG4gRSBE cmFrZSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBMb3UsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBTaW5jZSB0aGUgV0cgZGlkIG5vdCBhZ3JlZSB0byB0aGlzIGNoYW5nZXMsIGxldCBhbG9uZSBk aXNjdXNzDQp0aGVtLDxicj4NCiZndDsmZ3Q7IHdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIHNpbXBs eSByb2xsYmFjayB0aGVzZSBjaGFuZ2VzIGFuZCBhc2sNCnRoZTxicj4NCiZndDsmZ3Q7IGF1dGhv cnMgdG8gd3JpdGUgYSBkcmFmdCBhZGRyZXNzaW5nIHRoZSB0b3BpY3MgeW91IGxpc3QgaW4geW91 cg0KZW1haWwsPGJyPg0KJmd0OyZndDsgYmVsb3c/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBUaGFua3MsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBKb2huPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyBTZW50IGZyb20gbXkgaVBob25lPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDsmZ3Q7Jmd0OyBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91 bmNlc0BpZXRmLm9yZ10NCk9uPGJyPg0KJmd0OyZndDsmZ3Q7IEJlaGFsZiBPZiBMb3UgQmVyZ2Vy PGJyPg0KJmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTYsIDIwMTIgMjoxMCBQ TTxicj4NCiZndDsmZ3Q7Jmd0OyBUbzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSk8YnI+DQomZ3Q7 Jmd0OyZndDsgQ2M6IGNjYW1wQGlldGYub3JnPGJyPg0KJmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJl OiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0 LTxicj4NCiZndDsmZ3Q7Jmd0OyBhc3NvY2lhdGVkLWxzcC0wNC50eHQ8YnI+DQomZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsgUmFrZXNoLDxicj4NCiZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwO1N1Y2ggbWFqb3IgY2hhbmdlcyAoaW4gc2NvcGUgYW5kIGZ1bmN0aW9uYWxpdHkp DQp0byBXRyBkcmFmdHMgYXJlPGJyPg0KJmd0OyZndDsmZ3Q7IHVzdWFsbHkgZGlzY3Vzc2VkIHdp dGggdGhlIFdHIHByaW9yIHRvIHRoZSBhdXRob3JzL2VkaXRvcnMNCmp1c3Q8YnI+DQomZ3Q7Jmd0 OyZndDsgcHVibGlzaGluZyB0aGUgY2hhbmdlcy4gJm5ic3A7QnV0LCB0aGlzIGlzIGEganVkZ21l bnQgY2FsbA0KYnkgdGhlIGRvY3VtZW50PGJyPg0KJmd0OyZndDsmZ3Q7IGVkaXRvcnMgaW4gaG93 LCBxdW90aW5nIHJmYzI0MTgsIHRoZXkgJnF1b3Q7ZW5zdXJbZV0gdGhhdA0KdGhlIGNvbnRlbnRz IG9mPGJyPg0KJmd0OyZndDsmZ3Q7IHRoZSBkb2N1bWVudCBhY2N1cmF0ZWx5IHJlZmxlY3QgdGhl IGRlY2lzaW9ucyB0aGF0IGhhdmUgYmVlbg0KbWFkZSBieTxicj4NCiZndDsmZ3Q7Jmd0OyB0aGUg d29ya2luZyBncm91cC4mcXVvdDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg U28gbGV0J3MganVtcCBpbnRvIGRpc2N1c3NpbmcgdGhlIGNoYW5nZXMuPGJyPg0KJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEFzIEkgc2VlIGl0IHRoaXMgZHJhZnQgaW50cm9kdWNlcyBz ZXZlcmFsIG1ham9yIGZ1bmN0aW9uYWwNCmNoYW5nZXM8YnI+DQomZ3Q7Jmd0OyZndDsgdGhhdCBo YXZlIG5vdCBiZWVuIGRpc2N1c3NlZCBieSB0aGUgV0cuICZuYnNwO0NvcnJlY3QgbWUgaWYNCkkg Z2V0IHRoZW08YnI+DQomZ3Q7Jmd0OyZndDsgd3JvbmcsIGJ1dCBJIGJlbGlldmUgdGhleSBpbmNs dWRlOjxicj4NCiZndDsmZ3Q7Jmd0OyAxKSBJbnRyb2R1Y3Rpb24gb2YgYSBzZWNvbmQgbWV0aG9k IGZvciBzaWduYWxpbmcgQ28tcm91dGVkDQpMU1BzPGJyPg0KJmd0OyZndDsmZ3Q7IDIpIFN1cHBv cnQgZm9yIEZSUiBieXBhc3MgdHVubmVscyBmb3IgcGlnZ3liYWNrZWQgb24gdGhlIFRQPGJyPg0K Jmd0OyZndDsmZ3Q7IGJpZGlyZWN0aW9uYWwgTFNQIG1lY2hhbmlzbXMuPGJyPg0KJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtUaGVyZSBhcmUgYWxzbyBvdGhlciBj aGFuZ2VzLCBidXQgSSdsbCBkZWZlcg0KZGlzY3Vzc2luZyB0aGVtPGJyPg0KJmd0OyZndDsmZ3Q7 ICZuYnNwOyAmbmJzcDt1bnRpbCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgYWJvdmUgaXMgY29uY2x1 ZGVkLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJcyB0aGlzIGNvcnJlY3Q/ PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEFzc3VtaW5nIHllcywgSSBoYXZl IHF1ZXN0aW9ucyBhYm91dCBib3RoIHJhdGlvbmFsIGFuZCBzcGVjaWZpYzxicj4NCiZndDsmZ3Q7 Jmd0OyBtZWNoYW5pc21zLiAmbmJzcDtGb3Igbm93IGxldCdzIGxvb2sgYXQgdGhlIGZvcm1lciwg c28gcGxlYXNlOjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBBKSBBcnRpY3Vs YXRlIHRoZSBpc3N1ZXMvbGltaXRhdGlvbnMgd2l0aCB1c2luZyB0aGUgUkZDMzQ3Mw0KZGVmaW5l ZDxicj4NCiZndDsmZ3Q7Jmd0OyBtZWNoYW5pc21zIGZvciAoY28tcm91dGVkKSBiaWRpcmVjdGlv bmFsIExTUHMgdGhhdCB5b3UnZCBsaWtlDQp0byBzZWU8YnI+DQomZ3Q7Jmd0OyZndDsgYWRkcmVz c2VkLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBCLjEpIEFydGljdWxhdGUg dGhlIEZSUi9HTVBMUy1yZWxhdGVkIGlzc3VlIHlvdSdkIGxpa2UgdG8NCmFkZHJlc3M/PGJyPg0K Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEIuMikgQXJ0aWN1bGF0ZSB3aHkgdGhpcyBp c3N1ZSBzaG91bGQgYmUgc29sdmVkIGluIGEgVFAtc3BlY2lmaWMNCmFuZDxicj4NCiZndDsmZ3Q7 Jmd0OyBub3QgR01QTFMgZ2VuZXJpYyBmYXNoaW9uPzxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyBUaGFua3MsPGJyPg0KJmd0OyZndDsmZ3Q7IExvdTxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyBPbiA4LzE2LzIwMTIgNDoyNiBQTSwgUmFrZXNoIEdhbmRoaSAo cmdhbmRoaSkgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBIaSBMb3UsPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgWWVzLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFBsZWFzZSBhZHZpc2UgaWYgeW91IHRoaW5rIGRldGFp bGVkIGVtYWlsIGlzIHJlcXVpcmVkLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgV2UgYmVsaWV2ZSBs YXRlc3QgZHJhZnQgc3VtbWFyaXplcyB0aGUgY2hhbmdlcyB3ZWxsIGFuZA0Kd2UgY291bGQ8YnI+ DQomZ3Q7Jmd0OyZndDsgc3RhcnQgcmV2aWV3L2Rpc2N1c3Npb25zIGZyb20gdGhlcmUuPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzLDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgUmFrZXNoPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJu Lm5ldF08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTYsIDIw MTIgNDowMCBQTTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVG86IFJha2VzaCBHYW5kaGkgKHJnYW5k aGkpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBDYzogY2NhbXBAaWV0Zi5vcmc7IHpoYW5nLmZlaTNA enRlLmNvbS5jbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtDQ0FNUF0gSS1E IEFjdGlvbjo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1y c3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dDxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IFJha2VzaCw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAm bmJzcDsgSXMgdGhpcyB0aGUgc3RhcnQgb2YgdGhlIHRocmVhZCB0aGF0IEkgcmVxdWVzdGVkDQpp bjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2NjYW1wL2N1cnJlbnQvbXNnMTM3MjkuaHRtbDxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IEluIHBhcnRpY3VsYXIsIGlzIGl0IHRoZSByZXNwb25zZSB0bzo8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJJ2QgbGlrZSB0byBhc2sgdGhhdCBzb21lb25lIChS YWtlc2gsIEZlaSwgZXRjLikgcmV2aWV3DQplYWNoIG9mIHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHByb3Bvc2VkIGNoYW5nZSBhbmQgdGhlIHJhdGlvbmFsIGZvciBlYWNoIGNoYW5nZSAo aW4NCm9uZSBvciBpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlcGFyYXRlIGUtbWFpbHMp LiBUaGUgV0cgZGlzY3Vzc2lvbiBjYW4gdGhlbiByZWFsbHkNCmJlZ2luIG9uIHRoZTxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByb3Bvc2VkIGNoYW5nZXMuIChXaGljaCBhcmUgcXVpdGUgc3Vi c3RhbnRpYWwgYm90aA0KaW4gc2NvcGUgYW5kPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW1w bGljYXRpb24uKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IExv dTxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDgvMTYvMjAx MiAzOjE5IFBNLCBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBIaSBBbGwsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBXZSBoYXZlIHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gb2YgdGhpcyBkcmFm dCB3aXRoDQpmb2xsb3dpbmcgY2hhbmdlczo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyAxLiAmbmJzcDtBZGRlZCBhIHNlY3Rpb24gb24gU2lnbmFsaW5nIG9mIENv LXJvdXRlZCBMU1BzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsg Mi4gJm5ic3A7QWRkZWQgY2xhcmlmaWNhdGlvbiBvbiBTaWduYWxpbmcgb2YgQXNzb2NpYXRlZA0K QmlkaXJlY3Rpb25hbDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgUHJvdGVjdGlvbiBMU1BzPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgMy4gJm5ic3A7QWRkZWQgYSBz ZWN0aW9uIG9uIFNpZ25hbGluZyBvZiBBdXRvLXR1bm5lbCBNZXNoLWdyb3VwDQpMU1BzPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgNC4gJm5ic3A7IEFkZGVkIGNs YXJpZmljYXRpb24gb24gU2lnbmFsaW5nIG9mIEludGVyLWRvbWFpbg0KQXNzb2NpYXRlZDxicj4N CiZndDsmZ3Q7Jmd0OyBCaWRpcmVjdGlvbmFsIExTUHM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyA1LiAmbmJzcDtUaGUgRXh0ZW5kZWQgQVNTT0NJQVRJT04gb2Jq ZWN0IGZvcm1hdCB3aXRoIEFzc29jaWF0aW9uDQpUeXBlPGJyPg0KJmd0OyZndDsmZ3Q7ICZxdW90 O0Fzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1AmcXVvdDsuIENsYXJpZmllZCBvbiBob3cNCnRv IHBvcHVsYXRlPGJyPg0KJmd0OyZndDsmZ3Q7IGRpZmZlcmVudCBmaWVsZHMgaW4gdGhpcyBvYmpl Y3QuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBXZSBiZWxpZXZlIHRoYXQgc29tZSBvZiB0aGVzZSBjaGFuZ2VzIHdl cmUgbmVjZXNzYXJ5DQp0byBhdm9pZCB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsgaW50ZXJvcGVyYWJp bGl0eSBpc3N1ZXMgZHVlIHRvIHBvdGVudGlhbGx5IGRpZmZlcmVudCBpbnRlcnByZXRhdGlvbnMu PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBZb3Vy IHJldmlldyBjb21tZW50cyBhcmUgd2VsY29tZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBSYWtlc2g8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg RnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5v cmddDQpPbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiBXZWRuZXNkYXksIEF1 Z3VzdCAxNSwgMjAxMiAxMDo1MyBBTTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBpLWQt YW5ub3VuY2VAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDYzogY2NhbXBAaWV0 Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBbQ0NBTVBdIEktRCBBY3Rp b246PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJz dnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lDQpJbnRlcm5ldC1E cmFmdHM8YnI+DQomZ3Q7Jmd0OyZndDsgZGlyZWN0b3JpZXMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgJm5ic3A7VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRy b2wNCmFuZCBNZWFzdXJlbWVudDxicj4NCiZndDsmZ3Q7Jmd0OyBQbGFuZSBXb3JraW5nIEdyb3Vw IG9mIHRoZSBJRVRGLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgJm5ic3A7ICZuYnNwO1RpdGxlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCjogUlNWUC1URSBFeHRlbnNpb25zIGZvciBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWw8 YnI+DQomZ3Q7Jmd0OyZndDsgTFNQczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAm bmJzcDtBdXRob3IocykgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBGZWkNClpoYW5nPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSdWlx dWFuIEppbmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFJha2VzaCBHYW5kaGk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7RmlsZW5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Og0KZHJhZnQtaWV0 Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC08YnI+DQomZ3Q7Jmd0OyZndDsg bHNwLTA0LnR4dDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtQYWdlcyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQo6IDE3PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgJm5ic3A7ICZuYnNwO0RhdGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7OiAyMDEyLTA4LTE1PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAm bmJzcDsgJm5ic3A7VGhlIE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUgKE1QTFMtVFApDQpyZXF1aXJl bWVudHMgZG9jdW1lbnQ8YnI+DQomZ3Q7Jmd0OyZndDsgW1JGQzU2NTRdLDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtkZXNjcmliZXMgdGhhdCBNUExTLVRQIE1VU1Qgc3Vw cG9ydCBhc3NvY2lhdGVkDQpiaWRpcmVjdGlvbmFsPGJyPg0KJmd0OyZndDsmZ3Q7IHBvaW50LTxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDt0by1wb2ludCBMU1BzLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZu YnNwO1RoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBtZXRob2QgdG8gYmluZA0KdHdvIHVuaWRpcmVj dGlvbmFsIExhYmVsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwO1N3aXRj aGVkIFBhdGhzIChMU1BzKSBpbnRvIGFuIGFzc29jaWF0ZWQNCmJpZGlyZWN0aW9uYWwgTFNQLiAm bmJzcDtUaGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7YXNzb2NpYXRp b24gaXMgYWNoaWV2ZWQgYnkgZGVmaW5pbmcgdGhlDQpuZXcgQXNzb2NpYXRpb24gVHlwZSBpbjxi cj4NCiZndDsmZ3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5i c3A7RXh0ZW5kZWQgQVNTT0NJQVRJT04gb2JqZWN0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUg SUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLTxicj4NCiZndDsmZ3Q7Jmd0OyBleHQtPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgYTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNzb2NpYXRlZC1s c3A8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRo ZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAt bXBscy10cC1yc3ZwdGUtZXh0LTxicj4NCiZndDsmZ3Q7Jmd0OyBhc3NvY2k8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGVkLWxzcC0wNDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2Nh bXAtbXBscy10cC1yc3ZwdGUtPGJyPg0KJmd0OyZndDsmZ3Q7IGV4dC08YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3NvY2lhdGVkLWxzcC0wNDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFANCmF0Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZ0cDovL2Z0cC5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENDQU1QIG1haWxpbmcgbGlzdDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENDQU1QQGlldGYub3JnPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyBDQ0FNUCBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsgQ0NBTVBAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgQ0NB TVAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBDQ0FNUEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ0NBTVAgbWFpbGluZyBsaXN0 PGJyPg0KQ0NBTVBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NjYW1wPGJyPg0KPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCjwvZm9udD4NCjxicj4NCg== --=_alternative 003F50B348257A60_=-- From lberger@labn.net Mon Aug 20 08:48:34 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B86721F8667 for ; Mon, 20 Aug 2012 08:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.385 X-Spam-Level: X-Spam-Status: No, score=-99.385 tagged_above=-999 required=5 tests=[AWL=1.021, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFZesobRku7S for ; Mon, 20 Aug 2012 08:48:33 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 5487921F863F for ; Mon, 20 Aug 2012 08:48:33 -0700 (PDT) Received: (qmail 2702 invoked by uid 0); 20 Aug 2012 15:48:10 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 20 Aug 2012 15:48:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=aUg7TZf3NF/vy/KrrsIdVYHRD3nxRiiAdoFtyS+umKA=; b=h+YoostrAJHQckhVgKS9+jNsK9AH5SqMrSx03DO7YwAKMtE054jlYchs05/aXpdyLOKh56ZlpnudxQ3mL7kfkHoUXVeQsgTl1yyKCb8O+KC2mOjb1zVQ30C4S0xb1Yu9; Received: from box313.bluehost.com ([69.89.31.113]:50964 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T3UD3-0005CY-VK for ccamp@ietf.org; Mon, 20 Aug 2012 09:48:10 -0600 Message-ID: <50325C2E.7060900@labn.net> Date: Mon, 20 Aug 2012 11:47:58 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] IETF84-CCAMP Draft Minutes Available X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 15:48:34 -0000 All, The draft minutes from Vancouver are available at: http://www.ietf.org/proceedings/84/minutes/minutes-84-ccamp Please review and comment to the list (or to the chairs) as soon as possible if you'd to see any corrections. Changes can only be made through next Friday so please get your comments in when possible. Much thanks to our WG secretaries, Daniele Ceccarelli and Dan King, for the minute taking/prep. Lou and Deborah From lberger@labn.net Mon Aug 20 10:28:52 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A37021F8608 for ; Mon, 20 Aug 2012 10:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.33 X-Spam-Level: X-Spam-Status: No, score=-100.33 tagged_above=-999 required=5 tests=[AWL=1.935, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3RQiJCYzeLy for ; Mon, 20 Aug 2012 10:28:51 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 6368421F85BB for ; Mon, 20 Aug 2012 10:28:51 -0700 (PDT) Received: (qmail 22361 invoked by uid 0); 20 Aug 2012 17:28:26 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 20 Aug 2012 17:28:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=G3QNhyQq6Nz7PXncAmG4y6T9793FBtoeRB6Evzh9C1M=; b=HXdzY7RYbKz5j5O3F987iSCA3Ln9neFHdY6qyFVlcu+r7Fs6IiVwmWViw6erKfMzLbPuXsBuJkIJOdBFLEehthMbkLbFNbFl+uQF09XmxcmHo6STYnQJk1g2LBix3YyU; Received: from box313.bluehost.com ([69.89.31.113]:33437 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T3Vm6-0002xU-1v; Mon, 20 Aug 2012 11:28:26 -0600 Message-ID: <503273AE.8000700@labn.net> Date: Mon, 20 Aug 2012 13:28:14 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> In-Reply-To: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 17:28:52 -0000 Authors, I see that the draft says: In case of ITU Application Code, there should be a mapping between the string defining the application code and the 64 bits number implementing the optical interface class. Where is this mapping defined? Doesn't it have to be either in this draft or a normative reference? Thanks, Lou On 8/16/2012 7:14 PM, internet-drafts@ietf.org wrote: > > 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 : Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks > Author(s) : Greg M. Bernstein > Young Lee > Dan Li > Wataru Imajuku > Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt > Pages : 33 > Date : 2012-08-16 > > Abstract: > A wavelength switched optical network (WSON) requires that certain > key information elements are made available to facilitate path > computation and the establishment of label switching paths (LSPs). > The information model described in "Routing and Wavelength > Assignment Information for Wavelength Switched Optical Networks" > shows what information is required at specific points in the WSON. > Part of the WSON information model contains aspects that may be of > general applicability to other technologies, while other parts are > fairly specific to WSONs. > > This document provides efficient, protocol-agnostic encodings for > the WSON specific information elements. It is intended that > protocol-specific documents will reference this memo to describe how > information is carried for specific uses. Such encodings can be used > to extend GMPLS signaling and routing protocols. In addition these > encodings could be used by other mechanisms to convey this same > information to a path computation element (PCE). > > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-wson-encode-16 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Mon Aug 20 10:38:44 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD23521F84FE for ; Mon, 20 Aug 2012 10:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.359 X-Spam-Level: X-Spam-Status: No, score=-100.359 tagged_above=-999 required=5 tests=[AWL=1.906, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzWvFVIl2UN5 for ; Mon, 20 Aug 2012 10:38:44 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 52E9F21F84FC for ; Mon, 20 Aug 2012 10:38:44 -0700 (PDT) Received: (qmail 17416 invoked by uid 0); 20 Aug 2012 17:38:21 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 20 Aug 2012 17:38:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=uc2z6l3pofwQQyF+nPSMGwNl0O9f9OHgcLbFM4b0Wok=; b=d3QVQSZpyzSO6POa+DWL4gUDkXtH+nkxmswA2XD45PQ6qEYR78aV6+VbMWjffODHMx7tZl0DoXRH+ROWOEIEqM0cIuPjQpJTgx/g4UB5ByaZRxzGHFTE0KwJn5skyC3+; Received: from box313.bluehost.com ([69.89.31.113]:34656 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T3Vvh-00078l-07; Mon, 20 Aug 2012 11:38:21 -0600 Message-ID: <50327601.2060502@labn.net> Date: Mon, 20 Aug 2012 13:38:09 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 17:38:45 -0000 Fei, To respond to your procedure point: On 8/17/2012 3:27 AM, zhang.fei3@zte.com.cn wrote: > I am not sure whether this draft should follow the the procedures > defined for WG documents or not. Individual drafts are completely under the control of the authors. Of course, they may choose to listen to feedback of WG participants in hope of getting their draft accepted as a WG draft.... Lou From gregb@grotto-networking.com Mon Aug 20 11:00:47 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725A921F854D for ; Mon, 20 Aug 2012 11:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm+1wY3gpc6u for ; Mon, 20 Aug 2012 11:00:46 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C828E21F8546 for ; Mon, 20 Aug 2012 11:00:46 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id D697A212D7A7 for ; Mon, 20 Aug 2012 13:00:45 -0500 (CDT) Message-ID: <50327B42.2010108@grotto-networking.com> Date: Mon, 20 Aug 2012 11:00:34 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ccamp@ietf.org References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> <503273AE.8000700@labn.net> In-Reply-To: <503273AE.8000700@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 18:00:47 -0000 Optical Interface Class draft authors can you respond to Lou/List. Let me know if we need to update the text. We are trying to get this into last call. Best Regards Greg On 8/20/2012 10:28 AM, Lou Berger wrote: > Authors, > > I see that the draft says: > In case of ITU Application Code, there should be a mapping between > the string defining the application code and the 64 bits number > implementing the optical interface class. > > Where is this mapping defined? Doesn't it have to be either in this > draft or a normative reference? > > Thanks, > Lou > > On 8/16/2012 7:14 PM, internet-drafts@ietf.org wrote: >> 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 : Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks >> Author(s) : Greg M. Bernstein >> Young Lee >> Dan Li >> Wataru Imajuku >> Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt >> Pages : 33 >> Date : 2012-08-16 >> >> Abstract: >> A wavelength switched optical network (WSON) requires that certain >> key information elements are made available to facilitate path >> computation and the establishment of label switching paths (LSPs). >> The information model described in "Routing and Wavelength >> Assignment Information for Wavelength Switched Optical Networks" >> shows what information is required at specific points in the WSON. >> Part of the WSON information model contains aspects that may be of >> general applicability to other technologies, while other parts are >> fairly specific to WSONs. >> >> This document provides efficient, protocol-agnostic encodings for >> the WSON specific information elements. It is intended that >> protocol-specific documents will reference this memo to describe how >> information is carried for specific uses. Such encodings can be used >> to extend GMPLS signaling and routing protocols. In addition these >> encodings could be used by other mechanisms to convey this same >> information to a path computation element (PCE). >> >> >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-wson-encode-16 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From lberger@labn.net Mon Aug 20 11:01:18 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC5C21F8559 for ; Mon, 20 Aug 2012 11:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.323 X-Spam-Level: X-Spam-Status: No, score=-100.323 tagged_above=-999 required=5 tests=[AWL=1.812, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_RMML_Stock10=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0SqHX42wCX2 for ; Mon, 20 Aug 2012 11:01:18 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id D95F321F8546 for ; Mon, 20 Aug 2012 11:01:17 -0700 (PDT) Received: (qmail 20333 invoked by uid 0); 20 Aug 2012 18:00:55 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 20 Aug 2012 18:00:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=5v3eYEUGbCF/3DOV0cEI7CyHdg9EkNLRBdTiw3cVdrY=; b=iP2nh7/qaieCpUnp5KNJVuGSLhEz+mBOwRCNY2QgL4ySSQ6si7x/4yZCNwRlnk1sOQDkJ42hzgb9+/gXjZEWDSG8YRR/ghJvUcVcvQjnL18UHaxA8kGE2jNhwN3eJ8zq; Received: from box313.bluehost.com ([69.89.31.113]:37196 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T3WHX-0000CI-Dl; Mon, 20 Aug 2012 12:00:55 -0600 Message-ID: <50327B4B.9050807@labn.net> Date: Mon, 20 Aug 2012 14:00:43 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 18:01:18 -0000 On 8/20/2012 7:32 AM, zhang.fei3@zte.com.cn wrote: > On 8/17/2012 1:44 PM, Gregory Mirsky wrote: > But I would question whether operators will use independent monitoring > and protection on, what looks exactly like, bi-directional co-routed > LSP. I think that c2) is not a separate case, but rather "an accident". > If an operator wants to build c2) he/she needs to use procedures defined > for b). > > We need to heare opinions from the operators, and one of Rekesh's > argument is listed below for reference: > It is fine to have non co-routed as default. RFC 3473 is a GMPLS > signaling procedure. It may not be optimal to have two different > signaling procedures, one for non co-routed (ext associated object) and > one for co-routed (RFC 3473) procedures. By adding a flag for co-routed, > same signaling (ext associated object) can be used for both which is > nice. We believe comparing of RRO can be misleading because two LSPs can > be on the same path even though provisioned to be non co-routed. > > Regards, > Greg Fei, I personally think we have plenty of input on requirements, at least in the TP context, captured in rfc5654. At this point, if someone wants to add a second control plane mechanism for controlling co-routed bidirectional, I (as co-chair) think, they need to make the case for it and get WG buy-in. In other words, I believe *current* working group consensus does *not* support introducing a second co-route bidirectional LSP signaling mechanism. I believe Rakesh said he'd read up on what's already supported and get back to the WG (presumably if he thinks another mechanism is justified). Of course, you and anyone else are free to make the case yourself. Lou From internet-drafts@ietf.org Mon Aug 20 18:40:13 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FDA21F85A3; Mon, 20 Aug 2012 18:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4j4sg3kc-F9; Mon, 20 Aug 2012 18:40:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD8021F8597; Mon, 20 Aug 2012 18:40:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120821014012.12834.63124.idtracker@ietfa.amsl.com> Date: Mon, 20 Aug 2012 18:40:12 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-dpm-07.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 01:40:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Label Switched Path (LSP) Data Path Delay Metrics in Gen= eralized MPLS/ MPLS-TE Networks Author(s) : Weiqiang Sun Guoying Zhang Filename : draft-ietf-ccamp-dpm-07.txt Pages : 33 Date : 2012-08-20 Abstract: When setting up a label switched path (LSP) in Generalized MPLS and MPLS/TE networks, the completion of the signaling process does not necessarily mean that the cross connection along the LSP have been programmed accordingly and in a timely manner. Meanwhile, the completion of signaling process may be used by applications as indication that data path has become usable. The existence of the inconsistency between the signaling messages and cross connection programing, and the possible failure of cross connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the application model and to build more robust applications. This document defines a series of performance metrics to evaluate the connectivity of data path in the signaling process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-dpm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-dpm-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-dpm-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sun.weiqiang@gmail.com Mon Aug 20 18:50:41 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05E711E809C; Mon, 20 Aug 2012 18:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQQn8z4aW6RM; Mon, 20 Aug 2012 18:50:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0A91311E809B; Mon, 20 Aug 2012 18:50:39 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so8110839pbb.31 for ; Mon, 20 Aug 2012 18:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=fILk4pRP7y984+BYA5KBWfpscmzX9SxKKQmO0HVEDhM=; b=x3meI0IntjZnnJZE1lYBgDMCBl+POTn5grLcyCX6gnleWzpLdnwPkFKG/ocDQlBLB6 qaHyhHscDAxoKxpfhfNy1hw1GUg4jH/72KOq9elv+axZRwuhqzq0r1aNw395//AI4gTW Lgkc5Low9RQkESGRpCddT8qg5GO0iwfJfF2MxwymHki86TU2RDe+L6rvq3E/FnJs5Qiq UsU7MDf4aqeU1Bhg4SF4LSy5nA7seb0Oqp9bbXvGIOGGYkJ4vm1RyMXvr3AtRtotAk2O M3zs8puwXe9Mib8jHM/TjJnb9Ion0u6l/U7LN33Lw5Sqg3HMR0YYD5uCST1LacYfXls1 7Fnw== Received: by 10.68.242.231 with SMTP id wt7mr34348730pbc.99.1345513839262; Mon, 20 Aug 2012 18:50:39 -0700 (PDT) Received: from [192.168.6.100] ([202.120.39.147]) by mx.google.com with ESMTPS id wd6sm308630pbc.15.2012.08.20.18.50.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 18:50:38 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Tue, 21 Aug 2012 09:50:28 +0800 From: Weiqiang Sun To: Klaas Wierenga , The IESG , , Message-ID: Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-dpm-07.txt In-Reply-To: <20120821014012.12834.63124.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: ccamp@ietf.org Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-dpm-07.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 01:50:41 -0000 Hello all, We have uploaded a new version of draft-ietf-ccamp-dpm by taking into account the Secdir review comments from Klaas. Three changes are made in this revision: 1) in the Abstract: We rephrased the following sentence: Old text: The existence of this delay and the possible failure of cross connection programming, if not properly treated, will result in data loss or even application failure. New text: The existence of the inconsistency between the signaling messages and cross connection programing, and the possible failure of cross connection programming, if not properly treated, will result in data loss or even application failure. 2) in 11.2. The Median of Metric We added the following text: When the number of defined values in the given sample is small, the metric median may not be typical and SHOULD be used carefully. 3) slight changes to <14. Acknowledgements> Thanks, Weiqiang and co-authors On 8/21/12 9:40 AM, "internet-drafts@ietf.org" wrote: > >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 (LSP) Data Path Delay Metrics in >Generalized MPLS/ MPLS-TE Networks > Author(s) : Weiqiang Sun > Guoying Zhang > Filename : draft-ietf-ccamp-dpm-07.txt > Pages : 33 > Date : 2012-08-20 > >Abstract: > When setting up a label switched path (LSP) in Generalized MPLS and > MPLS/TE networks, the completion of the signaling process does not > necessarily mean that the cross connection along the LSP have been > programmed accordingly and in a timely manner. Meanwhile, the > completion of signaling process may be used by applications as > indication that data path has become usable. The existence of the > inconsistency between the signaling messages and cross connection > programing, and the possible failure of cross connection programming, > if not properly treated, will result in data loss or even application > failure. Characterization of this performance can thus help > designers to improve the application model and to build more robust > applications. This document defines a series of performance metrics > to evaluate the connectivity of data path in the signaling process. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-ccamp-dpm > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-ccamp-dpm-07 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-dpm-07 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp From swallow@cisco.com Tue Aug 21 14:53:03 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C5821F8530 for ; Tue, 21 Aug 2012 14:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.534 X-Spam-Level: X-Spam-Status: No, score=-110.534 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_RMML_Stock10=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3cvm6sEahVI for ; Tue, 21 Aug 2012 14:53:02 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5170B21F847D for ; Tue, 21 Aug 2012 14:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=3348; q=dns/txt; s=iport; t=1345585982; x=1346795582; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MG0uDGiKM9dNWAYSFDt2i9KqXLa8MBR7eX85DIFZ4K4=; b=eB37qL8zrl3TRohHLs2P98RzbQtJ3pTs/ONhZ+verSQp8Syxk438dVOI 3XIjsPS8qBgqsoehmYU0M/bAA2Vb8kKGxP3CU9lMH64RpeesGFbpNcjTs 3XRN9CaDV81Y8SxQ2ALEAWwbYF+QF/u8OSorVgmAirUR3UyJTXYaIC2j8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMoANFCtJXG//2dsb2JhbABFul+BB4IgAQEBBAEBAQ8BJzQLEgEIDgoeNwslAgQBDQUih2sLmRegIgSLCAqHEgOVUo4tgWaCYQ X-IronPort-AV: E=Sophos;i="4.77,804,1336348800"; d="scan'208";a="113964838" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 21 Aug 2012 21:53:02 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7LLr1SQ031446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Aug 2012 21:53:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Tue, 21 Aug 2012 16:53:00 -0500 From: "George Swallow (swallow)" To: Lou Berger , "zhang.fei3@zte.com.cn" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: AQHNf+dUvHY+1ytsFkS0HKsh/JjuhA== Date: Tue, 21 Aug 2012 21:53:00 +0000 Message-ID: In-Reply-To: <50327B4B.9050807@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.32.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19130.001 x-tm-as-result: No--47.943100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 21:53:03 -0000 All - It is interesting that we have before us a draft which has both TP and TE in the name. I believe that has much to do with the disagreements here. I've spoken with operators who are interested in applying some but not all aspects of TP to TE. The aspects that they want are bidirectionality and "better OAM" where the details of this may vary, but generally include BFD be it of the TP-in-GAL variety or just BFD bootstrapped (as normal) across a bidirectional forwarding adjacency. One aspect of TE that many would like to preserve is FRR. Both node and link. That is they don't care if in a failure things are not strictly co-routed. And some have uses for bidirectional adjacencies that aren't co-routed. I also note in passing that some want no-php, but also see cases where php servers their needs and is more efficient on their deployed hardware. Personally, I see no need to update RFC5654 as I'm happy to have all this fall under the ruberic of TE. But I very much want to have a means of signaling bidirectional TE LSPs, preserving the ability to have node and link FRR. I also think it would be wrong to call this TP. Let TP stand as the narrowly drawn profile it is. But the middle ground between TE and TP will get filled in. And that can all be extensions to TE. ...George On 8/20/12 2:00 PM, "Lou Berger" wrote: > > >On 8/20/2012 7:32 AM, zhang.fei3@zte.com.cn wrote: >> On 8/17/2012 1:44 PM, Gregory Mirsky wrote: >> But I would question whether operators will use independent monitoring >> and protection on, what looks exactly like, bi-directional co-routed >> LSP. I think that c2) is not a separate case, but rather "an accident". >> If an operator wants to build c2) he/she needs to use procedures defined >> for b). >>=20 >> We need to heare opinions from the operators, and one of Rekesh's >> argument is listed below for reference: >> It is fine to have non co-routed as default. RFC 3473 is a GMPLS >> signaling procedure. It may not be optimal to have two different >> signaling procedures, one for non co-routed (ext associated object) and >> one for co-routed (RFC 3473) procedures. By adding a flag for co-routed, >> same signaling (ext associated object) can be used for both which is >> nice. We believe comparing of RRO can be misleading because two LSPs can >> be on the same path even though provisioned to be non co-routed. >> =20 >> Regards, >> Greg > >Fei, > I personally think we have plenty of input on requirements, at least in >the TP context, captured in rfc5654. > >At this point, if someone wants to add a second control plane mechanism >for controlling co-routed bidirectional, I (as co-chair) think, they >need to make the case for it and get WG buy-in. In other words, I >believe *current* working group consensus does *not* support introducing >a second co-route bidirectional LSP signaling mechanism. > >I believe Rakesh said he'd read up on what's already supported and get >back to the WG (presumably if he thinks another mechanism is justified). >Of course, you and anyone else are free to make the case yourself. > >Lou > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp From adrian@olddog.co.uk Wed Aug 22 02:15:44 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBED021F84F8 for ; Wed, 22 Aug 2012 02:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AohQcxi9KXXb for ; Wed, 22 Aug 2012 02:15:43 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 73EC821F84F5 for ; Wed, 22 Aug 2012 02:15:43 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7M9FfqB026802; Wed, 22 Aug 2012 10:15:41 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7M9Fdx5026785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Aug 2012 10:15:40 +0100 From: "Adrian Farrel" To: "'Masanori Miyazawa'" , References: <0b7101cd3de9$8bfadbc0$a3f09340$@olddog.co.uk> <00ef01cd43b1$35ebf160$a1c3d420$@kddilabs.jp> In-Reply-To: <00ef01cd43b1$35ebf160$a1c3d420$@kddilabs.jp> Date: Wed, 22 Aug 2012 10:15:38 +0100 Message-ID: <153401cd8046$b2af4770$180dd650$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHQW7vPShMYMTWtVF3+Petz8y8AvgFifFZkl1S8BkA= Content-Language: en-gb Cc: ccamp@ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ted-mib X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 09:15:44 -0000 Hi, I'm sorry! I missed this email. Please see in line. > > Could you please sort out "MIB" versus "MIB module". There is only one > > MIB. There are many MIB modules - this document defines a MIB module > > > [Masanori Miyazawa] > # I could not understand above comment. You mean that descriptions of "MIB > modules" exit in this document? Mainly you should talk about "the MIB module defined in this document". The MIB module defined in this document forms part of "the MIB" i.e. all the data in the whole world:-) > > You need to avoid using citations (e.g. [RFC3630]) within the MIB module > > itself. MIB modules are extracted from their documents and stand alone. This means that you are allowed to use square brackets between in the MIB module itself. Some example changes are... OLD tedTable OBJECT-TYPE SYNTAX SEQUENCE OF TedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table indicates multiple TED information which has been supported by [RFC3630]." ::= { tedObjects 1 } NEW tedTable OBJECT-TYPE SYNTAX SEQUENCE OF TedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table indicates multiple TED information which has been supported by RFC 3630." REFERENCE "Traffic Engineering (TE) Extensions to OSPF Version 2, RFC 3630." ::= { tedObjects 1 } END OLD tedLocalRouterId OBJECT-TYPE SYNTAX TedRouterIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the router ID of the router originating the LSA. If OSPF is used to advertise LSA, this represents a Router ID. If ISIS is used, this represents a System ID. Otherwise, this represents zero." REFERENCE " OSPF Version 2, [RFC2328], C.1 OSPF for IPv6, [RFC5340], C.1 [ISO10589], Section 7.1 " ::= { tedEntry 2 } NEW tedLocalRouterId OBJECT-TYPE SYNTAX TedRouterIdTC MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object represents the router ID of the router originating the LSA. If OSPF is used to advertise LSA, this represents a Router ID. If ISIS is used, this represents a System ID. Otherwise, this represents zero." REFERENCE "1. OSPF Version 2, RFC 2328, C.1 2. OSPF for IPv6, RFC 5340, C.1 3. Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473), ISO10589, Section 7.1." ::= { tedEntry 2 } END OLD tedLinkType OBJECT-TYPE SYNTAX INTEGER { pointToPoint (1), multiAccess (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This indicates the type of the link such as point-to-point or multi-access." REFERENCE " Traffic Engineering (TE) Extensions to OSPF Version 2, [RFC 3630], 2.5.1" ::= { tedEntry 8 } NEW tedLinkType OBJECT-TYPE SYNTAX INTEGER { pointToPoint (1), multiAccess (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This indicates the type of the link such as point-to-point or multi-access." REFERENCE "Traffic Engineering (TE) Extensions to OSPF Version 2, RFC 3630, 2.5.1" ::= { tedEntry 8 } END > > I'm having some trouble with the use of 2119 language in the Description > > for tedLinkInformationData. > > > > Two examples... > > > > If tedLinkInformationSource has the value unknown(0), this > > object SHOULD contain a value of zeroDotZero. > > > > Under what circumstances can this use of "SHOULD" be varied? > [Masanori Miyazawa] > # At this time, we do not have a detailed situation to vary change to the > value unknown (0). > Should we delete the word "SHOULD"? or should the value unknown (0) be > deleted in this MIB if it is not used? This looks like it needs to read... If tedLinkInformationSource has the value unknown(0), this object MUST contain a value of zeroDotZero. > > If tedLinkInformationSource has the value > > locallyConfigured(1), this object MAY contain the identifier of > > the corresponding row entry in the teLinkTable of TE-LINK-STD- > > MIB[RFC4220], the identifier of the corresponding row in a local > > proprietary TE link MIB module, or the value of zeroDotZero > > otherwise. > > > > The use of "MAY" here implies that an implementation can choose to fill > > in the row pointer if it likes, but this is entirely an implementation > > choice. Is this what you are saying, or do you want to constrain the > > behavior more forcefully if TE-LINK-STD-MIB is implemented? > > > [Masanori Miyazawa] > # No, we think the implementation of this object is not constrained > forcefully. If the pointer is needed, we think this object should be used. OK. How about making it... If tedLinkInformationSource has the value locallyConfigured(1), an implementation can use this object to supply the identifier of the corresponding row entry in the teLinkTable of TE-LINK-STD-MIB (RFC 4220), the identifier of the corresponding row in a local proprietary TE link MIB module, or the value of zeroDotZero. > > tedLocalIfAddrEntry OBJECT-TYPE > > SYNTAX TedLocalIfAddrEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "This entry contains the IP address information of the local > > TE > > link." > > INDEX { tedLinkIndex, tedLocalIfAddr } > > ::= { tedLocalIfAddrTable 1 } > > > > TedLocalIfAddrEntry ::= SEQUENCE { > > tedLocalIfAddrType InetAddressType, > > tedLocalIfAddr InetAddress > > > > } > > > > What would it look like to walk this table by increasing index value? > > Would all the shorter v4 addresses show first, or would the numerically > > smaller v6 addresses get mixed in with the v4 addresses? > > > > If the latter is possible, you should use the address type as an index > > as well. > > > [Masanori Miyazawa] > # As you know, note that tedLocalIfAddrTable as well as tedRemoteIfAddrTable > are independently defined, because the Interface IP Address sub-TLV may > appear more than once within the same Link-TLV. > Therefore, if the address is only used as index, another arbitrary index > such as tedIndex would be also needed to represent the relationship with > tedTable. OK. Understood. > > tedStatusChangeNotificationMaxRate and > > tedCreatedDeletedNotificationMaxRate > > > > I am surprised that the Defval for these is 0 (no throttling) since the > > text recognises that this is a risky situation that may cause the box > > to blow up. Surely the default should be some safe setting. > > > > But then I wondered what a suitable safe setting would be and realised > > it would be "No Notifications". Except there is no way to say this with > > these objects. > > > > What do you think? > [Masanori Miyazawa] > #The reason for setting 0 as defval is to prevent sudden increase in > notification information. If we set the value as 10, the SNMP manager would > receive a number of alarms which is proportional to number of routers. For > instance, same ospf domain consists of 5 routers, the SNMP manager would > receive up to 50 alarms. So, I think that the optimal value of defval is 1. OK. Make that change. > > For completeness, we usually get asked to state in the Security section > > what the risks are with write access objects. In this case it is really > > easy... > > > > There are only two write-access objects in this MIB module: > > tedStatusChangeNotificationMaxRate and > > tedCreatedDeletedNotificationMaxRate. Malicious modification of > > these objects could cause the management agent, the network, or the > > router to become overloaded with Notifications in cases of high > > churn within the network. > [Masanori Miyazawa] > # You mean that we only need to describe the above sentence in section > 8[security consideration]? Yes. Thanks, Adrian From lberger@labn.net Wed Aug 22 05:40:19 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD47921F8683 for ; Wed, 22 Aug 2012 05:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.298 X-Spam-Level: X-Spam-Status: No, score=-99.298 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RMML_Stock10=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es3Xt6viTj4P for ; Wed, 22 Aug 2012 05:40:15 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 3B0F321F8604 for ; Wed, 22 Aug 2012 05:40:15 -0700 (PDT) Received: (qmail 5915 invoked by uid 0); 22 Aug 2012 12:40:14 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 22 Aug 2012 12:40:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=TLV79OCudBjZtqnA8A22p5gUttjCZt1/zdvV2O28rwY=; b=dkIKQiOAuXPBcnk+DaJYf8+AFqzn84V8L4iTGX3jWt6/slcO4hyIfQKHcdFYMYC0t8FN4WkK0jLxi17anVhuxCTgR398q0fSvB/usg3SXCTSLxmSyNi2NeuE5Fc1cEdC; Received: from box313.bluehost.com ([69.89.31.113]:60259 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T4AEI-0001mp-3R; Wed, 22 Aug 2012 06:40:14 -0600 Message-ID: <5034D323.6000409@labn.net> Date: Wed, 22 Aug 2012 08:40:03 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "George Swallow (swallow)" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 12:40:19 -0000 Hi George, I had a little trouble understanding what additional functionality you were identifying in your message, but after rereading it a few times, I think I may understand what you are looking for. Unless I'm mistaken it comes down to: > want to have a means of signaling bidirectional TE LSPs, > preserving the ability to have node and link FRR. And this is independent from co-routed or not. Is this correct? Assuming it is, I think there are two related use cases: 1) When the bidirectional data paths are established using a GMPLS bidirectional LSP, and 2) When the bidirectional data paths are established using the extension defined in rsvpte-ext-associated-lsp-03 (note not -04) In the case of (1), GMPLS birdirectional LSPs with FRR, I think you're right. This would require additional specification. Clearly (as John suggested) discussion on such mechanisms would need to at least start based on an independent (new) draft. I personally don't think there's any reason why someone couldn't author and submit such an independent draft. In the case of (2), as you're not suggesting co-routed recovery, why can't FRR just be used with procedures defined in rsvpte-ext-associated-lsp-03 (note not -04)? It's even possible to specify the ERO and FRR related objects for the reverse/upstream LSP using the REVERSE_LSP object. Are you just suggesting the need for an informative "Recovery Considerations" section that covers interaction of associated bidirectional LSPs with recovery/FRR? Or something more? Lou On 8/21/2012 5:53 PM, George Swallow (swallow) wrote: > All - > > It is interesting that we have before us a draft which has both TP and TE > in the name. I believe that has much to do with the disagreements here. > > I've spoken with operators who are interested in applying some but not all > aspects of TP to TE. > > The aspects that they want are bidirectionality and "better OAM" where the > details of this may vary, but generally include BFD be it of the TP-in-GAL > variety or just BFD bootstrapped (as normal) across a bidirectional > forwarding adjacency. > > One aspect of TE that many would like to preserve is FRR. Both node and > link. That is they don't care if in a failure things are not strictly > co-routed. And some have uses for bidirectional adjacencies that aren't > co-routed. > > I also note in passing that some want no-php, but also see cases where php > servers their needs and is more efficient on their deployed hardware. > > Personally, I see no need to update RFC5654 as I'm happy to have all this > fall under the ruberic of TE. > > But I very much want to have a means of signaling bidirectional TE LSPs, > preserving the ability to have node and link FRR. I also think it would > be wrong to call this TP. Let TP stand as the narrowly drawn profile it > is. But the middle ground between TE and TP will get filled in. And that > can all be extensions to TE. > > ...George > > On 8/20/12 2:00 PM, "Lou Berger" wrote: > >> >> >> On 8/20/2012 7:32 AM, zhang.fei3@zte.com.cn wrote: >>> On 8/17/2012 1:44 PM, Gregory Mirsky wrote: >>> But I would question whether operators will use independent monitoring >>> and protection on, what looks exactly like, bi-directional co-routed >>> LSP. I think that c2) is not a separate case, but rather "an accident". >>> If an operator wants to build c2) he/she needs to use procedures defined >>> for b). >>> >>> We need to heare opinions from the operators, and one of Rekesh's >>> argument is listed below for reference: >>> It is fine to have non co-routed as default. RFC 3473 is a GMPLS >>> signaling procedure. It may not be optimal to have two different >>> signaling procedures, one for non co-routed (ext associated object) and >>> one for co-routed (RFC 3473) procedures. By adding a flag for co-routed, >>> same signaling (ext associated object) can be used for both which is >>> nice. We believe comparing of RRO can be misleading because two LSPs can >>> be on the same path even though provisioned to be non co-routed. >>> >>> Regards, >>> Greg >> >> Fei, >> I personally think we have plenty of input on requirements, at least in >> the TP context, captured in rfc5654. >> >> At this point, if someone wants to add a second control plane mechanism >> for controlling co-routed bidirectional, I (as co-chair) think, they >> need to make the case for it and get WG buy-in. In other words, I >> believe *current* working group consensus does *not* support introducing >> a second co-route bidirectional LSP signaling mechanism. >> >> I believe Rakesh said he'd read up on what's already supported and get >> back to the WG (presumably if he thinks another mechanism is justified). >> Of course, you and anyone else are free to make the case yourself. >> >> Lou >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > From db3546@att.com Wed Aug 22 13:26:15 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878CD21F86BE for ; Wed, 22 Aug 2012 13:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTvRmi9urrnS for ; Wed, 22 Aug 2012 13:26:15 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 19D0F21F86B9 for ; Wed, 22 Aug 2012 13:26:09 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 06045305.0.1082052.00-343.2918964.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 22 Aug 2012 20:26:09 +0000 (UTC) X-MXL-Hash: 5035406176d7eadf-f5fce9d6365a6847e6396b9057b4d2ead5a2e7f6 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7MKQ7XU020370; Wed, 22 Aug 2012 13:26:08 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7MKQ1RX020154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2012 13:26:03 -0700 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by fflint03.pst.cso.att.com (RSA Interceptor); Wed, 22 Aug 2012 13:25:41 -0700 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0318.001; Wed, 22 Aug 2012 16:25:40 -0400 From: "BRUNGARD, DEBORAH A" To: "draft-ietf-ccamp-lmp-behavior-negotiation@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ietf-ccamp-lmp-behavior-negotiation Thread-Index: Ac2ApEoJpN/5/6CeT0ege3yy+aNrww== Date: Wed, 22 Aug 2012 20:25:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.172.222] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=usOTAW4VaJ4A:10 a=UuCIVDXKKtwA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=ZZzAehfQNmMA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:1] X-AnalysisOut: [0 a=JoNjQhV--J0A:10 a=xwOvzTHDVLE4u4nGvK72ag==:17 a=48vgC7] X-AnalysisOut: [mUAAAA:8 a=ccc8i8lWbWQxareQMRoA:9 a=CjuIK1q_8ugA:10] Cc: "ccamp@ietf.org" , "ccamp-ads@tools.ietf.org" Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-lmp-behavior-negotiation X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 20:26:15 -0000 Authors, Contributors, (CCAMP) In preparation of this document for Last Call: Are you aware of any IPR that applies to draft-ietf-ccamp-lmp-behavior-nego= tiation? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor, please answer the ab= ove by responding to this email regardless of whether or not you are aware = of any relevant IPR. This document will not advance to the next stage until= a response has been received from each author and listed contributor. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please s= ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik= i/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your respons= e. From huawei.danli@huawei.com Wed Aug 22 17:36:06 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D487521F8619 for ; Wed, 22 Aug 2012 17:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.618 X-Spam-Level: ** X-Spam-Status: No, score=2.618 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JSqq7v9Hx3n for ; Wed, 22 Aug 2012 17:36:06 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id DD4D921F8607 for ; Wed, 22 Aug 2012 17:36:05 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJU56146; Wed, 22 Aug 2012 16:36:05 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 17:32:08 -0700 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 17:32:13 -0700 Received: from SZXEML538-MBX.china.huawei.com ([169.254.4.15]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Thu, 23 Aug 2012 08:32:07 +0800 From: Lidan To: "BRUNGARD, DEBORAH A" , "draft-ietf-ccamp-lmp-behavior-negotiation@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ietf-ccamp-lmp-behavior-negotiation Thread-Index: Ac2ApEoJpN/5/6CeT0ege3yy+aNrwwAIk5dw Date: Thu, 23 Aug 2012 00:32:06 +0000 Message-ID: <92A1F6CF27D54D4DA5364E59D892A02A2567F162@szxeml538-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.73.151] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" , "ccamp-ads@tools.ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLWxtcC1iZWhhdmlvci1uZWdvdGlhdGlvbg==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 00:36:07 -0000 QXMgYW4gYXV0aG9yIG9mIHRoaXMgZHJhZnQsIEkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgaW4g dGhpcyBkcmFmdC4NCg0KVGhhbmtzLA0KDQpEYW4NCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+ yMs6IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3Jn XSC0+rHtIEJSVU5HQVJELCBERUJPUkFIIEENCreiy83KsbzkOiAyMDEyxOo41MIyM8jVIDQ6MjYN CsrVvP7IyzogZHJhZnQtaWV0Zi1jY2FtcC1sbXAtYmVoYXZpb3ItbmVnb3RpYXRpb25AdG9vbHMu aWV0Zi5vcmcNCrOty806IGNjYW1wQGlldGYub3JnOyBjY2FtcC1hZHNAdG9vbHMuaWV0Zi5vcmcN Ctb3zOI6IFtDQ0FNUF0gUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRmLWNjYW1wLWxtcC1iZWhh dmlvci1uZWdvdGlhdGlvbg0KDQpBdXRob3JzLCBDb250cmlidXRvcnMsIChDQ0FNUCkNCg0KSW4g cHJlcGFyYXRpb24gb2YgdGhpcyBkb2N1bWVudCBmb3IgTGFzdCBDYWxsOg0KDQpBcmUgeW91IGF3 YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtY2NhbXAtbG1wLWJlaGF2 aW9yLW5lZ290aWF0aW9uPw0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGlu IGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2 OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBk b2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IsIHBsZWFzZSBhbnN3ZXIgdGhlIGFib3ZlIGJ5 IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlv dSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhpcyBkb2N1bWVudCB3aWxsIG5vdCBh ZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2 ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1dG9yLg0KDQpJZiB5b3UgYXJl IG9uIHRoZSBDQ0FNUCBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRo b3Igb3IgY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRl ciB0aGUgSUVURiBJUFIgcnVsZXMgd2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJ RVRGIGlmIHlvdSBhcmUgYXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1 dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tIHBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlv biBvciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuICBGb3IgbW9y ZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kIGh0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFBy b3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpDQ0FNUCBXRyBDaGFpcnMNCg0KUFMgUGxlYXNlIGluY2x1 ZGUgYWxsIGxpc3RlZCBpbiB0aGUgaGVhZGVycyBvZiB0aGlzIG1lc3NhZ2UgaW4geW91ciByZXNw b25zZS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0K From ma-miyazawa@kddilabs.jp Wed Aug 22 20:51:27 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547A821F8543 for ; Wed, 22 Aug 2012 20:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eosm4ql24zUc for ; Wed, 22 Aug 2012 20:51:21 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 80DD521F8545 for ; Wed, 22 Aug 2012 20:51:15 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 5141F174818D; Thu, 23 Aug 2012 12:51:11 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7X4ZwN4dlz5; Thu, 23 Aug 2012 12:51:10 +0900 (JST) Received: from mail.cn.kddilabs.jp (yellow.lan.kddilabs.jp [172.19.98.10]) by mandala.kddilabs.jp (Postfix) with ESMTP id 68BB7174818A; Thu, 23 Aug 2012 12:51:10 +0900 (JST) Received: from miyazawaVAIO (dhcp50.wlan.kddilabs.jp [172.19.110.50]) by mail.cn.kddilabs.jp (Postfix) with ESMTP id 507271E0002; Thu, 23 Aug 2012 12:51:10 +0900 (JST) From: "Masanori Miyazawa" To: , References: <0b7101cd3de9$8bfadbc0$a3f09340$@olddog.co.uk> <00ef01cd43b1$35ebf160$a1c3d420$@kddilabs.jp> <153401cd8046$b2af4770$180dd650$@olddog.co.uk> In-Reply-To: <153401cd8046$b2af4770$180dd650$@olddog.co.uk> Date: Thu, 23 Aug 2012 12:51:07 +0900 Message-ID: <000901cd80e2$86d606b0$94821410$@kddilabs.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHQW7vPShMYMTWtVF3+Petz8y8AvgFifFZkAgasLsGXRcN9wA== Content-Language: ja Cc: ccamp@ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ted-mib X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 03:51:27 -0000 Ho, Adrian Thank you for sending your comments. I understood your comments and agreed. I will update the document to reflect your comments, and post it as latest version. Regards, Masanori > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, August 22, 2012 6:16 PM > To: 'Masanori Miyazawa'; > draft-ietf-ccamp-gmpls-ted-mib.all@tools.ietf.org > Cc: ccamp@ietf.org > Subject: RE: AD review of draft-ietf-ccamp-gmpls-ted-mib > > Hi, > > I'm sorry! I missed this email. > > Please see in line. > > > > Could you please sort out "MIB" versus "MIB module". There is only > > > one MIB. There are many MIB modules - this document defines a MIB > > > module > > > > > [Masanori Miyazawa] > > # I could not understand above comment. You mean that descriptions of > > "MIB modules" exit in this document? > > Mainly you should talk about "the MIB module defined in this document". > > The MIB module defined in this document forms part of "the MIB" i.e. all > the data in the whole world:-) > > > > You need to avoid using citations (e.g. [RFC3630]) within the MIB > > > module itself. MIB modules are extracted from their documents and stand > alone. > > This means that you are allowed to use square brackets between in the MIB > module itself. > > Some example changes are... > > OLD > tedTable OBJECT-TYPE > SYNTAX SEQUENCE OF TedEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table indicates multiple TED information which has been > supported by [RFC3630]." > ::= { tedObjects 1 } > NEW > tedTable OBJECT-TYPE > SYNTAX SEQUENCE OF TedEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table indicates multiple TED information which has been > supported by RFC 3630." > REFERENCE > "Traffic Engineering (TE) Extensions to OSPF Version 2, > RFC 3630." > ::= { tedObjects 1 } > END > > > OLD > tedLocalRouterId OBJECT-TYPE > SYNTAX TedRouterIdTC > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This object represents the router ID of the router originating > the LSA. If OSPF is used to advertise LSA, this represents a Router > ID. If ISIS is used, this represents a System ID. Otherwise, this > represents zero." > REFERENCE > " OSPF Version 2, [RFC2328], C.1 > OSPF for IPv6, [RFC5340], C.1 > [ISO10589], Section 7.1 " > ::= { tedEntry 2 } > NEW > tedLocalRouterId OBJECT-TYPE > SYNTAX TedRouterIdTC > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This object represents the router ID of the router originating > the LSA. If OSPF is used to advertise LSA, this represents a Router > ID. If ISIS is used, this represents a System ID. Otherwise, this > represents zero." > REFERENCE > "1. OSPF Version 2, RFC 2328, C.1 > 2. OSPF for IPv6, RFC 5340, C.1 > 3. Intermediate system to Intermediate system routeing > information exchange protocol for use in conjunction with > the Protocol for providing the Connectionless-mode Network > Service (ISO 8473), ISO10589, Section 7.1." > ::= { tedEntry 2 } > END > > > OLD > tedLinkType OBJECT-TYPE > SYNTAX INTEGER { > pointToPoint (1), > multiAccess (2) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This indicates the type of the link such as point-to-point or > multi-access." > REFERENCE > " Traffic Engineering (TE) Extensions to OSPF Version 2, [RFC > 3630], 2.5.1" > ::= { tedEntry 8 } > NEW > tedLinkType OBJECT-TYPE > SYNTAX INTEGER { > pointToPoint (1), > multiAccess (2) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This indicates the type of the link such as point-to-point or > multi-access." > REFERENCE > "Traffic Engineering (TE) Extensions to OSPF Version 2, > RFC 3630, 2.5.1" > ::= { tedEntry 8 } > END > > > > > I'm having some trouble with the use of 2119 language in the > > > Description for tedLinkInformationData. > > > > > > Two examples... > > > > > > If tedLinkInformationSource has the value unknown(0), this > > > object SHOULD contain a value of zeroDotZero. > > > > > > Under what circumstances can this use of "SHOULD" be varied? > > [Masanori Miyazawa] > > # At this time, we do not have a detailed situation to vary change to > > the value unknown (0). > > Should we delete the word "SHOULD"? or should the value unknown (0) be > > deleted in this MIB if it is not used? > > This looks like it needs to read... > > If tedLinkInformationSource has the value unknown(0), this > object MUST contain a value of zeroDotZero. > > > > If tedLinkInformationSource has the value > > > locallyConfigured(1), this object MAY contain the identifier > of > > > the corresponding row entry in the teLinkTable of TE-LINK-STD- > > > MIB[RFC4220], the identifier of the corresponding row in a local > > > proprietary TE link MIB module, or the value of zeroDotZero > > > otherwise. > > > > > > The use of "MAY" here implies that an implementation can choose to > > > fill in the row pointer if it likes, but this is entirely an > > > implementation choice. Is this what you are saying, or do you want > > > to constrain the behavior more forcefully if TE-LINK-STD-MIB is > implemented? > > > > > [Masanori Miyazawa] > > # No, we think the implementation of this object is not constrained > > forcefully. If the pointer is needed, we think this object should be > used. > > OK. > How about making it... > > If tedLinkInformationSource has the value > locallyConfigured(1), an implementation can use this object to > supply the identifier of the corresponding row entry in the > teLinkTable of TE-LINK-STD-MIB (RFC 4220), the identifier of > the corresponding row in a local proprietary TE link MIB module, > or the value of zeroDotZero. > > > > tedLocalIfAddrEntry OBJECT-TYPE > > > SYNTAX TedLocalIfAddrEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "This entry contains the IP address information of the > > > local TE > > > link." > > > INDEX { tedLinkIndex, tedLocalIfAddr } > > > ::= { tedLocalIfAddrTable 1 } > > > > > > TedLocalIfAddrEntry ::= SEQUENCE { > > > tedLocalIfAddrType InetAddressType, > > > tedLocalIfAddr InetAddress > > > > > > } > > > > > > What would it look like to walk this table by increasing index value? > > > Would all the shorter v4 addresses show first, or would the > > > numerically smaller v6 addresses get mixed in with the v4 addresses? > > > > > > If the latter is possible, you should use the address type as an > > > index as well. > > > > > [Masanori Miyazawa] > > # As you know, note that tedLocalIfAddrTable as well as > > tedRemoteIfAddrTable are independently defined, because the Interface > > IP Address sub-TLV may appear more than once within the same Link-TLV. > > Therefore, if the address is only used as index, another arbitrary > > index such as tedIndex would be also needed to represent the > > relationship with tedTable. > > OK. Understood. > > > > tedStatusChangeNotificationMaxRate and > > > tedCreatedDeletedNotificationMaxRate > > > > > > I am surprised that the Defval for these is 0 (no throttling) since > > > the text recognises that this is a risky situation that may cause > > > the box to blow up. Surely the default should be some safe setting. > > > > > > But then I wondered what a suitable safe setting would be and > > > realised it would be "No Notifications". Except there is no way to > > > say this with these objects. > > > > > > What do you think? > > [Masanori Miyazawa] > > #The reason for setting 0 as defval is to prevent sudden increase in > > notification information. If we set the value as 10, the SNMP manager > > would receive a number of alarms which is proportional to number of > > routers. For instance, same ospf domain consists of 5 routers, the > > SNMP manager would receive up to 50 alarms. So, I think that the optimal > value of defval is 1. > > OK. Make that change. > > > > For completeness, we usually get asked to state in the Security > > > section what the risks are with write access objects. In this case > > > it is really easy... > > > > > > There are only two write-access objects in this MIB module: > > > tedStatusChangeNotificationMaxRate and > > > tedCreatedDeletedNotificationMaxRate. Malicious modification of > > > these objects could cause the management agent, the network, or the > > > router to become overloaded with Notifications in cases of high > > > churn within the network. > > [Masanori Miyazawa] > > # You mean that we only need to describe the above sentence in section > > 8[security consideration]? > > Yes. > > Thanks, > Adrian > From daniele.ceccarelli@ericsson.com Wed Aug 22 22:31:31 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E2621F84D7; Wed, 22 Aug 2012 22:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.687 X-Spam-Level: X-Spam-Status: No, score=-3.687 tagged_above=-999 required=5 tests=[AWL=2.562, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxPRYibOdPmr; Wed, 22 Aug 2012 22:31:31 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2CD21F84C5; Wed, 22 Aug 2012 22:31:30 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-86-5035c0302dce Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C1.21.17130.030C5305; Thu, 23 Aug 2012 07:31:28 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.2.59]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 23 Aug 2012 07:31:28 +0200 From: Daniele Ceccarelli To: "ccamp-bounces@ietf.org" Date: Thu, 23 Aug 2012 07:31:27 +0200 Thread-Topic: [CCAMP] Regarding IPR on draft-ietf-ccamp-lmp-behavior-negotiation Thread-Index: AQHNgPCKTMXH+2sq/k6jRsWRwQCKlA== Message-ID: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvra7BAdMAg693LCxmfdO06L99id3i yZwbLBbLnnQwO7B4LFnyk8njy+XPbAFMUVw2Kak5mWWpRfp2CVwZn39+Yy94xVex/EsrUwPj Vp4uRg4OCQETidNfK7oYOYFMMYkL99azdTFycQgJnGKU+Hb2PxOEs4BR4npbBytIA5uAlcST Qz4gDSICphI/Fn1lAalhFrjOKPHgylxmkASLgKrEvqetLCC2sECgRG/LXCaIhiCJxc9/s0DY ehI3H69mBbF5BcIlXr7cBRZnFJCVmLB7ESOIzSwgLnHryXwmiOsEJJbsOc8MYYtKvHz8jxWi Xkbi16ZvrBD1OhILdn9ig7C1JZYtfM0MMV9Q4uTMJywTGEVmIRk7C0nLLCQts5C0LGBkWcUo nJuYmZNebq6XWpSZXFycn6dXnLqJERgdB7f8NtjBuOm+2CFGaQ4WJXFePdX9/kIC6Yklqdmp qQWpRfFFpTmpxYcYmTg4pRoYnWz3HBcwfTPX9+ChHXnyccpiIfZCKvlnKl8EuKpdW7n9deKX Z289NllO69E6sd5N91/WNFaNA9uu59XNdG29cdD81CxxYeHJVwMSi5706hz+9zFZ13TCE7PH 9hvdWWMYF7sk/heIUPtYf3xSm03ZbHXRVXqMwbLCS3YxKLBlNHFd8n/W+LxdiaU4I9FQi7mo OBEAB/45sVwCAAA= Cc: "draft-ietf-ccamp-lmp-behavior-negotiation@tools.ietf.org" , "ccamp@ietf.org" , "ccamp-ads@tools.ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-lmp-behavior-negotiation X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 05:31:31 -0000 No, i'm not aware of any IPR=0A= =0A= BR=0A= Daniele=0A= =0A= *** E-mail via DME powered by mobile broadband ***=0A= =0A= --Original message---=0A= Sender: "ccamp-bounces@ietf.org" =0A= Sent time: 22/ago/2012 22:25=0A= To: draft-ietf-ccamp-lmp-behavior-negotiation@tools.ietf.org=0A= Cc: ccamp@ietf.org, ccamp-ads@tools.ietf.org=0A= Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-lmp-behavior-negotiation= =0A= =0A= Authors, Contributors, (CCAMP)=0A= =0A= In preparation of this document for Last Call:=0A= =0A= Are you aware of any IPR that applies to draft-ietf-ccamp-lmp-behavior-nego= tiation?=0A= =0A= If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)?=0A= =0A= If you are listed as a document author or contributor, please answer the ab= ove by responding to this email regardless of whether or not you are aware = of any relevant IPR. This document will not advance to the next stage until= a response has been received from each author and listed contributor.=0A= =0A= If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please s= ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik= i/IntellectualProperty.=0A= =0A= Thank you,=0A= CCAMP WG Chairs=0A= =0A= PS Please include all listed in the headers of this message in your respons= e.=0A= =0A= =0A= _______________________________________________=0A= CCAMP mailing list=0A= CCAMP@ietf.org=0A= https://www.ietf.org/mailman/listinfo/ccamp= From lberger@labn.net Thu Aug 23 06:30:34 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CB821F8564 for ; Thu, 23 Aug 2012 06:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.384 X-Spam-Level: X-Spam-Status: No, score=-99.384 tagged_above=-999 required=5 tests=[AWL=0.777, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNkRZnOwIhst for ; Thu, 23 Aug 2012 06:30:34 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 50D2021F8545 for ; Thu, 23 Aug 2012 06:30:34 -0700 (PDT) Received: (qmail 19320 invoked by uid 0); 23 Aug 2012 13:30:32 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 23 Aug 2012 13:30:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=y1YkDO+Ojp5BugfO/iQkc7XjeaJuhkcWjNFfeZ1+X6s=; b=lTIxKw41LZp3S9JcsLUqrxiO4+b7hLrCN9N6hhkGMUb6km05DWtDpOTApUqo8EV5AjHfor49NZJYIkfn4kmrbaCWsEIQGzDRZH4MgYJfY2Xg5XcfEG1rg1a3lZgR+SUg; Received: from box313.bluehost.com ([69.89.31.113]:56575 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T4XUW-0001Zn-F1; Thu, 23 Aug 2012 07:30:32 -0600 Message-ID: <5036306E.4070308@labn.net> Date: Thu, 23 Aug 2012 09:30:22 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-lmp-behavior-negotiation@tools.ietf.org" , "ccamp@ietf.org" , "ccamp-ads@tools.ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-lmp-behavior-negotiation X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 13:30:35 -0000 On 8/22/2012 4:25 PM, BRUNGARD, DEBORAH A wrote: > Authors, Contributors, (CCAMP) > > In preparation of this document for Last Call: > > Are you aware of any IPR that applies to > draft-ietf-ccamp-lmp-behavior-negotiation? > I'm not aware of any IPR that applies to this draft. Lou (co-author) > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If you are listed as a document author or contributor, please answer > the above by responding to this email regardless of whether or not > you are aware of any relevant IPR. This document will not advance to > the next stage until a response has been received from each author > and listed contributor. > > If you are on the CCAMP WG email list but are not listed as an author > or contributor, we remind you of your obligations under the IETF IPR > rules which encourages you to notify the IETF if you are aware of IPR > of others on an IETF contribution, or to refrain from participating > in any contribution or discussion related to your undisclosed IPR. > For more information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > CCAMP WG Chairs > > PS Please include all listed in the headers of this message in your response. > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From rgandhi@cisco.com Thu Aug 23 09:20:36 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E4021F85B1 for ; Thu, 23 Aug 2012 09:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.39 X-Spam-Level: X-Spam-Status: No, score=-8.39 tagged_above=-999 required=5 tests=[AWL=2.208, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb6e5vjKMOQh for ; Thu, 23 Aug 2012 09:20:35 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3330621F85AF for ; Thu, 23 Aug 2012 09:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5798; q=dns/txt; s=iport; t=1345738835; x=1346948435; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=WoIcUF0/6SN/kzJXpYvyf2WRtyqF1KZxsyS+InaRyP0=; b=UyLWHWbWFV5U1I9ISDIOOrmUOgjMa8qvE+XETRm3pmI2NsHbOjYQEzvQ ktfTcPj5Bkk1lNrulStkG1Ia+hbrQvZtMAFeU/tntXyGjodWHVNKhNmyB t1KTb7in1RQ+kiDs0kCTD4eR0htFwmtYcpBYK7Bifu2H1RtobaC9RtgS1 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADJXNlCtJV2d/2dsb2JhbABFhgGzZW2BB4IgAQEBBBIBEBE+BwwGARkEAQEDAgYdAwIEMBQBCAkBBA4FCAEZh2sLmUyNGJMqgSGJZ4V/MmADlmiNGYFngmOBYQ X-IronPort-AV: E=Sophos;i="4.80,301,1344211200"; d="scan'208";a="111610433" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 23 Aug 2012 16:20:34 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7NGKYwG020135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Aug 2012 16:20:34 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Thu, 23 Aug 2012 11:20:34 -0500 From: "Rakesh Gandhi (rgandhi)" To: "ccamp@ietf.org" Thread-Topic: Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac2BSy6dKWryoN3/QKaPbjEu2q9iww== Date: Thu, 23 Aug 2012 16:20:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.212.97] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19132.005 x-tm-as-result: No--48.393300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 16:20:36 -0000 RGVhciBXRywNCg0KV2UgbGlrZSB0byByZXF1ZXN0IGEgcmV2aWV3IGZyb20gdGhlIFdHIG9uIHRo ZSBjaGFuZ2VzIGluIHZlcnNpb24gMDQgb2YgdGhlIGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1y c3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwIGNvbXBhcmVkIHRvIHZlcnNpb24gMDMuIA0KDQpUaGUg bWFqb3JpdHkgb2YgdGhlIHByb3Bvc2VkIGNoYW5nZXMgYXJlIGFyb3VuZCB0aGUgZm9ybWF0IGFu ZCBob3cgdG8gcG9wdWxhdGUgdGhlIGV4dGVuZGVkIGFzc29jaWF0aW9uIG9iamVjdCBhcyBsaXN0 ZWQgYmVsb3cuDQoNCk5vdGU6IEJhc2VkIG9uIHRoZSBmZWVkYmFja3MgcmVjZWl2ZWQgc28gZmFy LCBjaGFuZ2VzIGZvciBpdGVtcyA0IGFuZCA1IGJlbG93IHdpbGwgYmUgcmV2ZXJ0ZWQuDQoNCjEu IEFzc29jaWF0aW9uLUlEOg0KSXQgd2FzIG5vdCBjbGVhciBmcm9tIHJlYWRpbmcgdGhlIHZlcnNp b24gMDMgb2YgdGhlIGRyYWZ0IGhvdyB0aGlzIGZpZWxkIGlzIHBvcHVsYXRlZCBpbiB0aGUgZXh0 ZW5kZWQgYXNzb2NpYXRpb24gb2JqZWN0LiBOZXcgdmVyc2lvbiAwNCBwcm9wb3NlcyB0byBwb3B1 bGF0ZSB0aGlzIGZpZWxkIGZyb20gdGhlIGxvY2FsbHkgcHJvdmlzaW9uZWQgdmFsdWUuIEFzIHRo aXMgdmFsdWUgaXMgaWRlbnRpY2FsbHkgcHJvdmlzaW9uZWQgb24gYm90aCBlbmRzLCBpdCBwcm92 aWRlcyBhIGZpZWxkIHRvIHRpZSB0aGUgdHdvIChmb3J3YXJkIGFuZCByZXZlcnNlKSBMU1BzIG9u IGVuZC1wb2ludHMuDQoNCjIuIElQdjQgYXNzb2NpYXRpb24gc291cmNlOg0KTmV3IHZlcnNpb24g MDQgYWRkcyBhIHRpZSBicmVha2VyIHJ1bGUgZm9yIGRvdWJsZSBzaWRlZCBwcm92aXNpb25lZCBM U1BzLg0KDQozLiBHbG9iYWwgYXNzb2NpYXRpb24gc291cmNlOg0KTmV3IHZlcnNpb24gY2xhcmlm aWVzIHRoZSB1c2FnZSBmb3IgdGhpcyBmaWVsZCBzaXRpbmcgaW5mb3JtYXRpb24gZnJvbSBSRkM2 MzcwIGFuZCBvdGhlciBtZW50aW9uZWQgZHJhZnRzLiBObyBuZXcgcnVsZSBhZGRlZC4NCg0KNC4g QXNzb2NpYXRpb24gVHlwZSBhbmQgQXNzb2NpYXRpb24gRmxhZ3M6DQpOZXcgdmVyc2lvbiBwcm9w b3NlcyB0byB1c2Ugb25lIGFzc29jaWF0aW9uIFR5cGUgZm9yIHNpbmdsZSBhbmQgZG91YmxlIHNp ZGVkIHByb3Zpc2lvbmVkIGJpLWRpcmVjdGlvbmFsIExTUHMgYW5kIGRlZmluZSBhc3NvY2lhdGlv biBmbGFncyBmb3IgdGhlbS4gVGhlc2UgY2hhbmdlcyB3aWxsIGJlIHJldmVydGVkIGFzIHRoZXkg YXJlIG5vdCBuZWNlc3NhcnkuIFRoZXJlIHdpbGwgbm90IGJlIEFzc29jaWF0aW9uIEZsYWdzIGZp ZWxkIGluIHRoZSBuZXh0IHZlcnNpb24uDQoNCjUuIFN1cHBvcnQgZm9yIGNvLXJvdXRlZCBMU1Bz Og0KTmV3IHZlcnNpb24gMDQgZGVmaW5lcyBhIGZsYWcgYW5kIGhhbmRsaW5nIGZvciBjby1yb3V0 ZWQgTFNQcy4gQmFzZWQgb24gdGhlIFdHIGZlZWRiYWNrIHJlY2VpdmVkLCB0aGVzZSBjaGFuZ2Vz IHdpbGwgYmUgcmV2ZXJ0ZWQuDQoNCjYuIEV4dGVuZGVkIEFzc29jaWF0aW9uIElEIChBZGRyZXNz KToNCk5ldyB2ZXJzaW9uIDA0IHByb3Bvc2VzIHRvIHVzZSBhbiBJUCBhZGRyZXNzIGFzIGV4dGVu ZGVkIGFzc29jaWF0aW9uIElEIChhZGRyZXNzKSBhcyBhbiBhZGRpdGlvbmFsIGlkZW50aWZpZXIu IFByZXZpb3VzIHZlcnNpb24gMDMgZGVmaW5lcyBhIHZhcmlhYmxlIGxlbmd0aCBmaWVsZCBidXQg ZGlkIG5vdCBtZW50aW9uIHdoYXQgcGFyYW1ldGVycyBjYW4gYmUgYWRkZWQgdGhlcmUuDQpBIHRp ZSBicmVha2VyIHJ1bGUgaXMgZGVmaW5lZCBmb3IgZG91YmxlIHNpZGVkIHByb3Zpc2lvbmVkIHZh bHVlLg0KDQo3LiBQYXRoIFByb3RlY3Rpb24gb2JqZWN0Og0KVmVyc2lvbiAwMyBvZiB0aGUgZHJh ZnQgdmFndWVseSBtZW50aW9uZWQgYW5kIGFzc3VtZWQgb2YgdXNpbmcgcHJvdGVjdGlvbiBvYmpl Y3QgZm9yIHBhdGggcHJvdGVjdGlvbi4gTmV3IHZlcnNpb24gMDQgYWRkcyBzb21lIHRleHRzIHRv IGNsYXJpZnkgaXQsIG5vIG5ldyBydWxlIGlzIGFkZGVkLg0KDQo4LiBBdXRvLXR1bm5lbCBtZXNo Og0KTmV3IHZlcnNpb24gMDQgYWRkcyBhIHNlY3Rpb24gdG8gZWxhYm9yYXRlIG9uIGEgdXNlIGNh c2UgZm9yIGF1dG8tdHVubmVsIG1lc2guIFRoaXMgaXMgYWRkZWQgYXMgYW4gRllJIGFuZCBjYW4g YmUgcmVtb3ZlZCBpZiBXRyB0aGlua3Mgc28uDQoNCjkuIENsYXJpZmljYXRpb24gZm9yIEludGVy LUFTIExTUHM6DQpJIGJlbGlldmUgdGhlcmUgd2FzIGFuIGVtYWlsIGV4Y2hhbmdlIGJldHdlZW4g TG91IGFuZCBGZWkgdG8gY2xhcmlmeSB0aGUgcmVsYXRpb25zaGlwIHdpdGggZHJhZnQgSS1ELCBk cmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS4gQSBzZWN0aW9u IGlzIGFkZGVkIGluIHZlcnNpb24tMDQgdG8gYWRkcmVzcyB0aGlzLiBQbGVhc2UgcmV2aWV3IHRo ZSBhZGRlZCB0ZXh0Lg0KDQpQbGVhc2UgYWR2aXNlIHVzIG9uIGFib3ZlIGNoYW5nZXMuIEJhc2Vk IG9uIHRoZSBjb25zZW5zdXMsIHdlIHdpbGwgdXBkYXRlIHRoZSBkcmFmdCBhY2NvcmRpbmdseS4N Cg0KVGhhbmtzLA0KUmFrZXNoDQogDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddIA0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTUsIDIwMTIgMTA6NTMgQU0NClRvOiBSYWtl c2ggR2FuZGhpIChyZ2FuZGhpKQ0KQ2M6IHpoYW5nLmZlaTNAenRlLmNvbS5jbjsgamluZ3JxQGN0 YnJpLmNvbS5jbg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1p ZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCg0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQt YXNzb2NpYXRlZC1sc3AtMDQudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IFJha2VzaCBHYW5kaGkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxl bmFtZToJIGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNw DQpSZXZpc2lvbjoJIDA0DQpUaXRsZToJCSBSU1ZQLVRFIEV4dGVuc2lvbnMgZm9yIEFzc29jaWF0 ZWQgQmlkaXJlY3Rpb25hbCBMU1BzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wOC0xNQ0KV0cgSUQ6 CQkgY2NhbXANCk51bWJlciBvZiBwYWdlczogMTcNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0 ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQt YXNzb2NpYXRlZC1sc3ANCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQN CkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQNCg0KQWJzdHJh Y3Q6DQogICBUaGUgTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgcmVxdWlyZW1lbnRz IGRvY3VtZW50IFtSRkM1NjU0XSwNCiAgIGRlc2NyaWJlcyB0aGF0IE1QTFMtVFAgTVVTVCBzdXBw b3J0IGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBwb2ludC0NCiAgIHRvLXBvaW50IExTUHMuDQoN CiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBtZXRob2QgdG8gYmluZCB0d28gdW5pZGlyZWN0 aW9uYWwgTGFiZWwNCiAgIFN3aXRjaGVkIFBhdGhzIChMU1BzKSBpbnRvIGFuIGFzc29jaWF0ZWQg YmlkaXJlY3Rpb25hbCBMU1AuICBUaGUNCiAgIGFzc29jaWF0aW9uIGlzIGFjaGlldmVkIGJ5IGRl ZmluaW5nIHRoZSBuZXcgQXNzb2NpYXRpb24gVHlwZSBpbiB0aGUNCiAgIEV4dGVuZGVkIEFTU09D SUFUSU9OIG9iamVjdC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCg== From jdrake@juniper.net Thu Aug 23 10:15:59 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBFA21F85AF for ; Thu, 23 Aug 2012 10:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.769 X-Spam-Level: X-Spam-Status: No, score=-5.769 tagged_above=-999 required=5 tests=[AWL=0.830, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUMEbcEVLsxy for ; Thu, 23 Aug 2012 10:15:58 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id D0A2E21F85A8 for ; Thu, 23 Aug 2012 10:15:58 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUDZlTREbJKUB1Q0b51WmdtD9PFgPkzRg@postini.com; Thu, 23 Aug 2012 10:15:58 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 23 Aug 2012 10:15:36 -0700 From: John E Drake To: "Rakesh Gandhi (rgandhi)" , "ccamp@ietf.org" Date: Thu, 23 Aug 2012 10:15:34 -0700 Thread-Topic: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac2BSy6dKWryoN3/QKaPbjEu2q9iwwAB6kfg Message-ID: <5E893DB832F57341992548CDBB333163A6321CE148@EMBX01-HQ.jnpr.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 17:15:59 -0000 This sounds extremely reasonable. Yours irrespectively, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Rakesh Gandhi (rgandhi) > Sent: Thursday, August 23, 2012 9:21 AM > To: ccamp@ietf.org > Subject: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls- > tp-rsvpte-ext-associated-lsp-04.txt >=20 > Dear WG, >=20 > We like to request a review from the WG on the changes in version 04 of > the draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp compared to > version 03. >=20 > The majority of the proposed changes are around the format and how to > populate the extended association object as listed below. >=20 > Note: Based on the feedbacks received so far, changes for items 4 and 5 > below will be reverted. >=20 > 1. Association-ID: > It was not clear from reading the version 03 of the draft how this > field is populated in the extended association object. New version 04 > proposes to populate this field from the locally provisioned value. As > this value is identically provisioned on both ends, it provides a field > to tie the two (forward and reverse) LSPs on end-points. >=20 > 2. IPv4 association source: > New version 04 adds a tie breaker rule for double sided provisioned > LSPs. >=20 > 3. Global association source: > New version clarifies the usage for this field siting information from > RFC6370 and other mentioned drafts. No new rule added. >=20 > 4. Association Type and Association Flags: > New version proposes to use one association Type for single and double > sided provisioned bi-directional LSPs and define association flags for > them. These changes will be reverted as they are not necessary. There > will not be Association Flags field in the next version. >=20 > 5. Support for co-routed LSPs: > New version 04 defines a flag and handling for co-routed LSPs. Based on > the WG feedback received, these changes will be reverted. >=20 > 6. Extended Association ID (Address): > New version 04 proposes to use an IP address as extended association ID > (address) as an additional identifier. Previous version 03 defines a > variable length field but did not mention what parameters can be added > there. > A tie breaker rule is defined for double sided provisioned value. >=20 > 7. Path Protection object: > Version 03 of the draft vaguely mentioned and assumed of using > protection object for path protection. New version 04 adds some texts > to clarify it, no new rule is added. >=20 > 8. Auto-tunnel mesh: > New version 04 adds a section to elaborate on a use case for auto- > tunnel mesh. This is added as an FYI and can be removed if WG thinks > so. >=20 > 9. Clarification for Inter-AS LSPs: > I believe there was an email exchange between Lou and Fei to clarify > the relationship with draft I-D, draft-zhang-ccamp-mpls-tp-rsvpte-ext- > tunnel-num. A section is added in version-04 to address this. Please > review the added text. >=20 > Please advise us on above changes. Based on the consensus, we will > update the draft accordingly. >=20 > Thanks, > Rakesh >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, August 15, 2012 10:53 AM > To: Rakesh Gandhi (rgandhi) > Cc: zhang.fei3@zte.com.cn; jingrq@ctbri.com.cn > Subject: New Version Notification for draft-ietf-ccamp-mpls-tp-rsvpte- > ext-associated-lsp-04.txt >=20 >=20 > A new version of I-D, draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- > lsp-04.txt > has been successfully submitted by Rakesh Gandhi and posted to the IETF > repository. >=20 > Filename: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp > Revision: 04 > Title: RSVP-TE Extensions for Associated Bidirectional LSPs > Creation date: 2012-08-15 > WG ID: ccamp > Number of pages: 17 > URL: http://www.ietf.org/internet-drafts/draft-ietf-ccamp- > mpls-tp-rsvpte-ext-associated-lsp-04.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls- > tp-rsvpte-ext-associated-lsp > Htmlized: http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp- > rsvpte-ext-associated-lsp-04 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp- > mpls-tp-rsvpte-ext-associated-lsp-04 >=20 > Abstract: > The MPLS Transport Profile (MPLS-TP) requirements document > [RFC5654], > describes that MPLS-TP MUST support associated bidirectional point- > to-point LSPs. >=20 > This document provides a method to bind two unidirectional Label > Switched Paths (LSPs) into an associated bidirectional LSP. The > association is achieved by defining the new Association Type in the > Extended ASSOCIATION object. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Fri Aug 24 10:55:42 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC1721F86F7 for ; Fri, 24 Aug 2012 10:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.395 X-Spam-Level: X-Spam-Status: No, score=-99.395 tagged_above=-999 required=5 tests=[AWL=0.766, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im1UpFWjh+ep for ; Fri, 24 Aug 2012 10:55:41 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 6F07721F86D4 for ; Fri, 24 Aug 2012 10:55:41 -0700 (PDT) Received: (qmail 10156 invoked by uid 0); 24 Aug 2012 17:55:39 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 24 Aug 2012 17:55:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=BYlSsHQlvyh80gtCX+ZTCMZJwQgz2CdZ9twJ/HnCl+o=; b=pQsD+uwlIqDjZq4/oApsCVu7kI+Q4TANok/gLIinSj2Z0O3K6AfovkfEK0mDklMwgdue8TvvRf3O6esETxlEyIYS4xHBYYj3ORHDdmQWsf5vcEdh14nIHgQqaQF7aZQX; Received: from box313.bluehost.com ([69.89.31.113]:38434 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T4y6d-0007IH-31; Fri, 24 Aug 2012 11:55:39 -0600 Message-ID: <5037C010.7010605@labn.net> Date: Fri, 24 Aug 2012 13:55:28 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Rakesh Gandhi (rgandhi)" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:55:42 -0000 Rakesh, Speaking as a WG participant, and ignoring changes 4 and 5 as you plan to revert these: On 8/23/2012 12:20 PM, Rakesh Gandhi (rgandhi) wrote: > Dear WG, > > We like to request a review from the WG on the changes in version 04 of the draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp compared to version 03. > > The majority of the proposed changes are around the format and how to populate the extended association object as listed below. > > Note: Based on the feedbacks received so far, changes for items 4 and 5 below will be reverted. > > 1. Association-ID: > It was not clear from reading the version 03 of the draft how this field is populated in the extended association object. New version 04 proposes to populate this field from the locally provisioned value. As this value is identically provisioned on both ends, it provides a field to tie the two (forward and reverse) LSPs on end-points. > > 2. IPv4 association source: > New version 04 adds a tie breaker rule for double sided provisioned LSPs. > > 3. Global association source: > New version clarifies the usage for this field siting information from RFC6370 and other mentioned drafts. No new rule added. > [4 and 5 removed form mail as to be reverted] > > 6. Extended Association ID (Address): > New version 04 proposes to use an IP address as extended association ID (address) as an additional identifier. Previous version 03 defines a variable length field but did not mention what parameters can be added there. > A tie breaker rule is defined for double sided provisioned value. > Assuming changes 1, 2, and 6, how is uniqueness (of the association ID field) guaranteed? > 7. Path Protection object: > Version 03 of the draft vaguely mentioned and assumed of using protection object for path protection. New version 04 adds some texts to clarify it, no new rule is added. > I think providing informative text on interactions of this document with the various defined recovery (4872 and 4872) and reroute (4090) mechanisms is a really good idea. That said, I found this section a bit opaque. Ignoring the wordsmithing, what specific points are you trying to make? > 8. Auto-tunnel mesh: > New version 04 adds a section to elaborate on a use case for auto-tunnel mesh. This is added as an FYI and can be removed if WG thinks so. > How is the association id field value selected in this case? > 9. Clarification for Inter-AS LSPs: > I believe there was an email exchange between Lou and Fei to clarify the relationship with draft I-D, draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num. A section is added in version-04 to address this. Please review the added text. > Well I (as chair) had asked in Vancouver that the authors of rsvpte-ext-tunnel-num propose some language *on the list* that would merge the functionality defined in that document into the WG document. The mailing list discussion concluded with Fei stating that he want to keep the drafts separate, which certainly is his call (as one is an individual draft). So to be clear, I have not requested any references to rsvpte-ext-tunnel-num in the WG draft. This section does highlight the issue of how remote global_ID can be learned in the interdomain case. I think the stated solution doesn't work with your current assignment approach, e.g., consider the case when the lower IP address is the egress of the initial LSP... Lou > Please advise us on above changes. Based on the consensus, we will update the draft accordingly. > > Thanks, > Rakesh > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, August 15, 2012 10:53 AM > To: Rakesh Gandhi (rgandhi) > Cc: zhang.fei3@zte.com.cn; jingrq@ctbri.com.cn > Subject: New Version Notification for draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > > A new version of I-D, draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > has been successfully submitted by Rakesh Gandhi and posted to the IETF repository. > > Filename: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp > Revision: 04 > Title: RSVP-TE Extensions for Associated Bidirectional LSPs > Creation date: 2012-08-15 > WG ID: ccamp > Number of pages: 17 > URL: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp > Htmlized: http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04 > > Abstract: > The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], > describes that MPLS-TP MUST support associated bidirectional point- > to-point LSPs. > > This document provides a method to bind two unidirectional Label > Switched Paths (LSPs) into an associated bidirectional LSP. The > association is achieved by defining the new Association Type in the > Extended ASSOCIATION object. > > > > > The IETF Secretariat > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From rgandhi@cisco.com Fri Aug 24 11:31:53 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41ED521F86CB for ; Fri, 24 Aug 2012 11:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI7amCduNHgi for ; Fri, 24 Aug 2012 11:31:52 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id CF89421F86A2 for ; Fri, 24 Aug 2012 11:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=6734; q=dns/txt; s=iport; t=1345833112; x=1347042712; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G/gmYyMpwqZhq1+hMQExdongaBpksMs4UE+gBLcxDks=; b=m1b4xvssB48EgdrIwfjLSuFJq+4GT4Nj2QxHYK+GpsIlwyDIQ95wOtjn aO+spqrK9oDdx4dFEGLg2jSHhAbmrhrdXjB3AIp5mkBWlFaJ+F861fGrf rhS7ca1XQ555tmR6tkIfdSysLC1CaJL75G7ACUk0q8khvi5244ohWNgq8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEnIN1CtJV2c/2dsb2JhbABFumWBB4IgAQEBAwEBAQEPASc0BAcFBwQCAQgOAwQBAQEKFAUEBycLFAkIAQEEDgUIARIHh2UGC5k8oBmFYIUoGoYXYAOWaY0ZgWeCY4Fh X-IronPort-AV: E=Sophos;i="4.80,304,1344211200"; d="scan'208";a="115060092" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 24 Aug 2012 18:31:47 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7OIVl9X012087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Aug 2012 18:31:47 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Fri, 24 Aug 2012 13:31:46 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger Thread-Topic: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac2BSy6dKWryoN3/QKaPbjEu2q9iwwBAF9gAAAmySlA= Date: Fri, 24 Aug 2012 18:31:46 +0000 Message-ID: References: <5037C010.7010605@labn.net> In-Reply-To: <5037C010.7010605@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.212.97] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19134.004 x-tm-as-result: No--60.884500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 18:31:53 -0000 Hi Lou, Thanks for your review. Please see inline.... -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, August 24, 2012 1:55 PM To: Rakesh Gandhi (rgandhi) Cc: ccamp@ietf.org Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp= -rsvpte-ext-associated-lsp-04.txt Rakesh, Speaking as a WG participant, and ignoring changes 4 and 5 as you plan to r= evert these: On 8/23/2012 12:20 PM, Rakesh Gandhi (rgandhi) wrote: > Dear WG, >=20 > We like to request a review from the WG on the changes in version 04 of t= he draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp compared to version 0= 3.=20 >=20 > The majority of the proposed changes are around the format and how to pop= ulate the extended association object as listed below. >=20 > Note: Based on the feedbacks received so far, changes for items 4 and 5 b= elow will be reverted. >=20 > 1. Association-ID: > It was not clear from reading the version 03 of the draft how this field = is populated in the extended association object. New version 04 proposes to= populate this field from the locally provisioned value. As this value is i= dentically provisioned on both ends, it provides a field to tie the two (fo= rward and reverse) LSPs on end-points. >=20 > 2. IPv4 association source: > New version 04 adds a tie breaker rule for double sided provisioned LSPs. >=20 > 3. Global association source: > New version clarifies the usage for this field siting information from RF= C6370 and other mentioned drafts. No new rule added. >=20 [4 and 5 removed form mail as to be reverted] >=20 > 6. Extended Association ID (Address): > New version 04 proposes to use an IP address as extended association ID (= address) as an additional identifier. Previous version 03 defines a variabl= e length field but did not mention what parameters can be added there. > A tie breaker rule is defined for double sided provisioned value. >=20 Assuming changes 1, 2, and 6, how is uniqueness (of the association ID field) guaranteed? 1, 2 and 6 together uniquely rep= resent a bidirectional LSPs in a network. In this proposal association ID c= an be shared by multiple tunnels on the same source node. > 7. Path Protection object: > Version 03 of the draft vaguely mentioned and assumed of using protection= object for path protection. New version 04 adds some texts to clarify it, = no new rule is added. >=20 I think providing informative text on interactions of this document with th= e various defined recovery (4872 and 4872) and reroute (4090) mechanisms is= a really good idea. That said, I found this section a bit opaque. Ignori= ng the wordsmithing, what specific points are you trying to make? It just highlights that for a bi-directional tunnel, there can be a wo= rking bidirectional LSPs and protecting bidirectional LSPs. That's all. > 8. Auto-tunnel mesh: > New version 04 adds a section to elaborate on a use case for auto-tunnel = mesh. This is added as an FYI and can be removed if WG thinks so. >=20 How is the association id field value selected in this case? Proposal allows that single association-id can be provisioned for a me= sh-group. So when a node initiates multiple auto-tunnels in a mesh-group, a= s per previous definition, a tunnel can be uniquely identified with , i.e. extended association object. > 9. Clarification for Inter-AS LSPs: > I believe there was an email exchange between Lou and Fei to clarify the = relationship with draft I-D, draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-nu= m. A section is added in version-04 to address this. Please review the adde= d text. >=20 Well I (as chair) had asked in Vancouver that the authors of rsvpte-ext-tun= nel-num propose some language *on the list* that would merge the functional= ity defined in that document into the WG document. The mailing list discussion concluded with Fei stating that he want to keep= the drafts separate, which certainly is his call (as one is an individual = draft). So to be clear, I have not requested any references to rsvpte-ext-= tunnel-num in the WG draft. This section does highlight the issue of how remote global_ID can be learne= d in the interdomain case. I think the stated solution doesn't work with y= our current assignment approach, e.g., consider the case when the lower IP = address is the egress of the initial LSP... I will let Fei address this comment. Thanks, Rakesh Lou > Please advise us on above changes. Based on the consensus, we will update= the draft accordingly. >=20 > Thanks, > Rakesh > =20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, August 15, 2012 10:53 AM > To: Rakesh Gandhi (rgandhi) > Cc: zhang.fei3@zte.com.cn; jingrq@ctbri.com.cn > Subject: New Version Notification for=20 > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >=20 >=20 > A new version of I-D,=20 > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > has been successfully submitted by Rakesh Gandhi and posted to the IETF r= epository. >=20 > Filename: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp > Revision: 04 > Title: RSVP-TE Extensions for Associated Bidirectional LSPs > Creation date: 2012-08-15 > WG ID: ccamp > Number of pages: 17 > URL: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpl= s-tp-rsvpte-ext-associated-lsp-04.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp= -rsvpte-ext-associated-lsp > Htmlized: http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvp= te-ext-associated-lsp-04 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls= -tp-rsvpte-ext-associated-lsp-04 >=20 > Abstract: > The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], > describes that MPLS-TP MUST support associated bidirectional point- > to-point LSPs. >=20 > This document provides a method to bind two unidirectional Label > Switched Paths (LSPs) into an associated bidirectional LSP. The > association is achieved by defining the new Association Type in the > Extended ASSOCIATION object. >=20 > = =20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 >=20 >=20 From rgandhi@cisco.com Fri Aug 24 11:59:02 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530F221F8646 for ; Fri, 24 Aug 2012 11:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWcUupXfY5+G for ; Fri, 24 Aug 2012 11:59:01 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 211CF21F8625 for ; Fri, 24 Aug 2012 11:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=5416; q=dns/txt; s=iport; t=1345834741; x=1347044341; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IbGYGd9EjULK9GjsdokZ3HsrNy2VA1dNK2RSBF//orc=; b=TbRDRbMke9Oczpw7Nn1BcDVn9s6WaVrh5HD8p2KLBvbcTbG93Nw79VCx 6BP79NSmoEDwidwJu9KqTSzRjn1gc8h44rE8tdHf8jK1h9m902nioYpYT ZuZQ+l7UFQWGO5sld1M75MfOUS8IvdBwV8oFo0S6n5qh5wX8uaW40PpNt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACbON1CtJV2a/2dsb2JhbABFumWBB4IgAQEBBAEBAQ8BJzQEEwQCAQgRBAEBCxQFBAcnCxQJCAEBBAESCAEZh2sLmTKgF4sIhjFgA5ZpjRmBZ4JjgWE X-IronPort-AV: E=Sophos;i="4.80,304,1344211200"; d="scan'208";a="115100620" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 24 Aug 2012 18:59:00 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7OIx0Fb016704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Aug 2012 18:59:00 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Fri, 24 Aug 2012 13:58:59 -0500 From: "Rakesh Gandhi (rgandhi)" To: John E Drake , "ccamp@ietf.org" Thread-Topic: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac2BSy6dKWryoN3/QKaPbjEu2q9iwwAB6kfgADXmQlA= Date: Fri, 24 Aug 2012 18:58:58 +0000 Message-ID: References: <5E893DB832F57341992548CDBB333163A6321CE148@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A6321CE148@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.212.97] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19136.001 x-tm-as-result: No--56.055000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 18:59:02 -0000 Thank you John for the review. Regards, Rakesh -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, August 23, 2012 1:16 PM To: Rakesh Gandhi (rgandhi); ccamp@ietf.org Subject: RE: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp= -rsvpte-ext-associated-lsp-04.txt This sounds extremely reasonable. Yours irrespectively, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=20 > Of Rakesh Gandhi (rgandhi) > Sent: Thursday, August 23, 2012 9:21 AM > To: ccamp@ietf.org > Subject: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-=20 > tp-rsvpte-ext-associated-lsp-04.txt >=20 > Dear WG, >=20 > We like to request a review from the WG on the changes in version 04=20 > of the draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp compared to=20 > version 03. >=20 > The majority of the proposed changes are around the format and how to=20 > populate the extended association object as listed below. >=20 > Note: Based on the feedbacks received so far, changes for items 4 and=20 > 5 below will be reverted. >=20 > 1. Association-ID: > It was not clear from reading the version 03 of the draft how this=20 > field is populated in the extended association object. New version 04=20 > proposes to populate this field from the locally provisioned value. As=20 > this value is identically provisioned on both ends, it provides a=20 > field to tie the two (forward and reverse) LSPs on end-points. >=20 > 2. IPv4 association source: > New version 04 adds a tie breaker rule for double sided provisioned=20 > LSPs. >=20 > 3. Global association source: > New version clarifies the usage for this field siting information from > RFC6370 and other mentioned drafts. No new rule added. >=20 > 4. Association Type and Association Flags: > New version proposes to use one association Type for single and double=20 > sided provisioned bi-directional LSPs and define association flags for=20 > them. These changes will be reverted as they are not necessary. There=20 > will not be Association Flags field in the next version. >=20 > 5. Support for co-routed LSPs: > New version 04 defines a flag and handling for co-routed LSPs. Based=20 > on the WG feedback received, these changes will be reverted. >=20 > 6. Extended Association ID (Address): > New version 04 proposes to use an IP address as extended association=20 > ID > (address) as an additional identifier. Previous version 03 defines a=20 > variable length field but did not mention what parameters can be added=20 > there. > A tie breaker rule is defined for double sided provisioned value. >=20 > 7. Path Protection object: > Version 03 of the draft vaguely mentioned and assumed of using=20 > protection object for path protection. New version 04 adds some texts=20 > to clarify it, no new rule is added. >=20 > 8. Auto-tunnel mesh: > New version 04 adds a section to elaborate on a use case for auto-=20 > tunnel mesh. This is added as an FYI and can be removed if WG thinks=20 > so. >=20 > 9. Clarification for Inter-AS LSPs: > I believe there was an email exchange between Lou and Fei to clarify=20 > the relationship with draft I-D, draft-zhang-ccamp-mpls-tp-rsvpte-ext- > tunnel-num. A section is added in version-04 to address this. Please=20 > review the added text. >=20 > Please advise us on above changes. Based on the consensus, we will=20 > update the draft accordingly. >=20 > Thanks, > Rakesh >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, August 15, 2012 10:53 AM > To: Rakesh Gandhi (rgandhi) > Cc: zhang.fei3@zte.com.cn; jingrq@ctbri.com.cn > Subject: New Version Notification for draft-ietf-ccamp-mpls-tp-rsvpte-=20 > ext-associated-lsp-04.txt >=20 >=20 > A new version of I-D, draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated- > lsp-04.txt > has been successfully submitted by Rakesh Gandhi and posted to the=20 > IETF repository. >=20 > Filename: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp > Revision: 04 > Title: RSVP-TE Extensions for Associated Bidirectional LSPs > Creation date: 2012-08-15 > WG ID: ccamp > Number of pages: 17 > URL: http://www.ietf.org/internet-drafts/draft-ietf-ccamp- > mpls-tp-rsvpte-ext-associated-lsp-04.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls- > tp-rsvpte-ext-associated-lsp > Htmlized: http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp- > rsvpte-ext-associated-lsp-04 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp- > mpls-tp-rsvpte-ext-associated-lsp-04 >=20 > Abstract: > The MPLS Transport Profile (MPLS-TP) requirements document=20 > [RFC5654], > describes that MPLS-TP MUST support associated bidirectional point- > to-point LSPs. >=20 > This document provides a method to bind two unidirectional Label > Switched Paths (LSPs) into an associated bidirectional LSP. The > association is achieved by defining the new Association Type in the > Extended ASSOCIATION object. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Fri Aug 24 13:40:57 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CB521F8596 for ; Fri, 24 Aug 2012 13:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.406 X-Spam-Level: X-Spam-Status: No, score=-99.406 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51BGrYTZCgFi for ; Fri, 24 Aug 2012 13:40:56 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id B4DB221F858E for ; Fri, 24 Aug 2012 13:40:48 -0700 (PDT) Received: (qmail 771 invoked by uid 0); 24 Aug 2012 20:40:47 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 24 Aug 2012 20:40:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=BgcTZQSSSKilXP/wBX+z/Y7YCWGUsJZwkPLC+SrMFt0=; b=aWYWa1S7fSmP8DmCQy9v41QvxbKCoCJ1hGmjI82+05H1j1wOUoyFWZqYK3MzRpErRNfpEstm7uGoYgVgCmt5JlEabnFElbdKsl1wl2OCBV016+8uLottAKZr57LwW1V8; Received: from box313.bluehost.com ([69.89.31.113]:56680 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T50gR-00076k-JY; Fri, 24 Aug 2012 14:40:47 -0600 Message-ID: <5037E6C4.5050507@labn.net> Date: Fri, 24 Aug 2012 16:40:36 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Rakesh Gandhi (rgandhi)" References: <5037C010.7010605@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 20:40:57 -0000 Rakesh, See below. On 8/24/2012 2:31 PM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, > > Thanks for your review. Please see inline.... > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, August 24, 2012 1:55 PM > To: Rakesh Gandhi (rgandhi) > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > Rakesh, > > Speaking as a WG participant, and ignoring changes 4 and 5 as you plan to revert these: > > On 8/23/2012 12:20 PM, Rakesh Gandhi (rgandhi) wrote: >> Dear WG, >> >> We like to request a review from the WG on the changes in version 04 of the draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp compared to version 03. >> >> The majority of the proposed changes are around the format and how to populate the extended association object as listed below. >> >> Note: Based on the feedbacks received so far, changes for items 4 and 5 below will be reverted. >> >> 1. Association-ID: >> It was not clear from reading the version 03 of the draft how this field is populated in the extended association object. New version 04 proposes to populate this field from the locally provisioned value. As this value is identically provisioned on both ends, it provides a field to tie the two (forward and reverse) LSPs on end-points. >> > >> 2. IPv4 association source: >> New version 04 adds a tie breaker rule for double sided provisioned LSPs. >> >> 3. Global association source: >> New version clarifies the usage for this field siting information from RFC6370 and other mentioned drafts. No new rule added. >> > > [4 and 5 removed form mail as to be reverted] > >> >> 6. Extended Association ID (Address): >> New version 04 proposes to use an IP address as extended association ID (address) as an additional identifier. Previous version 03 defines a variable length field but did not mention what parameters can be added there. >> A tie breaker rule is defined for double sided provisioned value. >> > > Assuming changes 1, 2, and 6, how is uniqueness (of the association ID > field) guaranteed? > > 1, 2 and 6 together uniquely represent a bidirectional LSPs in a network. In this proposal association ID can be shared by multiple tunnels on the same source node. > Sure, but who picks the association-id such that uniqueness is assured in the double sided provisioning case? If assuming this is always provisioned, then how does the provisioning entity, which may be one or more people at a CLI, pick the association-id such that it is unique across the tuple ? (neither a single provision device nor polling the ingress and egress are really reasonable solutions.) Wouldn't it be better for the Association Source and Association ID to be administratively set? e.g., to the IP address and value selected by the provisioning source. (Extended Association ID could also be used if desired, but I'm not sure it really adds value.) > >> 7. Path Protection object: >> Version 03 of the draft vaguely mentioned and assumed of using protection object for path protection. New version 04 adds some texts to clarify it, no new rule is added. >> > > I think providing informative text on interactions of this document with the various defined recovery (4872 and 4872) and reroute (4090) mechanisms is a really good idea. That said, I found this section a bit opaque. Ignoring the wordsmithing, what specific points are you trying to make? > > It just highlights that for a bi-directional tunnel, there can be a working bidirectional LSPs and protecting bidirectional LSPs. That's all. > I think the proposed text is really confusing and doesn't cover the full scope (in particular 4872 is about recovery which is both protection and restoration, it doesn't cover 4873 or 4090). Can you propose (one the list) some alternate text? > >> 8. Auto-tunnel mesh: >> New version 04 adds a section to elaborate on a use case for auto-tunnel mesh. This is added as an FYI and can be removed if WG thinks so. >> > > How is the association id field value selected in this case? > > Proposal allows that single association-id can be provisioned for a mesh-group. I don't think you have text that supports this. The closest you come is: A node provisioned to build a mesh of associated bidirectional LSPs may use identical association ID for the given mesh-group member peers. which doesn't say that the "identical association ID" MUST be provisioned. Lou >> So when a node initiates multiple auto-tunnels in a mesh-group, as per previous definition, a tunnel can be uniquely identified with , i.e. extended association object. > > >> 9. Clarification for Inter-AS LSPs: >> I believe there was an email exchange between Lou and Fei to clarify the relationship with draft I-D, draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num. A section is added in version-04 to address this. Please review the added text. >> > > Well I (as chair) had asked in Vancouver that the authors of rsvpte-ext-tunnel-num propose some language *on the list* that would merge the functionality defined in that document into the WG document. > The mailing list discussion concluded with Fei stating that he want to keep the drafts separate, which certainly is his call (as one is an individual draft). So to be clear, I have not requested any references to rsvpte-ext-tunnel-num in the WG draft. > > This section does highlight the issue of how remote global_ID can be learned in the interdomain case. I think the stated solution doesn't work with your current assignment approach, e.g., consider the case when the lower IP address is the egress of the initial LSP... > > I will let Fei address this comment. > > Thanks, > Rakesh > > > Lou > > >> Please advise us on above changes. Based on the consensus, we will update the draft accordingly. >> >> Thanks, >> Rakesh >> >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, August 15, 2012 10:53 AM >> To: Rakesh Gandhi (rgandhi) >> Cc: zhang.fei3@zte.com.cn; jingrq@ctbri.com.cn >> Subject: New Version Notification for >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> >> A new version of I-D, >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> has been successfully submitted by Rakesh Gandhi and posted to the IETF repository. >> >> Filename: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp >> Revision: 04 >> Title: RSVP-TE Extensions for Associated Bidirectional LSPs >> Creation date: 2012-08-15 >> WG ID: ccamp >> Number of pages: 17 >> URL: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> Status: http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp >> Htmlized: http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04 >> >> Abstract: >> The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], >> describes that MPLS-TP MUST support associated bidirectional point- >> to-point LSPs. >> >> This document provides a method to bind two unidirectional Label >> Switched Paths (LSPs) into an associated bidirectional LSP. The >> association is achieved by defining the new Association Type in the >> Extended ASSOCIATION object. >> >> >> >> >> The IETF Secretariat >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > > > > From rgandhi@cisco.com Fri Aug 24 14:18:53 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EA921F85FF for ; Fri, 24 Aug 2012 14:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.759 X-Spam-Level: X-Spam-Status: No, score=-8.759 tagged_above=-999 required=5 tests=[AWL=1.840, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zy77pWwarsG for ; Fri, 24 Aug 2012 14:18:52 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9299621F85A5 for ; Fri, 24 Aug 2012 14:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=9217; q=dns/txt; s=iport; t=1345843132; x=1347052732; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pemCZsiwGynSkQ41wQ/YRzgxr5ZqIyFZ6krKnjtabMo=; b=BGyt2D8J0SXA/9q1Y3HlZ5/fc8lxPQTWJ/AYOjPFPM/diiN4uq2Zqef3 up+hY1Vh2MghUGWAW4xGBeNRs31tOdUoEji1yeCuWpgDO0Uh/+IUAg3+X C7PJoxmP7qFCUrdY+tqK7bZpUCVttdjXuaT2MjdhLXTsgVHkFQh292IZK A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAL7uN1CtJV2d/2dsb2JhbABFummBB4IgAQEBAwEBAQEPASc0BAcMBAIBCA4DBAEBAQoUBQQHJwsUCQgBAQQOBQgBEgeHZQYLmTWgE4VghSgahhdgA5ZpjRmBZ4JjgWE X-IronPort-AV: E=Sophos;i="4.80,304,1344211200"; d="scan'208";a="115135343" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 24 Aug 2012 21:18:52 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7OLIpEs029222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Aug 2012 21:18:51 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Fri, 24 Aug 2012 16:18:51 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger Thread-Topic: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac2BSy6dKWryoN3/QKaPbjEu2q9iwwBAF9gAAAmySlD//+CQAIAAS+fw Date: Fri, 24 Aug 2012 21:18:51 +0000 Message-ID: References: <5037C010.7010605@labn.net> <5037E6C4.5050507@labn.net> In-Reply-To: <5037E6C4.5050507@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.212.97] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19136.001 x-tm-as-result: No--64.579600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 21:18:54 -0000 Hi Lou, Please see inline.... -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, August 24, 2012 4:41 PM To: Rakesh Gandhi (rgandhi) Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp= -rsvpte-ext-associated-lsp-04.txt Rakesh, See below. On 8/24/2012 2:31 PM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, >=20 > Thanks for your review. Please see inline.... >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, August 24, 2012 1:55 PM > To: Rakesh Gandhi (rgandhi) > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] Review Request For Changes in=20 > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >=20 > Rakesh, >=20 > Speaking as a WG participant, and ignoring changes 4 and 5 as you plan to= revert these: >=20 > On 8/23/2012 12:20 PM, Rakesh Gandhi (rgandhi) wrote: >> Dear WG, >> >> We like to request a review from the WG on the changes in version 04 of = the draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp compared to version = 03.=20 >> >> The majority of the proposed changes are around the format and how to po= pulate the extended association object as listed below. >> >> Note: Based on the feedbacks received so far, changes for items 4 and 5 = below will be reverted. >> >> 1. Association-ID: >> It was not clear from reading the version 03 of the draft how this field= is populated in the extended association object. New version 04 proposes t= o populate this field from the locally provisioned value. As this value is = identically provisioned on both ends, it provides a field to tie the two (f= orward and reverse) LSPs on end-points. >> >=20 >> 2. IPv4 association source: >> New version 04 adds a tie breaker rule for double sided provisioned LSPs= . >> >> 3. Global association source: >> New version clarifies the usage for this field siting information from R= FC6370 and other mentioned drafts. No new rule added. >> >=20 > [4 and 5 removed form mail as to be reverted] >=20 >> >> 6. Extended Association ID (Address): >> New version 04 proposes to use an IP address as extended association ID = (address) as an additional identifier. Previous version 03 defines a variab= le length field but did not mention what parameters can be added there. >> A tie breaker rule is defined for double sided provisioned value. >> >=20 > Assuming changes 1, 2, and 6, how is uniqueness (of the association ID > field) guaranteed? >=20 > 1, 2 and 6 together uniquely r= epresent a bidirectional LSPs in a network. In this proposal association ID= can be shared by multiple tunnels on the same source node. >=20 Sure, but who picks the association-id such that uniqueness is assured in t= he double sided provisioning case? If assuming this is always provisioned, then how does the provisioning enti= ty, which may be one or more people at a CLI, pick the association-id such = that it is unique across the tuple ? (nei= ther a single provision device nor polling the ingress and egress are reall= y reasonable solutions.) Wouldn't it be better for the Association Source and Association ID to be a= dministratively set? e.g., to the IP address and value selected by the prov= isioning source. (Extended Association ID could also be used if desired, bu= t I'm not sure it really adds value.) Sure, association-id and association-source can be set administrative= ly or by any other means (we can reword the draft). Idea here is that for d= ouble sided provisioned LSPs, they need to have the same values, so both si= des can glue the matching LSPs. >=20 >> 7. Path Protection object: >> Version 03 of the draft vaguely mentioned and assumed of using protectio= n object for path protection. New version 04 adds some texts to clarify it,= no new rule is added. >> >=20 > I think providing informative text on interactions of this document with = the various defined recovery (4872 and 4872) and reroute (4090) mechanisms = is a really good idea. That said, I found this section a bit opaque. Igno= ring the wordsmithing, what specific points are you trying to make? >=20 > It just highlights that for a bi-directional tunnel, there can be a = working bidirectional LSPs and protecting bidirectional LSPs. That's all. >=20 I think the proposed text is really confusing and doesn't cover the full sc= ope (in particular 4872 is about recovery which is both protection and rest= oration, it doesn't cover 4873 or 4090). Can you propose (one the list) some alternate text? Idea here is that there are multiple bidirectional LSPs for a tunnel = for different LSP roles. We could remove the LSP type as primary and second= ary reference from the text, and just state LSPs for different roles. >=20 >> 8. Auto-tunnel mesh: >> New version 04 adds a section to elaborate on a use case for auto-tunnel= mesh. This is added as an FYI and can be removed if WG thinks so. >> >=20 > How is the association id field value selected in this case? >=20 > Proposal allows that single association-id can be provisioned for a = mesh-group.=20 I don't think you have text that supports this. The closest you come is: A node provisioned to build a mesh of associated bidirectional LSPs may use identical association ID for the given mesh-group member peers. which doesn't say that the "identical association ID" MUST be provisioned. Yes, we can clarify this. Thanks, Rakesh Lou >> So when a node initiates multiple auto-tunnels in a mesh-group, as per p= revious definition, a tunnel can be uniquely identified with , i.e. extended association object. >=20 >=20 >> 9. Clarification for Inter-AS LSPs: >> I believe there was an email exchange between Lou and Fei to clarify the= relationship with draft I-D, draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-n= um. A section is added in version-04 to address this. Please review the add= ed text. >> >=20 > Well I (as chair) had asked in Vancouver that the authors of rsvpte-ext-t= unnel-num propose some language *on the list* that would merge the function= ality defined in that document into the WG document. > The mailing list discussion concluded with Fei stating that he want to ke= ep the drafts separate, which certainly is his call (as one is an individua= l draft). So to be clear, I have not requested any references to rsvpte-ex= t-tunnel-num in the WG draft. >=20 > This section does highlight the issue of how remote global_ID can be lear= ned in the interdomain case. I think the stated solution doesn't work with= your current assignment approach, e.g., consider the case when the lower I= P address is the egress of the initial LSP... >=20 > I will let Fei address this comment. >=20 > Thanks, > Rakesh >=20 >=20 > Lou >=20 >=20 >> Please advise us on above changes. Based on the consensus, we will updat= e the draft accordingly. >> >> Thanks, >> Rakesh >> =20 >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, August 15, 2012 10:53 AM >> To: Rakesh Gandhi (rgandhi) >> Cc: zhang.fei3@zte.com.cn; jingrq@ctbri.com.cn >> Subject: New Version Notification for=20 >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> >> A new version of I-D, >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> has been successfully submitted by Rakesh Gandhi and posted to the IETF = repository. >> >> Filename: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp >> Revision: 04 >> Title: RSVP-TE Extensions for Associated Bidirectional LSPs >> Creation date: 2012-08-15 >> WG ID: ccamp >> Number of pages: 17 >> URL: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mp= ls-tp-rsvpte-ext-associated-lsp-04.txt >> Status: http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-t= p-rsvpte-ext-associated-lsp >> Htmlized: http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsv= pte-ext-associated-lsp-04 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpl= s-tp-rsvpte-ext-associated-lsp-04 >> >> Abstract: >> The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], >> describes that MPLS-TP MUST support associated bidirectional point- >> to-point LSPs. >> >> This document provides a method to bind two unidirectional Label >> Switched Paths (LSPs) into an associated bidirectional LSP. The >> association is achieved by defining the new Association Type in the >> Extended ASSOCIATION object. >> >> = =20 >> >> >> The IETF Secretariat >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> >=20 >=20 >=20 >=20 From internet-drafts@ietf.org Sat Aug 25 00:26:29 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACCD21F8523; Sat, 25 Aug 2012 00:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCdFzFEYTO2e; Sat, 25 Aug 2012 00:26:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECB921F8468; Sat, 25 Aug 2012 00:26:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120825072629.29132.33058.idtracker@ietfa.amsl.com> Date: Sat, 25 Aug 2012 00:26:29 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-g709-framework-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 07:26:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Framework for GMPLS and PCE Control of G.709 Optical Tra= nsport Networks Author(s) : Fatai Zhang Dan Li Han Li Sergio Belotti Daniele Ceccarelli Filename : draft-ietf-ccamp-gmpls-g709-framework-09.txt Pages : 28 Date : 2012-08-25 Abstract: This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTN) as specified in ITU-T Recommendation G.709 as consented in October 2009. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-g709-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-g709-framework-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhangfatai@huawei.com Sat Aug 25 00:36:24 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF2621F851B for ; Sat, 25 Aug 2012 00:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.705 X-Spam-Level: ** X-Spam-Status: No, score=2.705 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjNc+SOIYEjB for ; Sat, 25 Aug 2012 00:36:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F108E21F8501 for ; Sat, 25 Aug 2012 00:36:23 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp03-ep.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id ALP00052; Fri, 24 Aug 2012 23:36:23 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 25 Aug 2012 00:33:53 -0700 Received: from SZXEML434-HUB.china.huawei.com (10.72.61.62) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 25 Aug 2012 00:34:01 -0700 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.171]) by szxeml434-hub.china.huawei.com ([10.72.61.62]) with mapi id 14.01.0323.003; Sat, 25 Aug 2012 15:33:49 +0800 From: Fatai Zhang To: "ccamp@ietf.org" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-g709-framework-09.txt Thread-Index: AQHNgpL3yno1zAEluk2dV0uyVrQgR5dqIPag Date: Sat, 25 Aug 2012 07:33:48 +0000 Message-ID: References: <20120825072629.29132.33058.idtracker@ietfa.amsl.com> In-Reply-To: <20120825072629.29132.33058.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.232] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "lihan@chinamobile.com" , "sergio.belotti@alcatel-lucent.it" Subject: [CCAMP] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2Nh?= =?gb2312?b?bXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDkudHh0?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 07:36:24 -0000 SGkgYWxsLA0KDQpBIG5ldyB2ZXJzaW9uIG9mIHRoaXMgaGFzIGJlZW4gdXBsb2FkZWQuIFR3byBt YWpvciBjaGFuZ2VzOg0KDQooMSkgVXBkYXRlZCBDb250cm9sIFBsYW5lIEJhY2t3YXJkIENvbXBh dGliaWxpdHkgYXMgc3VnZ2VzdGVkIGJ5IExvdS4NCigyKSBSZW1vdmVkIGEgc2lnbmFsaW5nIHJl cXVpcmVtZW50IGFib3V0IEhpZXJhcmNoeSBpbmZvcm1hdGlvbiBhcyB3ZSBhbHJlYWR5IGFncmVl ZC4NCg0KUGxlYXNlIGNoZWNrIGZvciB0aGUgZGV0YWlscy4NCg0KVGhlIGF1dGhvcnMgdGhpbmsg dGhhdCB0aGlzIGRyYWZ0IHNob3VsZCBiZSByZWFkeSBmb3IgTEMuDQoNCg0KDQpCZXN0IFJlZ2Fy ZHMNCg0KRmF0YWkNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogY2NhbXAtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnDQq3osvNyrG85DogMjAxMsTqONTCMjXI1SAxNToyNg0KytW8/sjLOiBp LWQtYW5ub3VuY2VAaWV0Zi5vcmcNCrOty806IGNjYW1wQGlldGYub3JnDQrW98ziOiBbQ0NBTVBd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDkudHh0 DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g b2YgdGhlIENvbW1vbiBDb250cm9sIGFuZCBNZWFzdXJlbWVudCBQbGFuZSBXb3JraW5nIEdyb3Vw IG9mIHRoZSBJRVRGLg0KDQoJVGl0bGUgICAgICAgICAgIDogRnJhbWV3b3JrIGZvciBHTVBMUyBh bmQgUENFIENvbnRyb2wgb2YgRy43MDkgT3B0aWNhbCBUcmFuc3BvcnQgTmV0d29ya3MNCglBdXRo b3IocykgICAgICAgOiBGYXRhaSBaaGFuZw0KICAgICAgICAgICAgICAgICAgICAgICAgICBEYW4g TGkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgSGFuIExpDQogICAgICAgICAgICAgICAgICAg ICAgICAgIFNlcmdpbyBCZWxvdHRpDQogICAgICAgICAgICAgICAgICAgICAgICAgIERhbmllbGUg Q2VjY2FyZWxsaQ0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcw OS1mcmFtZXdvcmstMDkudHh0DQoJUGFnZXMgICAgICAgICAgIDogMjgNCglEYXRlICAgICAgICAg ICAgOiAyMDEyLTA4LTI1DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBh IGZyYW1ld29yayB0byBhbGxvdyB0aGUgZGV2ZWxvcG1lbnQgb2YNCiAgIHByb3RvY29sIGV4dGVu c2lvbnMgdG8gc3VwcG9ydCBHZW5lcmFsaXplZCBNdWx0aS1Qcm90b2NvbCBMYWJlbA0KICAgU3dp dGNoaW5nIChHTVBMUykgYW5kIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCAoUENFKSBjb250cm9s IG9mDQogICBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3b3JrcyAoT1ROKSBhcyBzcGVjaWZpZWQgaW4g SVRVLVQgUmVjb21tZW5kYXRpb24NCiAgIEcuNzA5IGFzIGNvbnNlbnRlZCBpbiBPY3RvYmVyIDIw MDkuDQoNCg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRy YWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2Ft cC1nbXBscy1nNzA5LWZyYW1ld29yaw0KDQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9u IGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2Nh bXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDkNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl cnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wOQ0KDQoNCkludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo= From zhang.fei3@zte.com.cn Sat Aug 25 20:44:01 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5120121F8513; Sat, 25 Aug 2012 20:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.001 X-Spam-Level: X-Spam-Status: No, score=-96.001 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfBCTYrJbl7n; Sat, 25 Aug 2012 20:44:00 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 139A421F8512; Sat, 25 Aug 2012 20:43:58 -0700 (PDT) Received: from [10.30.3.21] by mx5.zte.com.cn with surfront esmtp id 232553673712530(version=TLSv1/SSLv3 cipher=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA bits=128 verify=NO); Sun, 26 Aug 2012 11:37:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7Q3hoRd032055; Sun, 26 Aug 2012 11:43:50 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <5037C010.7010605@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: 784D37F1:E1BDC4D4-48257A66:00127BF4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Sun, 26 Aug 2012 11:43:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-26 11:43:40, Serialize complete at 2012-08-26 11:43:40 Content-Type: multipart/alternative; boundary="=_alternative 0014687948257A66_=" X-MAIL: mse02.zte.com.cn q7Q3hoRd032055 Cc: "ccamp@ietf.org" , ccamp-bounces@ietf.org Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 03:44:01 -0000 This is a multipart message in MIME format. --=_alternative 0014687948257A66_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTG91LCANCg0KVGhhbmtzIGZvciB5b3VyIGRldGFpbGVkIHJldmlldywgc25pcHBlZCB0aGUg b3RoZXJzLCBzZWUgaW5saW5lIHdpdGggPGZlaT4NCg0KV2VsbCBJIChhcyBjaGFpcikgaGFkIGFz a2VkIGluIFZhbmNvdXZlciB0aGF0IHRoZSBhdXRob3JzIG9mDQpyc3ZwdGUtZXh0LXR1bm5lbC1u dW0gcHJvcG9zZSBzb21lIGxhbmd1YWdlICpvbiB0aGUgbGlzdCogdGhhdCB3b3VsZA0KbWVyZ2Ug dGhlIGZ1bmN0aW9uYWxpdHkgZGVmaW5lZCBpbiB0aGF0IGRvY3VtZW50IGludG8gdGhlIFdHIGRv Y3VtZW50Lg0KVGhlIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uIGNvbmNsdWRlZCB3aXRoIEZlaSBz dGF0aW5nIHRoYXQgaGUgd2FudCB0bw0Ka2VlcCB0aGUgZHJhZnRzIHNlcGFyYXRlLCB3aGljaCBj ZXJ0YWlubHkgaXMgaGlzIGNhbGwgKGFzIG9uZSBpcyBhbg0KaW5kaXZpZHVhbCBkcmFmdCkuICBT byB0byBiZSBjbGVhciwgSSBoYXZlIG5vdCByZXF1ZXN0ZWQgYW55IHJlZmVyZW5jZXMNCnRvIHJz dnB0ZS1leHQtdHVubmVsLW51bSBpbiB0aGUgV0cgZHJhZnQuDQoNCjxGZWk+IFN1cmUsIHRoaXMg cGFydCBpcyBhbHNvIGluZm9ybWF0aW9uYWwgYW5kIHRoZXJlIGlzIG5vIG5ldyBtZWNoYW5pc20g DQppbnRyb2R1Y2VkIGhlcmUuIDopDQoNClRoaXMgc2VjdGlvbiBkb2VzIGhpZ2hsaWdodCB0aGUg aXNzdWUgb2YgaG93IHJlbW90ZSBnbG9iYWxfSUQgY2FuIGJlDQpsZWFybmVkIGluIHRoZSBpbnRl cmRvbWFpbiBjYXNlLiAgSSB0aGluayB0aGUgc3RhdGVkIHNvbHV0aW9uIGRvZXNuJ3QNCndvcmsg d2l0aCB5b3VyIGN1cnJlbnQgYXNzaWdubWVudCBhcHByb2FjaCwgZS5nLiwgY29uc2lkZXIgdGhl IGNhc2Ugd2hlbg0KdGhlIGxvd2VyIElQIGFkZHJlc3MgaXMgdGhlIGVncmVzcyBvZiB0aGUgaW5p dGlhbCBMU1AuLi4NCg0KPEZlaT4gRm9yIHRoZSBzaW5nbGVkIHNpZGVkIHByb3Zpc2lvbmluZyBt b2RlbCwgdGhlIGluaXRpYWwgTFNQIHNvdXJjZSANCmFkZHJlc3MgKEFzc29jaWF0aW9uIFNvdXJj ZSlhbmQgZ2xvYmFsX0lEIGFyZSBwdXNoZWQgaW50byB0aGUgRUEgb2JqZWN0cywgDQpzbyB0aGUg aW5ncmVzcyBjYW4gbGVhcm4gdGhlIGdsb2JhbCBJRCBvZiB0aGUgcGVlciBub2RlIGJ5IHRoZSBk ZWZpbmVkIA0KQXNzb2NpYXRpb24gVHlwZSAiTFNQIElkZW50aWZpZXJzIiB3aGljaCBpcyBjYXJy aWVkIGluIHRoZSBQYXRoIG1lc3NhZ2UgDQphbmQgYmFjayBpbiB0aGUgUmVzdiBtZXNzYWdlcy4N Cg0KRm9yIHRoZSBkb3VibGVkIHNpZGVkIHByb3Zpc2lvbmluZyBtb2RlbCwgc2luY2UgdGhlIGxv d2VyIElQIGFkZHJlc3MgDQooQXNzb2NpYXRpb24gU291cmNlKSB3aW5zIHRoZSB0aWUgYnJlYWtl ciwgdGhlIEFzc29jaWF0aW9uIG9iamVjdCB3aXRoIA0KQXNzb2NpYXRpb24gVHlwZSAiTFNQIElk ZW50aWZpZXJzIiBjYW4gYmUgcHVzaGVkIGludG8gdGhlIFBhdGggbWVzc2FnZSBieSANCnRoZSBs b3dlciBJUCBhZGRyZXNzIGluaXRpYWwgTFNQIGNhbiBjYXJyeSBiYWNrIHRoZSBnbG9iYWxfSUQg b2YgdGhlIA0KaGlnaGVyIElQIGFkZHJlc3MgaW4gdGhlIFJlc3YgbWVzc2FnZS4NCg0KSW4gb3Ro ZXIgd29yZHMsIHRoZSBBc3NvY2lhdGlvbiBvYmplY3Qgd2l0aCBBc3NvY2lhdGlvbiBUeWVwICJM U1AgDQpJZGVudGlmaWVycyIgYXJlIGFsd2F5cyBwdXNoZWQgYnkgdGhlIEFzc29jaWF0aW9uIFNv dXJjZSBpbnRvIHRoZSBQYXRoIA0KbWVzc2FnZSBjYW4gY2FycmllZCBiYWNrIGluIHRoZSBSZXN2 IG1lc3NhZ2Ugd2l0aCB0aGUgcGVlciBub2RlJ3MgDQpnbG9iYWxfSUQgaW4gYm90aCBwcm92aXNp b25pbmcgbW9kZWwgaWYgbmVjZXNzYXJ5Lg0KDQpEbyB5b3UgdGhpbmsgdGhlIGN1cnJlbnRseSBk ZXNjcmlwdGlvbiBuZWVkcyBtb3JlIGNsYXJpZmljYXRpb24gd29yZHM/DQoNClRoYW5rcw0KDQpG ZWkNCg0KDQoNCkxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+IA0Kt6K8/sjLOiAgY2NhbXAt Ym91bmNlc0BpZXRmLm9yZw0KMjAxMi0wOC0yNSAwMTo1NQ0KDQrK1bz+yMsNCiJSYWtlc2ggR2Fu ZGhpIChyZ2FuZGhpKSIgPHJnYW5kaGlAY2lzY28uY29tPg0Ks63LzQ0KImNjYW1wQGlldGYub3Jn IiA8Y2NhbXBAaWV0Zi5vcmc+DQrW98ziDQpSZTogW0NDQU1QXSBSZXZpZXcgUmVxdWVzdCBGb3Ig Q2hhbmdlcyBpbiANCmRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0 ZWQtbHNwLTA0LnR4dA0KDQoNCg0KDQoNCg0KUmFrZXNoLA0KDQpTcGVha2luZyBhcyBhIFdHIHBh cnRpY2lwYW50LCBhbmQgaWdub3JpbmcgY2hhbmdlcyA0IGFuZCA1IGFzIHlvdSBwbGFuDQp0byBy ZXZlcnQgdGhlc2U6DQoNCk9uIDgvMjMvMjAxMiAxMjoyMCBQTSwgUmFrZXNoIEdhbmRoaSAocmdh bmRoaSkgd3JvdGU6DQo+IERlYXIgV0csDQo+IA0KPiBXZSBsaWtlIHRvIHJlcXVlc3QgYSByZXZp ZXcgZnJvbSB0aGUgV0cgb24gdGhlIGNoYW5nZXMgaW4gdmVyc2lvbiAwNCBvZiANCnRoZSBkcmFm dC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcCBjb21wYXJlZCB0 byB2ZXJzaW9uIA0KMDMuIA0KPiANCj4gVGhlIG1ham9yaXR5IG9mIHRoZSBwcm9wb3NlZCBjaGFu Z2VzIGFyZSBhcm91bmQgdGhlIGZvcm1hdCBhbmQgaG93IHRvIA0KcG9wdWxhdGUgdGhlIGV4dGVu ZGVkIGFzc29jaWF0aW9uIG9iamVjdCBhcyBsaXN0ZWQgYmVsb3cuDQo+IA0KPiBOb3RlOiBCYXNl ZCBvbiB0aGUgZmVlZGJhY2tzIHJlY2VpdmVkIHNvIGZhciwgY2hhbmdlcyBmb3IgaXRlbXMgNCBh bmQgNSANCmJlbG93IHdpbGwgYmUgcmV2ZXJ0ZWQuDQo+IA0KPiAxLiBBc3NvY2lhdGlvbi1JRDoN Cj4gSXQgd2FzIG5vdCBjbGVhciBmcm9tIHJlYWRpbmcgdGhlIHZlcnNpb24gMDMgb2YgdGhlIGRy YWZ0IGhvdyB0aGlzIGZpZWxkIA0KaXMgcG9wdWxhdGVkIGluIHRoZSBleHRlbmRlZCBhc3NvY2lh dGlvbiBvYmplY3QuIE5ldyB2ZXJzaW9uIDA0IHByb3Bvc2VzIA0KdG8gcG9wdWxhdGUgdGhpcyBm aWVsZCBmcm9tIHRoZSBsb2NhbGx5IHByb3Zpc2lvbmVkIHZhbHVlLiBBcyB0aGlzIHZhbHVlIA0K aXMgaWRlbnRpY2FsbHkgcHJvdmlzaW9uZWQgb24gYm90aCBlbmRzLCBpdCBwcm92aWRlcyBhIGZp ZWxkIHRvIHRpZSB0aGUgDQp0d28gKGZvcndhcmQgYW5kIHJldmVyc2UpIExTUHMgb24gZW5kLXBv aW50cy4NCj4gDQoNCj4gMi4gSVB2NCBhc3NvY2lhdGlvbiBzb3VyY2U6DQo+IE5ldyB2ZXJzaW9u IDA0IGFkZHMgYSB0aWUgYnJlYWtlciBydWxlIGZvciBkb3VibGUgc2lkZWQgcHJvdmlzaW9uZWQg DQpMU1BzLg0KPiANCj4gMy4gR2xvYmFsIGFzc29jaWF0aW9uIHNvdXJjZToNCj4gTmV3IHZlcnNp b24gY2xhcmlmaWVzIHRoZSB1c2FnZSBmb3IgdGhpcyBmaWVsZCBzaXRpbmcgaW5mb3JtYXRpb24g ZnJvbSANClJGQzYzNzAgYW5kIG90aGVyIG1lbnRpb25lZCBkcmFmdHMuIE5vIG5ldyBydWxlIGFk ZGVkLg0KPiANCg0KWzQgYW5kIDUgcmVtb3ZlZCBmb3JtIG1haWwgYXMgdG8gYmUgcmV2ZXJ0ZWRd DQoNCj4gDQo+IDYuIEV4dGVuZGVkIEFzc29jaWF0aW9uIElEIChBZGRyZXNzKToNCj4gTmV3IHZl cnNpb24gMDQgcHJvcG9zZXMgdG8gdXNlIGFuIElQIGFkZHJlc3MgYXMgZXh0ZW5kZWQgYXNzb2Np YXRpb24gSUQgDQooYWRkcmVzcykgYXMgYW4gYWRkaXRpb25hbCBpZGVudGlmaWVyLiBQcmV2aW91 cyB2ZXJzaW9uIDAzIGRlZmluZXMgYSANCnZhcmlhYmxlIGxlbmd0aCBmaWVsZCBidXQgZGlkIG5v dCBtZW50aW9uIHdoYXQgcGFyYW1ldGVycyBjYW4gYmUgYWRkZWQgDQp0aGVyZS4NCj4gQSB0aWUg YnJlYWtlciBydWxlIGlzIGRlZmluZWQgZm9yIGRvdWJsZSBzaWRlZCBwcm92aXNpb25lZCB2YWx1 ZS4NCj4gDQoNCkFzc3VtaW5nIGNoYW5nZXMgMSwgMiwgYW5kIDYsIGhvdyBpcyB1bmlxdWVuZXNz IChvZiB0aGUgYXNzb2NpYXRpb24gSUQNCmZpZWxkKSBndWFyYW50ZWVkPw0KDQo+IDcuIFBhdGgg UHJvdGVjdGlvbiBvYmplY3Q6DQo+IFZlcnNpb24gMDMgb2YgdGhlIGRyYWZ0IHZhZ3VlbHkgbWVu dGlvbmVkIGFuZCBhc3N1bWVkIG9mIHVzaW5nIA0KcHJvdGVjdGlvbiBvYmplY3QgZm9yIHBhdGgg cHJvdGVjdGlvbi4gTmV3IHZlcnNpb24gMDQgYWRkcyBzb21lIHRleHRzIHRvIA0KY2xhcmlmeSBp dCwgbm8gbmV3IHJ1bGUgaXMgYWRkZWQuDQo+IA0KDQpJIHRoaW5rIHByb3ZpZGluZyBpbmZvcm1h dGl2ZSB0ZXh0IG9uIGludGVyYWN0aW9ucyBvZiB0aGlzIGRvY3VtZW50IHdpdGgNCnRoZSB2YXJp b3VzIGRlZmluZWQgcmVjb3ZlcnkgKDQ4NzIgYW5kIDQ4NzIpIGFuZCByZXJvdXRlICg0MDkwKQ0K bWVjaGFuaXNtcyBpcyBhIHJlYWxseSBnb29kIGlkZWEuICBUaGF0IHNhaWQsIEkgZm91bmQgdGhp cyBzZWN0aW9uIGEgYml0DQpvcGFxdWUuICBJZ25vcmluZyB0aGUgd29yZHNtaXRoaW5nLCB3aGF0 IHNwZWNpZmljIHBvaW50cyBhcmUgeW91IHRyeWluZw0KdG8gbWFrZT8NCg0KPiA4LiBBdXRvLXR1 bm5lbCBtZXNoOg0KPiBOZXcgdmVyc2lvbiAwNCBhZGRzIGEgc2VjdGlvbiB0byBlbGFib3JhdGUg b24gYSB1c2UgY2FzZSBmb3IgYXV0by10dW5uZWwgDQptZXNoLiBUaGlzIGlzIGFkZGVkIGFzIGFu IEZZSSBhbmQgY2FuIGJlIHJlbW92ZWQgaWYgV0cgdGhpbmtzIHNvLg0KPiANCg0KSG93IGlzIHRo ZSBhc3NvY2lhdGlvbiBpZCBmaWVsZCB2YWx1ZSBzZWxlY3RlZCBpbiB0aGlzIGNhc2U/DQoNCg0K PiA5LiBDbGFyaWZpY2F0aW9uIGZvciBJbnRlci1BUyBMU1BzOg0KPiBJIGJlbGlldmUgdGhlcmUg d2FzIGFuIGVtYWlsIGV4Y2hhbmdlIGJldHdlZW4gTG91IGFuZCBGZWkgdG8gY2xhcmlmeSB0aGUg DQpyZWxhdGlvbnNoaXAgd2l0aCBkcmFmdCBJLUQsIA0KZHJhZnQtemhhbmctY2NhbXAtbXBscy10 cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0uIEEgc2VjdGlvbiBpcyBhZGRlZCBpbiANCnZlcnNpb24t MDQgdG8gYWRkcmVzcyB0aGlzLiBQbGVhc2UgcmV2aWV3IHRoZSBhZGRlZCB0ZXh0Lg0KPiANCg0K V2VsbCBJIChhcyBjaGFpcikgaGFkIGFza2VkIGluIFZhbmNvdXZlciB0aGF0IHRoZSBhdXRob3Jz IG9mDQpyc3ZwdGUtZXh0LXR1bm5lbC1udW0gcHJvcG9zZSBzb21lIGxhbmd1YWdlICpvbiB0aGUg bGlzdCogdGhhdCB3b3VsZA0KbWVyZ2UgdGhlIGZ1bmN0aW9uYWxpdHkgZGVmaW5lZCBpbiB0aGF0 IGRvY3VtZW50IGludG8gdGhlIFdHIGRvY3VtZW50Lg0KVGhlIG1haWxpbmcgbGlzdCBkaXNjdXNz aW9uIGNvbmNsdWRlZCB3aXRoIEZlaSBzdGF0aW5nIHRoYXQgaGUgd2FudCB0bw0Ka2VlcCB0aGUg ZHJhZnRzIHNlcGFyYXRlLCB3aGljaCBjZXJ0YWlubHkgaXMgaGlzIGNhbGwgKGFzIG9uZSBpcyBh bg0KaW5kaXZpZHVhbCBkcmFmdCkuICBTbyB0byBiZSBjbGVhciwgSSBoYXZlIG5vdCByZXF1ZXN0 ZWQgYW55IHJlZmVyZW5jZXMNCnRvIHJzdnB0ZS1leHQtdHVubmVsLW51bSBpbiB0aGUgV0cgZHJh ZnQuDQoNClRoaXMgc2VjdGlvbiBkb2VzIGhpZ2hsaWdodCB0aGUgaXNzdWUgb2YgaG93IHJlbW90 ZSBnbG9iYWxfSUQgY2FuIGJlDQpsZWFybmVkIGluIHRoZSBpbnRlcmRvbWFpbiBjYXNlLiAgSSB0 aGluayB0aGUgc3RhdGVkIHNvbHV0aW9uIGRvZXNuJ3QNCndvcmsgd2l0aCB5b3VyIGN1cnJlbnQg YXNzaWdubWVudCBhcHByb2FjaCwgZS5nLiwgY29uc2lkZXIgdGhlIGNhc2Ugd2hlbg0KdGhlIGxv d2VyIElQIGFkZHJlc3MgaXMgdGhlIGVncmVzcyBvZiB0aGUgaW5pdGlhbCBMU1AuLi4NCg0KTG91 DQoNCg0KPiBQbGVhc2UgYWR2aXNlIHVzIG9uIGFib3ZlIGNoYW5nZXMuIEJhc2VkIG9uIHRoZSBj b25zZW5zdXMsIHdlIHdpbGwgDQp1cGRhdGUgdGhlIGRyYWZ0IGFjY29yZGluZ2x5Lg0KPiANCj4g VGhhbmtzLA0KPiBSYWtlc2gNCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddIA0KPiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxNSwgMjAxMiAxMDo1MyBBTQ0K PiBUbzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCj4gQ2M6IHpoYW5nLmZlaTNAenRlLmNvbS5j bjsgamluZ3JxQGN0YnJpLmNvbS5jbg0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIA0KZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1s c3AtMDQudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIA0KZHJhZnQtaWV0Zi1j Y2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQo+IGhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUmFrZXNoIEdhbmRoaSBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGIA0KcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOiBkcmFmdC1pZXRmLWNjYW1wLW1w bHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcA0KPiBSZXZpc2lvbjogICAgICAgICAgICAg ICAwNA0KPiBUaXRsZTogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUlNWUC1URSBF eHRlbnNpb25zIGZvciANCkFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1BzDQo+IENyZWF0aW9u IGRhdGU6ICAgICAgICAgICAgICAgICAgMjAxMi0wOC0xNQ0KPiBXRyBJRDogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgY2NhbXANCj4gTnVtYmVyIG9mIHBhZ2VzOiAxNw0KPiBVUkw6 ICAgICAgICAgICAgIA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQoNCj4g U3RhdHVzOiAgICAgICAgICANCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3ANCg0KPiBIdG1saXpl ZDogICAgICAgIA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1t cGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQNCg0KPiBEaWZmOiAgICAgICAgICAg IA0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jY2FtcC1tcGxz LXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQNCg0KPiANCj4gQWJzdHJhY3Q6DQo+ICAg IFRoZSBNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSByZXF1aXJlbWVudHMgZG9jdW1l bnQgW1JGQzU2NTRdLA0KPiAgICBkZXNjcmliZXMgdGhhdCBNUExTLVRQIE1VU1Qgc3VwcG9ydCBh c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcG9pbnQtDQo+ICAgIHRvLXBvaW50IExTUHMuDQo+IA0K PiAgICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgbWV0aG9kIHRvIGJpbmQgdHdvIHVuaWRpcmVj dGlvbmFsIExhYmVsDQo+ICAgIFN3aXRjaGVkIFBhdGhzIChMU1BzKSBpbnRvIGFuIGFzc29jaWF0 ZWQgYmlkaXJlY3Rpb25hbCBMU1AuICBUaGUNCj4gICAgYXNzb2NpYXRpb24gaXMgYWNoaWV2ZWQg YnkgZGVmaW5pbmcgdGhlIG5ldyBBc3NvY2lhdGlvbiBUeXBlIGluIHRoZQ0KPiAgICBFeHRlbmRl ZCBBU1NPQ0lBVElPTiBvYmplY3QuDQo+IA0KPiAgDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0 YXJpYXQNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IENDQU1QIG1haWxpbmcgbGlzdA0KPiBDQ0FNUEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+IA0KPiANCj4gDQo+IA0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcg bGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2NhbXANCg0KDQoNCg== --=_alternative 0014687948257A66_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIExvdSwgPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHlvdXIgZGV0 YWlsZWQgcmV2aWV3LCBzbmlwcGVkDQp0aGUgb3RoZXJzLCBzZWUgaW5saW5lIHdpdGggJmx0O2Zl aSZndDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5XZWxsIEkgKGFzIGNoYWly KSBoYWQgYXNrZWQgaW4gVmFuY291dmVyIHRoYXQgdGhlDQphdXRob3JzIG9mPGJyPg0KcnN2cHRl LWV4dC10dW5uZWwtbnVtIHByb3Bvc2Ugc29tZSBsYW5ndWFnZSAqb24gdGhlIGxpc3QqIHRoYXQg d291bGQ8YnI+DQptZXJnZSB0aGUgZnVuY3Rpb25hbGl0eSBkZWZpbmVkIGluIHRoYXQgZG9jdW1l bnQgaW50byB0aGUgV0cgZG9jdW1lbnQuPGJyPg0KVGhlIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9u IGNvbmNsdWRlZCB3aXRoIEZlaSBzdGF0aW5nIHRoYXQgaGUgd2FudCB0bzxicj4NCmtlZXAgdGhl IGRyYWZ0cyBzZXBhcmF0ZSwgd2hpY2ggY2VydGFpbmx5IGlzIGhpcyBjYWxsIChhcyBvbmUgaXMg YW48YnI+DQppbmRpdmlkdWFsIGRyYWZ0KS4gJm5ic3A7U28gdG8gYmUgY2xlYXIsIEkgaGF2ZSBu b3QgcmVxdWVzdGVkIGFueSByZWZlcmVuY2VzPGJyPg0KdG8gcnN2cHRlLWV4dC10dW5uZWwtbnVt IGluIHRoZSBXRyBkcmFmdC48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZsdDtGZWkmZ3Q7IFN1cmUsIHRoaXMgcGFydCBpcyBhbHNvIGluZm9ybWF0aW9uYWwNCmFuZCB0 aGVyZSBpcyBubyBuZXcgbWVjaGFuaXNtIGludHJvZHVjZWQgaGVyZS4gOik8YnI+DQo8YnI+DQpU aGlzIHNlY3Rpb24gZG9lcyBoaWdobGlnaHQgdGhlIGlzc3VlIG9mIGhvdyByZW1vdGUgZ2xvYmFs X0lEIGNhbiBiZTxicj4NCmxlYXJuZWQgaW4gdGhlIGludGVyZG9tYWluIGNhc2UuICZuYnNwO0kg dGhpbmsgdGhlIHN0YXRlZCBzb2x1dGlvbiBkb2Vzbid0PGJyPg0Kd29yayB3aXRoIHlvdXIgY3Vy cmVudCBhc3NpZ25tZW50IGFwcHJvYWNoLCBlLmcuLCBjb25zaWRlciB0aGUgY2FzZSB3aGVuPGJy Pg0KdGhlIGxvd2VyIElQIGFkZHJlc3MgaXMgdGhlIGVncmVzcyBvZiB0aGUgaW5pdGlhbCBMU1Au Li48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jmx0O0ZlaSZndDsgRm9yIHRoZSBzaW5nbGVkIHNpZGVkIHByb3Zpc2lvbmluZw0KbW9kZWwsIHRo ZSBpbml0aWFsIExTUCBzb3VyY2UgYWRkcmVzcyAoQXNzb2NpYXRpb24gU291cmNlKWFuZCBnbG9i YWxfSUQNCmFyZSBwdXNoZWQgaW50byB0aGUgRUEgb2JqZWN0cywgc28gdGhlIGluZ3Jlc3MgY2Fu IGxlYXJuIHRoZSBnbG9iYWwgSUQNCm9mIHRoZSBwZWVyIG5vZGUgYnkgdGhlIGRlZmluZWQgQXNz b2NpYXRpb24gVHlwZSAmcXVvdDtMU1AgSWRlbnRpZmllcnMmcXVvdDsNCndoaWNoIGlzIGNhcnJp ZWQgaW4gdGhlIFBhdGggbWVzc2FnZSBhbmQgYmFjayBpbiB0aGUgUmVzdiBtZXNzYWdlcy48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZvciB0aGUgZG91 YmxlZCBzaWRlZCBwcm92aXNpb25pbmcgbW9kZWwsDQpzaW5jZSB0aGUgbG93ZXIgSVAgYWRkcmVz cyAoQXNzb2NpYXRpb24gU291cmNlKSB3aW5zIHRoZSB0aWUgYnJlYWtlciwgdGhlDQpBc3NvY2lh dGlvbiBvYmplY3Qgd2l0aCBBc3NvY2lhdGlvbiBUeXBlICZxdW90O0xTUCBJZGVudGlmaWVycyZx dW90OyBjYW4NCmJlIHB1c2hlZCBpbnRvIHRoZSBQYXRoIG1lc3NhZ2UgYnkgdGhlIGxvd2VyIElQ IGFkZHJlc3MgaW5pdGlhbCBMU1AgY2FuDQpjYXJyeSBiYWNrIHRoZSBnbG9iYWxfSUQgb2YgdGhl IGhpZ2hlciBJUCBhZGRyZXNzIGluIHRoZSBSZXN2IG1lc3NhZ2UuPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JbiBvdGhlciB3b3JkcywgdGhlIEFzc29j aWF0aW9uIG9iamVjdA0Kd2l0aCBBc3NvY2lhdGlvbiBUeWVwICZxdW90O0xTUCBJZGVudGlmaWVy cyZxdW90OyBhcmUgYWx3YXlzIHB1c2hlZCBieQ0KdGhlIEFzc29jaWF0aW9uIFNvdXJjZSBpbnRv IHRoZSBQYXRoIG1lc3NhZ2UgY2FuIGNhcnJpZWQgYmFjayBpbiB0aGUgUmVzdg0KbWVzc2FnZSB3 aXRoIHRoZSBwZWVyIG5vZGUncyBnbG9iYWxfSUQgaW4gYm90aCBwcm92aXNpb25pbmcgbW9kZWwg aWYgbmVjZXNzYXJ5LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+RG8geW91IHRoaW5rIHRoZSBjdXJyZW50bHkgZGVzY3JpcHRpb24NCm5lZWRzIG1vcmUg Y2xhcmlmaWNhdGlvbiB3b3Jkcz88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlRoYW5rczwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+RmVpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjxiPkxvdSBCZXJnZXIgJmx0O2xiZXJnZXJAbGFibi5uZXQmZ3Q7PC9iPg0KPC9m b250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO2Nj YW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+MjAxMi0wOC0yNSAwMTo1NTwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSZxdW90 Ow0KJmx0O3JnYW5kaGlAY2lzY28uY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Y2Nh bXBAaWV0Zi5vcmcmcXVvdDsgJmx0O2NjYW1wQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+UmU6IFtDQ0FNUF0gUmV2aWV3IFJlcXVlc3QgRm9yIENoYW5nZXMNCmluICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29j aWF0ZWQtbHNwLTA0LnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+UmFrZXNoLDxicj4NCjxicj4NClNwZWFraW5nIGFzIGEgV0cgcGFy dGljaXBhbnQsIGFuZCBpZ25vcmluZyBjaGFuZ2VzIDQgYW5kIDUgYXMgeW91IHBsYW48YnI+DQp0 byByZXZlcnQgdGhlc2U6PGJyPg0KPGJyPg0KT24gOC8yMy8yMDEyIDEyOjIwIFBNLCBSYWtlc2gg R2FuZGhpIChyZ2FuZGhpKSB3cm90ZTo8YnI+DQomZ3Q7IERlYXIgV0csPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFdlIGxpa2UgdG8gcmVxdWVzdCBhIHJldmlldyBmcm9tIHRoZSBXRyBvbiB0aGUgY2hh bmdlcyBpbiB2ZXJzaW9uDQowNCBvZiB0aGUgZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0 ZS1leHQtYXNzb2NpYXRlZC1sc3AgY29tcGFyZWQgdG8NCnZlcnNpb24gMDMuIDxicj4NCiZndDsg PGJyPg0KJmd0OyBUaGUgbWFqb3JpdHkgb2YgdGhlIHByb3Bvc2VkIGNoYW5nZXMgYXJlIGFyb3Vu ZCB0aGUgZm9ybWF0IGFuZCBob3cNCnRvIHBvcHVsYXRlIHRoZSBleHRlbmRlZCBhc3NvY2lhdGlv biBvYmplY3QgYXMgbGlzdGVkIGJlbG93Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBOb3RlOiBCYXNl ZCBvbiB0aGUgZmVlZGJhY2tzIHJlY2VpdmVkIHNvIGZhciwgY2hhbmdlcyBmb3IgaXRlbXMgNA0K YW5kIDUgYmVsb3cgd2lsbCBiZSByZXZlcnRlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgMS4gQXNz b2NpYXRpb24tSUQ6PGJyPg0KJmd0OyBJdCB3YXMgbm90IGNsZWFyIGZyb20gcmVhZGluZyB0aGUg dmVyc2lvbiAwMyBvZiB0aGUgZHJhZnQgaG93IHRoaXMNCmZpZWxkIGlzIHBvcHVsYXRlZCBpbiB0 aGUgZXh0ZW5kZWQgYXNzb2NpYXRpb24gb2JqZWN0LiBOZXcgdmVyc2lvbiAwNCBwcm9wb3Nlcw0K dG8gcG9wdWxhdGUgdGhpcyBmaWVsZCBmcm9tIHRoZSBsb2NhbGx5IHByb3Zpc2lvbmVkIHZhbHVl LiBBcyB0aGlzIHZhbHVlDQppcyBpZGVudGljYWxseSBwcm92aXNpb25lZCBvbiBib3RoIGVuZHMs IGl0IHByb3ZpZGVzIGEgZmllbGQgdG8gdGllIHRoZQ0KdHdvIChmb3J3YXJkIGFuZCByZXZlcnNl KSBMU1BzIG9uIGVuZC1wb2ludHMuPGJyPg0KJmd0OyA8YnI+DQo8YnI+DQomZ3Q7IDIuIElQdjQg YXNzb2NpYXRpb24gc291cmNlOjxicj4NCiZndDsgTmV3IHZlcnNpb24gMDQgYWRkcyBhIHRpZSBi cmVha2VyIHJ1bGUgZm9yIGRvdWJsZSBzaWRlZCBwcm92aXNpb25lZA0KTFNQcy48YnI+DQomZ3Q7 IDxicj4NCiZndDsgMy4gR2xvYmFsIGFzc29jaWF0aW9uIHNvdXJjZTo8YnI+DQomZ3Q7IE5ldyB2 ZXJzaW9uIGNsYXJpZmllcyB0aGUgdXNhZ2UgZm9yIHRoaXMgZmllbGQgc2l0aW5nIGluZm9ybWF0 aW9uDQpmcm9tIFJGQzYzNzAgYW5kIG90aGVyIG1lbnRpb25lZCBkcmFmdHMuIE5vIG5ldyBydWxl IGFkZGVkLjxicj4NCiZndDsgPGJyPg0KPGJyPg0KWzQgYW5kIDUgcmVtb3ZlZCBmb3JtIG1haWwg YXMgdG8gYmUgcmV2ZXJ0ZWRdPGJyPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDYuIEV4dGVuZGVk IEFzc29jaWF0aW9uIElEIChBZGRyZXNzKTo8YnI+DQomZ3Q7IE5ldyB2ZXJzaW9uIDA0IHByb3Bv c2VzIHRvIHVzZSBhbiBJUCBhZGRyZXNzIGFzIGV4dGVuZGVkIGFzc29jaWF0aW9uDQpJRCAoYWRk cmVzcykgYXMgYW4gYWRkaXRpb25hbCBpZGVudGlmaWVyLiBQcmV2aW91cyB2ZXJzaW9uIDAzIGRl ZmluZXMgYQ0KdmFyaWFibGUgbGVuZ3RoIGZpZWxkIGJ1dCBkaWQgbm90IG1lbnRpb24gd2hhdCBw YXJhbWV0ZXJzIGNhbiBiZSBhZGRlZA0KdGhlcmUuPGJyPg0KJmd0OyBBIHRpZSBicmVha2VyIHJ1 bGUgaXMgZGVmaW5lZCBmb3IgZG91YmxlIHNpZGVkIHByb3Zpc2lvbmVkIHZhbHVlLjxicj4NCiZn dDsgPGJyPg0KPGJyPg0KQXNzdW1pbmcgY2hhbmdlcyAxLCAyLCBhbmQgNiwgaG93IGlzIHVuaXF1 ZW5lc3MgKG9mIHRoZSBhc3NvY2lhdGlvbiBJRDxicj4NCmZpZWxkKSBndWFyYW50ZWVkPzxicj4N Cjxicj4NCiZndDsgNy4gUGF0aCBQcm90ZWN0aW9uIG9iamVjdDo8YnI+DQomZ3Q7IFZlcnNpb24g MDMgb2YgdGhlIGRyYWZ0IHZhZ3VlbHkgbWVudGlvbmVkIGFuZCBhc3N1bWVkIG9mIHVzaW5nIHBy b3RlY3Rpb24NCm9iamVjdCBmb3IgcGF0aCBwcm90ZWN0aW9uLiBOZXcgdmVyc2lvbiAwNCBhZGRz IHNvbWUgdGV4dHMgdG8gY2xhcmlmeSBpdCwNCm5vIG5ldyBydWxlIGlzIGFkZGVkLjxicj4NCiZn dDsgPGJyPg0KPGJyPg0KSSB0aGluayBwcm92aWRpbmcgaW5mb3JtYXRpdmUgdGV4dCBvbiBpbnRl cmFjdGlvbnMgb2YgdGhpcyBkb2N1bWVudCB3aXRoPGJyPg0KdGhlIHZhcmlvdXMgZGVmaW5lZCBy ZWNvdmVyeSAoNDg3MiBhbmQgNDg3MikgYW5kIHJlcm91dGUgKDQwOTApPGJyPg0KbWVjaGFuaXNt cyBpcyBhIHJlYWxseSBnb29kIGlkZWEuICZuYnNwO1RoYXQgc2FpZCwgSSBmb3VuZCB0aGlzIHNl Y3Rpb24NCmEgYml0PGJyPg0Kb3BhcXVlLiAmbmJzcDtJZ25vcmluZyB0aGUgd29yZHNtaXRoaW5n LCB3aGF0IHNwZWNpZmljIHBvaW50cyBhcmUgeW91IHRyeWluZzxicj4NCnRvIG1ha2U/PGJyPg0K PGJyPg0KJmd0OyA4LiBBdXRvLXR1bm5lbCBtZXNoOjxicj4NCiZndDsgTmV3IHZlcnNpb24gMDQg YWRkcyBhIHNlY3Rpb24gdG8gZWxhYm9yYXRlIG9uIGEgdXNlIGNhc2UgZm9yIGF1dG8tdHVubmVs DQptZXNoLiBUaGlzIGlzIGFkZGVkIGFzIGFuIEZZSSBhbmQgY2FuIGJlIHJlbW92ZWQgaWYgV0cg dGhpbmtzIHNvLjxicj4NCiZndDsgPGJyPg0KPGJyPg0KSG93IGlzIHRoZSBhc3NvY2lhdGlvbiBp ZCBmaWVsZCB2YWx1ZSBzZWxlY3RlZCBpbiB0aGlzIGNhc2U/PGJyPg0KPGJyPg0KPGJyPg0KJmd0 OyA5LiBDbGFyaWZpY2F0aW9uIGZvciBJbnRlci1BUyBMU1BzOjxicj4NCiZndDsgSSBiZWxpZXZl IHRoZXJlIHdhcyBhbiBlbWFpbCBleGNoYW5nZSBiZXR3ZWVuIExvdSBhbmQgRmVpIHRvIGNsYXJp ZnkNCnRoZSByZWxhdGlvbnNoaXAgd2l0aCBkcmFmdCBJLUQsIGRyYWZ0LXpoYW5nLWNjYW1wLW1w bHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLg0KQSBzZWN0aW9uIGlzIGFkZGVkIGluIHZlcnNp b24tMDQgdG8gYWRkcmVzcyB0aGlzLiBQbGVhc2UgcmV2aWV3IHRoZSBhZGRlZA0KdGV4dC48YnI+ DQomZ3Q7IDxicj4NCjxicj4NCldlbGwgSSAoYXMgY2hhaXIpIGhhZCBhc2tlZCBpbiBWYW5jb3V2 ZXIgdGhhdCB0aGUgYXV0aG9ycyBvZjxicj4NCnJzdnB0ZS1leHQtdHVubmVsLW51bSBwcm9wb3Nl IHNvbWUgbGFuZ3VhZ2UgKm9uIHRoZSBsaXN0KiB0aGF0IHdvdWxkPGJyPg0KbWVyZ2UgdGhlIGZ1 bmN0aW9uYWxpdHkgZGVmaW5lZCBpbiB0aGF0IGRvY3VtZW50IGludG8gdGhlIFdHIGRvY3VtZW50 Ljxicj4NClRoZSBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiBjb25jbHVkZWQgd2l0aCBGZWkgc3Rh dGluZyB0aGF0IGhlIHdhbnQgdG88YnI+DQprZWVwIHRoZSBkcmFmdHMgc2VwYXJhdGUsIHdoaWNo IGNlcnRhaW5seSBpcyBoaXMgY2FsbCAoYXMgb25lIGlzIGFuPGJyPg0KaW5kaXZpZHVhbCBkcmFm dCkuICZuYnNwO1NvIHRvIGJlIGNsZWFyLCBJIGhhdmUgbm90IHJlcXVlc3RlZCBhbnkgcmVmZXJl bmNlczxicj4NCnRvIHJzdnB0ZS1leHQtdHVubmVsLW51bSBpbiB0aGUgV0cgZHJhZnQuPGJyPg0K PGJyPg0KVGhpcyBzZWN0aW9uIGRvZXMgaGlnaGxpZ2h0IHRoZSBpc3N1ZSBvZiBob3cgcmVtb3Rl IGdsb2JhbF9JRCBjYW4gYmU8YnI+DQpsZWFybmVkIGluIHRoZSBpbnRlcmRvbWFpbiBjYXNlLiAm bmJzcDtJIHRoaW5rIHRoZSBzdGF0ZWQgc29sdXRpb24gZG9lc24ndDxicj4NCndvcmsgd2l0aCB5 b3VyIGN1cnJlbnQgYXNzaWdubWVudCBhcHByb2FjaCwgZS5nLiwgY29uc2lkZXIgdGhlIGNhc2Ug d2hlbjxicj4NCnRoZSBsb3dlciBJUCBhZGRyZXNzIGlzIHRoZSBlZ3Jlc3Mgb2YgdGhlIGluaXRp YWwgTFNQLi4uPGJyPg0KPGJyPg0KTG91PGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBQbGVhc2UgYWR2 aXNlIHVzIG9uIGFib3ZlIGNoYW5nZXMuIEJhc2VkIG9uIHRoZSBjb25zZW5zdXMsIHdlIHdpbGwN CnVwZGF0ZSB0aGUgZHJhZnQgYWNjb3JkaW5nbHkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5r cyw8YnI+DQomZ3Q7IFJha2VzaDxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIDxicj4NCiZndDsg U2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTUsIDIwMTIgMTA6NTMgQU08YnI+DQomZ3Q7IFRvOiBS YWtlc2ggR2FuZGhpIChyZ2FuZGhpKTxicj4NCiZndDsgQ2M6IHpoYW5nLmZlaTNAenRlLmNvbS5j bjsgamluZ3JxQGN0YnJpLmNvbS5jbjxicj4NCiZndDsgU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lh dGVkLWxzcC0wNC50eHQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRl ZC1sc3AtMDQudHh0PGJyPg0KJmd0OyBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IFJha2VzaCBHYW5kaGkgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS48YnI+DQom Z3Q7IDxicj4NCiZndDsgRmlsZW5hbWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1y c3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwPGJyPg0KJmd0OyBSZXZpc2lvbjogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7MDQ8YnI+ DQomZ3Q7IFRpdGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KUlNWUC1URSBFeHRlbnNpb25zIGZvciBBc3NvY2lhdGVkIEJp ZGlyZWN0aW9uYWwgTFNQczxicj4NCiZndDsgQ3JlYXRpb24gZGF0ZTogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7MjAxMi0wOC0x NTxicj4NCiZndDsgV0cgSUQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpjY2FtcDxicj4NCiZndDsgTnVtYmVyIG9mIHBhZ2Vz OiAxNzxicj4NCiZndDsgVVJMOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNjYW1w LW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQ8YnI+DQomZ3Q7IFN0YXR1 czogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2h0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRl ZC1sc3A8YnI+DQomZ3Q7IEh0bWxpemVkOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4 dC1hc3NvY2lhdGVkLWxzcC0wNDxicj4NCiZndDsgRGlmZjogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNDxicj4NCiZn dDsgPGJyPg0KJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUaGUgTVBMUyBU cmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgcmVxdWlyZW1lbnRzIGRvY3VtZW50DQpbUkZDNTY1 NF0sPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ZGVzY3JpYmVzIHRoYXQgTVBMUy1UUCBNVVNUIHN1 cHBvcnQgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsDQpwb2ludC08YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDt0by1wb2ludCBMU1BzLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7VGhp cyBkb2N1bWVudCBwcm92aWRlcyBhIG1ldGhvZCB0byBiaW5kIHR3byB1bmlkaXJlY3Rpb25hbA0K TGFiZWw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtTd2l0Y2hlZCBQYXRocyAoTFNQcykgaW50byBh biBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCkxTUC4gJm5ic3A7VGhlPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7YXNzb2NpYXRpb24gaXMgYWNoaWV2ZWQgYnkgZGVmaW5pbmcgdGhlIG5ldyBBc3Nv Y2lhdGlvbg0KVHlwZSBpbiB0aGU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtFeHRlbmRlZCBBU1NP Q0lBVElPTiBvYmplY3QuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQomZ3Q7IDxicj4NCiZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7IENDQU1QIG1haWxpbmcgbGlzdDxicj4NCiZndDsgQ0NBTVBAaWV0Zi5vcmc8YnI+DQomZ3Q7 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0K Q0NBTVBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NjYW1wPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 0014687948257A66_=-- From lberger@labn.net Sun Aug 26 07:21:35 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C6B21F8534 for ; Sun, 26 Aug 2012 07:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.769 X-Spam-Level: X-Spam-Status: No, score=-95.769 tagged_above=-999 required=5 tests=[AWL=-2.903, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaV3cDllTTSZ for ; Sun, 26 Aug 2012 07:21:35 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id E618521F8533 for ; Sun, 26 Aug 2012 07:21:34 -0700 (PDT) Received: (qmail 17248 invoked by uid 0); 26 Aug 2012 14:21:33 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 26 Aug 2012 14:21:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=aKvth+sDc+hvpNcuBm5H1QL78IZlgTl697qwGIt9vC8=; b=IFRLMJZ25CCU2enzi1EW6I8dqqMNzX2nsqUZgxTqqvx1DEOAXoS+rn+IxJwTiGGSXgwyxFiWktYc8+zKbhsQtZEht4HLD3bPogEr1wdDaAOWa1EEXuXYAXoYiibJ51rq; Received: from box313.bluehost.com ([69.89.31.113]:57282 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T5diX-0005q6-DG; Sun, 26 Aug 2012 08:21:33 -0600 Message-ID: <503A30E4.8040109@labn.net> Date: Sun, 26 Aug 2012 10:21:24 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Fatai Zhang References: <20120825072629.29132.33058.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" Subject: Re: [CCAMP] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2Nh?= =?gb2312?b?bXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDkudHh0?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 14:21:35 -0000 Fatai/All, Thanks for the update. I believe we mentioned the desire to LC the routing and signaling documents together with this document. Hopefully they'll be updated soon too. Lou On 8/25/2012 3:33 AM, Fatai Zhang wrote: > The authors think that this draft should be ready for LC. From lberger@labn.net Sun Aug 26 07:30:45 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E4521F853B for ; Sun, 26 Aug 2012 07:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.377 X-Spam-Level: X-Spam-Status: No, score=-99.377 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKOJQ1dRDTvK for ; Sun, 26 Aug 2012 07:30:44 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id E2BF121F847F for ; Sun, 26 Aug 2012 07:30:43 -0700 (PDT) Received: (qmail 32375 invoked by uid 0); 26 Aug 2012 14:30:43 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 26 Aug 2012 14:30:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=mIWbcwPVIEXi06dT0038VxqsGaDUx0DIxoWPQHJUw3A=; b=y3t1KyOb5OXBDN+w46iWlmcVK0f2O12NFpUk9KeV6Y/xfd5Vl4p+ltv0Qdk2gMNJzgDFLFMi+d5HKlzZ9s5mW0rOESUG/uOz9iYeeaJtY+Di1VvB6xFGtepiWfZNS1aD; Received: from box313.bluehost.com ([69.89.31.113]:57971 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T5drO-00088B-SK; Sun, 26 Aug 2012 08:30:43 -0600 Message-ID: <503A3309.4020907@labn.net> Date: Sun, 26 Aug 2012 10:30:33 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Rakesh Gandhi (rgandhi)" References: <5037C010.7010605@labn.net> <5037E6C4.5050507@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 14:30:45 -0000 Rakesh, See below (using normal reply notation)... On 8/24/2012 5:18 PM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, > > Please see inline.... > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, August 24, 2012 4:41 PM > To: Rakesh Gandhi (rgandhi) > Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn > Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > Rakesh, > > See below. > > On 8/24/2012 2:31 PM, Rakesh Gandhi (rgandhi) wrote: >> Hi Lou, >> >> Thanks for your review. Please see inline.... >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, August 24, 2012 1:55 PM >> To: Rakesh Gandhi (rgandhi) >> Cc: ccamp@ietf.org >> Subject: Re: [CCAMP] Review Request For Changes in >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> Rakesh, >> >> Speaking as a WG participant, and ignoring changes 4 and 5 as you plan to revert these: >> >> On 8/23/2012 12:20 PM, Rakesh Gandhi (rgandhi) wrote: >>> Dear WG, >>> >>> We like to request a review from the WG on the changes in version 04 of the draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp compared to version 03. >>> >>> The majority of the proposed changes are around the format and how to populate the extended association object as listed below. >>> >>> Note: Based on the feedbacks received so far, changes for items 4 and 5 below will be reverted. >>> >>> 1. Association-ID: >>> It was not clear from reading the version 03 of the draft how this field is populated in the extended association object. New version 04 proposes to populate this field from the locally provisioned value. As this value is identically provisioned on both ends, it provides a field to tie the two (forward and reverse) LSPs on end-points. >>> >> >>> 2. IPv4 association source: >>> New version 04 adds a tie breaker rule for double sided provisioned LSPs. >>> >>> 3. Global association source: >>> New version clarifies the usage for this field siting information from RFC6370 and other mentioned drafts. No new rule added. >>> >> >> [4 and 5 removed form mail as to be reverted] >> >>> >>> 6. Extended Association ID (Address): >>> New version 04 proposes to use an IP address as extended association ID (address) as an additional identifier. Previous version 03 defines a variable length field but did not mention what parameters can be added there. >>> A tie breaker rule is defined for double sided provisioned value. >>> >> >> Assuming changes 1, 2, and 6, how is uniqueness (of the association ID >> field) guaranteed? >> >> 1, 2 and 6 together uniquely represent a bidirectional LSPs in a network. In this proposal association ID can be shared by multiple tunnels on the same source node. >> > > Sure, but who picks the association-id such that uniqueness is assured in the double sided provisioning case? > > If assuming this is always provisioned, then how does the provisioning entity, which may be one or more people at a CLI, pick the association-id such that it is unique across the tuple ? (neither a single provision device nor polling the ingress and egress are really reasonable solutions.) > > Wouldn't it be better for the Association Source and Association ID to be administratively set? e.g., to the IP address and value selected by the provisioning source. (Extended Association ID could also be used if desired, but I'm not sure it really adds value.) > > Sure, association-id and association-source can be set administratively or by any other means (we can reword the draft). Idea here is that for double sided provisioned LSPs, they need to have the same values, so both sides can glue the matching LSPs. > I think we agree on the objective, now we just need some words to achieve it. (I.e., whatever text is specified, it must support a viable approach to ensuring uniqueness, i.e., no collision.) So, care to try again on proposing such language? > > >> >>> 7. Path Protection object: >>> Version 03 of the draft vaguely mentioned and assumed of using protection object for path protection. New version 04 adds some texts to clarify it, no new rule is added. >>> >> >> I think providing informative text on interactions of this document with the various defined recovery (4872 and 4872) and reroute (4090) mechanisms is a really good idea. That said, I found this section a bit opaque. Ignoring the wordsmithing, what specific points are you trying to make? >> >> It just highlights that for a bi-directional tunnel, there can be a working bidirectional LSPs and protecting bidirectional LSPs. That's all. >> > > I think the proposed text is really confusing and doesn't cover the full scope (in particular 4872 is about recovery which is both protection and restoration, it doesn't cover 4873 or 4090). Can you propose (one the > list) some alternate text? > > Idea here is that there are multiple bidirectional LSPs for a tunnel for different LSP roles. We could remove the LSP type as primary and secondary reference from the text, and just state LSPs for different roles. > Again, I think the issue is with the proposed language. >> >>> 8. Auto-tunnel mesh: >>> New version 04 adds a section to elaborate on a use case for auto-tunnel mesh. This is added as an FYI and can be removed if WG thinks so. >>> >> >> How is the association id field value selected in this case? >> >> Proposal allows that single association-id can be provisioned for a mesh-group. > I don't think you have text that supports this. The closest you come is: > A node provisioned to > build a mesh of associated bidirectional LSPs may use identical > association ID for the given mesh-group member peers. > > which doesn't say that the "identical association ID" MUST be provisioned. > > Yes, we can clarify this. > Great! Lou > Thanks, > Rakesh > > Lou > >>> So when a node initiates multiple auto-tunnels in a mesh-group, as per previous definition, a tunnel can be uniquely identified with , i.e. extended association object. >> > > > >> >>> 9. Clarification for Inter-AS LSPs: >>> I believe there was an email exchange between Lou and Fei to clarify the relationship with draft I-D, draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num. A section is added in version-04 to address this. Please review the added text. >>> >> >> Well I (as chair) had asked in Vancouver that the authors of rsvpte-ext-tunnel-num propose some language *on the list* that would merge the functionality defined in that document into the WG document. >> The mailing list discussion concluded with Fei stating that he want to keep the drafts separate, which certainly is his call (as one is an individual draft). So to be clear, I have not requested any references to rsvpte-ext-tunnel-num in the WG draft. >> >> This section does highlight the issue of how remote global_ID can be learned in the interdomain case. I think the stated solution doesn't work with your current assignment approach, e.g., consider the case when the lower IP address is the egress of the initial LSP... >> >> I will let Fei address this comment. >> >> Thanks, >> Rakesh >> >> >> Lou >> >> >>> Please advise us on above changes. Based on the consensus, we will update the draft accordingly. >>> >>> Thanks, >>> Rakesh >>> >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Wednesday, August 15, 2012 10:53 AM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: zhang.fei3@zte.com.cn; jingrq@ctbri.com.cn >>> Subject: New Version Notification for >>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>> >>> >>> A new version of I-D, >>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>> has been successfully submitted by Rakesh Gandhi and posted to the IETF repository. >>> >>> Filename: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp >>> Revision: 04 >>> Title: RSVP-TE Extensions for Associated Bidirectional LSPs >>> Creation date: 2012-08-15 >>> WG ID: ccamp >>> Number of pages: 17 >>> URL: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>> Status: http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp >>> Htmlized: http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04 >>> >>> Abstract: >>> The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], >>> describes that MPLS-TP MUST support associated bidirectional point- >>> to-point LSPs. >>> >>> This document provides a method to bind two unidirectional Label >>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>> association is achieved by defining the new Association Type in the >>> Extended ASSOCIATION object. >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> >> >> >> >> > > > > From lberger@labn.net Sun Aug 26 12:46:05 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE5321F855F for ; Sun, 26 Aug 2012 12:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.863 X-Spam-Level: X-Spam-Status: No, score=-97.863 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_63=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PywBdjCsUB6F for ; Sun, 26 Aug 2012 12:46:03 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 8E49F21F8555 for ; Sun, 26 Aug 2012 12:45:55 -0700 (PDT) Received: (qmail 14626 invoked by uid 0); 26 Aug 2012 19:45:50 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 26 Aug 2012 19:45:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=1vKW5VtmKmFOBzdg/1pWOOPsSm5+EeM6Hzj41jnUgZc=; b=2RMz7IGusi8qvpNYfCZe/Eg2zrlcf1fEw+0ZOfdE2OnM/uSN34KA4l0Y6BPxNFL7pSGHRVb2O0M67wM2RR5M03LeJPLG18IWb5+cX9kD0OFZ15/E23Vy93qtSLsR0EhW; Received: from box313.bluehost.com ([69.89.31.113]:55000 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T5imM-0005eh-AQ; Sun, 26 Aug 2012 13:45:50 -0600 Message-ID: <503A7CE5.1060700@labn.net> Date: Sun, 26 Aug 2012 15:45:41 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 19:46:05 -0000 On 8/25/2012 11:43 PM, zhang.fei3@zte.com.cn wrote: > > Hi Lou, > > Thanks for your detailed review, snipped the others, see inline with > > Well I (as chair) had asked in Vancouver that the authors of > rsvpte-ext-tunnel-num propose some language *on the list* that would > merge the functionality defined in that document into the WG document. > The mailing list discussion concluded with Fei stating that he want to > keep the drafts separate, which certainly is his call (as one is an > individual draft). So to be clear, I have not requested any references > to rsvpte-ext-tunnel-num in the WG draft. > > Sure, this part is also informational and there is no new > mechanism introduced here. :) Given the recent discussion (on co-routed) I don't think the reference makes any sense given the scope of rsvpte-ext-tunnel-num propose is co-routed bidirectional which is currently 100% out of scope of this document. > > This section does highlight the issue of how remote global_ID can be > learned in the interdomain case. I think the stated solution doesn't > work with your current assignment approach, e.g., consider the case when > the lower IP address is the egress of the initial LSP... > > For the singled sided provisioning model, the initial LSP source > address (Association Source)and global_ID are pushed into the EA > objects, so the ingress can learn the global ID of the peer node by the > defined Association Type "LSP Identifiers" which is carried in the Path > message and back in the Resv messages. this implies a rule of the lower IP address always signaling its LSP first. Seems a bit arbitrary to me, and isn't reflected in the current text. How about just following the administrative approach being discussed with Rakesh in the other thread on the same topic? Lou > > For the doubled sided provisioning model, since the lower IP address > (Association Source) wins the tie breaker, the Association object with > Association Type "LSP Identifiers" can be pushed into the Path message > by the lower IP address initial LSP can carry back the global_ID of the > higher IP address in the Resv message. > > In other words, the Association object with Association Tyep "LSP > Identifiers" are always pushed by the Association Source into the Path > message can carried back in the Resv message with the peer node's > global_ID in both provisioning model if necessary. > > Do you think the currently description needs more clarification words? > > Thanks > > Fei > > > *Lou Berger * > ·¢¼þÈË: ccamp-bounces@ietf.org > > 2012-08-25 01:55 > > > ÊÕ¼þÈË > "Rakesh Gandhi (rgandhi)" > ³­ËÍ > "ccamp@ietf.org" > Ö÷Ìâ > Re: [CCAMP] Review Request For Changes in > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > > > > > > > > Rakesh, > > Speaking as a WG participant, and ignoring changes 4 and 5 as you plan > to revert these: > > On 8/23/2012 12:20 PM, Rakesh Gandhi (rgandhi) wrote: >> Dear WG, >> >> We like to request a review from the WG on the changes in version 04 > of the draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp compared to > version 03. >> >> The majority of the proposed changes are around the format and how to > populate the extended association object as listed below. >> >> Note: Based on the feedbacks received so far, changes for items 4 and > 5 below will be reverted. >> >> 1. Association-ID: >> It was not clear from reading the version 03 of the draft how this > field is populated in the extended association object. New version 04 > proposes to populate this field from the locally provisioned value. As > this value is identically provisioned on both ends, it provides a field > to tie the two (forward and reverse) LSPs on end-points. >> > >> 2. IPv4 association source: >> New version 04 adds a tie breaker rule for double sided provisioned LSPs. >> >> 3. Global association source: >> New version clarifies the usage for this field siting information from > RFC6370 and other mentioned drafts. No new rule added. >> > > [4 and 5 removed form mail as to be reverted] > >> >> 6. Extended Association ID (Address): >> New version 04 proposes to use an IP address as extended association > ID (address) as an additional identifier. Previous version 03 defines a > variable length field but did not mention what parameters can be added > there. >> A tie breaker rule is defined for double sided provisioned value. >> > > Assuming changes 1, 2, and 6, how is uniqueness (of the association ID > field) guaranteed? > >> 7. Path Protection object: >> Version 03 of the draft vaguely mentioned and assumed of using > protection object for path protection. New version 04 adds some texts to > clarify it, no new rule is added. >> > > I think providing informative text on interactions of this document with > the various defined recovery (4872 and 4872) and reroute (4090) > mechanisms is a really good idea. That said, I found this section a bit > opaque. Ignoring the wordsmithing, what specific points are you trying > to make? > >> 8. Auto-tunnel mesh: >> New version 04 adds a section to elaborate on a use case for > auto-tunnel mesh. This is added as an FYI and can be removed if WG > thinks so. >> > > How is the association id field value selected in this case? > > >> 9. Clarification for Inter-AS LSPs: >> I believe there was an email exchange between Lou and Fei to clarify > the relationship with draft I-D, > draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num. A section is added in > version-04 to address this. Please review the added text. >> > > Well I (as chair) had asked in Vancouver that the authors of > rsvpte-ext-tunnel-num propose some language *on the list* that would > merge the functionality defined in that document into the WG document. > The mailing list discussion concluded with Fei stating that he want to > keep the drafts separate, which certainly is his call (as one is an > individual draft). So to be clear, I have not requested any references > to rsvpte-ext-tunnel-num in the WG draft. > > This section does highlight the issue of how remote global_ID can be > learned in the interdomain case. I think the stated solution doesn't > work with your current assignment approach, e.g., consider the case when > the lower IP address is the egress of the initial LSP... > > Lou > > >> Please advise us on above changes. Based on the consensus, we will > update the draft accordingly. >> >> Thanks, >> Rakesh >> >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, August 15, 2012 10:53 AM >> To: Rakesh Gandhi (rgandhi) >> Cc: zhang.fei3@zte.com.cn; jingrq@ctbri.com.cn >> Subject: New Version Notification for > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> >> A new version of I-D, > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> has been successfully submitted by Rakesh Gandhi and posted to the > IETF repository. >> >> Filename: > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp >> Revision: 04 >> Title: RSVP-TE Extensions for > Associated Bidirectional LSPs >> Creation date: 2012-08-15 >> WG ID: ccamp >> Number of pages: 17 >> URL: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> Status: > http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp >> Htmlized: > http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04 >> Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04 >> >> Abstract: >> The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], >> describes that MPLS-TP MUST support associated bidirectional point- >> to-point LSPs. >> >> This document provides a method to bind two unidirectional Label >> Switched Paths (LSPs) into an associated bidirectional LSP. The >> association is achieved by defining the new Association Type in the >> Extended ASSOCIATION object. >> >> > >> >> >> The IETF Secretariat >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > From zhang.fei3@zte.com.cn Sun Aug 26 18:03:40 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0327621F84E4 for ; Sun, 26 Aug 2012 18:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.827 X-Spam-Level: X-Spam-Status: No, score=-95.827 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZatNBvjQPva for ; Sun, 26 Aug 2012 18:03:38 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 90E9821F84F8 for ; Sun, 26 Aug 2012 18:03:37 -0700 (PDT) Received: from [10.30.3.20] by mx5.zte.com.cn with surfront esmtp id 232552685115152(version=TLSv1/SSLv3 cipher=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA bits=128 verify=NO); Mon, 27 Aug 2012 08:57:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q7R13JRY068699; Mon, 27 Aug 2012 09:03:20 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <503A7CE5.1060700@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: 99904969:03AF6206-48257A67:0003B2C9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Mon, 27 Aug 2012 09:03:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-27 09:03:20, Serialize complete at 2012-08-27 09:03:20 Content-Type: multipart/alternative; boundary="=_alternative 0005B57748257A67_=" X-MAIL: mse01.zte.com.cn q7R13JRY068699 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 01:03:40 -0000 This is a multipart message in MIME format. --=_alternative 0005B57748257A67_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TG91LCBzZWUgcmVzcG9uc2UgbGluZWQgd2l0aCA8ZmVpMT4NCg0KVGhhbmtzDQoNCkZlaQ0KDQoN Cg0KTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gDQoyMDEyLTA4LTI3IDAzOjQ1DQoNCsrV vP7Iyw0KemhhbmcuZmVpM0B6dGUuY29tLmNuDQqzrcvNDQoiY2NhbXBAaWV0Zi5vcmciIDxjY2Ft cEBpZXRmLm9yZz4sICJSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSIgDQo8cmdhbmRoaUBjaXNjby5j b20+DQrW98ziDQpSZTogW0NDQU1QXSBSZXZpZXcgUmVxdWVzdCBGb3IgQ2hhbmdlcyBpbiANCmRy YWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0K DQoNCg0KDQoNCg0KDQoNCk9uIDgvMjUvMjAxMiAxMTo0MyBQTSwgemhhbmcuZmVpM0B6dGUuY29t LmNuIHdyb3RlOg0KPiANCj4gSGkgTG91LA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIGRldGFpbGVk IHJldmlldywgc25pcHBlZCB0aGUgb3RoZXJzLCBzZWUgaW5saW5lIHdpdGggDQo8ZmVpPg0KPiAN Cj4gV2VsbCBJIChhcyBjaGFpcikgaGFkIGFza2VkIGluIFZhbmNvdXZlciB0aGF0IHRoZSBhdXRo b3JzIG9mDQo+IHJzdnB0ZS1leHQtdHVubmVsLW51bSBwcm9wb3NlIHNvbWUgbGFuZ3VhZ2UgKm9u IHRoZSBsaXN0KiB0aGF0IHdvdWxkDQo+IG1lcmdlIHRoZSBmdW5jdGlvbmFsaXR5IGRlZmluZWQg aW4gdGhhdCBkb2N1bWVudCBpbnRvIHRoZSBXRyBkb2N1bWVudC4NCj4gVGhlIG1haWxpbmcgbGlz dCBkaXNjdXNzaW9uIGNvbmNsdWRlZCB3aXRoIEZlaSBzdGF0aW5nIHRoYXQgaGUgd2FudCB0bw0K PiBrZWVwIHRoZSBkcmFmdHMgc2VwYXJhdGUsIHdoaWNoIGNlcnRhaW5seSBpcyBoaXMgY2FsbCAo YXMgb25lIGlzIGFuDQo+IGluZGl2aWR1YWwgZHJhZnQpLiAgU28gdG8gYmUgY2xlYXIsIEkgaGF2 ZSBub3QgcmVxdWVzdGVkIGFueSByZWZlcmVuY2VzDQo+IHRvIHJzdnB0ZS1leHQtdHVubmVsLW51 bSBpbiB0aGUgV0cgZHJhZnQuDQo+IA0KPiA8RmVpPiBTdXJlLCB0aGlzIHBhcnQgaXMgYWxzbyBp bmZvcm1hdGlvbmFsIGFuZCB0aGVyZSBpcyBubyBuZXcNCj4gbWVjaGFuaXNtIGludHJvZHVjZWQg aGVyZS4gOikNCg0KR2l2ZW4gdGhlIHJlY2VudCBkaXNjdXNzaW9uIChvbiBjby1yb3V0ZWQpIEkg ZG9uJ3QgdGhpbmsgdGhlIHJlZmVyZW5jZQ0KbWFrZXMgYW55IHNlbnNlIGdpdmVuIHRoZSBzY29w ZSBvZiByc3ZwdGUtZXh0LXR1bm5lbC1udW0gcHJvcG9zZSBpcw0KY28tcm91dGVkIGJpZGlyZWN0 aW9uYWwgd2hpY2ggaXMgY3VycmVudGx5IDEwMCUgb3V0IG9mIHNjb3BlIG9mIHRoaXMNCmRvY3Vt ZW50Lg0KDQoNCjxmZWkxPk9rLCBJIGFncmVlIHdpdGggeW91ciBzdGF0ZW1lbnQsIGFuZCB0aGUg dGV4dCBqdXN0IHdhbnRzIHRvIHNob3cgDQp0aGF0DQp0aGUgc2FtZSBwcm9jZWR1cmUgZGVmaW5l ZCBpbiByc3ZwdGUtZXh0LXR1bm5lbC1udW0gKHdoaWNoIGlzIHNjb3BlZCB0byANCmNvcm91dGVk IGJpZGlyZWN0aW9uYWwgTFNQKSBjYW4gYmUgdXNlZCBoZXJlIGFsc28gaWYgbmVjZXNzYXJ5LiAN Cg0KRG8geW91IGhhdmUgYW55IGFkdmljZSBob3cgdG8gb3JnYW5pemUgdGhpcyBwYXJhZ3JhcGg/ DQoNCigxKVJlbW92ZSB0aGUgY2l0ZWQgcmVmZXJlbmNlIGFuZCBkZWxldGUgdGhpcyBwYXJhZ3Jh cGgsIGp1c3QgaWdub3JlIHRoaXMNCmlzc3VlLg0KDQooMilSZW1vdmUgdGhlIGNpdGVkIHJlZmVy ZW5jZSBhbmQga2VlcCB0aGlzIHBhcmFncmFwaCAod2l0aCByZXZpc2lvbikNCg0KSWYgaXQgaXMg KDIpLCBjYW4geW91IGhlbHAgZ2l2ZSBzb21lIHdvcmRzPw0KDQpPciBvdGhlciBzY2hlbWVzPw0K DQoNCj4gDQo+IFRoaXMgc2VjdGlvbiBkb2VzIGhpZ2hsaWdodCB0aGUgaXNzdWUgb2YgaG93IHJl bW90ZSBnbG9iYWxfSUQgY2FuIGJlDQo+IGxlYXJuZWQgaW4gdGhlIGludGVyZG9tYWluIGNhc2Uu ICBJIHRoaW5rIHRoZSBzdGF0ZWQgc29sdXRpb24gZG9lc24ndA0KPiB3b3JrIHdpdGggeW91ciBj dXJyZW50IGFzc2lnbm1lbnQgYXBwcm9hY2gsIGUuZy4sIGNvbnNpZGVyIHRoZSBjYXNlIHdoZW4N Cj4gdGhlIGxvd2VyIElQIGFkZHJlc3MgaXMgdGhlIGVncmVzcyBvZiB0aGUgaW5pdGlhbCBMU1Au Li4NCj4gDQo+IDxGZWk+IEZvciB0aGUgc2luZ2xlZCBzaWRlZCBwcm92aXNpb25pbmcgbW9kZWws IHRoZSBpbml0aWFsIExTUCBzb3VyY2UNCj4gYWRkcmVzcyAoQXNzb2NpYXRpb24gU291cmNlKWFu ZCBnbG9iYWxfSUQgYXJlIHB1c2hlZCBpbnRvIHRoZSBFQQ0KPiBvYmplY3RzLCBzbyB0aGUgaW5n cmVzcyBjYW4gbGVhcm4gdGhlIGdsb2JhbCBJRCBvZiB0aGUgcGVlciBub2RlIGJ5IHRoZQ0KPiBk ZWZpbmVkIEFzc29jaWF0aW9uIFR5cGUgIkxTUCBJZGVudGlmaWVycyIgd2hpY2ggaXMgY2Fycmll ZCBpbiB0aGUgUGF0aA0KPiBtZXNzYWdlIGFuZCBiYWNrIGluIHRoZSBSZXN2IG1lc3NhZ2VzLg0K DQp0aGlzIGltcGxpZXMgYSBydWxlIG9mIHRoZSBsb3dlciBJUCBhZGRyZXNzIGFsd2F5cyBzaWdu YWxpbmcgaXRzIExTUA0KZmlyc3QuICBTZWVtcyBhIGJpdCBhcmJpdHJhcnkgdG8gbWUsIGFuZCBp c24ndCByZWZsZWN0ZWQgaW4gdGhlIGN1cnJlbnQNCnRleHQuICBIb3cgYWJvdXQganVzdCBmb2xs b3dpbmcgdGhlIGFkbWluaXN0cmF0aXZlIGFwcHJvYWNoIGJlaW5nDQpkaXNjdXNzZWQgd2l0aCBS YWtlc2ggaW4gdGhlIG90aGVyIHRocmVhZCBvbiB0aGUgc2FtZSB0b3BpYz8NCg0KPGZlaTE+VGhl IEFzc29jaWF0aW9uIFNvdXJjZSBjb3VsZCBiZSB0aGUgbG93ZXIgSVAgYWRkcmVzcyBvciB0aGUg aGlnaGVyIA0KSVAgYWRkcmVzcyBpbg0Kc2luZ2xlIHNpZGVkIHByb3Zpc2lvbmluZyBtb2RlbCwg d2hpY2ggaXMgZGVwZW5kaW5nIG9uIHRoZSB0b3VjaCBwb2ludCBhbmQNCmRpZmZlcmVudCBmcm9t IHRoZSBkb3VibGUgc2lkZWQgKHRoZSBsb3dlciBJUCBhZGRyZXNzIGFsd2F5cyB3aW5zKS4gVGhl IA0KYWRtaW5pc3RyYXRpdmUNCmFwcHJvYWNoIGNhbiBpbnRlZ3JhdGUgYm90aCBtb2RlbHMsIHdp bGwgYmUgYSBnb29kIGlkZWEuDQoNCg0KTG91DQoNCj4gDQo+IEZvciB0aGUgZG91YmxlZCBzaWRl ZCBwcm92aXNpb25pbmcgbW9kZWwsIHNpbmNlIHRoZSBsb3dlciBJUCBhZGRyZXNzDQo+IChBc3Nv Y2lhdGlvbiBTb3VyY2UpIHdpbnMgdGhlIHRpZSBicmVha2VyLCB0aGUgQXNzb2NpYXRpb24gb2Jq ZWN0IHdpdGgNCj4gQXNzb2NpYXRpb24gVHlwZSAiTFNQIElkZW50aWZpZXJzIiBjYW4gYmUgcHVz aGVkIGludG8gdGhlIFBhdGggbWVzc2FnZQ0KPiBieSB0aGUgbG93ZXIgSVAgYWRkcmVzcyBpbml0 aWFsIExTUCBjYW4gY2FycnkgYmFjayB0aGUgZ2xvYmFsX0lEIG9mIHRoZQ0KPiBoaWdoZXIgSVAg YWRkcmVzcyBpbiB0aGUgUmVzdiBtZXNzYWdlLg0KPiANCj4gSW4gb3RoZXIgd29yZHMsIHRoZSBB c3NvY2lhdGlvbiBvYmplY3Qgd2l0aCBBc3NvY2lhdGlvbiBUeWVwICJMU1ANCj4gSWRlbnRpZmll cnMiIGFyZSBhbHdheXMgcHVzaGVkIGJ5IHRoZSBBc3NvY2lhdGlvbiBTb3VyY2UgaW50byB0aGUg UGF0aA0KPiBtZXNzYWdlIGNhbiBjYXJyaWVkIGJhY2sgaW4gdGhlIFJlc3YgbWVzc2FnZSB3aXRo IHRoZSBwZWVyIG5vZGUncw0KPiBnbG9iYWxfSUQgaW4gYm90aCBwcm92aXNpb25pbmcgbW9kZWwg aWYgbmVjZXNzYXJ5Lg0KPiANCj4gRG8geW91IHRoaW5rIHRoZSBjdXJyZW50bHkgZGVzY3JpcHRp b24gbmVlZHMgbW9yZSBjbGFyaWZpY2F0aW9uIHdvcmRzPw0KPiANCj4gVGhhbmtzDQo+IA0KPiBG ZWkNCj4gDQo+IA0KPiAqTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4qDQo+ILeivP7Iyzog IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcNCj4gDQo+IDIwMTItMDgtMjUgMDE6NTUNCj4gDQo+IA0K PiDK1bz+yMsNCj4gICAgICAgICAgICAgICAgIlJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIiA8cmdh bmRoaUBjaXNjby5jb20+DQo+ILOty80NCj4gICAgICAgICAgICAgICAgImNjYW1wQGlldGYub3Jn IiA8Y2NhbXBAaWV0Zi5vcmc+DQo+INb3zOINCj4gICAgICAgICAgICAgICAgUmU6IFtDQ0FNUF0g UmV2aWV3IFJlcXVlc3QgRm9yIENoYW5nZXMgaW4gDQo+ICBkcmFmdC1pZXRmLWNjYW1wLW1wbHMt dHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCj4gDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gDQo+IA0KPiBSYWtlc2gsDQo+IA0KPiBTcGVha2luZyBhcyBhIFdHIHBhcnRpY2lwYW50 LCBhbmQgaWdub3JpbmcgY2hhbmdlcyA0IGFuZCA1IGFzIHlvdSBwbGFuDQo+IHRvIHJldmVydCB0 aGVzZToNCj4gDQo+IE9uIDgvMjMvMjAxMiAxMjoyMCBQTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRo aSkgd3JvdGU6DQo+PiBEZWFyIFdHLA0KPj4NCj4+IFdlIGxpa2UgdG8gcmVxdWVzdCBhIHJldmll dyBmcm9tIHRoZSBXRyBvbiB0aGUgY2hhbmdlcyBpbiB2ZXJzaW9uIDA0DQo+IG9mIHRoZSBkcmFm dC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcCBjb21wYXJlZCB0 bw0KPiB2ZXJzaW9uIDAzLg0KPj4NCj4+IFRoZSBtYWpvcml0eSBvZiB0aGUgcHJvcG9zZWQgY2hh bmdlcyBhcmUgYXJvdW5kIHRoZSBmb3JtYXQgYW5kIGhvdyB0bw0KPiBwb3B1bGF0ZSB0aGUgZXh0 ZW5kZWQgYXNzb2NpYXRpb24gb2JqZWN0IGFzIGxpc3RlZCBiZWxvdy4NCj4+DQo+PiBOb3RlOiBC YXNlZCBvbiB0aGUgZmVlZGJhY2tzIHJlY2VpdmVkIHNvIGZhciwgY2hhbmdlcyBmb3IgaXRlbXMg NCBhbmQNCj4gNSBiZWxvdyB3aWxsIGJlIHJldmVydGVkLg0KPj4NCj4+IDEuIEFzc29jaWF0aW9u LUlEOg0KPj4gSXQgd2FzIG5vdCBjbGVhciBmcm9tIHJlYWRpbmcgdGhlIHZlcnNpb24gMDMgb2Yg dGhlIGRyYWZ0IGhvdyB0aGlzDQo+IGZpZWxkIGlzIHBvcHVsYXRlZCBpbiB0aGUgZXh0ZW5kZWQg YXNzb2NpYXRpb24gb2JqZWN0LiBOZXcgdmVyc2lvbiAwNA0KPiBwcm9wb3NlcyB0byBwb3B1bGF0 ZSB0aGlzIGZpZWxkIGZyb20gdGhlIGxvY2FsbHkgcHJvdmlzaW9uZWQgdmFsdWUuIEFzDQo+IHRo aXMgdmFsdWUgaXMgaWRlbnRpY2FsbHkgcHJvdmlzaW9uZWQgb24gYm90aCBlbmRzLCBpdCBwcm92 aWRlcyBhIGZpZWxkDQo+IHRvIHRpZSB0aGUgdHdvIChmb3J3YXJkIGFuZCByZXZlcnNlKSBMU1Bz IG9uIGVuZC1wb2ludHMuDQo+Pg0KPiANCj4+IDIuIElQdjQgYXNzb2NpYXRpb24gc291cmNlOg0K Pj4gTmV3IHZlcnNpb24gMDQgYWRkcyBhIHRpZSBicmVha2VyIHJ1bGUgZm9yIGRvdWJsZSBzaWRl ZCBwcm92aXNpb25lZCANCkxTUHMuDQo+Pg0KPj4gMy4gR2xvYmFsIGFzc29jaWF0aW9uIHNvdXJj ZToNCj4+IE5ldyB2ZXJzaW9uIGNsYXJpZmllcyB0aGUgdXNhZ2UgZm9yIHRoaXMgZmllbGQgc2l0 aW5nIGluZm9ybWF0aW9uIGZyb20NCj4gUkZDNjM3MCBhbmQgb3RoZXIgbWVudGlvbmVkIGRyYWZ0 cy4gTm8gbmV3IHJ1bGUgYWRkZWQuDQo+Pg0KPiANCj4gWzQgYW5kIDUgcmVtb3ZlZCBmb3JtIG1h aWwgYXMgdG8gYmUgcmV2ZXJ0ZWRdDQo+IA0KPj4NCj4+IDYuIEV4dGVuZGVkIEFzc29jaWF0aW9u IElEIChBZGRyZXNzKToNCj4+IE5ldyB2ZXJzaW9uIDA0IHByb3Bvc2VzIHRvIHVzZSBhbiBJUCBh ZGRyZXNzIGFzIGV4dGVuZGVkIGFzc29jaWF0aW9uDQo+IElEIChhZGRyZXNzKSBhcyBhbiBhZGRp dGlvbmFsIGlkZW50aWZpZXIuIFByZXZpb3VzIHZlcnNpb24gMDMgZGVmaW5lcyBhDQo+IHZhcmlh YmxlIGxlbmd0aCBmaWVsZCBidXQgZGlkIG5vdCBtZW50aW9uIHdoYXQgcGFyYW1ldGVycyBjYW4g YmUgYWRkZWQNCj4gdGhlcmUuDQo+PiBBIHRpZSBicmVha2VyIHJ1bGUgaXMgZGVmaW5lZCBmb3Ig ZG91YmxlIHNpZGVkIHByb3Zpc2lvbmVkIHZhbHVlLg0KPj4NCj4gDQo+IEFzc3VtaW5nIGNoYW5n ZXMgMSwgMiwgYW5kIDYsIGhvdyBpcyB1bmlxdWVuZXNzIChvZiB0aGUgYXNzb2NpYXRpb24gSUQN Cj4gZmllbGQpIGd1YXJhbnRlZWQ/DQo+IA0KPj4gNy4gUGF0aCBQcm90ZWN0aW9uIG9iamVjdDoN Cj4+IFZlcnNpb24gMDMgb2YgdGhlIGRyYWZ0IHZhZ3VlbHkgbWVudGlvbmVkIGFuZCBhc3N1bWVk IG9mIHVzaW5nDQo+IHByb3RlY3Rpb24gb2JqZWN0IGZvciBwYXRoIHByb3RlY3Rpb24uIE5ldyB2 ZXJzaW9uIDA0IGFkZHMgc29tZSB0ZXh0cyB0bw0KPiBjbGFyaWZ5IGl0LCBubyBuZXcgcnVsZSBp cyBhZGRlZC4NCj4+DQo+IA0KPiBJIHRoaW5rIHByb3ZpZGluZyBpbmZvcm1hdGl2ZSB0ZXh0IG9u IGludGVyYWN0aW9ucyBvZiB0aGlzIGRvY3VtZW50IHdpdGgNCj4gdGhlIHZhcmlvdXMgZGVmaW5l ZCByZWNvdmVyeSAoNDg3MiBhbmQgNDg3MikgYW5kIHJlcm91dGUgKDQwOTApDQo+IG1lY2hhbmlz bXMgaXMgYSByZWFsbHkgZ29vZCBpZGVhLiAgVGhhdCBzYWlkLCBJIGZvdW5kIHRoaXMgc2VjdGlv biBhIGJpdA0KPiBvcGFxdWUuICBJZ25vcmluZyB0aGUgd29yZHNtaXRoaW5nLCB3aGF0IHNwZWNp ZmljIHBvaW50cyBhcmUgeW91IHRyeWluZw0KPiB0byBtYWtlPw0KPiANCj4+IDguIEF1dG8tdHVu bmVsIG1lc2g6DQo+PiBOZXcgdmVyc2lvbiAwNCBhZGRzIGEgc2VjdGlvbiB0byBlbGFib3JhdGUg b24gYSB1c2UgY2FzZSBmb3INCj4gYXV0by10dW5uZWwgbWVzaC4gVGhpcyBpcyBhZGRlZCBhcyBh biBGWUkgYW5kIGNhbiBiZSByZW1vdmVkIGlmIFdHDQo+IHRoaW5rcyBzby4NCj4+DQo+IA0KPiBI b3cgaXMgdGhlIGFzc29jaWF0aW9uIGlkIGZpZWxkIHZhbHVlIHNlbGVjdGVkIGluIHRoaXMgY2Fz ZT8NCj4gDQo+IA0KPj4gOS4gQ2xhcmlmaWNhdGlvbiBmb3IgSW50ZXItQVMgTFNQczoNCj4+IEkg YmVsaWV2ZSB0aGVyZSB3YXMgYW4gZW1haWwgZXhjaGFuZ2UgYmV0d2VlbiBMb3UgYW5kIEZlaSB0 byBjbGFyaWZ5DQo+IHRoZSByZWxhdGlvbnNoaXAgd2l0aCBkcmFmdCBJLUQsDQo+IGRyYWZ0LXpo YW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLiBBIHNlY3Rpb24gaXMgYWRk ZWQgaW4NCj4gdmVyc2lvbi0wNCB0byBhZGRyZXNzIHRoaXMuIFBsZWFzZSByZXZpZXcgdGhlIGFk ZGVkIHRleHQuDQo+Pg0KPiANCj4gV2VsbCBJIChhcyBjaGFpcikgaGFkIGFza2VkIGluIFZhbmNv dXZlciB0aGF0IHRoZSBhdXRob3JzIG9mDQo+IHJzdnB0ZS1leHQtdHVubmVsLW51bSBwcm9wb3Nl IHNvbWUgbGFuZ3VhZ2UgKm9uIHRoZSBsaXN0KiB0aGF0IHdvdWxkDQo+IG1lcmdlIHRoZSBmdW5j dGlvbmFsaXR5IGRlZmluZWQgaW4gdGhhdCBkb2N1bWVudCBpbnRvIHRoZSBXRyBkb2N1bWVudC4N Cj4gVGhlIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uIGNvbmNsdWRlZCB3aXRoIEZlaSBzdGF0aW5n IHRoYXQgaGUgd2FudCB0bw0KPiBrZWVwIHRoZSBkcmFmdHMgc2VwYXJhdGUsIHdoaWNoIGNlcnRh aW5seSBpcyBoaXMgY2FsbCAoYXMgb25lIGlzIGFuDQo+IGluZGl2aWR1YWwgZHJhZnQpLiAgU28g dG8gYmUgY2xlYXIsIEkgaGF2ZSBub3QgcmVxdWVzdGVkIGFueSByZWZlcmVuY2VzDQo+IHRvIHJz dnB0ZS1leHQtdHVubmVsLW51bSBpbiB0aGUgV0cgZHJhZnQuDQo+IA0KPiBUaGlzIHNlY3Rpb24g ZG9lcyBoaWdobGlnaHQgdGhlIGlzc3VlIG9mIGhvdyByZW1vdGUgZ2xvYmFsX0lEIGNhbiBiZQ0K PiBsZWFybmVkIGluIHRoZSBpbnRlcmRvbWFpbiBjYXNlLiAgSSB0aGluayB0aGUgc3RhdGVkIHNv bHV0aW9uIGRvZXNuJ3QNCj4gd29yayB3aXRoIHlvdXIgY3VycmVudCBhc3NpZ25tZW50IGFwcHJv YWNoLCBlLmcuLCBjb25zaWRlciB0aGUgY2FzZSB3aGVuDQo+IHRoZSBsb3dlciBJUCBhZGRyZXNz IGlzIHRoZSBlZ3Jlc3Mgb2YgdGhlIGluaXRpYWwgTFNQLi4uDQo+IA0KPiBMb3UNCj4gDQo+IA0K Pj4gUGxlYXNlIGFkdmlzZSB1cyBvbiBhYm92ZSBjaGFuZ2VzLiBCYXNlZCBvbiB0aGUgY29uc2Vu c3VzLCB3ZSB3aWxsDQo+IHVwZGF0ZSB0aGUgZHJhZnQgYWNjb3JkaW5nbHkuDQo+Pg0KPj4gVGhh bmtzLA0KPj4gUmFrZXNoDQo+PiANCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXQ0KPj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTUsIDIwMTIgMTA6NTMgQU0N Cj4+IFRvOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KPj4gQ2M6IHpoYW5nLmZlaTNAenRlLmNv bS5jbjsgamluZ3JxQGN0YnJpLmNvbS5jbg0KPj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lh dGVkLWxzcC0wNC50eHQNCj4+DQo+Pg0KPj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsDQo+IGRyYWZ0 LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KPj4g aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSYWtlc2ggR2FuZGhpIGFuZCBwb3N0 ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4+DQo+PiBGaWxlbmFtZTogDQo+ICBkcmFm dC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcA0KPj4gUmV2aXNp b246ICAgICAgICAgICAgICAgICAgMDQNCj4+IFRpdGxlOiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUlNWUC1URSBFeHRlbnNpb25zIGZvcg0KPiBBc3NvY2lhdGVkIEJpZGlyZWN0 aW9uYWwgTFNQcw0KPj4gQ3JlYXRpb24gZGF0ZTogICAgICAgICAgICAgICAgICAyMDEyLTA4LTE1 DQo+PiBXRyBJRDogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNjYW1wDQo+PiBO dW1iZXIgb2YgcGFnZXM6IDE3DQo+PiBVUkw6IA0KPiANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0 ZWQtbHNwLTA0LnR4dA0KDQo+PiBTdGF0dXM6IA0KPiAgDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQt bHNwDQoNCj4+IEh0bWxpemVkOiANCj4gIA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQNCg0KPj4g RGlmZjogDQo+ICANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt Y2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0DQoNCj4+DQo+PiBBYnN0 cmFjdDoNCj4+ICAgIFRoZSBNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSByZXF1aXJl bWVudHMgZG9jdW1lbnQgDQpbUkZDNTY1NF0sDQo+PiAgICBkZXNjcmliZXMgdGhhdCBNUExTLVRQ IE1VU1Qgc3VwcG9ydCBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgcG9pbnQtDQo+PiAgICB0by1w b2ludCBMU1BzLg0KPj4NCj4+ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBtZXRob2QgdG8g YmluZCB0d28gdW5pZGlyZWN0aW9uYWwgTGFiZWwNCj4+ICAgIFN3aXRjaGVkIFBhdGhzIChMU1Bz KSBpbnRvIGFuIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuICBUaGUNCj4+ICAgIGFzc29j aWF0aW9uIGlzIGFjaGlldmVkIGJ5IGRlZmluaW5nIHRoZSBuZXcgQXNzb2NpYXRpb24gVHlwZSBp biB0aGUNCj4+ICAgIEV4dGVuZGVkIEFTU09DSUFUSU9OIG9iamVjdC4NCj4+DQo+PiANCj4gDQo+ Pg0KPj4NCj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4g Q0NBTVBAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2NhbXANCj4+DQo+Pg0KPj4NCj4+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IENDQU1QIG1haWxpbmcgbGlzdA0KPiBDQ0FNUEBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+IA0KPiANCg0K DQoNCg== --=_alternative 0005B57748257A67_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxvdSwgc2VlIHJlc3BvbnNlIGxp bmVkIHdpdGggJmx0O2ZlaTEmZ3Q7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5UaGFua3M8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj48Yj5Mb3UgQmVyZ2VyICZsdDtsYmVyZ2VyQGxhYm4ubmV0Jmd0OzwvYj4NCjwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTA4LTI3IDAzOjQ1 PC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PnpoYW5nLmZlaTNAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Y2NhbXBAaWV0 Zi5vcmcmcXVvdDsgJmx0O2NjYW1wQGlldGYub3JnJmd0OywNCiZxdW90O1Jha2VzaCBHYW5kaGkg KHJnYW5kaGkpJnF1b3Q7ICZsdDtyZ2FuZGhpQGNpc2NvLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPlJlOiBbQ0NBTVBdIFJldmlldyBSZXF1ZXN0IEZvciBDaGFuZ2VzDQppbiBkcmFmdC1pZXRm LWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQ8L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjxi cj4NCk9uIDgvMjUvMjAxMiAxMTo0MyBQTSwgemhhbmcuZmVpM0B6dGUuY29tLmNuIHdyb3RlOjxi cj4NCiZndDsgPGJyPg0KJmd0OyBIaSBMb3UsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyBm b3IgeW91ciBkZXRhaWxlZCByZXZpZXcsIHNuaXBwZWQgdGhlIG90aGVycywgc2VlIGlubGluZSB3 aXRoDQombHQ7ZmVpJmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBXZWxsIEkgKGFzIGNoYWlyKSBo YWQgYXNrZWQgaW4gVmFuY291dmVyIHRoYXQgdGhlIGF1dGhvcnMgb2Y8YnI+DQomZ3Q7IHJzdnB0 ZS1leHQtdHVubmVsLW51bSBwcm9wb3NlIHNvbWUgbGFuZ3VhZ2UgKm9uIHRoZSBsaXN0KiB0aGF0 IHdvdWxkPGJyPg0KJmd0OyBtZXJnZSB0aGUgZnVuY3Rpb25hbGl0eSBkZWZpbmVkIGluIHRoYXQg ZG9jdW1lbnQgaW50byB0aGUgV0cgZG9jdW1lbnQuPGJyPg0KJmd0OyBUaGUgbWFpbGluZyBsaXN0 IGRpc2N1c3Npb24gY29uY2x1ZGVkIHdpdGggRmVpIHN0YXRpbmcgdGhhdCBoZSB3YW50DQp0bzxi cj4NCiZndDsga2VlcCB0aGUgZHJhZnRzIHNlcGFyYXRlLCB3aGljaCBjZXJ0YWlubHkgaXMgaGlz IGNhbGwgKGFzIG9uZSBpcyBhbjxicj4NCiZndDsgaW5kaXZpZHVhbCBkcmFmdCkuICZuYnNwO1Nv IHRvIGJlIGNsZWFyLCBJIGhhdmUgbm90IHJlcXVlc3RlZCBhbnkNCnJlZmVyZW5jZXM8YnI+DQom Z3Q7IHRvIHJzdnB0ZS1leHQtdHVubmVsLW51bSBpbiB0aGUgV0cgZHJhZnQuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7ICZsdDtGZWkmZ3Q7IFN1cmUsIHRoaXMgcGFydCBpcyBhbHNvIGluZm9ybWF0aW9u YWwgYW5kIHRoZXJlIGlzIG5vDQpuZXc8YnI+DQomZ3Q7IG1lY2hhbmlzbSBpbnRyb2R1Y2VkIGhl cmUuIDopPGJyPg0KPGJyPg0KR2l2ZW4gdGhlIHJlY2VudCBkaXNjdXNzaW9uIChvbiBjby1yb3V0 ZWQpIEkgZG9uJ3QgdGhpbmsgdGhlIHJlZmVyZW5jZTxicj4NCm1ha2VzIGFueSBzZW5zZSBnaXZl biB0aGUgc2NvcGUgb2YgcnN2cHRlLWV4dC10dW5uZWwtbnVtIHByb3Bvc2UgaXM8YnI+DQpjby1y b3V0ZWQgYmlkaXJlY3Rpb25hbCB3aGljaCBpcyBjdXJyZW50bHkgMTAwJSBvdXQgb2Ygc2NvcGUg b2YgdGhpczxicj4NCmRvY3VtZW50Ljxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7ZmVpMSZndDs8L2ZvbnQ+PHR0Pjxmb250IHNp emU9Mj5PaywNCkkgYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVudCwgYW5kIHRoZSB0ZXh0IGp1c3Qg d2FudHMgdG8gc2hvdyB0aGF0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj50aGUg c2FtZSBwcm9jZWR1cmUgZGVmaW5lZCBpbiByc3ZwdGUtZXh0LXR1bm5lbC1udW0NCih3aGljaCBp cyBzY29wZWQgdG8gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5jb3JvdXRlZCBi aWRpcmVjdGlvbmFsIExTUCkgY2FuIGJlIHVzZWQgaGVyZSBhbHNvDQppZiBuZWNlc3NhcnkuIDwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+RG8geW91IGhhdmUgYW55IGFk dmljZSBob3cgdG8gb3JnYW5pemUgdGhpcyBwYXJhZ3JhcGg/PC9mb250PjwvdHQ+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4oMSlSZW1vdmUgdGhlIGNpdGVkIHJlZmVyZW5jZSBhbmQgZGVs ZXRlIHRoaXMgcGFyYWdyYXBoLA0KanVzdCBpZ25vcmUgdGhpczwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+aXNzdWUuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4oMilSZW1vdmUgdGhlIGNpdGVkIHJlZmVyZW5jZSBhbmQga2VlcCB0aGlzIHBhcmFncmFw aA0KKHdpdGggcmV2aXNpb24pPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5JZiBpdCBpcyAoMiksIGNhbiB5b3UgaGVscCBnaXZlIHNvbWUgd29yZHM/PC9mb250PjwvdHQ+ DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5PciBvdGhlciBzY2hlbWVzPzwvZm9udD48L3R0 Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoaXMg c2VjdGlvbiBkb2VzIGhpZ2hsaWdodCB0aGUgaXNzdWUgb2YgaG93IHJlbW90ZSBnbG9iYWxfSUQg Y2FuDQpiZTxicj4NCiZndDsgbGVhcm5lZCBpbiB0aGUgaW50ZXJkb21haW4gY2FzZS4gJm5ic3A7 SSB0aGluayB0aGUgc3RhdGVkIHNvbHV0aW9uDQpkb2Vzbid0PGJyPg0KJmd0OyB3b3JrIHdpdGgg eW91ciBjdXJyZW50IGFzc2lnbm1lbnQgYXBwcm9hY2gsIGUuZy4sIGNvbnNpZGVyIHRoZSBjYXNl DQp3aGVuPGJyPg0KJmd0OyB0aGUgbG93ZXIgSVAgYWRkcmVzcyBpcyB0aGUgZWdyZXNzIG9mIHRo ZSBpbml0aWFsIExTUC4uLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbHQ7RmVpJmd0OyBGb3IgdGhl IHNpbmdsZWQgc2lkZWQgcHJvdmlzaW9uaW5nIG1vZGVsLCB0aGUgaW5pdGlhbA0KTFNQIHNvdXJj ZTxicj4NCiZndDsgYWRkcmVzcyAoQXNzb2NpYXRpb24gU291cmNlKWFuZCBnbG9iYWxfSUQgYXJl IHB1c2hlZCBpbnRvIHRoZSBFQTxicj4NCiZndDsgb2JqZWN0cywgc28gdGhlIGluZ3Jlc3MgY2Fu IGxlYXJuIHRoZSBnbG9iYWwgSUQgb2YgdGhlIHBlZXIgbm9kZSBieQ0KdGhlPGJyPg0KJmd0OyBk ZWZpbmVkIEFzc29jaWF0aW9uIFR5cGUgJnF1b3Q7TFNQIElkZW50aWZpZXJzJnF1b3Q7IHdoaWNo IGlzIGNhcnJpZWQNCmluIHRoZSBQYXRoPGJyPg0KJmd0OyBtZXNzYWdlIGFuZCBiYWNrIGluIHRo ZSBSZXN2IG1lc3NhZ2VzLjxicj4NCjxicj4NCnRoaXMgaW1wbGllcyBhIHJ1bGUgb2YgdGhlIGxv d2VyIElQIGFkZHJlc3MgYWx3YXlzIHNpZ25hbGluZyBpdHMgTFNQPGJyPg0KZmlyc3QuICZuYnNw O1NlZW1zIGEgYml0IGFyYml0cmFyeSB0byBtZSwgYW5kIGlzbid0IHJlZmxlY3RlZCBpbiB0aGUg Y3VycmVudDxicj4NCnRleHQuICZuYnNwO0hvdyBhYm91dCBqdXN0IGZvbGxvd2luZyB0aGUgYWRt aW5pc3RyYXRpdmUgYXBwcm9hY2ggYmVpbmc8YnI+DQpkaXNjdXNzZWQgd2l0aCBSYWtlc2ggaW4g dGhlIG90aGVyIHRocmVhZCBvbiB0aGUgc2FtZSB0b3BpYz88L2ZvbnQ+PC90dD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0O2ZlaTEmZ3Q7PC9mb250Pjx0dD48 Zm9udCBzaXplPTI+VGhlDQpBc3NvY2lhdGlvbiBTb3VyY2UgY291bGQgYmUgdGhlIGxvd2VyIElQ IGFkZHJlc3Mgb3IgdGhlIGhpZ2hlciBJUCBhZGRyZXNzDQppbjwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+c2luZ2xlIHNpZGVkIHByb3Zpc2lvbmluZyBtb2RlbCwgd2hpY2ggaXMg ZGVwZW5kaW5nDQpvbiB0aGUgdG91Y2ggcG9pbnQgYW5kPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj5kaWZmZXJlbnQgZnJvbSB0aGUgZG91YmxlIHNpZGVkICh0aGUgbG93ZXIgSVAg YWRkcmVzcw0KYWx3YXlzIHdpbnMpLiBUaGUgYWRtaW5pc3RyYXRpdmU8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPmFwcHJvYWNoIGNhbiBpbnRlZ3JhdGUgYm90aCBtb2RlbHMsIHdp bGwgYmUgYSBnb29kDQppZGVhLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+TG91PGJyPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZvciB0aGUgZG91YmxlZCBz aWRlZCBwcm92aXNpb25pbmcgbW9kZWwsIHNpbmNlIHRoZSBsb3dlciBJUCBhZGRyZXNzPGJyPg0K Jmd0OyAoQXNzb2NpYXRpb24gU291cmNlKSB3aW5zIHRoZSB0aWUgYnJlYWtlciwgdGhlIEFzc29j aWF0aW9uIG9iamVjdA0Kd2l0aDxicj4NCiZndDsgQXNzb2NpYXRpb24gVHlwZSAmcXVvdDtMU1Ag SWRlbnRpZmllcnMmcXVvdDsgY2FuIGJlIHB1c2hlZCBpbnRvIHRoZQ0KUGF0aCBtZXNzYWdlPGJy Pg0KJmd0OyBieSB0aGUgbG93ZXIgSVAgYWRkcmVzcyBpbml0aWFsIExTUCBjYW4gY2FycnkgYmFj ayB0aGUgZ2xvYmFsX0lEIG9mDQp0aGU8YnI+DQomZ3Q7IGhpZ2hlciBJUCBhZGRyZXNzIGluIHRo ZSBSZXN2IG1lc3NhZ2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIG90aGVyIHdvcmRzLCB0aGUg QXNzb2NpYXRpb24gb2JqZWN0IHdpdGggQXNzb2NpYXRpb24gVHllcCAmcXVvdDtMU1A8YnI+DQom Z3Q7IElkZW50aWZpZXJzJnF1b3Q7IGFyZSBhbHdheXMgcHVzaGVkIGJ5IHRoZSBBc3NvY2lhdGlv biBTb3VyY2UgaW50bw0KdGhlIFBhdGg8YnI+DQomZ3Q7IG1lc3NhZ2UgY2FuIGNhcnJpZWQgYmFj ayBpbiB0aGUgUmVzdiBtZXNzYWdlIHdpdGggdGhlIHBlZXIgbm9kZSdzPGJyPg0KJmd0OyBnbG9i YWxfSUQgaW4gYm90aCBwcm92aXNpb25pbmcgbW9kZWwgaWYgbmVjZXNzYXJ5Ljxicj4NCiZndDsg PGJyPg0KJmd0OyBEbyB5b3UgdGhpbmsgdGhlIGN1cnJlbnRseSBkZXNjcmlwdGlvbiBuZWVkcyBt b3JlIGNsYXJpZmljYXRpb24gd29yZHM/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rczxicj4N CiZndDsgPGJyPg0KJmd0OyBGZWk8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAqTG91 IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDsqPGJyPg0KJmd0OyC3orz+yMs6ICZuYnNw O2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQomZ3Q7IDxicj4NCiZndDsgMjAxMi0wOC0yNSAw MTo1NTxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgytW8/sjLPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZxdW90O1Jha2VzaA0KR2FuZGhpIChyZ2FuZGhpKSZxdW90OyAmbHQ7cmdhbmRoaUBj aXNjby5jb20mZ3Q7PGJyPg0KJmd0OyCzrcvNPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O2NjYW1wQGll dGYub3JnJnF1b3Q7DQombHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0OyDW98ziPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO1JlOg0KW0NDQU1QXSBSZXZpZXcgUmVxdWVzdCBGb3IgQ2hhbmdlcyBpbiAmbmJz cDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgJm5ic3A7ZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRw LXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyBSYWtlc2gsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNwZWFr aW5nIGFzIGEgV0cgcGFydGljaXBhbnQsIGFuZCBpZ25vcmluZyBjaGFuZ2VzIDQgYW5kIDUgYXMg eW91DQpwbGFuPGJyPg0KJmd0OyB0byByZXZlcnQgdGhlc2U6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IE9uIDgvMjMvMjAxMiAxMjoyMCBQTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6PGJy Pg0KJmd0OyZndDsgRGVhciBXRyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFdlIGxpa2Ug dG8gcmVxdWVzdCBhIHJldmlldyBmcm9tIHRoZSBXRyBvbiB0aGUgY2hhbmdlcyBpbiB2ZXJzaW9u DQowNDxicj4NCiZndDsgb2YgdGhlIGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0 LWFzc29jaWF0ZWQtbHNwIGNvbXBhcmVkDQp0bzxicj4NCiZndDsgdmVyc2lvbiAwMy48YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBtYWpvcml0eSBvZiB0aGUgcHJvcG9zZWQgY2hhbmdl cyBhcmUgYXJvdW5kIHRoZSBmb3JtYXQgYW5kDQpob3cgdG88YnI+DQomZ3Q7IHBvcHVsYXRlIHRo ZSBleHRlbmRlZCBhc3NvY2lhdGlvbiBvYmplY3QgYXMgbGlzdGVkIGJlbG93Ljxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgTm90ZTogQmFzZWQgb24gdGhlIGZlZWRiYWNrcyByZWNlaXZlZCBz byBmYXIsIGNoYW5nZXMgZm9yIGl0ZW1zDQo0IGFuZDxicj4NCiZndDsgNSBiZWxvdyB3aWxsIGJl IHJldmVydGVkLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgMS4gQXNzb2NpYXRpb24tSUQ6 PGJyPg0KJmd0OyZndDsgSXQgd2FzIG5vdCBjbGVhciBmcm9tIHJlYWRpbmcgdGhlIHZlcnNpb24g MDMgb2YgdGhlIGRyYWZ0IGhvdw0KdGhpczxicj4NCiZndDsgZmllbGQgaXMgcG9wdWxhdGVkIGlu IHRoZSBleHRlbmRlZCBhc3NvY2lhdGlvbiBvYmplY3QuIE5ldyB2ZXJzaW9uDQowNDxicj4NCiZn dDsgcHJvcG9zZXMgdG8gcG9wdWxhdGUgdGhpcyBmaWVsZCBmcm9tIHRoZSBsb2NhbGx5IHByb3Zp c2lvbmVkIHZhbHVlLg0KQXM8YnI+DQomZ3Q7IHRoaXMgdmFsdWUgaXMgaWRlbnRpY2FsbHkgcHJv dmlzaW9uZWQgb24gYm90aCBlbmRzLCBpdCBwcm92aWRlcyBhDQpmaWVsZDxicj4NCiZndDsgdG8g dGllIHRoZSB0d28gKGZvcndhcmQgYW5kIHJldmVyc2UpIExTUHMgb24gZW5kLXBvaW50cy48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgMi4gSVB2NCBhc3NvY2lhdGlvbiBz b3VyY2U6PGJyPg0KJmd0OyZndDsgTmV3IHZlcnNpb24gMDQgYWRkcyBhIHRpZSBicmVha2VyIHJ1 bGUgZm9yIGRvdWJsZSBzaWRlZCBwcm92aXNpb25lZA0KTFNQcy48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IDMuIEdsb2JhbCBhc3NvY2lhdGlvbiBzb3VyY2U6PGJyPg0KJmd0OyZndDsgTmV3 IHZlcnNpb24gY2xhcmlmaWVzIHRoZSB1c2FnZSBmb3IgdGhpcyBmaWVsZCBzaXRpbmcgaW5mb3Jt YXRpb24NCmZyb208YnI+DQomZ3Q7IFJGQzYzNzAgYW5kIG90aGVyIG1lbnRpb25lZCBkcmFmdHMu IE5vIG5ldyBydWxlIGFkZGVkLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFs0 IGFuZCA1IHJlbW92ZWQgZm9ybSBtYWlsIGFzIHRvIGJlIHJldmVydGVkXTxicj4NCiZndDsgPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA2LiBFeHRlbmRlZCBBc3NvY2lhdGlvbiBJRCAoQWRk cmVzcyk6PGJyPg0KJmd0OyZndDsgTmV3IHZlcnNpb24gMDQgcHJvcG9zZXMgdG8gdXNlIGFuIElQ IGFkZHJlc3MgYXMgZXh0ZW5kZWQgYXNzb2NpYXRpb248YnI+DQomZ3Q7IElEIChhZGRyZXNzKSBh cyBhbiBhZGRpdGlvbmFsIGlkZW50aWZpZXIuIFByZXZpb3VzIHZlcnNpb24gMDMgZGVmaW5lcw0K YTxicj4NCiZndDsgdmFyaWFibGUgbGVuZ3RoIGZpZWxkIGJ1dCBkaWQgbm90IG1lbnRpb24gd2hh dCBwYXJhbWV0ZXJzIGNhbiBiZSBhZGRlZDxicj4NCiZndDsgdGhlcmUuPGJyPg0KJmd0OyZndDsg QSB0aWUgYnJlYWtlciBydWxlIGlzIGRlZmluZWQgZm9yIGRvdWJsZSBzaWRlZCBwcm92aXNpb25l ZCB2YWx1ZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBBc3N1bWluZyBjaGFu Z2VzIDEsIDIsIGFuZCA2LCBob3cgaXMgdW5pcXVlbmVzcyAob2YgdGhlIGFzc29jaWF0aW9uDQpJ RDxicj4NCiZndDsgZmllbGQpIGd1YXJhbnRlZWQ/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyA3 LiBQYXRoIFByb3RlY3Rpb24gb2JqZWN0Ojxicj4NCiZndDsmZ3Q7IFZlcnNpb24gMDMgb2YgdGhl IGRyYWZ0IHZhZ3VlbHkgbWVudGlvbmVkIGFuZCBhc3N1bWVkIG9mIHVzaW5nPGJyPg0KJmd0OyBw cm90ZWN0aW9uIG9iamVjdCBmb3IgcGF0aCBwcm90ZWN0aW9uLiBOZXcgdmVyc2lvbiAwNCBhZGRz IHNvbWUgdGV4dHMNCnRvPGJyPg0KJmd0OyBjbGFyaWZ5IGl0LCBubyBuZXcgcnVsZSBpcyBhZGRl ZC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHRoaW5rIHByb3ZpZGluZyBp bmZvcm1hdGl2ZSB0ZXh0IG9uIGludGVyYWN0aW9ucyBvZiB0aGlzIGRvY3VtZW50DQp3aXRoPGJy Pg0KJmd0OyB0aGUgdmFyaW91cyBkZWZpbmVkIHJlY292ZXJ5ICg0ODcyIGFuZCA0ODcyKSBhbmQg cmVyb3V0ZSAoNDA5MCk8YnI+DQomZ3Q7IG1lY2hhbmlzbXMgaXMgYSByZWFsbHkgZ29vZCBpZGVh LiAmbmJzcDtUaGF0IHNhaWQsIEkgZm91bmQgdGhpcyBzZWN0aW9uDQphIGJpdDxicj4NCiZndDsg b3BhcXVlLiAmbmJzcDtJZ25vcmluZyB0aGUgd29yZHNtaXRoaW5nLCB3aGF0IHNwZWNpZmljIHBv aW50cyBhcmUNCnlvdSB0cnlpbmc8YnI+DQomZ3Q7IHRvIG1ha2U/PGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jmd0OyA4LiBBdXRvLXR1bm5lbCBtZXNoOjxicj4NCiZndDsmZ3Q7IE5ldyB2ZXJzaW9uIDA0 IGFkZHMgYSBzZWN0aW9uIHRvIGVsYWJvcmF0ZSBvbiBhIHVzZSBjYXNlIGZvcjxicj4NCiZndDsg YXV0by10dW5uZWwgbWVzaC4gVGhpcyBpcyBhZGRlZCBhcyBhbiBGWUkgYW5kIGNhbiBiZSByZW1v dmVkIGlmIFdHPGJyPg0KJmd0OyB0aGlua3Mgc28uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7IDxi cj4NCiZndDsgSG93IGlzIHRoZSBhc3NvY2lhdGlvbiBpZCBmaWVsZCB2YWx1ZSBzZWxlY3RlZCBp biB0aGlzIGNhc2U/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IDkuIENsYXJp ZmljYXRpb24gZm9yIEludGVyLUFTIExTUHM6PGJyPg0KJmd0OyZndDsgSSBiZWxpZXZlIHRoZXJl IHdhcyBhbiBlbWFpbCBleGNoYW5nZSBiZXR3ZWVuIExvdSBhbmQgRmVpIHRvIGNsYXJpZnk8YnI+ DQomZ3Q7IHRoZSByZWxhdGlvbnNoaXAgd2l0aCBkcmFmdCBJLUQsPGJyPg0KJmd0OyBkcmFmdC16 aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS4gQSBzZWN0aW9uIGlzIGFk ZGVkDQppbjxicj4NCiZndDsgdmVyc2lvbi0wNCB0byBhZGRyZXNzIHRoaXMuIFBsZWFzZSByZXZp ZXcgdGhlIGFkZGVkIHRleHQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgV2Vs bCBJIChhcyBjaGFpcikgaGFkIGFza2VkIGluIFZhbmNvdXZlciB0aGF0IHRoZSBhdXRob3JzIG9m PGJyPg0KJmd0OyByc3ZwdGUtZXh0LXR1bm5lbC1udW0gcHJvcG9zZSBzb21lIGxhbmd1YWdlICpv biB0aGUgbGlzdCogdGhhdCB3b3VsZDxicj4NCiZndDsgbWVyZ2UgdGhlIGZ1bmN0aW9uYWxpdHkg ZGVmaW5lZCBpbiB0aGF0IGRvY3VtZW50IGludG8gdGhlIFdHIGRvY3VtZW50Ljxicj4NCiZndDsg VGhlIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uIGNvbmNsdWRlZCB3aXRoIEZlaSBzdGF0aW5nIHRo YXQgaGUgd2FudA0KdG88YnI+DQomZ3Q7IGtlZXAgdGhlIGRyYWZ0cyBzZXBhcmF0ZSwgd2hpY2gg Y2VydGFpbmx5IGlzIGhpcyBjYWxsIChhcyBvbmUgaXMgYW48YnI+DQomZ3Q7IGluZGl2aWR1YWwg ZHJhZnQpLiAmbmJzcDtTbyB0byBiZSBjbGVhciwgSSBoYXZlIG5vdCByZXF1ZXN0ZWQgYW55DQpy ZWZlcmVuY2VzPGJyPg0KJmd0OyB0byByc3ZwdGUtZXh0LXR1bm5lbC1udW0gaW4gdGhlIFdHIGRy YWZ0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIHNlY3Rpb24gZG9lcyBoaWdobGlnaHQgdGhl IGlzc3VlIG9mIGhvdyByZW1vdGUgZ2xvYmFsX0lEIGNhbg0KYmU8YnI+DQomZ3Q7IGxlYXJuZWQg aW4gdGhlIGludGVyZG9tYWluIGNhc2UuICZuYnNwO0kgdGhpbmsgdGhlIHN0YXRlZCBzb2x1dGlv bg0KZG9lc24ndDxicj4NCiZndDsgd29yayB3aXRoIHlvdXIgY3VycmVudCBhc3NpZ25tZW50IGFw cHJvYWNoLCBlLmcuLCBjb25zaWRlciB0aGUgY2FzZQ0Kd2hlbjxicj4NCiZndDsgdGhlIGxvd2Vy IElQIGFkZHJlc3MgaXMgdGhlIGVncmVzcyBvZiB0aGUgaW5pdGlhbCBMU1AuLi48YnI+DQomZ3Q7 IDxicj4NCiZndDsgTG91PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IFBsZWFz ZSBhZHZpc2UgdXMgb24gYWJvdmUgY2hhbmdlcy4gQmFzZWQgb24gdGhlIGNvbnNlbnN1cywgd2UN CndpbGw8YnI+DQomZ3Q7IHVwZGF0ZSB0aGUgZHJhZnQgYWNjb3JkaW5nbHkuPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBUaGFua3MsPGJyPg0KJmd0OyZndDsgUmFrZXNoPGJyPg0KJmd0OyZn dDsgJm5ic3A7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCiZndDsmZ3Q7IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ108YnI+DQomZ3Q7Jmd0OyBTZW50OiBXZWRuZXNk YXksIEF1Z3VzdCAxNSwgMjAxMiAxMDo1MyBBTTxicj4NCiZndDsmZ3Q7IFRvOiBSYWtlc2ggR2Fu ZGhpIChyZ2FuZGhpKTxicj4NCiZndDsmZ3Q7IENjOiB6aGFuZy5mZWkzQHp0ZS5jb20uY247IGpp bmdycUBjdGJyaS5jb20uY248YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yPGJyPg0KJmd0OyBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4 dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsPGJyPg0KJmd0OyBkcmFmdC1pZXRmLWNjYW1w LW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQ8YnI+DQomZ3Q7Jmd0OyBo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJha2VzaCBHYW5kaGkgYW5kIHBvc3Rl ZCB0bw0KdGhlPGJyPg0KJmd0OyBJRVRGIHJlcG9zaXRvcnkuPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBGaWxlbmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgJm5ic3A7ZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRw LXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3A8YnI+DQomZ3Q7Jmd0OyBSZXZpc2lvbjogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 MDQ8YnI+DQomZ3Q7Jmd0OyBUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUlNWUC1URQ0KRXh0ZW5zaW9ucyBmb3I8YnI+ DQomZ3Q7IEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1BzPGJyPg0KJmd0OyZndDsgQ3JlYXRp b24gZGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7MjAxMi0wOC0xNTxicj4NCiZndDsmZ3Q7IFdHIElEOiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjY2Ft cDxicj4NCiZndDsmZ3Q7IE51bWJlciBvZiBwYWdlczogMTc8YnI+DQomZ3Q7Jmd0OyBVUkw6ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2 cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQ8YnI+DQomZ3Q7Jmd0OyBTdGF0dXM6ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgJm5ic3A7aHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lh dGVkLWxzcDxicj4NCiZndDsmZ3Q7IEh0bWxpemVkOiAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4N CiZndDsgJm5ic3A7aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1t cGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQ8YnI+DQomZ3Q7Jmd0OyBEaWZmOiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyAmbmJzcDtodHRwOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRl LWV4dC1hc3NvY2lhdGVkLWxzcC0wNDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQWJzdHJh Y3Q6PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO1RoZSBNUExTIFRyYW5zcG9ydCBQcm9maWxl IChNUExTLVRQKSByZXF1aXJlbWVudHMNCmRvY3VtZW50IFtSRkM1NjU0XSw8YnI+DQomZ3Q7Jmd0 OyAmbmJzcDsgJm5ic3A7ZGVzY3JpYmVzIHRoYXQgTVBMUy1UUCBNVVNUIHN1cHBvcnQgYXNzb2Np YXRlZCBiaWRpcmVjdGlvbmFsDQpwb2ludC08YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7dG8t cG9pbnQgTFNQcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtUaGlz IGRvY3VtZW50IHByb3ZpZGVzIGEgbWV0aG9kIHRvIGJpbmQgdHdvIHVuaWRpcmVjdGlvbmFsDQpM YWJlbDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtTd2l0Y2hlZCBQYXRocyAoTFNQcykgaW50 byBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwNCkxTUC4gJm5ic3A7VGhlPGJyPg0KJmd0OyZn dDsgJm5ic3A7ICZuYnNwO2Fzc29jaWF0aW9uIGlzIGFjaGlldmVkIGJ5IGRlZmluaW5nIHRoZSBu ZXcgQXNzb2NpYXRpb24NClR5cGUgaW4gdGhlPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO0V4 dGVuZGVkIEFTU09DSUFUSU9OIG9iamVjdC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRo ZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IENDQU1Q IG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IENDQU1QQGlldGYub3JnPGJyPg0KJmd0OyZndDsg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgQ0NB TVAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBDQ0FNUEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4NCiZndDsgPGJyPg0KJmd0 OyA8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 0005B57748257A67_=-- From internet-drafts@ietf.org Sun Aug 26 23:34:39 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E3F21F8577; Sun, 26 Aug 2012 23:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wA3lq3OrEciU; Sun, 26 Aug 2012 23:34:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3AC21F84F9; Sun, 26 Aug 2012 23:34:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120827063408.2608.16578.idtracker@ietfa.amsl.com> Date: Sun, 26 Aug 2012 23:34:08 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 06:34:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Signa= ling Extensions for the evolving G.709 Optical Transport Networks Control Author(s) : Fatai Zhang Guoying Zhang Sergio Belotti Daniele Ceccarelli Khuzema Pithewan Filename : draft-ietf-ccamp-gmpls-signaling-g709v3-04.txt Pages : 26 Date : 2012-08-26 Abstract: Recent progress in ITU-T Recommendation G.709 standardization has introduced new ODU containers (ODU0, ODU4, ODU2e and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. Several recent documents have proposed ways to modify GMPLS signaling protocols to support these new OTN features. It is important that a single solution is developed for use in GMPLS signaling and routing protocols. This solution must support ODUk multiplexing capabilities, address all of the new features, be acceptable to all equipment vendors, and be extensible considering continued OTN evolution. This document describes the extensions to the Generalized Multi- Protocol Label Switching (GMPLS) signaling to control the evolving Optical Transport Networks (OTN) addressing ODUk multiplexing and new features including ODU0, ODU4, ODU2e and ODUflex. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-signaling-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-signaling-g709v3-= 04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhangfatai@huawei.com Sun Aug 26 23:54:53 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9858611E808D for ; Sun, 26 Aug 2012 23:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.621 X-Spam-Level: ** X-Spam-Status: No, score=2.621 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVMP4VwXggQP for ; Sun, 26 Aug 2012 23:54:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1DE11E808A for ; Sun, 26 Aug 2012 23:54:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp01-ep.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id APF00670; Sun, 26 Aug 2012 22:54:52 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 26 Aug 2012 23:48:24 -0700 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 26 Aug 2012 23:48:24 -0700 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.171]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Mon, 27 Aug 2012 14:48:20 +0800 From: Fatai Zhang To: "ccamp@ietf.org" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-04.txt Thread-Index: AQHNhB4vfEEXel7r9ESLyBpsmqpV0JdtNKSQ Date: Mon, 27 Aug 2012 06:48:20 +0000 Message-ID: References: <20120827063408.2608.16578.idtracker@ietfa.amsl.com> In-Reply-To: <20120827063408.2608.16578.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.232] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "zhangguoying@mail.ritt.com.cn" , "sergio.belotti@alcatel-lucent.it" Subject: [CCAMP] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2Nh?= =?gb2312?b?bXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNC50eHQ=?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 06:54:53 -0000 SGkgYWxsLA0KDQpBIG5ldyB2ZXJzaW9uIGhhcyBiZWVuIHVwbG9hZGVkLiBNYWpvciB1cGRhdGVz Og0KDQoxKSBSZW1vdmVkIEhpZXJhcmNoeSBzdHVmZiBpbiBTZWN0aW9uIDcgYXMgd2UgYWdyZWVk Lg0KMikgVXBkYXRlZCBDUCBCYWNrd2FyZCBDb21wYXRpYmlsaXR5IENvbnNpZGVyYXRpb25zIGFz IExvdSBzdWdnZXN0ZWQuDQozKSBTb21lIGRlc2NyaXB0aW9uIGluY2x1ZGluZyBjb25mb3JtYW5j ZSBsYW5ndWFnZSB3YXMgcmVmaW5lZC4gDQoNClBsZWFzZSByZXZpZXcgZm9yIGRldGFpbHMuDQoN Cg0KDQpCZXN0IFJlZ2FyZHMNCg0KRmF0YWkNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7I yzogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmdd ILT6se0gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQq3osvNyrG85DogMjAxMsTqONTCMjfI1SAx NDozNA0KytW8/sjLOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCrOty806IGNjYW1wQGlldGYub3Jn DQrW98ziOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFs aW5nLWc3MDl2My0wNC50eHQNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRyb2wgYW5kIE1lYXN1cmVtZW50IFBs YW5lIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNCglUaXRsZSAgICAgICAgICAgOiBHZW5l cmFsaXplZCBNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKEdNUExTKSBTaWduYWxpbmcg RXh0ZW5zaW9ucyBmb3IgdGhlIGV2b2x2aW5nIEcuNzA5IE9wdGljYWwgVHJhbnNwb3J0IE5ldHdv cmtzIENvbnRyb2wNCglBdXRob3IocykgICAgICAgOiBGYXRhaSBaaGFuZw0KICAgICAgICAgICAg ICAgICAgICAgICAgICBHdW95aW5nIFpoYW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgIFNl cmdpbyBCZWxvdHRpDQogICAgICAgICAgICAgICAgICAgICAgICAgIERhbmllbGUgQ2VjY2FyZWxs aQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBLaHV6ZW1hIFBpdGhld2FuDQoJRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0LnR4dA0K CVBhZ2VzICAgICAgICAgICA6IDI2DQoJRGF0ZSAgICAgICAgICAgIDogMjAxMi0wOC0yNg0KDQpB YnN0cmFjdDoNCiAgIFJlY2VudCBwcm9ncmVzcyBpbiBJVFUtVCBSZWNvbW1lbmRhdGlvbiBHLjcw OSBzdGFuZGFyZGl6YXRpb24gaGFzDQogICBpbnRyb2R1Y2VkIG5ldyBPRFUgY29udGFpbmVycyAo T0RVMCwgT0RVNCwgT0RVMmUgYW5kIE9EVWZsZXgpIGFuZA0KICAgZW5oYW5jZWQgT3B0aWNhbCBU cmFuc3BvcnQgTmV0d29ya2luZyAoT1ROKSBmbGV4aWJpbGl0eS4gU2V2ZXJhbA0KICAgcmVjZW50 IGRvY3VtZW50cyBoYXZlIHByb3Bvc2VkIHdheXMgdG8gbW9kaWZ5IEdNUExTIHNpZ25hbGluZw0K ICAgcHJvdG9jb2xzIHRvIHN1cHBvcnQgdGhlc2UgbmV3IE9UTiBmZWF0dXJlcy4NCg0KICAgSXQg aXMgaW1wb3J0YW50IHRoYXQgYSBzaW5nbGUgc29sdXRpb24gaXMgZGV2ZWxvcGVkIGZvciB1c2Ug aW4gR01QTFMNCiAgIHNpZ25hbGluZyBhbmQgcm91dGluZyBwcm90b2NvbHMuIFRoaXMgc29sdXRp b24gbXVzdCBzdXBwb3J0IE9EVWsNCiAgIG11bHRpcGxleGluZyBjYXBhYmlsaXRpZXMsIGFkZHJl c3MgYWxsIG9mIHRoZSBuZXcgZmVhdHVyZXMsIGJlDQogICBhY2NlcHRhYmxlIHRvIGFsbCBlcXVp cG1lbnQgdmVuZG9ycywgYW5kIGJlIGV4dGVuc2libGUgY29uc2lkZXJpbmcNCiAgIGNvbnRpbnVl ZCBPVE4gZXZvbHV0aW9uLg0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgZXh0ZW5z aW9ucyB0byB0aGUgR2VuZXJhbGl6ZWQgTXVsdGktDQogICBQcm90b2NvbCBMYWJlbCBTd2l0Y2hp bmcgKEdNUExTKSBzaWduYWxpbmcgdG8gY29udHJvbCB0aGUgZXZvbHZpbmcNCiAgIE9wdGljYWwg VHJhbnNwb3J0IE5ldHdvcmtzIChPVE4pIGFkZHJlc3NpbmcgT0RVayBtdWx0aXBsZXhpbmcgYW5k IG5ldw0KICAgZmVhdHVyZXMgaW5jbHVkaW5nIE9EVTAsIE9EVTQsIE9EVTJlIGFuZCBPRFVmbGV4 Lg0KDQoNCg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRy YWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jY2Ft cC1nbXBscy1zaWduYWxpbmctZzcwOXYzDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNp b24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j Y2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTA0DQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91 cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wNA0KDQoNCkludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo= From zhangfatai@huawei.com Mon Aug 27 02:04:57 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC5021F8554 for ; Mon, 27 Aug 2012 02:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.627 X-Spam-Level: ** X-Spam-Status: No, score=2.627 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwxGIG1fh9qj for ; Mon, 27 Aug 2012 02:04:57 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6582B21F8526 for ; Mon, 27 Aug 2012 02:04:57 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id APP00632; Mon, 27 Aug 2012 01:04:57 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 27 Aug 2012 02:01:57 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 27 Aug 2012 02:01:59 -0700 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.171]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Mon, 27 Aug 2012 17:01:52 +0800 From: Fatai Zhang To: Lou Berger Thread-Topic: =?gb2312?B?W0NDQU1QXSC08Li0OiAgSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1n?= =?gb2312?Q?mpls-g709-framework-09.txt?= Thread-Index: AQHNg5Ydfubt4uGAoUiUCd1OkqebNZdtXeSA Date: Mon, 27 Aug 2012 09:01:51 +0000 Message-ID: References: <20120825072629.29132.33058.idtracker@ietfa.amsl.com> <503A30E4.8040109@labn.net> In-Reply-To: <503A30E4.8040109@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.232] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogILTwuLQ6ICBJLUQgQWN0aW9uOiBkcmFmdC1p?= =?gb2312?b?ZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTA5LnR4dA==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:04:58 -0000 SGkgTG91LA0KDQpUaGFua3MuIFdlIGFyZSBmb2xsb3dpbmcgeW91ciBzdWdnZXN0aW9uLg0KDQoN Cg0KDQoNCkJlc3QgUmVnYXJkcw0KDQpGYXRhaQ0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8 /sjLOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQq3osvNyrG85DogMjAx MsTqONTCMjbI1SAyMjoyMQ0KytW8/sjLOiBGYXRhaSBaaGFuZw0Ks63LzTogY2NhbXBAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmcN Ctb3zOI6IFJlOiBbQ0NBTVBdILTwuLQ6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtZzcwOS1mcmFtZXdvcmstMDkudHh0DQoNCkZhdGFpL0FsbCwNCglUaGFua3MgZm9yIHRoZSB1 cGRhdGUuIEkgYmVsaWV2ZSB3ZSBtZW50aW9uZWQgdGhlIGRlc2lyZSB0byBMQyB0aGUNCnJvdXRp bmcgYW5kIHNpZ25hbGluZyBkb2N1bWVudHMgdG9nZXRoZXIgd2l0aCB0aGlzIGRvY3VtZW50LiBI b3BlZnVsbHkNCnRoZXknbGwgYmUgdXBkYXRlZCBzb29uIHRvby4NCg0KTG91DQoNCk9uIDgvMjUv MjAxMiAzOjMzIEFNLCBGYXRhaSBaaGFuZyB3cm90ZToNCj4gVGhlIGF1dGhvcnMgdGhpbmsgdGhh dCB0aGlzIGRyYWZ0IHNob3VsZCBiZSByZWFkeSBmb3IgTEMuDQo= From internet-drafts@ietf.org Mon Aug 27 02:53:13 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5625A21F853E; Mon, 27 Aug 2012 02:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlQF11jwx+k6; Mon, 27 Aug 2012 02:53:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38AD21F8471; Mon, 27 Aug 2012 02:53:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120827095312.30361.8733.idtracker@ietfa.amsl.com> Date: Mon, 27 Aug 2012 02:53:12 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:53:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Traffic Engineering Extensions to OSPF for Generalized M= PLS (GMPLS) Control of Evolving G.709 OTN Networks Author(s) : Daniele Ceccarelli Diego Caviglia Fatai Zhang Dan Li Sergio Belotti Pietro Vittorio Grandi Rajan Rao Khuzema Pithewan John E Drake Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-03.txt Pages : 32 Date : 2012-08-27 Abstract: The recent revision of ITU-T Recommendation G.709 [G709-V3] has introduced new fixed and flexible ODU containers, enabling optimized support for an increasingly abundant service mix. This document describes OSPF routing protocol extensions to support Generalized MPLS (GMPLS) control of all currently defined ODU containers, in support of both sub-lambda and lambda level routing granularity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From daniele.ceccarelli@ericsson.com Mon Aug 27 02:59:15 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B3F21F85C3 for ; Mon, 27 Aug 2012 02:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=1.867, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF3lNGid1Bmn for ; Mon, 27 Aug 2012 02:59:15 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 937D221F8625 for ; Mon, 27 Aug 2012 02:59:14 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-f8-503b44f14d53 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 60.67.11467.1F44B305; Mon, 27 Aug 2012 11:59:13 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.2.59]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 27 Aug 2012 11:59:13 +0200 From: Daniele Ceccarelli To: "ccamp@ietf.org" , Lou Berger Date: Mon, 27 Aug 2012 11:59:12 +0200 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-03.txt Thread-Index: Ac2EOeIUPLmfS6nBSWOxYQrxQZ5jfgAAE2nQ Message-ID: References: <20120827095312.30361.8733.idtracker@ietfa.amsl.com> In-Reply-To: <20120827095312.30361.8733.idtracker@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre5HF+sAg5mLVCyezLnBYtHR/JbF gcljyZKfTB4fNjWzBTBFcdmkpOZklqUW6dslcGXsunOZreCbcMXXUy3MDYwt/F2MnBwSAiYS ez//ZoKwxSQu3FvP1sXIxSEkcIpRoq/hAjNIQkhgDqPExnWZXYwcHGwCVhJPDvmAhEUEXCT6 t5xlBLFZBFQl5t9bAFYuLOAlMXHvJXaIGm+JZW+eM0PYRhJbu1aC7eIVCJdY3DydFWK8g8TF KSdZQGxOAUeJ49vusoHYjAKyEhN2LwKbzywgLnHryXyoOwUkluw5zwxhi0q8fPyPFaJeRuLX pm+sEPV6EjemTmGDsLUlli18zQyxV1Di5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxSicm5iZ k15uqJdalJlcXJyfp1ecuokRGCEHt/zW3cF46pzIIUZpDhYlcV6upP3+QgLpiSWp2ampBalF 8UWlOanFhxiZODilGhhz3Ix2evdzWnXzPA58eEqEu2Jil6hbFucsJbWS3LbfC4yqTdc4WawS u2s1uSF2s+UWk+nSM223yIsKmEjvNF7ddnCOUu3T51OChfUuL+gMC62RUlcwctjBucWs7rp0 XGZaf2quaOHtVlW9R3w/qpf1uMnYzgs3iWQ9qXfr59KOZcZFTKseKrEUZyQaajEXFScCAANi x/5eAgAA Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:59:15 -0000 ...and with the OSPF draft all of them have been updated (fwk+signaling+r= outing). Please note that also the info-model one is part of the OTN drafts ready fo= r LC. Having the 4 of them last called together or FWK+INFO at round 1 and = OSPF+RSVP later is the same for me...as you prefer from an administrative p= oint of view. BR Daniele >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 >On Behalf Of internet-drafts@ietf.org >Sent: luned=EC 27 agosto 2012 11.53 >To: i-d-announce@ietf.org >Cc: ccamp@ietf.org >Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-03.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the Common Control and=20 >Measurement Plane Working Group of the IETF. > > Title : Traffic Engineering Extensions to=20 >OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709=20 >OTN Networks > Author(s) : Daniele Ceccarelli > Diego Caviglia > Fatai Zhang > Dan Li > Sergio Belotti > Pietro Vittorio Grandi > Rajan Rao > Khuzema Pithewan > John E Drake > Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-03.txt > Pages : 32 > Date : 2012-08-27 > >Abstract: > The recent revision of ITU-T Recommendation G.709 [G709-V3] has > introduced new fixed and flexible ODU containers, enabling optimized > support for an increasingly abundant service mix. > > This document describes OSPF routing protocol extensions to support > Generalized MPLS (GMPLS) control of all currently defined ODU > containers, in support of both sub-lambda and lambda level routing > granularity. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-03 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp >= From lberger@labn.net Mon Aug 27 12:12:28 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3273421F851E for ; Mon, 27 Aug 2012 12:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.378 X-Spam-Level: X-Spam-Status: No, score=-99.378 tagged_above=-999 required=5 tests=[AWL=0.783, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJ4ksJMLQN3m for ; Mon, 27 Aug 2012 12:12:27 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 9264121F852B for ; Mon, 27 Aug 2012 12:12:27 -0700 (PDT) Received: (qmail 31189 invoked by uid 0); 27 Aug 2012 18:30:35 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 27 Aug 2012 18:30:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=sWp/OxIY04wIiL3IEmzXlT0jjRqFauKraqbAHXPJP0Y=; b=YMR5eVaYSMOi4ex7pGWv5cejB3Uvtk3i3W9OdEtoz0io+cEPTCyrpIlVnzB1An46BAGxg+sDtOckf8HW9eZxVx1mSD8eY3ebLIINJHFDUB08u2aFI8HmVgHVgbaFZL4g; Received: from box313.bluehost.com ([69.89.31.113]:57752 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T6455-0002lT-62; Mon, 27 Aug 2012 12:30:35 -0600 Message-ID: <503BBCC8.1080701@labn.net> Date: Mon, 27 Aug 2012 14:30:32 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:12:28 -0000 Fei, The problem only exists in the double sided provisioing case, so no need to complicate the single sided provisioning case. Lou On 8/26/2012 9:03 PM, zhang.fei3@zte.com.cn wrote: > The administrative > approach can integrate both models, will be a good idea. From db3546@att.com Mon Aug 27 12:19:48 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4C621F854E for ; Mon, 27 Aug 2012 12:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FP8EtHlWLVbs for ; Mon, 27 Aug 2012 12:19:48 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id A52A521F8545 for ; Mon, 27 Aug 2012 12:19:47 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 358cb305.0.356827.00-463.988005.nbfkord-smmo03.seg.att.com (envelope-from ); Mon, 27 Aug 2012 19:19:48 +0000 (UTC) X-MXL-Hash: 503bc85444509cc9-9070091028cb532ecaa886823a9efd699fdf3407 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7RJJkUj028556; Mon, 27 Aug 2012 15:19:47 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7RJJed5028534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2012 15:19:41 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by sflint02.pst.cso.att.com (RSA Interceptor); Mon, 27 Aug 2012 15:19:28 -0400 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0318.001; Mon, 27 Aug 2012 15:19:28 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: Proposed OTN Liaison to ITU-T SG15 Thread-Index: Ac2EiOAijqaw/xIMTy+Ekzakdite+g== Date: Mon, 27 Aug 2012 19:19:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=RWEAq7CW3jcA:10 a=O1CQ54kEHT8A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=fNHMvnHlXtsA:1] X-AnalysisOut: [0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=2bhlq4p] X-AnalysisOut: [WgJrl_keWyRUA:9 a=CjuIK1q_8ugA:10] Subject: [CCAMP] Proposed OTN Liaison to ITU-T SG15 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:19:48 -0000 CCAMP, Here's a proposed OTN liaison to SG15's Q9, Q11, Q12, and Q14 responding to= their liaisons. Let us know if any comments by end of week. Deborah and Lou ------- Title: Current Status of OTN Work The CCAMP Working Group of IETF would like to thank you for your liaisons r= elated to OTN. We would like to inform you that we are preparing for Workin= g Group Last Call the following documents related to OTN: http://www.ietf.org/id/draft-ietf-ccamp-gmpls-g709-framework-09.txt http://www.ietf.org/id/draft-ietf-ccamp-otn-g709-info-model-04.txt http://www.ietf.org/id/draft-ietf-ccamp-gmpls-ospf-g709v3-03.txt http://www.ietf.org/id/draft-ietf-ccamp-gmpls-signaling-g709v3-04.txt We welcome any comments that you may have on these documents, either via Li= aison or on the CCAMP mailing list (https://www.ietf.org/mailman/listinfo/c= camp). As we are actively working on these documents, please check for the = latest revision. We look forward to continuing our cooperative relationship= with you on these topics. From db3546@att.com Mon Aug 27 12:27:05 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B790521F8517 for ; Mon, 27 Aug 2012 12:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kIN2YJadKEy for ; Mon, 27 Aug 2012 12:27:05 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id EE24221F8510 for ; Mon, 27 Aug 2012 12:27:04 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 80acb305.0.39269.00-486.111907.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 27 Aug 2012 19:27:04 +0000 (UTC) X-MXL-Hash: 503bca085d2d5549-14b3178c4db35774f915a7df4071f65d394b55fe Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7RJR203026337; Mon, 27 Aug 2012 12:27:03 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7RJQnTV025995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2012 12:26:50 -0700 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by fflint04.pst.cso.att.com (RSA Interceptor); Mon, 27 Aug 2012 12:26:32 -0700 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0318.001; Mon, 27 Aug 2012 15:26:28 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: Proposed WSON Liaison to ITU-T SG15 Thread-Index: Ac2Eidp5aWEYigq6RVi3Ud7Q2Hf3DQ== Date: Mon, 27 Aug 2012 19:26:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=RWEAq7CW3jcA:10 a=50M8nx4tWPUA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=7KC3GS_3nJ4A:1] X-AnalysisOut: [0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a=bUPMkNnsSacXKyLhNNQA:9 a] X-AnalysisOut: [=CjuIK1q_8ugA:10] Subject: [CCAMP] Proposed WSON Liaison to ITU-T SG15 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:27:05 -0000 CCAMP, Here's a proposed WSON liaison to SG15's Q6, Q12, and Q14 responding to the= ir Liaisons. Let us know if any comments by end of week. Deborah and Lou --- Title: WSON and Flexible Grids The CCAMP Working Group of IETF would like to thank you for your liaison on= Flexible Grids and the updates on your work. We have taken your work into = consideration and we are continuing to progress our work. At this time, it = is still in a very early phase. We would appreciate if you would keep us in= formed of your progress in this area. In addition, we would like to inform you that we are enhancing our work on = WSON with respect to management aspects. We would appreciate if you would k= eep us informed of your progress in this area. Best regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs From rgandhi@cisco.com Mon Aug 27 14:16:44 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6C621F849A for ; Mon, 27 Aug 2012 14:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJ6OpBY9P9OU for ; Mon, 27 Aug 2012 14:16:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 30D8421F845A for ; Mon, 27 Aug 2012 14:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10381; q=dns/txt; s=iport; t=1346102203; x=1347311803; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SewOexAG1omp3rJiRLcf/HWTeSWnKRuhCvWxC/mL3fY=; b=jRUUzJ7wPjvTfkI8d6TIU8+pZn6jfdhwbSEHdpoA3SPl4YmZPtUVAsiN 40RAkK833umEAu1wDc7UVBl+wbb85HRsPyAhI8CRZbspYVf5QZdHLNU6W XTNm7/HU7AQENgCu7/ogEkLzWvjvVJout0G+n1jzWmQE3LtZjfK7LpG3j U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAP7iO1CtJV2c/2dsb2JhbABFunyBB4IgAQEBAwEBAQEPASc0BAcFBwQCAQgOAwQBAQEKFAUEBycLFAkIAgQOBQgBEgeHZQYLmk+gJ4VghSgahV9gA5ZpjRqBZ4JjgWE X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="112747492" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 27 Aug 2012 21:16:42 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7RLGghC013824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Aug 2012 21:16:42 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Mon, 27 Aug 2012 16:16:42 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger Thread-Topic: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac2BSy6dKWryoN3/QKaPbjEu2q9iwwBAF9gAAAmySlD//+CQAIAAS+fwgAJxX4D//lFBwA== Date: Mon, 27 Aug 2012 21:16:41 +0000 Message-ID: References: <5037C010.7010605@labn.net> <5037E6C4.5050507@labn.net> <503A3309.4020907@labn.net> In-Reply-To: <503A3309.4020907@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.244.173] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--63.754000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 21:16:44 -0000 Thanks Lou. Let me propose revised texts for section 3.2.6 [item 7], 3.2.7 [item 8] and= 4.1 [items 1,2,3,6].=09 Regards, Rakesh -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Sunday, August 26, 2012 10:31 AM To: Rakesh Gandhi (rgandhi) Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp= -rsvpte-ext-associated-lsp-04.txt Rakesh, See below (using normal reply notation)... On 8/24/2012 5:18 PM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, >=20 > Please see inline.... >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, August 24, 2012 4:41 PM > To: Rakesh Gandhi (rgandhi) > Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn > Subject: Re: [CCAMP] Review Request For Changes in=20 > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >=20 > Rakesh, >=20 > See below. >=20 > On 8/24/2012 2:31 PM, Rakesh Gandhi (rgandhi) wrote: >> Hi Lou, >> >> Thanks for your review. Please see inline.... >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, August 24, 2012 1:55 PM >> To: Rakesh Gandhi (rgandhi) >> Cc: ccamp@ietf.org >> Subject: Re: [CCAMP] Review Request For Changes in=20 >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> Rakesh, >> >> Speaking as a WG participant, and ignoring changes 4 and 5 as you plan t= o revert these: >> >> On 8/23/2012 12:20 PM, Rakesh Gandhi (rgandhi) wrote: >>> Dear WG, >>> >>> We like to request a review from the WG on the changes in version 04 of= the draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp compared to version= 03.=20 >>> >>> The majority of the proposed changes are around the format and how to p= opulate the extended association object as listed below. >>> >>> Note: Based on the feedbacks received so far, changes for items 4 and 5= below will be reverted. >>> >>> 1. Association-ID: >>> It was not clear from reading the version 03 of the draft how this fiel= d is populated in the extended association object. New version 04 proposes = to populate this field from the locally provisioned value. As this value is= identically provisioned on both ends, it provides a field to tie the two (= forward and reverse) LSPs on end-points. >>> >> >>> 2. IPv4 association source: >>> New version 04 adds a tie breaker rule for double sided provisioned LSP= s. >>> >>> 3. Global association source: >>> New version clarifies the usage for this field siting information from = RFC6370 and other mentioned drafts. No new rule added. >>> >> >> [4 and 5 removed form mail as to be reverted] >> >>> >>> 6. Extended Association ID (Address): >>> New version 04 proposes to use an IP address as extended association ID= (address) as an additional identifier. Previous version 03 defines a varia= ble length field but did not mention what parameters can be added there. >>> A tie breaker rule is defined for double sided provisioned value. >>> >> >> Assuming changes 1, 2, and 6, how is uniqueness (of the association=20 >> ID >> field) guaranteed? >> >> 1, 2 and 6 together uniquely = represent a bidirectional LSPs in a network. In this proposal association I= D can be shared by multiple tunnels on the same source node. >> >=20 > Sure, but who picks the association-id such that uniqueness is assured in= the double sided provisioning case? >=20 > If assuming this is always provisioned, then how does the provisioning=20 > entity, which may be one or more people at a CLI, pick the=20 > association-id such that it is unique across the tuple=20 > ? (neither a single provision device=20 > nor polling the ingress and egress are really reasonable solutions.) >=20 > Wouldn't it be better for the Association Source and Association ID to=20 > be administratively set? e.g., to the IP address and value selected by=20 > the provisioning source. (Extended Association ID could also be used=20 > if desired, but I'm not sure it really adds value.) >=20 > Sure, association-id and association-source can be set administrati= vely or by any other means (we can reword the draft). Idea here is that for= double sided provisioned LSPs, they need to have the same values, so both = sides can glue the matching LSPs. >=20 I think we agree on the objective, now we just need some words to achieve i= t. (I.e., whatever text is specified, it must support a viable approach to = ensuring uniqueness, i.e., no collision.) So, care to try again on proposi= ng such language? >=20 >=20 >> >>> 7. Path Protection object: >>> Version 03 of the draft vaguely mentioned and assumed of using protecti= on object for path protection. New version 04 adds some texts to clarify it= , no new rule is added. >>> >> >> I think providing informative text on interactions of this document with= the various defined recovery (4872 and 4872) and reroute (4090) mechanisms= is a really good idea. That said, I found this section a bit opaque. Ign= oring the wordsmithing, what specific points are you trying to make? >> >> It just highlights that for a bi-directional tunnel, there can be a= working bidirectional LSPs and protecting bidirectional LSPs. That's all. >> >=20 > I think the proposed text is really confusing and doesn't cover the=20 > full scope (in particular 4872 is about recovery which is both=20 > protection and restoration, it doesn't cover 4873 or 4090). Can you=20 > propose (one the > list) some alternate text? >=20 > Idea here is that there are multiple bidirectional LSPs for a tunne= l for different LSP roles. We could remove the LSP type as primary and seco= ndary reference from the text, and just state LSPs for different roles. >=20 Again, I think the issue is with the proposed language. >> >>> 8. Auto-tunnel mesh: >>> New version 04 adds a section to elaborate on a use case for auto-tunne= l mesh. This is added as an FYI and can be removed if WG thinks so. >>> >> >> How is the association id field value selected in this case? >> >> Proposal allows that single association-id can be provisioned for a= mesh-group.=20 > I don't think you have text that supports this. The closest you come is: > A node provisioned to > build a mesh of associated bidirectional LSPs may use identical > association ID for the given mesh-group member peers. >=20 > which doesn't say that the "identical association ID" MUST be provisioned= . >=20 > Yes, we can clarify this. >=20 Great! Lou > Thanks, > Rakesh >=20 > Lou >=20 >>> So when a node initiates multiple auto-tunnels in a mesh-group, as per = previous definition, a tunnel can be uniquely identified with , i.e. extended association object. >> >=20 >=20 >=20 >> >>> 9. Clarification for Inter-AS LSPs: >>> I believe there was an email exchange between Lou and Fei to clarify th= e relationship with draft I-D, draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-= num. A section is added in version-04 to address this. Please review the ad= ded text. >>> >> >> Well I (as chair) had asked in Vancouver that the authors of rsvpte-ext-= tunnel-num propose some language *on the list* that would merge the functio= nality defined in that document into the WG document. >> The mailing list discussion concluded with Fei stating that he want to k= eep the drafts separate, which certainly is his call (as one is an individu= al draft). So to be clear, I have not requested any references to rsvpte-e= xt-tunnel-num in the WG draft. >> >> This section does highlight the issue of how remote global_ID can be lea= rned in the interdomain case. I think the stated solution doesn't work wit= h your current assignment approach, e.g., consider the case when the lower = IP address is the egress of the initial LSP... >> >> I will let Fei address this comment. >> >> Thanks, >> Rakesh >> >> >> Lou >> >> >>> Please advise us on above changes. Based on the consensus, we will upda= te the draft accordingly. >>> >>> Thanks, >>> Rakesh >>> =20 >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Wednesday, August 15, 2012 10:53 AM >>> To: Rakesh Gandhi (rgandhi) >>> Cc: zhang.fei3@zte.com.cn; jingrq@ctbri.com.cn >>> Subject: New Version Notification for=20 >>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>> >>> >>> A new version of I-D, >>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >>> has been successfully submitted by Rakesh Gandhi and posted to the IETF= repository. >>> >>> Filename: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp >>> Revision: 04 >>> Title: RSVP-TE Extensions for Associated Bidirectional LSPs >>> Creation date: 2012-08-15 >>> WG ID: ccamp >>> Number of pages: 17 >>> URL: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-m= pls-tp-rsvpte-ext-associated-lsp-04.txt >>> Status: http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-= tp-rsvpte-ext-associated-lsp >>> Htmlized: http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rs= vpte-ext-associated-lsp-04 >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mp= ls-tp-rsvpte-ext-associated-lsp-04 >>> >>> Abstract: >>> The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654]= , >>> describes that MPLS-TP MUST support associated bidirectional point- >>> to-point LSPs. >>> >>> This document provides a method to bind two unidirectional Label >>> Switched Paths (LSPs) into an associated bidirectional LSP. The >>> association is achieved by defining the new Association Type in the >>> Extended ASSOCIATION object. >>> >>> = =20 >>> >>> >>> The IETF Secretariat >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> >> >> >> >> >=20 >=20 >=20 >=20 From zhang.fei3@zte.com.cn Mon Aug 27 19:20:50 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502A811E8099 for ; Mon, 27 Aug 2012 19:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.916 X-Spam-Level: X-Spam-Status: No, score=-96.916 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTkVesifo9UP for ; Mon, 27 Aug 2012 19:20:49 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9BC11E808E for ; Mon, 27 Aug 2012 19:20:48 -0700 (PDT) Received: from [192.168.168.119] by mx5.zte.com.cn with surfront esmtp id 10723473195744; Tue, 28 Aug 2012 10:04:46 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 515F076C0FD; Tue, 28 Aug 2012 10:16:29 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q7S2KcuW094379; Tue, 28 Aug 2012 10:20:38 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <503BBCC8.1080701@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: 60768B2E:0B179745-48257A68:000CB1F8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 28 Aug 2012 10:20:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-28 10:20:36, Serialize complete at 2012-08-28 10:20:36 Content-Type: multipart/alternative; boundary="=_alternative 000CC8D248257A68_=" X-MAIL: mse01.zte.com.cn q7S2KcuW094379 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 02:20:50 -0000 This is a multipart message in MIME format. --=_alternative 000CC8D248257A68_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhhbmsgeW91IGxvdQ0KDQpIb3cgYWJvdXQgY2hhbmdpbmcgdGhlIGRlc2NyaXB0aW9ucyBpbiBw YXJhZ3JhcGggMy4yLjgNCg0KICAgSW4gc29tZSBzY2VuYXJpb3MsIGEgbm9kZSB0aGF0IGlzIHRo ZSBhc3NvY2lhdGlvbiBzb3VyY2UgTUFZIG5lZWQgdG8NCiAgIGxlYXJuIGFib3V0IHRoZSBHbG9i YWxfSUQgW1JGQzYzNzBdIG9mIHRoZSBwZWVyIG5vZGUsIHdoaWNoIGNhbiBiZQ0KICAgZG9uZSBi eSBpbnNlcnRpbmcgdGhlIEFTU09DSUFUSU9OIG9iamVjdCB3aXRoIEFzc29jaWF0aW9uIFR5cGUg IkxTUA0KICAgaWRlbnRpZmllcnMiIGluIHRoZSBvdXRnb2luZyBQYXRoIG1lc3NhZ2UgYW5kIGJl aW5nIGNhcnJpZWQgYmFjayBpbg0KICAgdGhlIFJlc3YgbWVzc2FnZSwgYXMgZGVmaW5lZCBpbiBb SS1ELCBkcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLQ0KICAgcnN2cHRlLWV4dC10dW5uZWwtbnVt XS4NCg0KaW50bw0KDQogICBJbiBzb21lIHNjZW5hcmlvcywgYSBub2RlIHRoYXQgaXMgdGhlIGFz c29jaWF0aW9uIHNvdXJjZSBNQVkgbmVlZCB0bw0KICAgbGVhcm4gYWJvdXQgdGhlIEdsb2JhbF9J RCBbUkZDNjM3MF0gb2YgdGhlIHBlZXIgbm9kZS4gQWx0aG91Z2ggdGhlDQogICBzY29wZSBvZiB0 aGUgZHJhZnQgW0ktRCwgDQpkcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVu bmVsLW51bV0NCiAgIGlzIGxpbWl0ZWQgdG8gdGhlIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExT UCwgdGhlIGRlZmluZWQgcHJvY2VkdXJlcyANCmNhbg0KICAgYmUgcmV1c2VkIGhlcmUgYWxzby4g VGhlIEFTU09DSUFUSU9OIG9iamVjdCB3aXRoIEFzc29jaWF0aW9uIFR5cGUgIkxTUA0KICAgSWRl bnRpZmllcnMiIGlzIGluc2VydGVkIGluIHRoZSBvdXRnb2luZyBQYXRoIG1lc3NhZ2UgYXQgdGhl IA0KYXNzb2NpYXRpb24NCiAgIHNvdXJjZSBhbmQgY2FycmllZCBiYWNrIGluIHRoZSBjb3JyZXNw b25kaW5nIFJlc3YgbWVzc2FnZS4gQWxsIHRoZSANCmZpZWxkcw0KICAgb2YgdGhlIEFTU09DSUFU SU9OIG9iamVjdCBleGNlcHQgdGhlIEFzc29jaWF0aW9uIFR5cGUgaW4gdGhlIFBhdGggDQptZXNz YWdlDQogICBjYW4gYmUgaWdub3JlZCBieSB0aGUgcmVjZWl2ZXIgYW5kIHRoZSBHbG9iYWxfSUQg b2YgdGhlIHBlZXIgbm9kZSBpcyANCnB1c2hlZA0KICAgaW50byB0aGUgZmllbGQgb2YgdGhlIEds b2JhbCBBc3NvY2lhdGlvbiBTb3VyY2UgaW4gdGhlIFJlc3YgbWVzc2FnZS4NCg0KQmVzdCByZWdh cmRzDQoNCkZlaQ0KDQoNCg0KTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gDQoyMDEyLTA4 LTI4IDAyOjMwDQoNCsrVvP7Iyw0KemhhbmcuZmVpM0B6dGUuY29tLmNuDQqzrcvNDQoiY2NhbXBA aWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4sICJSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSIgDQo8 cmdhbmRoaUBjaXNjby5jb20+DQrW98ziDQpSZTogW0NDQU1QXSBSZXZpZXcgUmVxdWVzdCBGb3Ig Q2hhbmdlcyBpbiANCmRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0 ZWQtbHNwLTA0LnR4dA0KDQoNCg0KDQoNCg0KRmVpLA0KICAgICAgICAgICAgICAgICBUaGUgcHJv YmxlbSBvbmx5IGV4aXN0cyBpbiB0aGUgZG91YmxlIHNpZGVkIHByb3Zpc2lvaW5nIA0KY2FzZSwg c28gbm8NCm5lZWQgdG8gY29tcGxpY2F0ZSB0aGUgc2luZ2xlIHNpZGVkIHByb3Zpc2lvbmluZyBj YXNlLg0KDQpMb3UNCg0KDQpPbiA4LzI2LzIwMTIgOTowMyBQTSwgemhhbmcuZmVpM0B6dGUuY29t LmNuIHdyb3RlOg0KPiBUaGUgYWRtaW5pc3RyYXRpdmUNCj4gYXBwcm9hY2ggY2FuIGludGVncmF0 ZSBib3RoIG1vZGVscywgd2lsbCBiZSBhIGdvb2QgaWRlYS4NCg0KDQoNCg== --=_alternative 000CC8D248257A68_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rIHlvdSBsb3U8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhvdyBhYm91dCBjaGFu Z2luZyB0aGUgZGVzY3JpcHRpb25zDQppbiBwYXJhZ3JhcGggMy4yLjg8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtJbiBzb21lIHNj ZW5hcmlvcywgYSBub2RlDQp0aGF0IGlzIHRoZSBhc3NvY2lhdGlvbiBzb3VyY2UgTUFZIG5lZWQg dG88YnI+DQogJm5ic3A7IGxlYXJuIGFib3V0IHRoZSBHbG9iYWxfSUQgW1JGQzYzNzBdIG9mIHRo ZSBwZWVyIG5vZGUsIHdoaWNoIGNhbg0KYmU8YnI+DQogJm5ic3A7IGRvbmUgYnkgaW5zZXJ0aW5n IHRoZSBBU1NPQ0lBVElPTiBvYmplY3Qgd2l0aCBBc3NvY2lhdGlvbiBUeXBlDQomcXVvdDtMU1A8 YnI+DQogJm5ic3A7IGlkZW50aWZpZXJzJnF1b3Q7IGluIHRoZSBvdXRnb2luZyBQYXRoIG1lc3Nh Z2UgYW5kIGJlaW5nIGNhcnJpZWQNCmJhY2sgaW48YnI+DQogJm5ic3A7IHRoZSBSZXN2IG1lc3Nh Z2UsIGFzIGRlZmluZWQgaW4gW0ktRCwgZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC08YnI+DQog Jm5ic3A7IHJzdnB0ZS1leHQtdHVubmVsLW51bV0uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pbnRvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7SW4gc29tZSBzY2VuYXJpb3MsIGEgbm9k ZQ0KdGhhdCBpcyB0aGUgYXNzb2NpYXRpb24gc291cmNlIE1BWSBuZWVkIHRvPGJyPg0KICZuYnNw OyBsZWFybiBhYm91dCB0aGUgR2xvYmFsX0lEIFtSRkM2MzcwXSBvZiB0aGUgcGVlciBub2RlLiBB bHRob3VnaA0KdGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7c2NvcGUgb2YgdGhlIGRyYWZ0IFtJLUQsDQpkcmFmdC16aGFuZy1jY2FtcC1t cGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bV08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtpcyBsaW1pdGVkIHRvIHRoZSBjby1yb3V0ZWQN CmJpZGlyZWN0aW9uYWwgTFNQLCB0aGUgZGVmaW5lZCBwcm9jZWR1cmVzIGNhbjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2JlIHJldXNlZCBo ZXJlIGFsc28uIFRoZQ0KQVNTT0NJQVRJT04gb2JqZWN0IHdpdGggQXNzb2NpYXRpb24gVHlwZSAm cXVvdDtMU1A8YnI+DQogJm5ic3A7IElkZW50aWZpZXJzJnF1b3Q7IGlzIGluc2VydGVkIGluIHRo ZSBvdXRnb2luZyBQYXRoIG1lc3NhZ2UgYXQgdGhlDQphc3NvY2lhdGlvbjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3NvdXJjZSBhbmQgY2Fy cmllZCBiYWNrDQppbiB0aGUgY29ycmVzcG9uZGluZyBSZXN2IG1lc3NhZ2UuIEFsbCB0aGUgZmll bGRzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5i c3A7b2YgdGhlIEFTU09DSUFUSU9OIG9iamVjdA0KZXhjZXB0IHRoZSBBc3NvY2lhdGlvbiBUeXBl IGluIHRoZSBQYXRoIG1lc3NhZ2U8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDtjYW4gYmUgaWdub3JlZCBieSB0aGUgcmVjZWl2ZXINCmFuZCB0 aGUgR2xvYmFsX0lEIG9mIHRoZSBwZWVyIG5vZGUgaXMgcHVzaGVkPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7aW50byB0aGUgZmllbGQgb2Yg dGhlIEdsb2JhbA0KQXNzb2NpYXRpb24gU291cmNlIGluIHRoZSBSZXN2IG1lc3NhZ2UuPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CZXN0IHJlZ2FyZHM8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9u dD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Mb3UgQmVy Z2VyICZsdDtsYmVyZ2VyQGxhYm4ubmV0Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTA4LTI4IDAyOjMwPC9mb250Pg0KPHRkIHdpZHRoPTYz JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnpoYW5nLmZlaTNAenRlLmNvbS5j bjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Y2NhbXBAaWV0Zi5vcmcmcXVvdDsgJmx0O2NjYW1w QGlldGYub3JnJmd0OywNCiZxdW90O1Jha2VzaCBHYW5kaGkgKHJnYW5kaGkpJnF1b3Q7ICZsdDty Z2FuZGhpQGNpc2NvLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbQ0NBTVBdIFJldmll dyBSZXF1ZXN0IEZvciBDaGFuZ2VzDQppbiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRl LWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkZlaSw8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KVGhlIHByb2JsZW0gb25seSBl eGlzdHMgaW4gdGhlIGRvdWJsZSBzaWRlZCBwcm92aXNpb2luZyBjYXNlLCBzbyBubzxicj4NCm5l ZWQgdG8gY29tcGxpY2F0ZSB0aGUgc2luZ2xlIHNpZGVkIHByb3Zpc2lvbmluZyBjYXNlLjxicj4N Cjxicj4NCkxvdTxicj4NCjxicj4NCjxicj4NCk9uIDgvMjYvMjAxMiA5OjAzIFBNLCB6aGFuZy5m ZWkzQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyBUaGUgYWRtaW5pc3RyYXRpdmU8YnI+DQom Z3Q7IGFwcHJvYWNoIGNhbiBpbnRlZ3JhdGUgYm90aCBtb2RlbHMsIHdpbGwgYmUgYSBnb29kIGlk ZWEuPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 000CC8D248257A68_=-- From lberger@labn.net Tue Aug 28 05:47:00 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5C721F853D for ; Tue, 28 Aug 2012 05:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.173 X-Spam-Level: X-Spam-Status: No, score=-98.173 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1EAiNtvncxr for ; Tue, 28 Aug 2012 05:46:59 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id A7DE121F8530 for ; Tue, 28 Aug 2012 05:46:59 -0700 (PDT) Received: (qmail 17993 invoked by uid 0); 28 Aug 2012 12:46:58 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 28 Aug 2012 12:46:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=/L70w/2f+zxH8WZVewYOqb9bJWsvwCXKk/Vb/Nl1nds=; b=dskAjekfP4nfCR/qK5iFn6JmfR+nwDG58THnsNiamULkRaDDXRXICeKCsfgcD7ggVHQdhsU5oNLYHAGmnO8MBdA9CWYTpKSJ+kivk0DPEL0wtD39lv6fqfsqDbwcVHMU; Received: from box313.bluehost.com ([69.89.31.113]:40032 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T6LC6-0003ux-Dm; Tue, 28 Aug 2012 06:46:58 -0600 Message-ID: <503CBDC2.9040308@labn.net> Date: Tue, 28 Aug 2012 08:46:58 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 12:47:00 -0000 Fei, I don't think the text addresses the issue of selection of association object contents in the case of double sided provisioning. How about: - in the case of double sided provisioning *only* 1. Association Source is set to an address selected by the node that originates the association. (which may be a management entity.) 2. Association ID is a value assigned but the node that originates the association. 3. Global Association Source, when used, is set to the Global_ID of the node that originates the association. 4. Extended Association ID, when used, is selected by the node that originates the association. - If either (3) or (4) are used, an Extended ASSOCIATION object [assoc-ext] is used. Otherwise a ASSOCIATION object [rfc4872] is used - while we're at it, in the case of single sided provisioning *only* (note only #1 differs) 1. Association Source is set to an address assigned to the node that originates the LSP. 2. Association ID is a value assigned but the node that originates the association. 3. Global Association Source, when used, is set to the Global_ID of the node that originates the association. 4. Extended Association ID, when used, is selected by the node that originates the association. - If either (3) or (4) are used, an Extended ASSOCIATION object [assoc-ext] is used. Otherwise a ASSOCIATION object [rfc4872] is used I think the above addresses my point as it can be used to ensure unique LSP association in all cases. BTW it also aligns very nicely with the existing definition of the association objects. To address what I suspect is your concern, 3.2.8 can then become something like (feel free to revise): 3.2.8 MPLS-TP Associated Bidirectional LSP Identifiers [RFC6370] defines the LSP associated identifiers based on the signaling parameters of each unidirectional LSP. The combination of each unidirectional LSP's parameters is used to identify the Associated Bidirectional LSP. Using the mechanisms defined in this document, any node that is along the path of both unidirectional LSPs can identify which pair of unidirectional LSPs support an Associated Bidirectional LSP as well as the signaling parameters required by [RFC6370]. Note that the LSP end-points will always be the path of both unidirectional LSPs. Lou On 8/27/2012 10:20 PM, zhang.fei3@zte.com.cn wrote: > > Thank you lou > > How about changing the descriptions in paragraph 3.2.8 > > In some scenarios, a node that is the association source MAY need to > learn about the Global_ID [RFC6370] of the peer node, which can be > done by inserting the ASSOCIATION object with Association Type "LSP > identifiers" in the outgoing Path message and being carried back in > the Resv message, as defined in [I-D, draft-zhang-ccamp-mpls-tp- > rsvpte-ext-tunnel-num]. > > into > > In some scenarios, a node that is the association source MAY need to > learn about the Global_ID [RFC6370] of the peer node. Although the > scope of the draft [I-D, > draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num] > is limited to the co-routed bidirectional LSP, the defined procedures > can > be reused here also. The ASSOCIATION object with Association Type "LSP > Identifiers" is inserted in the outgoing Path message at the association > source and carried back in the corresponding Resv message. All the > fields > of the ASSOCIATION object except the Association Type in the Path > message > can be ignored by the receiver and the Global_ID of the peer node is > pushed > into the field of the Global Association Source in the Resv message. > > Best regards > > Fei > > > *Lou Berger * > > 2012-08-28 02:30 > > > ÊÕ¼þÈË > zhang.fei3@zte.com.cn > ³­ËÍ > "ccamp@ietf.org" , "Rakesh Gandhi (rgandhi)" > > Ö÷Ìâ > Re: [CCAMP] Review Request For Changes in > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > > > > > > > > Fei, > The problem only exists in the double sided provisioing > case, so no > need to complicate the single sided provisioning case. > > Lou > > > On 8/26/2012 9:03 PM, zhang.fei3@zte.com.cn wrote: >> The administrative >> approach can integrate both models, will be a good idea. > > From zhang.fei3@zte.com.cn Tue Aug 28 07:46:36 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EF721F84BF for ; Tue, 28 Aug 2012 07:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.918 X-Spam-Level: X-Spam-Status: No, score=-95.918 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rd4qoRAfpGD1 for ; Tue, 28 Aug 2012 07:46:35 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 90B1D21F84B3 for ; Tue, 28 Aug 2012 07:46:34 -0700 (PDT) Received: from [10.30.3.20] by mx5.zte.com.cn with surfront esmtp id 232552685115152(version=TLSv1/SSLv3 cipher=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA bits=128 verify=NO); Tue, 28 Aug 2012 22:40:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q7SEkJq0072663; Tue, 28 Aug 2012 22:46:19 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <503CBDC2.9040308@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: AEB4A9D3:3FF720E7-48257A68:004FF8E0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 28 Aug 2012 22:46:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-28 22:46:18, Serialize complete at 2012-08-28 22:46:18 Content-Type: multipart/alternative; boundary="=_alternative 00510E0548257A68_=" X-MAIL: mse01.zte.com.cn q7SEkJq0072663 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 14:46:36 -0000 This is a multipart message in MIME format. --=_alternative 00510E0548257A68_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TG91DQoNCi0gaW4gdGhlIGNhc2Ugb2YgZG91YmxlIHNpZGVkIHByb3Zpc2lvbmluZyAqb25seSoN CiAgMS4gQXNzb2NpYXRpb24gU291cmNlIGlzIHNldCB0byBhbiBhZGRyZXNzIHNlbGVjdGVkIGJ5 IHRoZSBub2RlIHRoYXQNCiAgICAgb3JpZ2luYXRlcyB0aGUgYXNzb2NpYXRpb24uICh3aGljaCBt YXkgYmUgYSBtYW5hZ2VtZW50IGVudGl0eS4pDQoNCjxmZWk+IERvIHlvdSBtZWFuIHRoZSBhc3Nv Y2l0aW9uIHNvdXJjZSBjYW4gYmUgbmVpdGhlciBBMSBub3IgWjkgaGVyZT8NCg0KICAzLjIuOCAg TVBMUy1UUCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQIElkZW50aWZpZXJzDQoNCiAgW1JG QzYzNzBdIGRlZmluZXMgdGhlIExTUCBhc3NvY2lhdGVkIGlkZW50aWZpZXJzIGJhc2VkIG9uIHRo ZQ0KICBzaWduYWxpbmcgcGFyYW1ldGVycyBvZiBlYWNoIHVuaWRpcmVjdGlvbmFsIExTUC4gVGhl IGNvbWJpbmF0aW9uDQogIG9mIGVhY2ggdW5pZGlyZWN0aW9uYWwgTFNQJ3MgcGFyYW1ldGVycyBp cyB1c2VkIHRvIGlkZW50aWZ5IHRoZQ0KICBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQLiAg VXNpbmcgdGhlIG1lY2hhbmlzbXMgZGVmaW5lZCBpbg0KICB0aGlzIGRvY3VtZW50LCBhbnkgbm9k ZSB0aGF0IGlzIGFsb25nIHRoZSBwYXRoIG9mIGJvdGgNCiAgdW5pZGlyZWN0aW9uYWwgTFNQcyBj YW4gaWRlbnRpZnkgd2hpY2ggcGFpciBvZiB1bmlkaXJlY3Rpb25hbCBMU1BzDQogIHN1cHBvcnQg YW4gQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUCBhcyB3ZWxsIGFzIHRoZSBzaWduYWxpbmcN CiAgcGFyYW1ldGVycyByZXF1aXJlZCBieSBbUkZDNjM3MF0uICBOb3RlIHRoYXQgdGhlIExTUCBl bmQtcG9pbnRzDQogIHdpbGwgYWx3YXlzIGJlIHRoZSBwYXRoIG9mIGJvdGggdW5pZGlyZWN0aW9u YWwgTFNQcy4NCg0KPEZlaT4gUkZDNjM3MCByZXF1aXJlcyBBMS1nbG9iYWxfSUQgYW5kIFo5LWds b2JhbF9JRCwgaG93IHRvIHB1c2ggdGhlbQ0KaW50byB0aGUgRXh0ZW5kZWQgQVNTT0NJQVRJT04g b2JqZWN0IHdpdGhvdXQgbmV3IEFzc29jaWF0aW9uIHR5cGU/DQogDQpIb3BlIHlvdXIgY2xhcmlm aWNhdGlvbg0KDQpUaGFua3MNCg0KRmVpDQoNCg0KDQpMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4u bmV0PiANCjIwMTItMDgtMjggMjA6NDYNCg0KytW8/sjLDQp6aGFuZy5mZWkzQHp0ZS5jb20uY24N CrOty80NCiJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPiwgIlJha2VzaCBHYW5kaGkg KHJnYW5kaGkpIiANCjxyZ2FuZGhpQGNpc2NvLmNvbT4NCtb3zOINClJlOiBbQ0NBTVBdIFJldmll dyBSZXF1ZXN0IEZvciBDaGFuZ2VzIGluIA0KZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0 ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQoNCg0KDQoNCg0KDQpGZWksDQoNCkkgZG9uJ3Qg dGhpbmsgdGhlIHRleHQgYWRkcmVzc2VzIHRoZSBpc3N1ZSBvZiBzZWxlY3Rpb24gb2YgYXNzb2Np YXRpb24NCm9iamVjdCBjb250ZW50cyBpbiB0aGUgY2FzZSBvZiBkb3VibGUgc2lkZWQgcHJvdmlz aW9uaW5nLiAgSG93IGFib3V0Og0KLSBpbiB0aGUgY2FzZSBvZiBkb3VibGUgc2lkZWQgcHJvdmlz aW9uaW5nICpvbmx5Kg0KICAxLiBBc3NvY2lhdGlvbiBTb3VyY2UgaXMgc2V0IHRvIGFuIGFkZHJl c3Mgc2VsZWN0ZWQgYnkgdGhlIG5vZGUgdGhhdA0KICAgICBvcmlnaW5hdGVzIHRoZSBhc3NvY2lh dGlvbi4gKHdoaWNoIG1heSBiZSBhIG1hbmFnZW1lbnQgZW50aXR5LikNCiAgMi4gQXNzb2NpYXRp b24gSUQgaXMgYSB2YWx1ZSBhc3NpZ25lZCBidXQgdGhlIG5vZGUgdGhhdCBvcmlnaW5hdGVzDQog ICAgIHRoZSBhc3NvY2lhdGlvbi4NCiAgMy4gR2xvYmFsIEFzc29jaWF0aW9uIFNvdXJjZSwgd2hl biB1c2VkLCBpcyBzZXQgdG8gdGhlIEdsb2JhbF9JRCBvZg0KICAgICB0aGUgbm9kZSB0aGF0IG9y aWdpbmF0ZXMgdGhlIGFzc29jaWF0aW9uLg0KICA0LiBFeHRlbmRlZCBBc3NvY2lhdGlvbiBJRCwg d2hlbiB1c2VkLCBpcyBzZWxlY3RlZCBieSB0aGUgbm9kZSB0aGF0DQogICAgIG9yaWdpbmF0ZXMg dGhlIGFzc29jaWF0aW9uLg0KICAtICBJZiBlaXRoZXIgKDMpIG9yICg0KSBhcmUgdXNlZCwgYW4g RXh0ZW5kZWQgQVNTT0NJQVRJT04gb2JqZWN0DQogICAgIFthc3NvYy1leHRdIGlzIHVzZWQuICBP dGhlcndpc2UgYSBBU1NPQ0lBVElPTiBvYmplY3QgW3JmYzQ4NzJdDQogICAgIGlzIHVzZWQNCg0K LSB3aGlsZSB3ZSdyZSBhdCBpdCwgaW4gdGhlIGNhc2Ugb2Ygc2luZ2xlIHNpZGVkIHByb3Zpc2lv bmluZyAqb25seSoNCihub3RlIG9ubHkgIzEgZGlmZmVycykNCiAgMS4gQXNzb2NpYXRpb24gU291 cmNlIGlzIHNldCB0byBhbiBhZGRyZXNzIGFzc2lnbmVkIHRvIHRoZSBub2RlIHRoYXQNCiAgICAg b3JpZ2luYXRlcyB0aGUgTFNQLg0KICAyLiBBc3NvY2lhdGlvbiBJRCBpcyBhIHZhbHVlIGFzc2ln bmVkIGJ1dCB0aGUgbm9kZSB0aGF0IG9yaWdpbmF0ZXMNCiAgICAgdGhlIGFzc29jaWF0aW9uLg0K ICAzLiBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlLCB3aGVuIHVzZWQsIGlzIHNldCB0byB0aGUg R2xvYmFsX0lEIG9mDQogICAgIHRoZSBub2RlIHRoYXQgb3JpZ2luYXRlcyB0aGUgYXNzb2NpYXRp b24uDQogIDQuIEV4dGVuZGVkIEFzc29jaWF0aW9uIElELCB3aGVuIHVzZWQsIGlzIHNlbGVjdGVk IGJ5IHRoZSBub2RlIHRoYXQNCiAgICAgb3JpZ2luYXRlcyB0aGUgYXNzb2NpYXRpb24uDQogIC0g IElmIGVpdGhlciAoMykgb3IgKDQpIGFyZSB1c2VkLCBhbiBFeHRlbmRlZCBBU1NPQ0lBVElPTiBv YmplY3QNCiAgICAgW2Fzc29jLWV4dF0gaXMgdXNlZC4gIE90aGVyd2lzZSBhIEFTU09DSUFUSU9O IG9iamVjdCBbcmZjNDg3Ml0NCiAgICAgaXMgdXNlZA0KDQpJIHRoaW5rIHRoZSBhYm92ZSBhZGRy ZXNzZXMgbXkgcG9pbnQgYXMgaXQgY2FuIGJlIHVzZWQgdG8gZW5zdXJlIHVuaXF1ZQ0KTFNQIGFz c29jaWF0aW9uIGluIGFsbCBjYXNlcy4gIEJUVyBpdCBhbHNvIGFsaWducyB2ZXJ5IG5pY2VseSB3 aXRoIHRoZQ0KZXhpc3RpbmcgZGVmaW5pdGlvbiBvZiB0aGUgYXNzb2NpYXRpb24gb2JqZWN0cy4N Cg0KVG8gYWRkcmVzcyB3aGF0IEkgc3VzcGVjdCBpcyB5b3VyIGNvbmNlcm4sIDMuMi44IGNhbiB0 aGVuIGJlY29tZQ0Kc29tZXRoaW5nIGxpa2UgKGZlZWwgZnJlZSB0byByZXZpc2UpOg0KDQogIDMu Mi44ICBNUExTLVRQIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1AgSWRlbnRpZmllcnMNCg0K ICBbUkZDNjM3MF0gZGVmaW5lcyB0aGUgTFNQIGFzc29jaWF0ZWQgaWRlbnRpZmllcnMgYmFzZWQg b24gdGhlDQogIHNpZ25hbGluZyBwYXJhbWV0ZXJzIG9mIGVhY2ggdW5pZGlyZWN0aW9uYWwgTFNQ LiBUaGUgY29tYmluYXRpb24NCiAgb2YgZWFjaCB1bmlkaXJlY3Rpb25hbCBMU1AncyBwYXJhbWV0 ZXJzIGlzIHVzZWQgdG8gaWRlbnRpZnkgdGhlDQogIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBM U1AuICBVc2luZyB0aGUgbWVjaGFuaXNtcyBkZWZpbmVkIGluDQogIHRoaXMgZG9jdW1lbnQsIGFu eSBub2RlIHRoYXQgaXMgYWxvbmcgdGhlIHBhdGggb2YgYm90aA0KICB1bmlkaXJlY3Rpb25hbCBM U1BzIGNhbiBpZGVudGlmeSB3aGljaCBwYWlyIG9mIHVuaWRpcmVjdGlvbmFsIExTUHMNCiAgc3Vw cG9ydCBhbiBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQIGFzIHdlbGwgYXMgdGhlIHNpZ25h bGluZw0KICBwYXJhbWV0ZXJzIHJlcXVpcmVkIGJ5IFtSRkM2MzcwXS4gIE5vdGUgdGhhdCB0aGUg TFNQIGVuZC1wb2ludHMNCiAgd2lsbCBhbHdheXMgYmUgdGhlIHBhdGggb2YgYm90aCB1bmlkaXJl Y3Rpb25hbCBMU1BzLg0KDQpMb3UNCg0KT24gOC8yNy8yMDEyIDEwOjIwIFBNLCB6aGFuZy5mZWkz QHp0ZS5jb20uY24gd3JvdGU6DQo+IA0KPiBUaGFuayB5b3UgbG91DQo+IA0KPiBIb3cgYWJvdXQg Y2hhbmdpbmcgdGhlIGRlc2NyaXB0aW9ucyBpbiBwYXJhZ3JhcGggMy4yLjgNCj4gDQo+ICAgIElu IHNvbWUgc2NlbmFyaW9zLCBhIG5vZGUgdGhhdCBpcyB0aGUgYXNzb2NpYXRpb24gc291cmNlIE1B WSBuZWVkIHRvDQo+ICAgbGVhcm4gYWJvdXQgdGhlIEdsb2JhbF9JRCBbUkZDNjM3MF0gb2YgdGhl IHBlZXIgbm9kZSwgd2hpY2ggY2FuIGJlDQo+ICAgZG9uZSBieSBpbnNlcnRpbmcgdGhlIEFTU09D SUFUSU9OIG9iamVjdCB3aXRoIEFzc29jaWF0aW9uIFR5cGUgIkxTUA0KPiAgIGlkZW50aWZpZXJz IiBpbiB0aGUgb3V0Z29pbmcgUGF0aCBtZXNzYWdlIGFuZCBiZWluZyBjYXJyaWVkIGJhY2sgaW4N Cj4gICB0aGUgUmVzdiBtZXNzYWdlLCBhcyBkZWZpbmVkIGluIFtJLUQsIGRyYWZ0LXpoYW5nLWNj YW1wLW1wbHMtdHAtDQo+ICAgcnN2cHRlLWV4dC10dW5uZWwtbnVtXS4NCj4gDQo+IGludG8NCj4g DQo+ICAgIEluIHNvbWUgc2NlbmFyaW9zLCBhIG5vZGUgdGhhdCBpcyB0aGUgYXNzb2NpYXRpb24g c291cmNlIE1BWSBuZWVkIHRvDQo+ICAgbGVhcm4gYWJvdXQgdGhlIEdsb2JhbF9JRCBbUkZDNjM3 MF0gb2YgdGhlIHBlZXIgbm9kZS4gQWx0aG91Z2ggdGhlDQo+ICAgIHNjb3BlIG9mIHRoZSBkcmFm dCBbSS1ELA0KPiBkcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51 bV0NCj4gICAgaXMgbGltaXRlZCB0byB0aGUgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLCB0 aGUgZGVmaW5lZCBwcm9jZWR1cmVzDQo+IGNhbg0KPiAgICBiZSByZXVzZWQgaGVyZSBhbHNvLiBU aGUgQVNTT0NJQVRJT04gb2JqZWN0IHdpdGggQXNzb2NpYXRpb24gVHlwZSANCiJMU1ANCj4gICBJ ZGVudGlmaWVycyIgaXMgaW5zZXJ0ZWQgaW4gdGhlIG91dGdvaW5nIFBhdGggbWVzc2FnZSBhdCB0 aGUgDQphc3NvY2lhdGlvbg0KPiAgICBzb3VyY2UgYW5kIGNhcnJpZWQgYmFjayBpbiB0aGUgY29y cmVzcG9uZGluZyBSZXN2IG1lc3NhZ2UuIEFsbCB0aGUNCj4gZmllbGRzDQo+ICAgIG9mIHRoZSBB U1NPQ0lBVElPTiBvYmplY3QgZXhjZXB0IHRoZSBBc3NvY2lhdGlvbiBUeXBlIGluIHRoZSBQYXRo DQo+IG1lc3NhZ2UNCj4gICAgY2FuIGJlIGlnbm9yZWQgYnkgdGhlIHJlY2VpdmVyIGFuZCB0aGUg R2xvYmFsX0lEIG9mIHRoZSBwZWVyIG5vZGUgaXMNCj4gcHVzaGVkDQo+ICAgIGludG8gdGhlIGZp ZWxkIG9mIHRoZSBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlIGluIHRoZSBSZXN2IG1lc3NhZ2Uu DQo+IA0KPiBCZXN0IHJlZ2FyZHMNCj4gDQo+IEZlaQ0KPiANCj4gDQo+ICpMb3UgQmVyZ2VyIDxs YmVyZ2VyQGxhYm4ubmV0PioNCj4gDQo+IDIwMTItMDgtMjggMDI6MzANCj4gDQo+IA0KPiDK1bz+ yMsNCj4gICAgICAgICAgICAgICAgemhhbmcuZmVpM0B6dGUuY29tLmNuDQo+ILOty80NCj4gICAg ICAgICAgICAgICAgImNjYW1wQGlldGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+LCAiUmFrZXNoIEdh bmRoaSANCihyZ2FuZGhpKSINCj4gPHJnYW5kaGlAY2lzY28uY29tPg0KPiDW98ziDQo+ICAgICAg ICAgICAgICAgIFJlOiBbQ0NBTVBdIFJldmlldyBSZXF1ZXN0IEZvciBDaGFuZ2VzIGluDQo+IGRy YWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IEZlaSwNCj4gICAgICAgICAgICAgICAg IFRoZSBwcm9ibGVtIG9ubHkgZXhpc3RzIGluIHRoZSBkb3VibGUgc2lkZWQgcHJvdmlzaW9pbmcN Cj4gY2FzZSwgc28gbm8NCj4gbmVlZCB0byBjb21wbGljYXRlIHRoZSBzaW5nbGUgc2lkZWQgcHJv dmlzaW9uaW5nIGNhc2UuDQo+IA0KPiBMb3UNCj4gDQo+IA0KPiBPbiA4LzI2LzIwMTIgOTowMyBQ TSwgemhhbmcuZmVpM0B6dGUuY29tLmNuIHdyb3RlOg0KPj4gVGhlIGFkbWluaXN0cmF0aXZlDQo+ PiBhcHByb2FjaCBjYW4gaW50ZWdyYXRlIGJvdGggbW9kZWxzLCB3aWxsIGJlIGEgZ29vZCBpZGVh Lg0KPiANCj4gDQoNCg0KDQo= --=_alternative 00510E0548257A68_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxvdTwvZm9udD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPi0gaW4gdGhlIGNhc2Ugb2YgZG91YmxlIHNpZGVkIHByb3Zpc2lv bmluZyAqb25seSo8YnI+DQogJm5ic3A7MS4gQXNzb2NpYXRpb24gU291cmNlIGlzIHNldCB0byBh biBhZGRyZXNzIHNlbGVjdGVkIGJ5IHRoZSBub2RlDQp0aGF0PGJyPg0KICZuYnNwOyAmbmJzcDsg b3JpZ2luYXRlcyB0aGUgYXNzb2NpYXRpb24uICh3aGljaCBtYXkgYmUgYSBtYW5hZ2VtZW50IGVu dGl0eS4pPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZsdDtmZWkmZ3Q7IERvIHlvdSBtZWFuIHRoZSBhc3NvY2l0aW9uDQpzb3VyY2UgY2FuIGJl IG5laXRoZXIgQTEgbm9yIFo5IGhlcmU/PC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jm5ic3A7IDMuMi44ICZuYnNwO01QTFMtVFAgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsDQpM U1AgSWRlbnRpZmllcnM8YnI+DQo8YnI+DQogJm5ic3A7W1JGQzYzNzBdIGRlZmluZXMgdGhlIExT UCBhc3NvY2lhdGVkIGlkZW50aWZpZXJzIGJhc2VkIG9uIHRoZTxicj4NCiAmbmJzcDtzaWduYWxp bmcgcGFyYW1ldGVycyBvZiBlYWNoIHVuaWRpcmVjdGlvbmFsIExTUC4gVGhlIGNvbWJpbmF0aW9u PGJyPg0KICZuYnNwO29mIGVhY2ggdW5pZGlyZWN0aW9uYWwgTFNQJ3MgcGFyYW1ldGVycyBpcyB1 c2VkIHRvIGlkZW50aWZ5IHRoZTxicj4NCiAmbmJzcDtBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwg TFNQLiAmbmJzcDtVc2luZyB0aGUgbWVjaGFuaXNtcyBkZWZpbmVkDQppbjxicj4NCiAmbmJzcDt0 aGlzIGRvY3VtZW50LCBhbnkgbm9kZSB0aGF0IGlzIGFsb25nIHRoZSBwYXRoIG9mIGJvdGg8YnI+ DQogJm5ic3A7dW5pZGlyZWN0aW9uYWwgTFNQcyBjYW4gaWRlbnRpZnkgd2hpY2ggcGFpciBvZiB1 bmlkaXJlY3Rpb25hbCBMU1BzPGJyPg0KICZuYnNwO3N1cHBvcnQgYW4gQXNzb2NpYXRlZCBCaWRp cmVjdGlvbmFsIExTUCBhcyB3ZWxsIGFzIHRoZSBzaWduYWxpbmc8YnI+DQogJm5ic3A7cGFyYW1l dGVycyByZXF1aXJlZCBieSBbUkZDNjM3MF0uICZuYnNwO05vdGUgdGhhdCB0aGUgTFNQIGVuZC1w b2ludHM8YnI+DQogJm5ic3A7d2lsbCBhbHdheXMgYmUgdGhlIHBhdGggb2YgYm90aCB1bmlkaXJl Y3Rpb25hbCBMU1BzLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbHQ7RmVpJmd0OyBSRkM2MzcwIHJlcXVpcmVzIEExLWdsb2JhbF9JRA0KYW5k IFo5LWdsb2JhbF9JRCwgaG93IHRvIHB1c2ggdGhlbTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+aW50byB0aGUgRXh0ZW5kZWQgQVNTT0NJQVRJT04gb2JqZWN0DQp3 aXRob3V0IG5ldyBBc3NvY2lhdGlvbiB0eXBlPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5Ib3BlIHlvdXIgY2xhcmlmaWNhdGlvbjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+TG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZn dDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0w OC0yOCAyMDo0NjwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj56aGFuZy5mZWkzQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOt y808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90 O2NjYW1wQGlldGYub3JnJnF1b3Q7ICZsdDtjY2FtcEBpZXRmLm9yZyZndDssDQomcXVvdDtSYWtl c2ggR2FuZGhpIChyZ2FuZGhpKSZxdW90OyAmbHQ7cmdhbmRoaUBjaXNjby5jb20mZ3Q7PC9mb250 Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj5SZTogW0NDQU1QXSBSZXZpZXcgUmVxdWVzdCBGb3IgQ2hhbmdlcw0KaW4g ZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0 PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0 ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5GZWksPGJyPg0KPGJyPg0KSSBkb24ndCB0aGluayB0aGUgdGV4dCBhZGRyZXNzZXMgdGhlIGlz c3VlIG9mIHNlbGVjdGlvbiBvZiBhc3NvY2lhdGlvbjxicj4NCm9iamVjdCBjb250ZW50cyBpbiB0 aGUgY2FzZSBvZiBkb3VibGUgc2lkZWQgcHJvdmlzaW9uaW5nLiAmbmJzcDtIb3cgYWJvdXQ6PGJy Pg0KLSBpbiB0aGUgY2FzZSBvZiBkb3VibGUgc2lkZWQgcHJvdmlzaW9uaW5nICpvbmx5Kjxicj4N CiAmbmJzcDsxLiBBc3NvY2lhdGlvbiBTb3VyY2UgaXMgc2V0IHRvIGFuIGFkZHJlc3Mgc2VsZWN0 ZWQgYnkgdGhlIG5vZGUNCnRoYXQ8YnI+DQogJm5ic3A7ICZuYnNwOyBvcmlnaW5hdGVzIHRoZSBh c3NvY2lhdGlvbi4gKHdoaWNoIG1heSBiZSBhIG1hbmFnZW1lbnQgZW50aXR5Lik8YnI+DQogJm5i c3A7Mi4gQXNzb2NpYXRpb24gSUQgaXMgYSB2YWx1ZSBhc3NpZ25lZCBidXQgdGhlIG5vZGUgdGhh dCBvcmlnaW5hdGVzPGJyPg0KICZuYnNwOyAmbmJzcDsgdGhlIGFzc29jaWF0aW9uLjxicj4NCiAm bmJzcDszLiBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlLCB3aGVuIHVzZWQsIGlzIHNldCB0byB0 aGUgR2xvYmFsX0lEDQpvZjxicj4NCiAmbmJzcDsgJm5ic3A7IHRoZSBub2RlIHRoYXQgb3JpZ2lu YXRlcyB0aGUgYXNzb2NpYXRpb24uPGJyPg0KICZuYnNwOzQuIEV4dGVuZGVkIEFzc29jaWF0aW9u IElELCB3aGVuIHVzZWQsIGlzIHNlbGVjdGVkIGJ5IHRoZSBub2RlIHRoYXQ8YnI+DQogJm5ic3A7 ICZuYnNwOyBvcmlnaW5hdGVzIHRoZSBhc3NvY2lhdGlvbi48YnI+DQogJm5ic3A7LSAmbmJzcDtJ ZiBlaXRoZXIgKDMpIG9yICg0KSBhcmUgdXNlZCwgYW4gRXh0ZW5kZWQgQVNTT0NJQVRJT04gb2Jq ZWN0PGJyPg0KICZuYnNwOyAmbmJzcDsgW2Fzc29jLWV4dF0gaXMgdXNlZC4gJm5ic3A7T3RoZXJ3 aXNlIGEgQVNTT0NJQVRJT04gb2JqZWN0DQpbcmZjNDg3Ml08YnI+DQogJm5ic3A7ICZuYnNwOyBp cyB1c2VkPGJyPg0KPGJyPg0KLSB3aGlsZSB3ZSdyZSBhdCBpdCwgaW4gdGhlIGNhc2Ugb2Ygc2lu Z2xlIHNpZGVkIHByb3Zpc2lvbmluZyAqb25seSo8YnI+DQoobm90ZSBvbmx5ICMxIGRpZmZlcnMp PGJyPg0KICZuYnNwOzEuIEFzc29jaWF0aW9uIFNvdXJjZSBpcyBzZXQgdG8gYW4gYWRkcmVzcyBh c3NpZ25lZCB0byB0aGUgbm9kZQ0KdGhhdDxicj4NCiAmbmJzcDsgJm5ic3A7IG9yaWdpbmF0ZXMg dGhlIExTUC48YnI+DQogJm5ic3A7Mi4gQXNzb2NpYXRpb24gSUQgaXMgYSB2YWx1ZSBhc3NpZ25l ZCBidXQgdGhlIG5vZGUgdGhhdCBvcmlnaW5hdGVzPGJyPg0KICZuYnNwOyAmbmJzcDsgdGhlIGFz c29jaWF0aW9uLjxicj4NCiAmbmJzcDszLiBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlLCB3aGVu IHVzZWQsIGlzIHNldCB0byB0aGUgR2xvYmFsX0lEDQpvZjxicj4NCiAmbmJzcDsgJm5ic3A7IHRo ZSBub2RlIHRoYXQgb3JpZ2luYXRlcyB0aGUgYXNzb2NpYXRpb24uPGJyPg0KICZuYnNwOzQuIEV4 dGVuZGVkIEFzc29jaWF0aW9uIElELCB3aGVuIHVzZWQsIGlzIHNlbGVjdGVkIGJ5IHRoZSBub2Rl IHRoYXQ8YnI+DQogJm5ic3A7ICZuYnNwOyBvcmlnaW5hdGVzIHRoZSBhc3NvY2lhdGlvbi48YnI+ DQogJm5ic3A7LSAmbmJzcDtJZiBlaXRoZXIgKDMpIG9yICg0KSBhcmUgdXNlZCwgYW4gRXh0ZW5k ZWQgQVNTT0NJQVRJT04gb2JqZWN0PGJyPg0KICZuYnNwOyAmbmJzcDsgW2Fzc29jLWV4dF0gaXMg dXNlZC4gJm5ic3A7T3RoZXJ3aXNlIGEgQVNTT0NJQVRJT04gb2JqZWN0DQpbcmZjNDg3Ml08YnI+ DQogJm5ic3A7ICZuYnNwOyBpcyB1c2VkPGJyPg0KPGJyPg0KSSB0aGluayB0aGUgYWJvdmUgYWRk cmVzc2VzIG15IHBvaW50IGFzIGl0IGNhbiBiZSB1c2VkIHRvIGVuc3VyZSB1bmlxdWU8YnI+DQpM U1AgYXNzb2NpYXRpb24gaW4gYWxsIGNhc2VzLiAmbmJzcDtCVFcgaXQgYWxzbyBhbGlnbnMgdmVy eSBuaWNlbHkgd2l0aA0KdGhlPGJyPg0KZXhpc3RpbmcgZGVmaW5pdGlvbiBvZiB0aGUgYXNzb2Np YXRpb24gb2JqZWN0cy48YnI+DQo8YnI+DQpUbyBhZGRyZXNzIHdoYXQgSSBzdXNwZWN0IGlzIHlv dXIgY29uY2VybiwgMy4yLjggY2FuIHRoZW4gYmVjb21lPGJyPg0Kc29tZXRoaW5nIGxpa2UgKGZl ZWwgZnJlZSB0byByZXZpc2UpOjxicj4NCjxicj4NCiAmbmJzcDszLjIuOCAmbmJzcDtNUExTLVRQ IEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1AgSWRlbnRpZmllcnM8YnI+DQo8YnI+DQogJm5i c3A7W1JGQzYzNzBdIGRlZmluZXMgdGhlIExTUCBhc3NvY2lhdGVkIGlkZW50aWZpZXJzIGJhc2Vk IG9uIHRoZTxicj4NCiAmbmJzcDtzaWduYWxpbmcgcGFyYW1ldGVycyBvZiBlYWNoIHVuaWRpcmVj dGlvbmFsIExTUC4gVGhlIGNvbWJpbmF0aW9uPGJyPg0KICZuYnNwO29mIGVhY2ggdW5pZGlyZWN0 aW9uYWwgTFNQJ3MgcGFyYW1ldGVycyBpcyB1c2VkIHRvIGlkZW50aWZ5IHRoZTxicj4NCiAmbmJz cDtBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQLiAmbmJzcDtVc2luZyB0aGUgbWVjaGFuaXNt cyBkZWZpbmVkDQppbjxicj4NCiAmbmJzcDt0aGlzIGRvY3VtZW50LCBhbnkgbm9kZSB0aGF0IGlz IGFsb25nIHRoZSBwYXRoIG9mIGJvdGg8YnI+DQogJm5ic3A7dW5pZGlyZWN0aW9uYWwgTFNQcyBj YW4gaWRlbnRpZnkgd2hpY2ggcGFpciBvZiB1bmlkaXJlY3Rpb25hbCBMU1BzPGJyPg0KICZuYnNw O3N1cHBvcnQgYW4gQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUCBhcyB3ZWxsIGFzIHRoZSBz aWduYWxpbmc8YnI+DQogJm5ic3A7cGFyYW1ldGVycyByZXF1aXJlZCBieSBbUkZDNjM3MF0uICZu YnNwO05vdGUgdGhhdCB0aGUgTFNQIGVuZC1wb2ludHM8YnI+DQogJm5ic3A7d2lsbCBhbHdheXMg YmUgdGhlIHBhdGggb2YgYm90aCB1bmlkaXJlY3Rpb25hbCBMU1BzLjxicj4NCjxicj4NCkxvdTxi cj4NCjxicj4NCk9uIDgvMjcvMjAxMiAxMDoyMCBQTSwgemhhbmcuZmVpM0B6dGUuY29tLmNuIHdy b3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFuayB5b3UgbG91PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEhvdyBhYm91dCBjaGFuZ2luZyB0aGUgZGVzY3JpcHRpb25zIGluIHBhcmFncmFwaCAzLjIu ODxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7SW4gc29tZSBzY2VuYXJpb3MsIGEg bm9kZSB0aGF0IGlzIHRoZSBhc3NvY2lhdGlvbiBzb3VyY2UNCk1BWSBuZWVkIHRvPGJyPg0KJmd0 OyAmbmJzcDsgbGVhcm4gYWJvdXQgdGhlIEdsb2JhbF9JRCBbUkZDNjM3MF0gb2YgdGhlIHBlZXIg bm9kZSwgd2hpY2gNCmNhbiBiZTxicj4NCiZndDsgJm5ic3A7IGRvbmUgYnkgaW5zZXJ0aW5nIHRo ZSBBU1NPQ0lBVElPTiBvYmplY3Qgd2l0aCBBc3NvY2lhdGlvbiBUeXBlDQomcXVvdDtMU1A8YnI+ DQomZ3Q7ICZuYnNwOyBpZGVudGlmaWVycyZxdW90OyBpbiB0aGUgb3V0Z29pbmcgUGF0aCBtZXNz YWdlIGFuZCBiZWluZyBjYXJyaWVkDQpiYWNrIGluPGJyPg0KJmd0OyAmbmJzcDsgdGhlIFJlc3Yg bWVzc2FnZSwgYXMgZGVmaW5lZCBpbiBbSS1ELCBkcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLTxi cj4NCiZndDsgJm5ic3A7IHJzdnB0ZS1leHQtdHVubmVsLW51bV0uPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IGludG88YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0luIHNvbWUgc2NlbmFy aW9zLCBhIG5vZGUgdGhhdCBpcyB0aGUgYXNzb2NpYXRpb24gc291cmNlDQpNQVkgbmVlZCB0bzxi cj4NCiZndDsgJm5ic3A7IGxlYXJuIGFib3V0IHRoZSBHbG9iYWxfSUQgW1JGQzYzNzBdIG9mIHRo ZSBwZWVyIG5vZGUuIEFsdGhvdWdoDQp0aGU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtzY29wZSBv ZiB0aGUgZHJhZnQgW0ktRCw8YnI+DQomZ3Q7IGRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2 cHRlLWV4dC10dW5uZWwtbnVtXTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2lzIGxpbWl0ZWQgdG8g dGhlIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUCwgdGhlIGRlZmluZWQNCnByb2NlZHVyZXM8 YnI+DQomZ3Q7IGNhbjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2JlIHJldXNlZCBoZXJlIGFsc28u IFRoZSBBU1NPQ0lBVElPTiBvYmplY3Qgd2l0aCBBc3NvY2lhdGlvbg0KVHlwZSAmcXVvdDtMU1A8 YnI+DQomZ3Q7ICZuYnNwOyBJZGVudGlmaWVycyZxdW90OyBpcyBpbnNlcnRlZCBpbiB0aGUgb3V0 Z29pbmcgUGF0aCBtZXNzYWdlDQphdCB0aGUgYXNzb2NpYXRpb248YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDtzb3VyY2UgYW5kIGNhcnJpZWQgYmFjayBpbiB0aGUgY29ycmVzcG9uZGluZyBSZXN2IG1l c3NhZ2UuDQpBbGwgdGhlPGJyPg0KJmd0OyBmaWVsZHM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtv ZiB0aGUgQVNTT0NJQVRJT04gb2JqZWN0IGV4Y2VwdCB0aGUgQXNzb2NpYXRpb24gVHlwZQ0KaW4g dGhlIFBhdGg8YnI+DQomZ3Q7IG1lc3NhZ2U8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtjYW4gYmUg aWdub3JlZCBieSB0aGUgcmVjZWl2ZXIgYW5kIHRoZSBHbG9iYWxfSUQgb2YgdGhlDQpwZWVyIG5v ZGUgaXM8YnI+DQomZ3Q7IHB1c2hlZDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2ludG8gdGhlIGZp ZWxkIG9mIHRoZSBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlIGluIHRoZQ0KUmVzdiBtZXNzYWdl Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBCZXN0IHJlZ2FyZHM8YnI+DQomZ3Q7IDxicj4NCiZndDsg RmVpPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgKkxvdSBCZXJnZXIgJmx0O2xiZXJn ZXJAbGFibi5uZXQmZ3Q7Kjxicj4NCiZndDsgPGJyPg0KJmd0OyAyMDEyLTA4LTI4IDAyOjMwPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyDK1bz+yMs8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 emhhbmcuZmVpM0B6dGUuY29tLmNuPGJyPg0KJmd0OyCzrcvNPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90 O2NjYW1wQGlldGYub3JnJnF1b3Q7DQombHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtSYWtl c2ggR2FuZGhpIChyZ2FuZGhpKSZxdW90Ozxicj4NCiZndDsgJmx0O3JnYW5kaGlAY2lzY28uY29t Jmd0Ozxicj4NCiZndDsg1vfM4jxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSZToNCltDQ0FNUF0gUmV2aWV3IFJl cXVlc3QgRm9yIENoYW5nZXMgaW48YnI+DQomZ3Q7IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1y c3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgRmVpLDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgcHJvYmxlbQ0Kb25seSBleGlz dHMgaW4gdGhlIGRvdWJsZSBzaWRlZCBwcm92aXNpb2luZzxicj4NCiZndDsgY2FzZSwgc28gbm88 YnI+DQomZ3Q7IG5lZWQgdG8gY29tcGxpY2F0ZSB0aGUgc2luZ2xlIHNpZGVkIHByb3Zpc2lvbmlu ZyBjYXNlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBMb3U8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyBPbiA4LzI2LzIwMTIgOTowMyBQTSwgemhhbmcuZmVpM0B6dGUuY29tLmNuIHdyb3Rl Ojxicj4NCiZndDsmZ3Q7IFRoZSBhZG1pbmlzdHJhdGl2ZTxicj4NCiZndDsmZ3Q7IGFwcHJvYWNo IGNhbiBpbnRlZ3JhdGUgYm90aCBtb2RlbHMsIHdpbGwgYmUgYSBnb29kIGlkZWEuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IDxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 00510E0548257A68_=-- From rgandhi@cisco.com Tue Aug 28 08:28:26 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C59E21F852B for ; Tue, 28 Aug 2012 08:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlCkoFepTWC6 for ; Tue, 28 Aug 2012 08:28:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0FE21F852A for ; Tue, 28 Aug 2012 08:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=7558; q=dns/txt; s=iport; t=1346167705; x=1347377305; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lQoG35ENHxb66HQQ4WGcJrSn8ju9x3ux4fyB/TPj5Wk=; b=kbQVJVsWnTjz9P/zLOS1oUPKPzY+0bq1lkkCEaH4if5ZdxL4sV4YGSLK UCJSDEAWucb32A2NDQlNAlIVN9WS8aFUThp2RH6nWOuv466KKG2cwgens CQYE4sZmWhupXoPd6072T+TFNuTFjlu0DS5voAlqP9g2Det2DWTP+KGjs 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAPziPFCtJXG9/2dsb2JhbAA7CoYDs3lugQeCIAEBAQQSASEzEgwEAgEGAg4DBAEBAQQGGQQFAgIwFAkIAgQBDQUIGodrm16NEgiTL4EdiWsQBIUvNmADpASBZ4JjgVg X-IronPort-AV: E=Sophos;i="4.80,327,1344211200"; d="scan'208";a="116044470" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 28 Aug 2012 15:28:24 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7SFSOlB018825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Aug 2012 15:28:24 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Tue, 28 Aug 2012 10:28:24 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger , "zhang.fei3@zte.com.cn" Thread-Topic: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: AQHNhMO1KWryoN3/QKaPbjEu2q9iw5dvgLYA///VJ2A= Date: Tue, 28 Aug 2012 15:28:23 +0000 Message-ID: References: <503CBDC2.9040308@labn.net> In-Reply-To: <503CBDC2.9040308@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.81.146] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--45.918900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:28:26 -0000 SGkgTG91LA0KDQpQbGVhc2Ugc2VlIGlubGluZS4uPFJHPi4uDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQpT ZW50OiBUdWVzZGF5LCBBdWd1c3QgMjgsIDIwMTIgODo0NyBBTQ0KVG86IHpoYW5nLmZlaTNAenRl LmNvbS5jbg0KQ2M6IGNjYW1wQGlldGYub3JnOyBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KU3Vi amVjdDogUmU6IFtDQ0FNUF0gUmV2aWV3IFJlcXVlc3QgRm9yIENoYW5nZXMgaW4gZHJhZnQtaWV0 Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQoNCkZlaSwN Cg0KSSBkb24ndCB0aGluayB0aGUgdGV4dCBhZGRyZXNzZXMgdGhlIGlzc3VlIG9mIHNlbGVjdGlv biBvZiBhc3NvY2lhdGlvbiBvYmplY3QgY29udGVudHMgaW4gdGhlIGNhc2Ugb2YgZG91YmxlIHNp ZGVkIHByb3Zpc2lvbmluZy4gIEhvdyBhYm91dDoNCi0gaW4gdGhlIGNhc2Ugb2YgZG91YmxlIHNp ZGVkIHByb3Zpc2lvbmluZyAqb25seSoNCiAgMS4gQXNzb2NpYXRpb24gU291cmNlIGlzIHNldCB0 byBhbiBhZGRyZXNzIHNlbGVjdGVkIGJ5IHRoZSBub2RlIHRoYXQNCiAgICAgb3JpZ2luYXRlcyB0 aGUgYXNzb2NpYXRpb24uICh3aGljaCBtYXkgYmUgYSBtYW5hZ2VtZW50IGVudGl0eS4pDQoNCjxS Rz4gRm9yIGRvdWJsZSBzaWRlZCBwcm92aXNpb25pbmcsIGJvdGggc2lkZXMgY2FuIG9yaWdpbmF0 ZSB0aGUgTFNQcyBpbmRlcGVuZGVudGx5LiBJbiB0aGlzIGNhc2UsIHRoZXJlIG5lZWRzIHRvIGJl IGEgcnVsZSBmb3IgYSBkZWZhdWx0IGJlaGF2aW9yIG9uIHdoaWNoIHNpZGUgYmVjb21lcyB0aGUg YXNzb2NpYXRpb24gc291cmNlIGFuZCBoZW5jZSB0aGUgcHJvcG9zYWwgdG8gcGljayB0aGUgc2lk ZSB3aXRoIGxvd2VyIElQIGFkZHJlc3MgZm9yIHRoZSBzb3VyY2UuIFRoaXMgcnVsZSBjYW4gYmUg b3ZlcnJpZGRlbiBieSB0aGUgbWFuYWdlbWVudCBlbnRpdHkgdG8gZGVzaWduYXRlIGEgc2lkZSB0 byBiZWNvbWUgYW4gYXNzb2NpYXRpb24gc291cmNlLg0KDQoNCiAgMi4gQXNzb2NpYXRpb24gSUQg aXMgYSB2YWx1ZSBhc3NpZ25lZCBidXQgdGhlIG5vZGUgdGhhdCBvcmlnaW5hdGVzDQogICAgIHRo ZSBhc3NvY2lhdGlvbi4NCiAgMy4gR2xvYmFsIEFzc29jaWF0aW9uIFNvdXJjZSwgd2hlbiB1c2Vk LCBpcyBzZXQgdG8gdGhlIEdsb2JhbF9JRCBvZg0KICAgICB0aGUgbm9kZSB0aGF0IG9yaWdpbmF0 ZXMgdGhlIGFzc29jaWF0aW9uLg0KICA0LiBFeHRlbmRlZCBBc3NvY2lhdGlvbiBJRCwgd2hlbiB1 c2VkLCBpcyBzZWxlY3RlZCBieSB0aGUgbm9kZSB0aGF0DQogICAgIG9yaWdpbmF0ZXMgdGhlIGFz c29jaWF0aW9uLg0KICAtICBJZiBlaXRoZXIgKDMpIG9yICg0KSBhcmUgdXNlZCwgYW4gRXh0ZW5k ZWQgQVNTT0NJQVRJT04gb2JqZWN0DQogICAgIFthc3NvYy1leHRdIGlzIHVzZWQuICBPdGhlcndp c2UgYSBBU1NPQ0lBVElPTiBvYmplY3QgW3JmYzQ4NzJdDQogICAgIGlzIHVzZWQNCg0KPFJHPiBB cyBib3RoIHNpZGVzIGNhbiBvcmlnaW5hdGUgTFNQcyBpbmRlcGVuZGVudGx5LCAgaXQgd291bGQg YmUgdXNlZnVsIHRvIGhhdmUgYSBzZW50ZW5jZSBpbiB0aGUgZHJhZnQgdG8gaW5kaWNhdGUgaG93 IHRoaXMgaXMgcG9wdWxhdGVkLiBBcyBhIHRpZSBicmVha2VyIHJ1bGUgYnkgZGVmYXVsdCBoaWdo ZXIgSVAgYWRkcmVzcyBkZXN0aW5hdGlvbiBpcyB1c2VkIGFuZCBpdCBjYW4gYmUgb3ZlcnJpZGRl biBieSB0aGUgbWFuYWdlbWVudCBlbnRpdHkuDQoNCg0KDQotIHdoaWxlIHdlJ3JlIGF0IGl0LCBp biB0aGUgY2FzZSBvZiBzaW5nbGUgc2lkZWQgcHJvdmlzaW9uaW5nICpvbmx5KiAobm90ZSBvbmx5 ICMxIGRpZmZlcnMpDQogIDEuIEFzc29jaWF0aW9uIFNvdXJjZSBpcyBzZXQgdG8gYW4gYWRkcmVz cyBhc3NpZ25lZCB0byB0aGUgbm9kZSB0aGF0DQogICAgIG9yaWdpbmF0ZXMgdGhlIExTUC4NCiAg Mi4gQXNzb2NpYXRpb24gSUQgaXMgYSB2YWx1ZSBhc3NpZ25lZCBidXQgdGhlIG5vZGUgdGhhdCBv cmlnaW5hdGVzDQogICAgIHRoZSBhc3NvY2lhdGlvbi4NCiAgMy4gR2xvYmFsIEFzc29jaWF0aW9u IFNvdXJjZSwgd2hlbiB1c2VkLCBpcyBzZXQgdG8gdGhlIEdsb2JhbF9JRCBvZg0KICAgICB0aGUg bm9kZSB0aGF0IG9yaWdpbmF0ZXMgdGhlIGFzc29jaWF0aW9uLg0KICA0LiBFeHRlbmRlZCBBc3Nv Y2lhdGlvbiBJRCwgd2hlbiB1c2VkLCBpcyBzZWxlY3RlZCBieSB0aGUgbm9kZSB0aGF0DQogICAg IG9yaWdpbmF0ZXMgdGhlIGFzc29jaWF0aW9uLg0KICAtICBJZiBlaXRoZXIgKDMpIG9yICg0KSBh cmUgdXNlZCwgYW4gRXh0ZW5kZWQgQVNTT0NJQVRJT04gb2JqZWN0DQogICAgIFthc3NvYy1leHRd IGlzIHVzZWQuICBPdGhlcndpc2UgYSBBU1NPQ0lBVElPTiBvYmplY3QgW3JmYzQ4NzJdDQogICAg IGlzIHVzZWQNCg0KSSB0aGluayB0aGUgYWJvdmUgYWRkcmVzc2VzIG15IHBvaW50IGFzIGl0IGNh biBiZSB1c2VkIHRvIGVuc3VyZSB1bmlxdWUgTFNQIGFzc29jaWF0aW9uIGluIGFsbCBjYXNlcy4g IEJUVyBpdCBhbHNvIGFsaWducyB2ZXJ5IG5pY2VseSB3aXRoIHRoZSBleGlzdGluZyBkZWZpbml0 aW9uIG9mIHRoZSBhc3NvY2lhdGlvbiBvYmplY3RzLg0KDQo8Ukc+IFRoaXMgc291bmRzIGdvb2Qu DQoNClRoYW5rcywNClJha2VzaA0KDQoNClRvIGFkZHJlc3Mgd2hhdCBJIHN1c3BlY3QgaXMgeW91 ciBjb25jZXJuLCAzLjIuOCBjYW4gdGhlbiBiZWNvbWUgc29tZXRoaW5nIGxpa2UgKGZlZWwgZnJl ZSB0byByZXZpc2UpOg0KDQogIDMuMi44ICBNUExTLVRQIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25h bCBMU1AgSWRlbnRpZmllcnMNCg0KICBbUkZDNjM3MF0gZGVmaW5lcyB0aGUgTFNQIGFzc29jaWF0 ZWQgaWRlbnRpZmllcnMgYmFzZWQgb24gdGhlDQogIHNpZ25hbGluZyBwYXJhbWV0ZXJzIG9mIGVh Y2ggdW5pZGlyZWN0aW9uYWwgTFNQLiBUaGUgY29tYmluYXRpb24NCiAgb2YgZWFjaCB1bmlkaXJl Y3Rpb25hbCBMU1AncyBwYXJhbWV0ZXJzIGlzIHVzZWQgdG8gaWRlbnRpZnkgdGhlDQogIEFzc29j aWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1AuICBVc2luZyB0aGUgbWVjaGFuaXNtcyBkZWZpbmVkIGlu DQogIHRoaXMgZG9jdW1lbnQsIGFueSBub2RlIHRoYXQgaXMgYWxvbmcgdGhlIHBhdGggb2YgYm90 aA0KICB1bmlkaXJlY3Rpb25hbCBMU1BzIGNhbiBpZGVudGlmeSB3aGljaCBwYWlyIG9mIHVuaWRp cmVjdGlvbmFsIExTUHMNCiAgc3VwcG9ydCBhbiBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQ IGFzIHdlbGwgYXMgdGhlIHNpZ25hbGluZw0KICBwYXJhbWV0ZXJzIHJlcXVpcmVkIGJ5IFtSRkM2 MzcwXS4gIE5vdGUgdGhhdCB0aGUgTFNQIGVuZC1wb2ludHMNCiAgd2lsbCBhbHdheXMgYmUgdGhl IHBhdGggb2YgYm90aCB1bmlkaXJlY3Rpb25hbCBMU1BzLg0KDQpMb3UNCg0KT24gOC8yNy8yMDEy IDEwOjIwIFBNLCB6aGFuZy5mZWkzQHp0ZS5jb20uY24gd3JvdGU6DQo+IA0KPiBUaGFuayB5b3Ug bG91DQo+IA0KPiBIb3cgYWJvdXQgY2hhbmdpbmcgdGhlIGRlc2NyaXB0aW9ucyBpbiBwYXJhZ3Jh cGggMy4yLjgNCj4gDQo+ICAgIEluIHNvbWUgc2NlbmFyaW9zLCBhIG5vZGUgdGhhdCBpcyB0aGUg YXNzb2NpYXRpb24gc291cmNlIE1BWSBuZWVkIHRvDQo+ICAgbGVhcm4gYWJvdXQgdGhlIEdsb2Jh bF9JRCBbUkZDNjM3MF0gb2YgdGhlIHBlZXIgbm9kZSwgd2hpY2ggY2FuIGJlDQo+ICAgZG9uZSBi eSBpbnNlcnRpbmcgdGhlIEFTU09DSUFUSU9OIG9iamVjdCB3aXRoIEFzc29jaWF0aW9uIFR5cGUg IkxTUA0KPiAgIGlkZW50aWZpZXJzIiBpbiB0aGUgb3V0Z29pbmcgUGF0aCBtZXNzYWdlIGFuZCBi ZWluZyBjYXJyaWVkIGJhY2sgaW4NCj4gICB0aGUgUmVzdiBtZXNzYWdlLCBhcyBkZWZpbmVkIGlu IFtJLUQsIGRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtDQo+ICAgcnN2cHRlLWV4dC10dW5uZWwt bnVtXS4NCj4gDQo+IGludG8NCj4gDQo+ICAgIEluIHNvbWUgc2NlbmFyaW9zLCBhIG5vZGUgdGhh dCBpcyB0aGUgYXNzb2NpYXRpb24gc291cmNlIE1BWSBuZWVkIHRvDQo+ICAgbGVhcm4gYWJvdXQg dGhlIEdsb2JhbF9JRCBbUkZDNjM3MF0gb2YgdGhlIHBlZXIgbm9kZS4gQWx0aG91Z2ggdGhlDQo+ ICAgIHNjb3BlIG9mIHRoZSBkcmFmdCBbSS1ELA0KPiBkcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRw LXJzdnB0ZS1leHQtdHVubmVsLW51bV0NCj4gICAgaXMgbGltaXRlZCB0byB0aGUgY28tcm91dGVk IGJpZGlyZWN0aW9uYWwgTFNQLCB0aGUgZGVmaW5lZCANCj4gcHJvY2VkdXJlcyBjYW4NCj4gICAg YmUgcmV1c2VkIGhlcmUgYWxzby4gVGhlIEFTU09DSUFUSU9OIG9iamVjdCB3aXRoIEFzc29jaWF0 aW9uIFR5cGUgIkxTUA0KPiAgIElkZW50aWZpZXJzIiBpcyBpbnNlcnRlZCBpbiB0aGUgb3V0Z29p bmcgUGF0aCBtZXNzYWdlIGF0IHRoZSBhc3NvY2lhdGlvbg0KPiAgICBzb3VyY2UgYW5kIGNhcnJp ZWQgYmFjayBpbiB0aGUgY29ycmVzcG9uZGluZyBSZXN2IG1lc3NhZ2UuIEFsbCB0aGUgDQo+IGZp ZWxkcw0KPiAgICBvZiB0aGUgQVNTT0NJQVRJT04gb2JqZWN0IGV4Y2VwdCB0aGUgQXNzb2NpYXRp b24gVHlwZSBpbiB0aGUgUGF0aCANCj4gbWVzc2FnZQ0KPiAgICBjYW4gYmUgaWdub3JlZCBieSB0 aGUgcmVjZWl2ZXIgYW5kIHRoZSBHbG9iYWxfSUQgb2YgdGhlIHBlZXIgbm9kZSANCj4gaXMgcHVz aGVkDQo+ICAgIGludG8gdGhlIGZpZWxkIG9mIHRoZSBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNl IGluIHRoZSBSZXN2IG1lc3NhZ2UuDQo+IA0KPiBCZXN0IHJlZ2FyZHMNCj4gDQo+IEZlaQ0KPiAN Cj4gDQo+ICpMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PioNCj4gDQo+IDIwMTItMDgtMjgg MDI6MzANCj4gDQo+IAkNCj4gytW8/sjLDQo+IAl6aGFuZy5mZWkzQHp0ZS5jb20uY24NCj4gs63L zQ0KPiAJImNjYW1wQGlldGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+LCAiUmFrZXNoIEdhbmRoaSAo cmdhbmRoaSkiDQo+IDxyZ2FuZGhpQGNpc2NvLmNvbT4NCj4g1vfM4g0KPiAJUmU6IFtDQ0FNUF0g UmV2aWV3IFJlcXVlc3QgRm9yIENoYW5nZXMgaW4gDQo+IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10 cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KPiANCj4gDQo+IAkNCj4gDQo+IA0K PiANCj4gDQo+IA0KPiBGZWksDQo+ICAgICAgICAgICAgICAgICBUaGUgcHJvYmxlbSBvbmx5IGV4 aXN0cyBpbiB0aGUgZG91YmxlIHNpZGVkIA0KPiBwcm92aXNpb2luZyBjYXNlLCBzbyBubyBuZWVk IHRvIGNvbXBsaWNhdGUgdGhlIHNpbmdsZSBzaWRlZCANCj4gcHJvdmlzaW9uaW5nIGNhc2UuDQo+ IA0KPiBMb3UNCj4gDQo+IA0KPiBPbiA4LzI2LzIwMTIgOTowMyBQTSwgemhhbmcuZmVpM0B6dGUu Y29tLmNuIHdyb3RlOg0KPj4gVGhlIGFkbWluaXN0cmF0aXZlDQo+PiBhcHByb2FjaCBjYW4gaW50 ZWdyYXRlIGJvdGggbW9kZWxzLCB3aWxsIGJlIGEgZ29vZCBpZGVhLg0KPiANCj4gDQo= From lberger@labn.net Tue Aug 28 08:44:14 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9CD11E8106 for ; Tue, 28 Aug 2012 08:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.167 X-Spam-Level: X-Spam-Status: No, score=-98.167 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGulpNf2MYrv for ; Tue, 28 Aug 2012 08:44:13 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id DD34411E8101 for ; Tue, 28 Aug 2012 08:44:12 -0700 (PDT) Received: (qmail 6255 invoked by uid 0); 28 Aug 2012 15:44:10 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 28 Aug 2012 15:44:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=3gCs+BoH3KxLDyxnGgPXG+39Ma4lND4KeqJ+hxpfyfM=; b=FjA7EnDly/CMHs9J+WqHSYPr32UU5md3f9BMoGWqOp7zN3X75F9DqEOnDNIAR7xjM9mF+HAINN4DAHlLGIviEi+wi/k3ld/cruFgO90POH4BeSVPggN0L2NJE/Yy4Lnm; Received: from box313.bluehost.com ([69.89.31.113]:58096 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T6NxZ-0002fP-MU; Tue, 28 Aug 2012 09:44:09 -0600 Message-ID: <503CE749.7050006@labn.net> Date: Tue, 28 Aug 2012 11:44:09 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:44:14 -0000 Fei, On 8/28/2012 10:46 AM, zhang.fei3@zte.com.cn wrote: > > Lou > > - in the case of double sided provisioning *only* > 1. Association Source is set to an address selected by the node that > originates the association. (which may be a management entity.) > > Do you mean the assocition source can be neither A1 nor Z9 here? > Yes. The only requirement is (global) uniqueness. > 3.2.8 MPLS-TP Associated Bidirectional LSP Identifiers > > [RFC6370] defines the LSP associated identifiers based on the > signaling parameters of each unidirectional LSP. The combination > of each unidirectional LSP's parameters is used to identify the > Associated Bidirectional LSP. Using the mechanisms defined in > this document, any node that is along the path of both > unidirectional LSPs can identify which pair of unidirectional LSPs > support an Associated Bidirectional LSP as well as the signaling > parameters required by [RFC6370]. Note that the LSP end-points > will always be the path of both unidirectional LSPs. > > RFC6370 requires A1-global_ID and Z9-global_ID, how to push them > into the Extended ASSOCIATION object without new Association type? > Solving this issue, i.e., how to signal Global_ID of an LSP, is currently not within the scope of this document. Given it's such a small addition, I as a WG contributor, see no reason not to broaden the scope of this draft (assuming the WG agrees) to include such support. Although, I think the title and intro of the document will need to be updated to reflect this change. I'm also fine with keeping out of scope, and solving it elsewhere. Lou > Hope your clarification > > Thanks > > Fei > > > *Lou Berger * > > 2012-08-28 20:46 > > > ÊÕ¼þÈË > zhang.fei3@zte.com.cn > ³­ËÍ > "ccamp@ietf.org" , "Rakesh Gandhi (rgandhi)" > > Ö÷Ìâ > Re: [CCAMP] Review Request For Changes in > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > > > > > > > > Fei, > > I don't think the text addresses the issue of selection of association > object contents in the case of double sided provisioning. How about: > - in the case of double sided provisioning *only* > 1. Association Source is set to an address selected by the node that > originates the association. (which may be a management entity.) > 2. Association ID is a value assigned but the node that originates > the association. > 3. Global Association Source, when used, is set to the Global_ID of > the node that originates the association. > 4. Extended Association ID, when used, is selected by the node that > originates the association. > - If either (3) or (4) are used, an Extended ASSOCIATION object > [assoc-ext] is used. Otherwise a ASSOCIATION object [rfc4872] > is used > > - while we're at it, in the case of single sided provisioning *only* > (note only #1 differs) > 1. Association Source is set to an address assigned to the node that > originates the LSP. > 2. Association ID is a value assigned but the node that originates > the association. > 3. Global Association Source, when used, is set to the Global_ID of > the node that originates the association. > 4. Extended Association ID, when used, is selected by the node that > originates the association. > - If either (3) or (4) are used, an Extended ASSOCIATION object > [assoc-ext] is used. Otherwise a ASSOCIATION object [rfc4872] > is used > > I think the above addresses my point as it can be used to ensure unique > LSP association in all cases. BTW it also aligns very nicely with the > existing definition of the association objects. > > To address what I suspect is your concern, 3.2.8 can then become > something like (feel free to revise): > > 3.2.8 MPLS-TP Associated Bidirectional LSP Identifiers > > [RFC6370] defines the LSP associated identifiers based on the > signaling parameters of each unidirectional LSP. The combination > of each unidirectional LSP's parameters is used to identify the > Associated Bidirectional LSP. Using the mechanisms defined in > this document, any node that is along the path of both > unidirectional LSPs can identify which pair of unidirectional LSPs > support an Associated Bidirectional LSP as well as the signaling > parameters required by [RFC6370]. Note that the LSP end-points > will always be the path of both unidirectional LSPs. > > Lou > > On 8/27/2012 10:20 PM, zhang.fei3@zte.com.cn wrote: >> >> Thank you lou >> >> How about changing the descriptions in paragraph 3.2.8 >> >> In some scenarios, a node that is the association source MAY need to >> learn about the Global_ID [RFC6370] of the peer node, which can be >> done by inserting the ASSOCIATION object with Association Type "LSP >> identifiers" in the outgoing Path message and being carried back in >> the Resv message, as defined in [I-D, draft-zhang-ccamp-mpls-tp- >> rsvpte-ext-tunnel-num]. >> >> into >> >> In some scenarios, a node that is the association source MAY need to >> learn about the Global_ID [RFC6370] of the peer node. Although the >> scope of the draft [I-D, >> draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num] >> is limited to the co-routed bidirectional LSP, the defined procedures >> can >> be reused here also. The ASSOCIATION object with Association Type "LSP >> Identifiers" is inserted in the outgoing Path message at the association >> source and carried back in the corresponding Resv message. All the >> fields >> of the ASSOCIATION object except the Association Type in the Path >> message >> can be ignored by the receiver and the Global_ID of the peer node is >> pushed >> into the field of the Global Association Source in the Resv message. >> >> Best regards >> >> Fei >> >> >> *Lou Berger * >> >> 2012-08-28 02:30 >> >> >> ÊÕ¼þÈË >> zhang.fei3@zte.com.cn >> ³­ËÍ >> "ccamp@ietf.org" , "Rakesh Gandhi > (rgandhi)" >> >> Ö÷Ìâ >> Re: [CCAMP] Review Request For Changes in >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> >> >> >> >> >> >> >> Fei, >> The problem only exists in the double sided provisioing >> case, so no >> need to complicate the single sided provisioning case. >> >> Lou >> >> >> On 8/26/2012 9:03 PM, zhang.fei3@zte.com.cn wrote: >>> The administrative >>> approach can integrate both models, will be a good idea. >> >> > > From zhang.fei3@zte.com.cn Tue Aug 28 08:57:17 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EB721F856F for ; Tue, 28 Aug 2012 08:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.885 X-Spam-Level: X-Spam-Status: No, score=-95.885 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE0gn37-AzPl for ; Tue, 28 Aug 2012 08:57:16 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 71CA821F852C for ; Tue, 28 Aug 2012 08:57:15 -0700 (PDT) Received: from [10.30.3.20] by mx5.zte.com.cn with surfront esmtp id 232552685115152(version=TLSv1/SSLv3 cipher=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA bits=128 verify=NO); Tue, 28 Aug 2012 23:50:47 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q7SFv32X001069; Tue, 28 Aug 2012 23:57:03 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <503CE749.7050006@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: 626A302D:470AD7F9-48257A68:0056FADD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 28 Aug 2012 23:57:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-28 23:57:02, Serialize complete at 2012-08-28 23:57:02 Content-Type: multipart/alternative; boundary="=_alternative 005787CC48257A68_=" X-MAIL: mse01.zte.com.cn q7SFv32X001069 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:57:17 -0000 This is a multipart message in MIME format. --=_alternative 005787CC48257A68_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhhbmsgeW91IExvdSBmb3IgeW91ciBuaWNlIGludGVycHJldGF0aW9uDQoNCldlIHdpbGwgdXBk YXRlIHRoZSBwYXJhZ3JhcGggMy4yLjggYXMgeW91IHByb3Bvc2VkLg0KDQpSZWdhcmRzDQoNCkZl aQ0KDQoNCg0KTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gDQoyMDEyLTA4LTI4IDIzOjQ0 DQoNCsrVvP7Iyw0KemhhbmcuZmVpM0B6dGUuY29tLmNuDQqzrcvNDQoiY2NhbXBAaWV0Zi5vcmci IDxjY2FtcEBpZXRmLm9yZz4sICJSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSIgDQo8cmdhbmRoaUBj aXNjby5jb20+DQrW98ziDQpSZTogW0NDQU1QXSBSZXZpZXcgUmVxdWVzdCBGb3IgQ2hhbmdlcyBp biANCmRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0 LnR4dA0KDQoNCg0KDQoNCg0KRmVpLA0KDQpPbiA4LzI4LzIwMTIgMTA6NDYgQU0sIHpoYW5nLmZl aTNAenRlLmNvbS5jbiB3cm90ZToNCj4gDQo+IExvdQ0KPiANCj4gLSBpbiB0aGUgY2FzZSBvZiBk b3VibGUgc2lkZWQgcHJvdmlzaW9uaW5nICpvbmx5Kg0KPiAgMS4gQXNzb2NpYXRpb24gU291cmNl IGlzIHNldCB0byBhbiBhZGRyZXNzIHNlbGVjdGVkIGJ5IHRoZSBub2RlIHRoYXQNCj4gICAgIG9y aWdpbmF0ZXMgdGhlIGFzc29jaWF0aW9uLiAod2hpY2ggbWF5IGJlIGEgbWFuYWdlbWVudCBlbnRp dHkuKQ0KPiANCj4gPGZlaT4gRG8geW91IG1lYW4gdGhlIGFzc29jaXRpb24gc291cmNlIGNhbiBi ZSBuZWl0aGVyIEExIG5vciBaOSBoZXJlPw0KPiANCg0KWWVzLiAgVGhlIG9ubHkgcmVxdWlyZW1l bnQgaXMgKGdsb2JhbCkgdW5pcXVlbmVzcy4NCg0KPiAgIDMuMi44ICBNUExTLVRQIEFzc29jaWF0 ZWQgQmlkaXJlY3Rpb25hbCBMU1AgSWRlbnRpZmllcnMNCj4gDQo+ICBbUkZDNjM3MF0gZGVmaW5l cyB0aGUgTFNQIGFzc29jaWF0ZWQgaWRlbnRpZmllcnMgYmFzZWQgb24gdGhlDQo+ICBzaWduYWxp bmcgcGFyYW1ldGVycyBvZiBlYWNoIHVuaWRpcmVjdGlvbmFsIExTUC4gVGhlIGNvbWJpbmF0aW9u DQo+ICBvZiBlYWNoIHVuaWRpcmVjdGlvbmFsIExTUCdzIHBhcmFtZXRlcnMgaXMgdXNlZCB0byBp ZGVudGlmeSB0aGUNCj4gIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1AuICBVc2luZyB0aGUg bWVjaGFuaXNtcyBkZWZpbmVkIGluDQo+ICB0aGlzIGRvY3VtZW50LCBhbnkgbm9kZSB0aGF0IGlz IGFsb25nIHRoZSBwYXRoIG9mIGJvdGgNCj4gIHVuaWRpcmVjdGlvbmFsIExTUHMgY2FuIGlkZW50 aWZ5IHdoaWNoIHBhaXIgb2YgdW5pZGlyZWN0aW9uYWwgTFNQcw0KPiAgc3VwcG9ydCBhbiBBc3Nv Y2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQIGFzIHdlbGwgYXMgdGhlIHNpZ25hbGluZw0KPiAgcGFy YW1ldGVycyByZXF1aXJlZCBieSBbUkZDNjM3MF0uICBOb3RlIHRoYXQgdGhlIExTUCBlbmQtcG9p bnRzDQo+ICB3aWxsIGFsd2F5cyBiZSB0aGUgcGF0aCBvZiBib3RoIHVuaWRpcmVjdGlvbmFsIExT UHMuDQo+IA0KPiA8RmVpPiBSRkM2MzcwIHJlcXVpcmVzIEExLWdsb2JhbF9JRCBhbmQgWjktZ2xv YmFsX0lELCBob3cgdG8gcHVzaCB0aGVtDQo+IGludG8gdGhlIEV4dGVuZGVkIEFTU09DSUFUSU9O IG9iamVjdCB3aXRob3V0IG5ldyBBc3NvY2lhdGlvbiB0eXBlPw0KPiANCg0KU29sdmluZyB0aGlz IGlzc3VlLCBpLmUuLCBob3cgdG8gc2lnbmFsIEdsb2JhbF9JRCBvZiBhbiBMU1AsIGlzDQpjdXJy ZW50bHkgbm90IHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KR2l2ZW4gaXQn cyBzdWNoIGEgc21hbGwgYWRkaXRpb24sIEkgYXMgYSBXRyBjb250cmlidXRvciwgc2VlIG5vIHJl YXNvbg0Kbm90IHRvIGJyb2FkZW4gdGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQgKGFzc3VtaW5nIHRo ZSBXRyBhZ3JlZXMpIHRvDQppbmNsdWRlIHN1Y2ggc3VwcG9ydC4gQWx0aG91Z2gsIEkgdGhpbmsg dGhlIHRpdGxlIGFuZCBpbnRybyBvZiB0aGUNCmRvY3VtZW50IHdpbGwgbmVlZCB0byBiZSB1cGRh dGVkIHRvIHJlZmxlY3QgdGhpcyBjaGFuZ2UuICBJJ20gYWxzbyBmaW5lDQp3aXRoIGtlZXBpbmcg b3V0IG9mIHNjb3BlLCBhbmQgc29sdmluZyBpdCBlbHNld2hlcmUuDQoNCg0KTG91DQoNCj4gSG9w ZSB5b3VyIGNsYXJpZmljYXRpb24NCj4gDQo+IFRoYW5rcw0KPiANCj4gRmVpDQo+IA0KPiANCj4g KkxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+Kg0KPiANCj4gMjAxMi0wOC0yOCAyMDo0Ng0K PiANCj4gDQo+IMrVvP7Iyw0KPiAgICAgICAgICAgICAgICB6aGFuZy5mZWkzQHp0ZS5jb20uY24N Cj4gs63LzQ0KPiAgICAgICAgICAgICAgICAiY2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9y Zz4sICJSYWtlc2ggR2FuZGhpIA0KKHJnYW5kaGkpIg0KPiA8cmdhbmRoaUBjaXNjby5jb20+DQo+ INb3zOINCj4gICAgICAgICAgICAgICAgUmU6IFtDQ0FNUF0gUmV2aWV3IFJlcXVlc3QgRm9yIENo YW5nZXMgaW4NCj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRl ZC1sc3AtMDQudHh0DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gRmVpLA0KPiAN Cj4gSSBkb24ndCB0aGluayB0aGUgdGV4dCBhZGRyZXNzZXMgdGhlIGlzc3VlIG9mIHNlbGVjdGlv biBvZiBhc3NvY2lhdGlvbg0KPiBvYmplY3QgY29udGVudHMgaW4gdGhlIGNhc2Ugb2YgZG91Ymxl IHNpZGVkIHByb3Zpc2lvbmluZy4gIEhvdyBhYm91dDoNCj4gLSBpbiB0aGUgY2FzZSBvZiBkb3Vi bGUgc2lkZWQgcHJvdmlzaW9uaW5nICpvbmx5Kg0KPiAgMS4gQXNzb2NpYXRpb24gU291cmNlIGlz IHNldCB0byBhbiBhZGRyZXNzIHNlbGVjdGVkIGJ5IHRoZSBub2RlIHRoYXQNCj4gICAgIG9yaWdp bmF0ZXMgdGhlIGFzc29jaWF0aW9uLiAod2hpY2ggbWF5IGJlIGEgbWFuYWdlbWVudCBlbnRpdHku KQ0KPiAgMi4gQXNzb2NpYXRpb24gSUQgaXMgYSB2YWx1ZSBhc3NpZ25lZCBidXQgdGhlIG5vZGUg dGhhdCBvcmlnaW5hdGVzDQo+ICAgICB0aGUgYXNzb2NpYXRpb24uDQo+ICAzLiBHbG9iYWwgQXNz b2NpYXRpb24gU291cmNlLCB3aGVuIHVzZWQsIGlzIHNldCB0byB0aGUgR2xvYmFsX0lEIG9mDQo+ ICAgICB0aGUgbm9kZSB0aGF0IG9yaWdpbmF0ZXMgdGhlIGFzc29jaWF0aW9uLg0KPiAgNC4gRXh0 ZW5kZWQgQXNzb2NpYXRpb24gSUQsIHdoZW4gdXNlZCwgaXMgc2VsZWN0ZWQgYnkgdGhlIG5vZGUg dGhhdA0KPiAgICAgb3JpZ2luYXRlcyB0aGUgYXNzb2NpYXRpb24uDQo+ICAtICBJZiBlaXRoZXIg KDMpIG9yICg0KSBhcmUgdXNlZCwgYW4gRXh0ZW5kZWQgQVNTT0NJQVRJT04gb2JqZWN0DQo+ICAg ICBbYXNzb2MtZXh0XSBpcyB1c2VkLiAgT3RoZXJ3aXNlIGEgQVNTT0NJQVRJT04gb2JqZWN0IFty ZmM0ODcyXQ0KPiAgICAgaXMgdXNlZA0KPiANCj4gLSB3aGlsZSB3ZSdyZSBhdCBpdCwgaW4gdGhl IGNhc2Ugb2Ygc2luZ2xlIHNpZGVkIHByb3Zpc2lvbmluZyAqb25seSoNCj4gKG5vdGUgb25seSAj MSBkaWZmZXJzKQ0KPiAgMS4gQXNzb2NpYXRpb24gU291cmNlIGlzIHNldCB0byBhbiBhZGRyZXNz IGFzc2lnbmVkIHRvIHRoZSBub2RlIHRoYXQNCj4gICAgIG9yaWdpbmF0ZXMgdGhlIExTUC4NCj4g IDIuIEFzc29jaWF0aW9uIElEIGlzIGEgdmFsdWUgYXNzaWduZWQgYnV0IHRoZSBub2RlIHRoYXQg b3JpZ2luYXRlcw0KPiAgICAgdGhlIGFzc29jaWF0aW9uLg0KPiAgMy4gR2xvYmFsIEFzc29jaWF0 aW9uIFNvdXJjZSwgd2hlbiB1c2VkLCBpcyBzZXQgdG8gdGhlIEdsb2JhbF9JRCBvZg0KPiAgICAg dGhlIG5vZGUgdGhhdCBvcmlnaW5hdGVzIHRoZSBhc3NvY2lhdGlvbi4NCj4gIDQuIEV4dGVuZGVk IEFzc29jaWF0aW9uIElELCB3aGVuIHVzZWQsIGlzIHNlbGVjdGVkIGJ5IHRoZSBub2RlIHRoYXQN Cj4gICAgIG9yaWdpbmF0ZXMgdGhlIGFzc29jaWF0aW9uLg0KPiAgLSAgSWYgZWl0aGVyICgzKSBv ciAoNCkgYXJlIHVzZWQsIGFuIEV4dGVuZGVkIEFTU09DSUFUSU9OIG9iamVjdA0KPiAgICAgW2Fz c29jLWV4dF0gaXMgdXNlZC4gIE90aGVyd2lzZSBhIEFTU09DSUFUSU9OIG9iamVjdCBbcmZjNDg3 Ml0NCj4gICAgIGlzIHVzZWQNCj4gDQo+IEkgdGhpbmsgdGhlIGFib3ZlIGFkZHJlc3NlcyBteSBw b2ludCBhcyBpdCBjYW4gYmUgdXNlZCB0byBlbnN1cmUgdW5pcXVlDQo+IExTUCBhc3NvY2lhdGlv biBpbiBhbGwgY2FzZXMuICBCVFcgaXQgYWxzbyBhbGlnbnMgdmVyeSBuaWNlbHkgd2l0aCB0aGUN Cj4gZXhpc3RpbmcgZGVmaW5pdGlvbiBvZiB0aGUgYXNzb2NpYXRpb24gb2JqZWN0cy4NCj4gDQo+ IFRvIGFkZHJlc3Mgd2hhdCBJIHN1c3BlY3QgaXMgeW91ciBjb25jZXJuLCAzLjIuOCBjYW4gdGhl biBiZWNvbWUNCj4gc29tZXRoaW5nIGxpa2UgKGZlZWwgZnJlZSB0byByZXZpc2UpOg0KPiANCj4g IDMuMi44ICBNUExTLVRQIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1AgSWRlbnRpZmllcnMN Cj4gDQo+ICBbUkZDNjM3MF0gZGVmaW5lcyB0aGUgTFNQIGFzc29jaWF0ZWQgaWRlbnRpZmllcnMg YmFzZWQgb24gdGhlDQo+ICBzaWduYWxpbmcgcGFyYW1ldGVycyBvZiBlYWNoIHVuaWRpcmVjdGlv bmFsIExTUC4gVGhlIGNvbWJpbmF0aW9uDQo+ICBvZiBlYWNoIHVuaWRpcmVjdGlvbmFsIExTUCdz IHBhcmFtZXRlcnMgaXMgdXNlZCB0byBpZGVudGlmeSB0aGUNCj4gIEFzc29jaWF0ZWQgQmlkaXJl Y3Rpb25hbCBMU1AuICBVc2luZyB0aGUgbWVjaGFuaXNtcyBkZWZpbmVkIGluDQo+ICB0aGlzIGRv Y3VtZW50LCBhbnkgbm9kZSB0aGF0IGlzIGFsb25nIHRoZSBwYXRoIG9mIGJvdGgNCj4gIHVuaWRp cmVjdGlvbmFsIExTUHMgY2FuIGlkZW50aWZ5IHdoaWNoIHBhaXIgb2YgdW5pZGlyZWN0aW9uYWwg TFNQcw0KPiAgc3VwcG9ydCBhbiBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQIGFzIHdlbGwg YXMgdGhlIHNpZ25hbGluZw0KPiAgcGFyYW1ldGVycyByZXF1aXJlZCBieSBbUkZDNjM3MF0uICBO b3RlIHRoYXQgdGhlIExTUCBlbmQtcG9pbnRzDQo+ICB3aWxsIGFsd2F5cyBiZSB0aGUgcGF0aCBv ZiBib3RoIHVuaWRpcmVjdGlvbmFsIExTUHMuDQo+IA0KPiBMb3UNCj4gDQo+IE9uIDgvMjcvMjAx MiAxMDoyMCBQTSwgemhhbmcuZmVpM0B6dGUuY29tLmNuIHdyb3RlOg0KPj4NCj4+IFRoYW5rIHlv dSBsb3UNCj4+DQo+PiBIb3cgYWJvdXQgY2hhbmdpbmcgdGhlIGRlc2NyaXB0aW9ucyBpbiBwYXJh Z3JhcGggMy4yLjgNCj4+DQo+PiAgICBJbiBzb21lIHNjZW5hcmlvcywgYSBub2RlIHRoYXQgaXMg dGhlIGFzc29jaWF0aW9uIHNvdXJjZSBNQVkgbmVlZCB0bw0KPj4gICBsZWFybiBhYm91dCB0aGUg R2xvYmFsX0lEIFtSRkM2MzcwXSBvZiB0aGUgcGVlciBub2RlLCB3aGljaCBjYW4gYmUNCj4+ICAg ZG9uZSBieSBpbnNlcnRpbmcgdGhlIEFTU09DSUFUSU9OIG9iamVjdCB3aXRoIEFzc29jaWF0aW9u IFR5cGUgIkxTUA0KPj4gICBpZGVudGlmaWVycyIgaW4gdGhlIG91dGdvaW5nIFBhdGggbWVzc2Fn ZSBhbmQgYmVpbmcgY2FycmllZCBiYWNrIGluDQo+PiAgIHRoZSBSZXN2IG1lc3NhZ2UsIGFzIGRl ZmluZWQgaW4gW0ktRCwgZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC0NCj4+ICAgcnN2cHRlLWV4 dC10dW5uZWwtbnVtXS4NCj4+DQo+PiBpbnRvDQo+Pg0KPj4gICAgSW4gc29tZSBzY2VuYXJpb3Ms IGEgbm9kZSB0aGF0IGlzIHRoZSBhc3NvY2lhdGlvbiBzb3VyY2UgTUFZIG5lZWQgdG8NCj4+ICAg bGVhcm4gYWJvdXQgdGhlIEdsb2JhbF9JRCBbUkZDNjM3MF0gb2YgdGhlIHBlZXIgbm9kZS4gQWx0 aG91Z2ggdGhlDQo+PiAgICBzY29wZSBvZiB0aGUgZHJhZnQgW0ktRCwNCj4+IGRyYWZ0LXpoYW5n LWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtXQ0KPj4gICAgaXMgbGltaXRlZCB0 byB0aGUgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLCB0aGUgZGVmaW5lZCANCnByb2NlZHVy ZXMNCj4+IGNhbg0KPj4gICAgYmUgcmV1c2VkIGhlcmUgYWxzby4gVGhlIEFTU09DSUFUSU9OIG9i amVjdCB3aXRoIEFzc29jaWF0aW9uIFR5cGUgDQoiTFNQDQo+PiAgIElkZW50aWZpZXJzIiBpcyBp bnNlcnRlZCBpbiB0aGUgb3V0Z29pbmcgUGF0aCBtZXNzYWdlIGF0IHRoZSANCmFzc29jaWF0aW9u DQo+PiAgICBzb3VyY2UgYW5kIGNhcnJpZWQgYmFjayBpbiB0aGUgY29ycmVzcG9uZGluZyBSZXN2 IG1lc3NhZ2UuIEFsbCB0aGUNCj4+IGZpZWxkcw0KPj4gICAgb2YgdGhlIEFTU09DSUFUSU9OIG9i amVjdCBleGNlcHQgdGhlIEFzc29jaWF0aW9uIFR5cGUgaW4gdGhlIFBhdGgNCj4+IG1lc3NhZ2UN Cj4+ICAgIGNhbiBiZSBpZ25vcmVkIGJ5IHRoZSByZWNlaXZlciBhbmQgdGhlIEdsb2JhbF9JRCBv ZiB0aGUgcGVlciBub2RlIGlzDQo+PiBwdXNoZWQNCj4+ICAgIGludG8gdGhlIGZpZWxkIG9mIHRo ZSBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlIGluIHRoZSBSZXN2IG1lc3NhZ2UuDQo+Pg0KPj4g QmVzdCByZWdhcmRzDQo+Pg0KPj4gRmVpDQo+Pg0KPj4NCj4+ICpMb3UgQmVyZ2VyIDxsYmVyZ2Vy QGxhYm4ubmV0PioNCj4+DQo+PiAyMDEyLTA4LTI4IDAyOjMwDQo+Pg0KPj4gDQo+PiDK1bz+yMsN Cj4+ICAgICAgICAgICAgICAgICAgemhhbmcuZmVpM0B6dGUuY29tLmNuDQo+PiCzrcvNDQo+PiAg ICAgICAgICAgICAgICAgICJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPiwgIlJha2Vz aCBHYW5kaGkNCj4gKHJnYW5kaGkpIg0KPj4gPHJnYW5kaGlAY2lzY28uY29tPg0KPj4g1vfM4g0K Pj4gICAgICAgICAgICAgICAgICBSZTogW0NDQU1QXSBSZXZpZXcgUmVxdWVzdCBGb3IgQ2hhbmdl cyBpbg0KPj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1s c3AtMDQudHh0DQo+Pg0KPj4NCj4+IA0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiBGZWksDQo+PiAg ICAgICAgICAgICAgICAgVGhlIHByb2JsZW0gb25seSBleGlzdHMgaW4gdGhlIGRvdWJsZSBzaWRl ZCBwcm92aXNpb2luZw0KPj4gY2FzZSwgc28gbm8NCj4+IG5lZWQgdG8gY29tcGxpY2F0ZSB0aGUg c2luZ2xlIHNpZGVkIHByb3Zpc2lvbmluZyBjYXNlLg0KPj4NCj4+IExvdQ0KPj4NCj4+DQo+PiBP biA4LzI2LzIwMTIgOTowMyBQTSwgemhhbmcuZmVpM0B6dGUuY29tLmNuIHdyb3RlOg0KPj4+IFRo ZSBhZG1pbmlzdHJhdGl2ZQ0KPj4+IGFwcHJvYWNoIGNhbiBpbnRlZ3JhdGUgYm90aCBtb2RlbHMs IHdpbGwgYmUgYSBnb29kIGlkZWEuDQo+Pg0KPj4NCj4gDQo+IA0KDQoNCg0K --=_alternative 005787CC48257A68_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rIHlvdSBMb3UgZm9yIHlv dXIgbmljZSBpbnRlcnByZXRhdGlvbjwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PldlIHdpbGwgdXBkYXRlIHRoZSBwYXJhZ3JhcGggMy4yLjggYXMgeW91IHByb3Bvc2VkLjwvZm9u dD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+UmVnYXJkczwvZm9udD48L3R0Pg0K PGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+RmVpPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+TG91IEJlcmdlciAmbHQ7bGJlcmdlckBs YWJuLm5ldCZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+MjAxMi0wOC0yOCAyMzo0NDwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj56aGFuZy5mZWkzQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPiZxdW90O2NjYW1wQGlldGYub3JnJnF1b3Q7ICZsdDtjY2FtcEBpZXRmLm9yZyZndDssDQom cXVvdDtSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSZxdW90OyAmbHQ7cmdhbmRoaUBjaXNjby5jb20m Z3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW0NDQU1QXSBSZXZpZXcgUmVxdWVzdCBGb3IgQ2hh bmdlcw0KaW4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1s c3AtMDQudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj5GZWksPGJyPg0KPGJyPg0KT24gOC8yOC8yMDEyIDEwOjQ2IEFNLCB6aGFuZy5m ZWkzQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IExvdTxicj4NCiZndDsg PGJyPg0KJmd0OyAtIGluIHRoZSBjYXNlIG9mIGRvdWJsZSBzaWRlZCBwcm92aXNpb25pbmcgKm9u bHkqPGJyPg0KJmd0OyAmbmJzcDsxLiBBc3NvY2lhdGlvbiBTb3VyY2UgaXMgc2V0IHRvIGFuIGFk ZHJlc3Mgc2VsZWN0ZWQgYnkgdGhlIG5vZGUNCnRoYXQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg b3JpZ2luYXRlcyB0aGUgYXNzb2NpYXRpb24uICh3aGljaCBtYXkgYmUgYSBtYW5hZ2VtZW50DQpl bnRpdHkuKTxicj4NCiZndDsgPGJyPg0KJmd0OyAmbHQ7ZmVpJmd0OyBEbyB5b3UgbWVhbiB0aGUg YXNzb2NpdGlvbiBzb3VyY2UgY2FuIGJlIG5laXRoZXIgQTEgbm9yDQpaOSBoZXJlPzxicj4NCiZn dDsgPGJyPg0KPGJyPg0KWWVzLiAmbmJzcDtUaGUgb25seSByZXF1aXJlbWVudCBpcyAoZ2xvYmFs KSB1bmlxdWVuZXNzLjxicj4NCjxicj4NCiZndDsgJm5ic3A7IDMuMi44ICZuYnNwO01QTFMtVFAg QXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUCBJZGVudGlmaWVyczxicj4NCiZndDsgPGJyPg0K Jmd0OyAmbmJzcDtbUkZDNjM3MF0gZGVmaW5lcyB0aGUgTFNQIGFzc29jaWF0ZWQgaWRlbnRpZmll cnMgYmFzZWQgb24gdGhlPGJyPg0KJmd0OyAmbmJzcDtzaWduYWxpbmcgcGFyYW1ldGVycyBvZiBl YWNoIHVuaWRpcmVjdGlvbmFsIExTUC4gVGhlIGNvbWJpbmF0aW9uPGJyPg0KJmd0OyAmbmJzcDtv ZiBlYWNoIHVuaWRpcmVjdGlvbmFsIExTUCdzIHBhcmFtZXRlcnMgaXMgdXNlZCB0byBpZGVudGlm eQ0KdGhlPGJyPg0KJmd0OyAmbmJzcDtBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQLiAmbmJz cDtVc2luZyB0aGUgbWVjaGFuaXNtcyBkZWZpbmVkDQppbjxicj4NCiZndDsgJm5ic3A7dGhpcyBk b2N1bWVudCwgYW55IG5vZGUgdGhhdCBpcyBhbG9uZyB0aGUgcGF0aCBvZiBib3RoPGJyPg0KJmd0 OyAmbmJzcDt1bmlkaXJlY3Rpb25hbCBMU1BzIGNhbiBpZGVudGlmeSB3aGljaCBwYWlyIG9mIHVu aWRpcmVjdGlvbmFsDQpMU1BzPGJyPg0KJmd0OyAmbmJzcDtzdXBwb3J0IGFuIEFzc29jaWF0ZWQg QmlkaXJlY3Rpb25hbCBMU1AgYXMgd2VsbCBhcyB0aGUgc2lnbmFsaW5nPGJyPg0KJmd0OyAmbmJz cDtwYXJhbWV0ZXJzIHJlcXVpcmVkIGJ5IFtSRkM2MzcwXS4gJm5ic3A7Tm90ZSB0aGF0IHRoZSBM U1AgZW5kLXBvaW50czxicj4NCiZndDsgJm5ic3A7d2lsbCBhbHdheXMgYmUgdGhlIHBhdGggb2Yg Ym90aCB1bmlkaXJlY3Rpb25hbCBMU1BzLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbHQ7RmVpJmd0 OyBSRkM2MzcwIHJlcXVpcmVzIEExLWdsb2JhbF9JRCBhbmQgWjktZ2xvYmFsX0lELCBob3cgdG8N CnB1c2ggdGhlbTxicj4NCiZndDsgaW50byB0aGUgRXh0ZW5kZWQgQVNTT0NJQVRJT04gb2JqZWN0 IHdpdGhvdXQgbmV3IEFzc29jaWF0aW9uIHR5cGU/PGJyPg0KJmd0OyAmbmJzcDs8YnI+DQo8YnI+ DQpTb2x2aW5nIHRoaXMgaXNzdWUsIGkuZS4sIGhvdyB0byBzaWduYWwgR2xvYmFsX0lEIG9mIGFu IExTUCwgaXM8YnI+DQpjdXJyZW50bHkgbm90IHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1 bWVudC48YnI+DQo8YnI+DQpHaXZlbiBpdCdzIHN1Y2ggYSBzbWFsbCBhZGRpdGlvbiwgSSBhcyBh IFdHIGNvbnRyaWJ1dG9yLCBzZWUgbm8gcmVhc29uPGJyPg0Kbm90IHRvIGJyb2FkZW4gdGhlIHNj b3BlIG9mIHRoaXMgZHJhZnQgKGFzc3VtaW5nIHRoZSBXRyBhZ3JlZXMpIHRvPGJyPg0KaW5jbHVk ZSBzdWNoIHN1cHBvcnQuIEFsdGhvdWdoLCBJIHRoaW5rIHRoZSB0aXRsZSBhbmQgaW50cm8gb2Yg dGhlPGJyPg0KZG9jdW1lbnQgd2lsbCBuZWVkIHRvIGJlIHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGlz IGNoYW5nZS4gJm5ic3A7SSdtIGFsc28NCmZpbmU8YnI+DQp3aXRoIGtlZXBpbmcgb3V0IG9mIHNj b3BlLCBhbmQgc29sdmluZyBpdCBlbHNld2hlcmUuPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj48YnI+DQpMb3U8YnI+DQo8YnI+DQomZ3Q7IEhvcGUgeW91ciBjbGFyaWZp Y2F0aW9uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rczxicj4NCiZndDsgPGJyPg0KJmd0OyBG ZWk8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAqTG91IEJlcmdlciAmbHQ7bGJlcmdl ckBsYWJuLm5ldCZndDsqPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDIwMTItMDgtMjggMjA6NDY8YnI+ DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7IMrVvP7Iyzxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt6 aGFuZy5mZWkzQHp0ZS5jb20uY248YnI+DQomZ3Q7ILOty808YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7 Y2NhbXBAaWV0Zi5vcmcmcXVvdDsNCiZsdDtjY2FtcEBpZXRmLm9yZyZndDssICZxdW90O1Jha2Vz aCBHYW5kaGkgKHJnYW5kaGkpJnF1b3Q7PGJyPg0KJmd0OyAmbHQ7cmdhbmRoaUBjaXNjby5jb20m Z3Q7PGJyPg0KJmd0OyDW98ziPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JlOg0KW0NDQU1QXSBSZXZpZXcgUmVx dWVzdCBGb3IgQ2hhbmdlcyBpbjxicj4NCiZndDsgZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJz dnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyBGZWksPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgZG9uJ3QgdGhp bmsgdGhlIHRleHQgYWRkcmVzc2VzIHRoZSBpc3N1ZSBvZiBzZWxlY3Rpb24gb2YgYXNzb2NpYXRp b248YnI+DQomZ3Q7IG9iamVjdCBjb250ZW50cyBpbiB0aGUgY2FzZSBvZiBkb3VibGUgc2lkZWQg cHJvdmlzaW9uaW5nLiAmbmJzcDtIb3cNCmFib3V0Ojxicj4NCiZndDsgLSBpbiB0aGUgY2FzZSBv ZiBkb3VibGUgc2lkZWQgcHJvdmlzaW9uaW5nICpvbmx5Kjxicj4NCiZndDsgJm5ic3A7MS4gQXNz b2NpYXRpb24gU291cmNlIGlzIHNldCB0byBhbiBhZGRyZXNzIHNlbGVjdGVkIGJ5IHRoZSBub2Rl DQp0aGF0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IG9yaWdpbmF0ZXMgdGhlIGFzc29jaWF0aW9u LiAod2hpY2ggbWF5IGJlIGEgbWFuYWdlbWVudA0KZW50aXR5Lik8YnI+DQomZ3Q7ICZuYnNwOzIu IEFzc29jaWF0aW9uIElEIGlzIGEgdmFsdWUgYXNzaWduZWQgYnV0IHRoZSBub2RlIHRoYXQgb3Jp Z2luYXRlczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB0aGUgYXNzb2NpYXRpb24uPGJyPg0KJmd0 OyAmbmJzcDszLiBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlLCB3aGVuIHVzZWQsIGlzIHNldCB0 byB0aGUgR2xvYmFsX0lEDQpvZjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB0aGUgbm9kZSB0aGF0 IG9yaWdpbmF0ZXMgdGhlIGFzc29jaWF0aW9uLjxicj4NCiZndDsgJm5ic3A7NC4gRXh0ZW5kZWQg QXNzb2NpYXRpb24gSUQsIHdoZW4gdXNlZCwgaXMgc2VsZWN0ZWQgYnkgdGhlIG5vZGUNCnRoYXQ8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgb3JpZ2luYXRlcyB0aGUgYXNzb2NpYXRpb24uPGJyPg0K Jmd0OyAmbmJzcDstICZuYnNwO0lmIGVpdGhlciAoMykgb3IgKDQpIGFyZSB1c2VkLCBhbiBFeHRl bmRlZCBBU1NPQ0lBVElPTg0Kb2JqZWN0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IFthc3NvYy1l eHRdIGlzIHVzZWQuICZuYnNwO090aGVyd2lzZSBhIEFTU09DSUFUSU9OIG9iamVjdA0KW3JmYzQ4 NzJdPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGlzIHVzZWQ8YnI+DQomZ3Q7IDxicj4NCiZndDsg LSB3aGlsZSB3ZSdyZSBhdCBpdCwgaW4gdGhlIGNhc2Ugb2Ygc2luZ2xlIHNpZGVkIHByb3Zpc2lv bmluZyAqb25seSo8YnI+DQomZ3Q7IChub3RlIG9ubHkgIzEgZGlmZmVycyk8YnI+DQomZ3Q7ICZu YnNwOzEuIEFzc29jaWF0aW9uIFNvdXJjZSBpcyBzZXQgdG8gYW4gYWRkcmVzcyBhc3NpZ25lZCB0 byB0aGUgbm9kZQ0KdGhhdDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBvcmlnaW5hdGVzIHRoZSBM U1AuPGJyPg0KJmd0OyAmbmJzcDsyLiBBc3NvY2lhdGlvbiBJRCBpcyBhIHZhbHVlIGFzc2lnbmVk IGJ1dCB0aGUgbm9kZSB0aGF0IG9yaWdpbmF0ZXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgdGhl IGFzc29jaWF0aW9uLjxicj4NCiZndDsgJm5ic3A7My4gR2xvYmFsIEFzc29jaWF0aW9uIFNvdXJj ZSwgd2hlbiB1c2VkLCBpcyBzZXQgdG8gdGhlIEdsb2JhbF9JRA0Kb2Y8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgdGhlIG5vZGUgdGhhdCBvcmlnaW5hdGVzIHRoZSBhc3NvY2lhdGlvbi48YnI+DQom Z3Q7ICZuYnNwOzQuIEV4dGVuZGVkIEFzc29jaWF0aW9uIElELCB3aGVuIHVzZWQsIGlzIHNlbGVj dGVkIGJ5IHRoZSBub2RlDQp0aGF0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IG9yaWdpbmF0ZXMg dGhlIGFzc29jaWF0aW9uLjxicj4NCiZndDsgJm5ic3A7LSAmbmJzcDtJZiBlaXRoZXIgKDMpIG9y ICg0KSBhcmUgdXNlZCwgYW4gRXh0ZW5kZWQgQVNTT0NJQVRJT04NCm9iamVjdDxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyBbYXNzb2MtZXh0XSBpcyB1c2VkLiAmbmJzcDtPdGhlcndpc2UgYSBBU1NP Q0lBVElPTiBvYmplY3QNCltyZmM0ODcyXTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBpcyB1c2Vk PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgdGhpbmsgdGhlIGFib3ZlIGFkZHJlc3NlcyBteSBwb2lu dCBhcyBpdCBjYW4gYmUgdXNlZCB0byBlbnN1cmUgdW5pcXVlPGJyPg0KJmd0OyBMU1AgYXNzb2Np YXRpb24gaW4gYWxsIGNhc2VzLiAmbmJzcDtCVFcgaXQgYWxzbyBhbGlnbnMgdmVyeSBuaWNlbHkN CndpdGggdGhlPGJyPg0KJmd0OyBleGlzdGluZyBkZWZpbml0aW9uIG9mIHRoZSBhc3NvY2lhdGlv biBvYmplY3RzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUbyBhZGRyZXNzIHdoYXQgSSBzdXNwZWN0 IGlzIHlvdXIgY29uY2VybiwgMy4yLjggY2FuIHRoZW4gYmVjb21lPGJyPg0KJmd0OyBzb21ldGhp bmcgbGlrZSAoZmVlbCBmcmVlIHRvIHJldmlzZSk6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNw OzMuMi44ICZuYnNwO01QTFMtVFAgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUCBJZGVudGlm aWVyczxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDtbUkZDNjM3MF0gZGVmaW5lcyB0aGUgTFNQ IGFzc29jaWF0ZWQgaWRlbnRpZmllcnMgYmFzZWQgb24gdGhlPGJyPg0KJmd0OyAmbmJzcDtzaWdu YWxpbmcgcGFyYW1ldGVycyBvZiBlYWNoIHVuaWRpcmVjdGlvbmFsIExTUC4gVGhlIGNvbWJpbmF0 aW9uPGJyPg0KJmd0OyAmbmJzcDtvZiBlYWNoIHVuaWRpcmVjdGlvbmFsIExTUCdzIHBhcmFtZXRl cnMgaXMgdXNlZCB0byBpZGVudGlmeQ0KdGhlPGJyPg0KJmd0OyAmbmJzcDtBc3NvY2lhdGVkIEJp ZGlyZWN0aW9uYWwgTFNQLiAmbmJzcDtVc2luZyB0aGUgbWVjaGFuaXNtcyBkZWZpbmVkDQppbjxi cj4NCiZndDsgJm5ic3A7dGhpcyBkb2N1bWVudCwgYW55IG5vZGUgdGhhdCBpcyBhbG9uZyB0aGUg cGF0aCBvZiBib3RoPGJyPg0KJmd0OyAmbmJzcDt1bmlkaXJlY3Rpb25hbCBMU1BzIGNhbiBpZGVu dGlmeSB3aGljaCBwYWlyIG9mIHVuaWRpcmVjdGlvbmFsDQpMU1BzPGJyPg0KJmd0OyAmbmJzcDtz dXBwb3J0IGFuIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1AgYXMgd2VsbCBhcyB0aGUgc2ln bmFsaW5nPGJyPg0KJmd0OyAmbmJzcDtwYXJhbWV0ZXJzIHJlcXVpcmVkIGJ5IFtSRkM2MzcwXS4g Jm5ic3A7Tm90ZSB0aGF0IHRoZSBMU1AgZW5kLXBvaW50czxicj4NCiZndDsgJm5ic3A7d2lsbCBh bHdheXMgYmUgdGhlIHBhdGggb2YgYm90aCB1bmlkaXJlY3Rpb25hbCBMU1BzLjxicj4NCiZndDsg PGJyPg0KJmd0OyBMb3U8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gOC8yNy8yMDEyIDEwOjIwIFBN LCB6aGFuZy5mZWkzQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBUaGFuayB5b3UgbG91PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBIb3cgYWJvdXQgY2hh bmdpbmcgdGhlIGRlc2NyaXB0aW9ucyBpbiBwYXJhZ3JhcGggMy4yLjg8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtJbiBzb21lIHNjZW5hcmlvcywgYSBub2RlIHRoYXQg aXMgdGhlIGFzc29jaWF0aW9uDQpzb3VyY2UgTUFZIG5lZWQgdG88YnI+DQomZ3Q7Jmd0OyAmbmJz cDsgbGVhcm4gYWJvdXQgdGhlIEdsb2JhbF9JRCBbUkZDNjM3MF0gb2YgdGhlIHBlZXIgbm9kZSwg d2hpY2gNCmNhbiBiZTxicj4NCiZndDsmZ3Q7ICZuYnNwOyBkb25lIGJ5IGluc2VydGluZyB0aGUg QVNTT0NJQVRJT04gb2JqZWN0IHdpdGggQXNzb2NpYXRpb24NClR5cGUgJnF1b3Q7TFNQPGJyPg0K Jmd0OyZndDsgJm5ic3A7IGlkZW50aWZpZXJzJnF1b3Q7IGluIHRoZSBvdXRnb2luZyBQYXRoIG1l c3NhZ2UgYW5kIGJlaW5nDQpjYXJyaWVkIGJhY2sgaW48YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgdGhl IFJlc3YgbWVzc2FnZSwgYXMgZGVmaW5lZCBpbiBbSS1ELCBkcmFmdC16aGFuZy1jY2FtcC1tcGxz LXRwLTxicj4NCiZndDsmZ3Q7ICZuYnNwOyByc3ZwdGUtZXh0LXR1bm5lbC1udW1dLjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgaW50bzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5i c3A7ICZuYnNwO0luIHNvbWUgc2NlbmFyaW9zLCBhIG5vZGUgdGhhdCBpcyB0aGUgYXNzb2NpYXRp b24NCnNvdXJjZSBNQVkgbmVlZCB0bzxicj4NCiZndDsmZ3Q7ICZuYnNwOyBsZWFybiBhYm91dCB0 aGUgR2xvYmFsX0lEIFtSRkM2MzcwXSBvZiB0aGUgcGVlciBub2RlLiBBbHRob3VnaA0KdGhlPGJy Pg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO3Njb3BlIG9mIHRoZSBkcmFmdCBbSS1ELDxicj4NCiZn dDsmZ3Q7IGRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtXTxi cj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtpcyBsaW1pdGVkIHRvIHRoZSBjby1yb3V0ZWQgYmlk aXJlY3Rpb25hbCBMU1AsIHRoZQ0KZGVmaW5lZCBwcm9jZWR1cmVzPGJyPg0KJmd0OyZndDsgY2Fu PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO2JlIHJldXNlZCBoZXJlIGFsc28uIFRoZSBBU1NP Q0lBVElPTiBvYmplY3Qgd2l0aA0KQXNzb2NpYXRpb24gVHlwZSAmcXVvdDtMU1A8YnI+DQomZ3Q7 Jmd0OyAmbmJzcDsgSWRlbnRpZmllcnMmcXVvdDsgaXMgaW5zZXJ0ZWQgaW4gdGhlIG91dGdvaW5n IFBhdGggbWVzc2FnZQ0KYXQgdGhlIGFzc29jaWF0aW9uPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZu YnNwO3NvdXJjZSBhbmQgY2FycmllZCBiYWNrIGluIHRoZSBjb3JyZXNwb25kaW5nIFJlc3YNCm1l c3NhZ2UuIEFsbCB0aGU8YnI+DQomZ3Q7Jmd0OyBmaWVsZHM8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsg Jm5ic3A7b2YgdGhlIEFTU09DSUFUSU9OIG9iamVjdCBleGNlcHQgdGhlIEFzc29jaWF0aW9uDQpU eXBlIGluIHRoZSBQYXRoPGJyPg0KJmd0OyZndDsgbWVzc2FnZTxicj4NCiZndDsmZ3Q7ICZuYnNw OyAmbmJzcDtjYW4gYmUgaWdub3JlZCBieSB0aGUgcmVjZWl2ZXIgYW5kIHRoZSBHbG9iYWxfSUQN Cm9mIHRoZSBwZWVyIG5vZGUgaXM8YnI+DQomZ3Q7Jmd0OyBwdXNoZWQ8YnI+DQomZ3Q7Jmd0OyAm bmJzcDsgJm5ic3A7aW50byB0aGUgZmllbGQgb2YgdGhlIEdsb2JhbCBBc3NvY2lhdGlvbiBTb3Vy Y2UgaW4NCnRoZSBSZXN2IG1lc3NhZ2UuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBCZXN0 IHJlZ2FyZHM8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZlaTxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAqTG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5l dCZndDsqPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAyMDEyLTA4LTI4IDAyOjMwPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsmZ3Q7IMrVvP7Iyzxicj4NCiZn dDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7emhhbmcuZmVpM0B6dGUuY29tLmNuPGJyPg0KJmd0OyZndDsgs63LzTxicj4N CiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7JnF1b3Q7Y2NhbXBAaWV0Zi5vcmcmcXVvdDsNCiZsdDtjY2FtcEBpZXRm Lm9yZyZndDssICZxdW90O1Jha2VzaCBHYW5kaGk8YnI+DQomZ3Q7IChyZ2FuZGhpKSZxdW90Ozxi cj4NCiZndDsmZ3Q7ICZsdDtyZ2FuZGhpQGNpc2NvLmNvbSZndDs8YnI+DQomZ3Q7Jmd0OyDW98zi PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtSZToNCltDQ0FNUF0gUmV2aWV3IFJlcXVlc3QgRm9yIENoYW5n ZXMgaW48YnI+DQomZ3Q7Jmd0OyBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1h c3NvY2lhdGVkLWxzcC0wNC50eHQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRmVpLDxicj4NCiZndDsmZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg VGhlIHByb2JsZW0NCm9ubHkgZXhpc3RzIGluIHRoZSBkb3VibGUgc2lkZWQgcHJvdmlzaW9pbmc8 YnI+DQomZ3Q7Jmd0OyBjYXNlLCBzbyBubzxicj4NCiZndDsmZ3Q7IG5lZWQgdG8gY29tcGxpY2F0 ZSB0aGUgc2luZ2xlIHNpZGVkIHByb3Zpc2lvbmluZyBjYXNlLjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgTG91PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9u IDgvMjYvMjAxMiA5OjAzIFBNLCB6aGFuZy5mZWkzQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0 OyZndDsmZ3Q7IFRoZSBhZG1pbmlzdHJhdGl2ZTxicj4NCiZndDsmZ3Q7Jmd0OyBhcHByb2FjaCBj YW4gaW50ZWdyYXRlIGJvdGggbW9kZWxzLCB3aWxsIGJlIGEgZ29vZCBpZGVhLjxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KPGJyPg0KPC9mb250 PjwvdHQ+DQo8YnI+DQo= --=_alternative 005787CC48257A68_=-- From lberger@labn.net Tue Aug 28 09:02:09 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEA711E808D for ; Tue, 28 Aug 2012 09:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.161 X-Spam-Level: X-Spam-Status: No, score=-98.161 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtW0nywojH8M for ; Tue, 28 Aug 2012 09:02:08 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 823AA11E80F8 for ; Tue, 28 Aug 2012 09:02:08 -0700 (PDT) Received: (qmail 9772 invoked by uid 0); 28 Aug 2012 16:02:06 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 28 Aug 2012 16:02:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=T1yIj3r14kxZ3LKZ6NUziQDZlODQ9bIEbt3dYWUW5JM=; b=ffmK2J/Ai79i146j1u5q23maNW6NmBOe4wwiV0hH1T8Mz/TgYHdnATJaLp1MUVNu9C7hD1l0VHUjLgPg27v2jCLqR8zGYcPI4baWN9eMvzEj4BUtojmVHH2rBS22Dle2; Received: from box313.bluehost.com ([69.89.31.113]:59882 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T6OEv-0001XX-Ij; Tue, 28 Aug 2012 10:02:06 -0600 Message-ID: <503CEB7D.1050401@labn.net> Date: Tue, 28 Aug 2012 12:02:05 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Rakesh Gandhi (rgandhi)" References: <503CBDC2.9040308@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:02:09 -0000 Rakesh, See below. On 8/28/2012 11:28 AM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, > > Please see inline.... > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, August 28, 2012 8:47 AM > To: zhang.fei3@zte.com.cn > Cc: ccamp@ietf.org; Rakesh Gandhi (rgandhi) > Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > Fei, > > I don't think the text addresses the issue of selection of association object contents in the case of double sided provisioning. How about: > - in the case of double sided provisioning *only* > 1. Association Source is set to an address selected by the node that > originates the association. (which may be a management entity.) > >> For double sided provisioning, both sides can originate the >> LSPs independently. In this case, there needs to be a rule for a >> default behavior on which side becomes the association source and >> hence the proposal to pick the side with lower IP address for the >> source. Why are you assuming that one of the endpoints must be the source? The key requirement is that the source+ID(s) must be unique. This means that ID(s) must be selected or obtained from the association source. >> This rule can be overridden by the management entity to >> designate a side to become an association source. This is where we disagree. IMO the entity that selects the ID(s) is the source and must provide the IP address in which the ID is scoped. > > > 2. Association ID is a value assigned but the node that originates > the association. > 3. Global Association Source, when used, is set to the Global_ID of > the node that originates the association. > 4. Extended Association ID, when used, is selected by the node that > originates the association. > - If either (3) or (4) are used, an Extended ASSOCIATION object > [assoc-ext] is used. Otherwise a ASSOCIATION object [rfc4872] > is used > >> As both sides can originate LSPs independently, it would be >> useful to have a sentence in the draft to indicate how this is >> populated. How what is populated, i.e., what is "this"? >> As a tie breaker rule by default higher IP address >> destination is used and it can be overridden by the management >> entity. I'm sorry, I just don't see how the "higher/lower" IP address scheme provides uniqueness WRT the ID(s). You previously said that the entity that provisions the LSP selects the ID. In this case it should also provide the IP address to ensure the object is unique. What am I missing? Thanks, Lou > > > > - while we're at it, in the case of single sided provisioning *only* (note only #1 differs) > 1. Association Source is set to an address assigned to the node that > originates the LSP. > 2. Association ID is a value assigned but the node that originates > the association. > 3. Global Association Source, when used, is set to the Global_ID of > the node that originates the association. > 4. Extended Association ID, when used, is selected by the node that > originates the association. > - If either (3) or (4) are used, an Extended ASSOCIATION object > [assoc-ext] is used. Otherwise a ASSOCIATION object [rfc4872] > is used > > I think the above addresses my point as it can be used to ensure unique LSP association in all cases. BTW it also aligns very nicely with the existing definition of the association objects. > > This sounds good. > > Thanks, > Rakesh > > > To address what I suspect is your concern, 3.2.8 can then become something like (feel free to revise): > > 3.2.8 MPLS-TP Associated Bidirectional LSP Identifiers > > [RFC6370] defines the LSP associated identifiers based on the > signaling parameters of each unidirectional LSP. The combination > of each unidirectional LSP's parameters is used to identify the > Associated Bidirectional LSP. Using the mechanisms defined in > this document, any node that is along the path of both > unidirectional LSPs can identify which pair of unidirectional LSPs > support an Associated Bidirectional LSP as well as the signaling > parameters required by [RFC6370]. Note that the LSP end-points > will always be the path of both unidirectional LSPs. > > Lou > > On 8/27/2012 10:20 PM, zhang.fei3@zte.com.cn wrote: >> >> Thank you lou >> >> How about changing the descriptions in paragraph 3.2.8 >> >> In some scenarios, a node that is the association source MAY need to >> learn about the Global_ID [RFC6370] of the peer node, which can be >> done by inserting the ASSOCIATION object with Association Type "LSP >> identifiers" in the outgoing Path message and being carried back in >> the Resv message, as defined in [I-D, draft-zhang-ccamp-mpls-tp- >> rsvpte-ext-tunnel-num]. >> >> into >> >> In some scenarios, a node that is the association source MAY need to >> learn about the Global_ID [RFC6370] of the peer node. Although the >> scope of the draft [I-D, >> draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num] >> is limited to the co-routed bidirectional LSP, the defined >> procedures can >> be reused here also. The ASSOCIATION object with Association Type "LSP >> Identifiers" is inserted in the outgoing Path message at the association >> source and carried back in the corresponding Resv message. All the >> fields >> of the ASSOCIATION object except the Association Type in the Path >> message >> can be ignored by the receiver and the Global_ID of the peer node >> is pushed >> into the field of the Global Association Source in the Resv message. >> >> Best regards >> >> Fei >> >> >> *Lou Berger * >> >> 2012-08-28 02:30 >> >> >> ÊÕ¼þÈË >> zhang.fei3@zte.com.cn >> ³­ËÍ >> "ccamp@ietf.org" , "Rakesh Gandhi (rgandhi)" >> >> Ö÷Ìâ >> Re: [CCAMP] Review Request For Changes in >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt >> >> >> >> >> >> >> >> >> Fei, >> The problem only exists in the double sided >> provisioing case, so no need to complicate the single sided >> provisioning case. >> >> Lou >> >> >> On 8/26/2012 9:03 PM, zhang.fei3@zte.com.cn wrote: >>> The administrative >>> approach can integrate both models, will be a good idea. >> >> From rgandhi@cisco.com Tue Aug 28 09:26:13 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6304521F852A for ; Tue, 28 Aug 2012 09:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.854 X-Spam-Level: X-Spam-Status: No, score=-6.854 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hso4JPI7KLi0 for ; Tue, 28 Aug 2012 09:26:12 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2611021F8527 for ; Tue, 28 Aug 2012 09:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=10026; q=dns/txt; s=iport; t=1346171172; x=1347380772; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Dkrs0cIndOIMbfg4Z/+XCcrpN4hpx30HC3lxL9HoAjw=; b=dC589ghLsspk2TeUmWedrSMoOfyNRY6817CEJzbQbT1V25t2/+Nvmy1p MVco/8i5brXwXivQagsmtsKBt/YIVroZTHilXvHwVdxufTJtM2YeiYm5v SHj1TT2SVR3NtnGjZtD4l1GKLJnQDNslj5gl3eN9ogGX/4u8ejGV/MJSU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOXvPFCtJV2b/2dsb2JhbAA7CoYDs3xugQeCIAEBAQMBEgEhMxIMBAIBBgIOAwQBAQEEBhkEBQICMBQJCAIEDgUIGodlBptVjRIIky2BHYlrEASFLzZgA6QEgWeCY4FY X-IronPort-AV: E=Sophos;i="4.80,327,1344211200"; d="scan'208";a="116066616" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 28 Aug 2012 16:26:11 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7SGQBgn003952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Aug 2012 16:26:11 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Tue, 28 Aug 2012 11:26:10 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger Thread-Topic: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: AQHNhMO1KWryoN3/QKaPbjEu2q9iw5dvgLYA///VJ2CAAGFdgP//rsXQ Date: Tue, 28 Aug 2012 16:26:08 +0000 Message-ID: References: <503CBDC2.9040308@labn.net> <503CEB7D.1050401@labn.net> In-Reply-To: <503CEB7D.1050401@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.81.146] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--57.249800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:26:13 -0000 SGkgTG91LA0KDQpQbGVhc2Ugc2VlIGlubGluZS4uPFJHMj4uDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQpT ZW50OiBUdWVzZGF5LCBBdWd1c3QgMjgsIDIwMTIgMTI6MDIgUE0NClRvOiBSYWtlc2ggR2FuZGhp IChyZ2FuZGhpKQ0KQ2M6IHpoYW5nLmZlaTNAenRlLmNvbS5jbjsgY2NhbXBAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbQ0NBTVBdIFJldmlldyBSZXF1ZXN0IEZvciBDaGFuZ2VzIGluIGRyYWZ0LWll dGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KDQpSYWtl c2gsDQoJU2VlIGJlbG93Lg0KDQpPbiA4LzI4LzIwMTIgMTE6MjggQU0sIFJha2VzaCBHYW5kaGkg KHJnYW5kaGkpIHdyb3RlOg0KPiBIaSBMb3UsDQo+IA0KPiBQbGVhc2Ugc2VlIGlubGluZS4uPFJH Pi4uDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb3UgQmVyZ2Vy IFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCj4gU2VudDogVHVlc2RheSwgQXVndXN0IDI4LCAy MDEyIDg6NDcgQU0NCj4gVG86IHpoYW5nLmZlaTNAenRlLmNvbS5jbg0KPiBDYzogY2NhbXBAaWV0 Zi5vcmc7IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFJl dmlldyBSZXF1ZXN0IEZvciBDaGFuZ2VzIGluIA0KPiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAt cnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCj4gDQo+IEZlaSwNCj4gDQo+IEkgZG9u J3QgdGhpbmsgdGhlIHRleHQgYWRkcmVzc2VzIHRoZSBpc3N1ZSBvZiBzZWxlY3Rpb24gb2YgYXNz b2NpYXRpb24gb2JqZWN0IGNvbnRlbnRzIGluIHRoZSBjYXNlIG9mIGRvdWJsZSBzaWRlZCBwcm92 aXNpb25pbmcuICBIb3cgYWJvdXQ6DQo+IC0gaW4gdGhlIGNhc2Ugb2YgZG91YmxlIHNpZGVkIHBy b3Zpc2lvbmluZyAqb25seSoNCj4gICAxLiBBc3NvY2lhdGlvbiBTb3VyY2UgaXMgc2V0IHRvIGFu IGFkZHJlc3Mgc2VsZWN0ZWQgYnkgdGhlIG5vZGUgdGhhdA0KPiAgICAgIG9yaWdpbmF0ZXMgdGhl IGFzc29jaWF0aW9uLiAod2hpY2ggbWF5IGJlIGEgbWFuYWdlbWVudCBlbnRpdHkuKQ0KPiANCj4+ IDxSRz4gRm9yIGRvdWJsZSBzaWRlZCBwcm92aXNpb25pbmcsIGJvdGggc2lkZXMgY2FuIG9yaWdp bmF0ZSB0aGUgTFNQcyANCj4+IGluZGVwZW5kZW50bHkuIEluIHRoaXMgY2FzZSwgdGhlcmUgbmVl ZHMgdG8gYmUgYSBydWxlIGZvciBhIGRlZmF1bHQgDQo+PiBiZWhhdmlvciBvbiB3aGljaCBzaWRl IGJlY29tZXMgdGhlIGFzc29jaWF0aW9uIHNvdXJjZSBhbmQgaGVuY2UgdGhlIA0KPj4gcHJvcG9z YWwgdG8gcGljayB0aGUgc2lkZSB3aXRoIGxvd2VyIElQIGFkZHJlc3MgZm9yIHRoZSBzb3VyY2Uu DQoNCldoeSBhcmUgeW91IGFzc3VtaW5nIHRoYXQgb25lIG9mIHRoZSBlbmRwb2ludHMgbXVzdCBi ZSB0aGUgc291cmNlPyAgVGhlIGtleSByZXF1aXJlbWVudCBpcyB0aGF0IHRoZSBzb3VyY2UrSUQo cykgbXVzdCBiZSB1bmlxdWUuICBUaGlzIG1lYW5zIHRoYXQgSUQocykgbXVzdCBiZSBzZWxlY3Rl ZCBvciBvYnRhaW5lZCBmcm9tIHRoZSBhc3NvY2lhdGlvbiBzb3VyY2UuDQoNCjxSRzI+IEkgc2F3 IHlvdXIgcmVwbHkgdG8gRmVpLiBTbyBvaywgYXNzb2NpYXRpb24tc291cmNlIGlzIG5vdCBuZWNl c3NhcmlseSBhIHJvdXRlciBzb3VyY2UgYWRkcmVzcy4gIA0KDQoNCj4+IFRoaXMgcnVsZSBjYW4g YmUgb3ZlcnJpZGRlbiBieSB0aGUgbWFuYWdlbWVudCBlbnRpdHkgdG8gZGVzaWduYXRlIGEgDQo+ PiBzaWRlIHRvIGJlY29tZSBhbiBhc3NvY2lhdGlvbiBzb3VyY2UuDQoNClRoaXMgaXMgd2hlcmUg d2UgZGlzYWdyZWUuICBJTU8gdGhlIGVudGl0eSB0aGF0IHNlbGVjdHMgdGhlIElEKHMpIGlzIHRo ZSBzb3VyY2UgYW5kIG11c3QgcHJvdmlkZSB0aGUgSVAgYWRkcmVzcyBpbiB3aGljaCB0aGUgSUQg aXMgc2NvcGVkLg0KDQo8UkcyPiBJIHNlZSwgc28gYXNzb2NpYXRpb24gc291cmNlIGFuZCBJRCBt dXN0IGJlIGdpdmVuIHRvIGEgbm9kZS4NCg0KDQoNCj4gDQo+ICAgMi4gQXNzb2NpYXRpb24gSUQg aXMgYSB2YWx1ZSBhc3NpZ25lZCBidXQgdGhlIG5vZGUgdGhhdCBvcmlnaW5hdGVzDQo+ICAgICAg dGhlIGFzc29jaWF0aW9uLg0KPiAgIDMuIEdsb2JhbCBBc3NvY2lhdGlvbiBTb3VyY2UsIHdoZW4g dXNlZCwgaXMgc2V0IHRvIHRoZSBHbG9iYWxfSUQgb2YNCj4gICAgICB0aGUgbm9kZSB0aGF0IG9y aWdpbmF0ZXMgdGhlIGFzc29jaWF0aW9uLg0KPiAgIDQuIEV4dGVuZGVkIEFzc29jaWF0aW9uIElE LCB3aGVuIHVzZWQsIGlzIHNlbGVjdGVkIGJ5IHRoZSBub2RlIHRoYXQNCj4gICAgICBvcmlnaW5h dGVzIHRoZSBhc3NvY2lhdGlvbi4NCj4gICAtICBJZiBlaXRoZXIgKDMpIG9yICg0KSBhcmUgdXNl ZCwgYW4gRXh0ZW5kZWQgQVNTT0NJQVRJT04gb2JqZWN0DQo+ICAgICAgW2Fzc29jLWV4dF0gaXMg dXNlZC4gIE90aGVyd2lzZSBhIEFTU09DSUFUSU9OIG9iamVjdCBbcmZjNDg3Ml0NCj4gICAgICBp cyB1c2VkDQo+IA0KPj4gPFJHPiBBcyBib3RoIHNpZGVzIGNhbiBvcmlnaW5hdGUgTFNQcyBpbmRl cGVuZGVudGx5LCAgaXQgd291bGQgYmUgDQo+PiB1c2VmdWwgdG8gaGF2ZSBhIHNlbnRlbmNlIGlu IHRoZSBkcmFmdCB0byBpbmRpY2F0ZSBob3cgdGhpcyBpcyANCj4+IHBvcHVsYXRlZC4NCg0KSG93 IHdoYXQgaXMgcG9wdWxhdGVkLCBpLmUuLCB3aGF0IGlzICJ0aGlzIj8NCg0KPFJHMj4gRXh0ZW5k ZWQgYXNzb2NpYXRpb24gSUQuDQoNCj4+IEFzIGEgdGllIGJyZWFrZXIgcnVsZSBieSBkZWZhdWx0 IGhpZ2hlciBJUCBhZGRyZXNzIGRlc3RpbmF0aW9uIGlzIA0KPj4gdXNlZCBhbmQgaXQgY2FuIGJl IG92ZXJyaWRkZW4gYnkgdGhlIG1hbmFnZW1lbnQgZW50aXR5Lg0KDQpJJ20gc29ycnksIEkganVz dCBkb24ndCBzZWUgaG93IHRoZSAiaGlnaGVyL2xvd2VyIiBJUCBhZGRyZXNzIHNjaGVtZSBwcm92 aWRlcyB1bmlxdWVuZXNzIFdSVCB0aGUgSUQocykuICBZb3UgcHJldmlvdXNseSBzYWlkIHRoYXQg dGhlIGVudGl0eSB0aGF0IHByb3Zpc2lvbnMgdGhlIExTUCBzZWxlY3RzIHRoZSBJRC4gIEluIHRo aXMgY2FzZSBpdCBzaG91bGQgYWxzbyBwcm92aWRlIHRoZSBJUCBhZGRyZXNzIHRvIGVuc3VyZSB0 aGUgb2JqZWN0IGlzIHVuaXF1ZS4NCg0KPFJHMj4gSSBzZWUgbm93IHdoYXQgeW91IGFyZSBzYXlp bmcuIFNvIGlkZW50aWNhbCB2YWx1ZXMgZm9yIDxBc3NvY2lhdGlvbi1JRCArIFNvdXJjZSArIEV4 dC1JRD4gbXVzdCBiZSBnaXZlbiB0byBub2RlcyBvbiBib3RoIHNpZGVzIG9mIHRoZSBMU1BzLiBJ dCBpcyBub3QgdGllZCB0byB0aGUgTFNQIHNvdXJjZS9kZXN0aW5hdGlvbi4NCg0KVGhhbmtzLA0K UmFrZXNoDQoNCg0KV2hhdCBhbSBJIG1pc3Npbmc/DQoNClRoYW5rcywNCkxvdQ0KDQo+IA0KPiAN Cj4gDQo+IC0gd2hpbGUgd2UncmUgYXQgaXQsIGluIHRoZSBjYXNlIG9mIHNpbmdsZSBzaWRlZCBw cm92aXNpb25pbmcgKm9ubHkqIChub3RlIG9ubHkgIzEgZGlmZmVycykNCj4gICAxLiBBc3NvY2lh dGlvbiBTb3VyY2UgaXMgc2V0IHRvIGFuIGFkZHJlc3MgYXNzaWduZWQgdG8gdGhlIG5vZGUgdGhh dA0KPiAgICAgIG9yaWdpbmF0ZXMgdGhlIExTUC4NCj4gICAyLiBBc3NvY2lhdGlvbiBJRCBpcyBh IHZhbHVlIGFzc2lnbmVkIGJ1dCB0aGUgbm9kZSB0aGF0IG9yaWdpbmF0ZXMNCj4gICAgICB0aGUg YXNzb2NpYXRpb24uDQo+ICAgMy4gR2xvYmFsIEFzc29jaWF0aW9uIFNvdXJjZSwgd2hlbiB1c2Vk LCBpcyBzZXQgdG8gdGhlIEdsb2JhbF9JRCBvZg0KPiAgICAgIHRoZSBub2RlIHRoYXQgb3JpZ2lu YXRlcyB0aGUgYXNzb2NpYXRpb24uDQo+ICAgNC4gRXh0ZW5kZWQgQXNzb2NpYXRpb24gSUQsIHdo ZW4gdXNlZCwgaXMgc2VsZWN0ZWQgYnkgdGhlIG5vZGUgdGhhdA0KPiAgICAgIG9yaWdpbmF0ZXMg dGhlIGFzc29jaWF0aW9uLg0KPiAgIC0gIElmIGVpdGhlciAoMykgb3IgKDQpIGFyZSB1c2VkLCBh biBFeHRlbmRlZCBBU1NPQ0lBVElPTiBvYmplY3QNCj4gICAgICBbYXNzb2MtZXh0XSBpcyB1c2Vk LiAgT3RoZXJ3aXNlIGEgQVNTT0NJQVRJT04gb2JqZWN0IFtyZmM0ODcyXQ0KPiAgICAgIGlzIHVz ZWQNCj4gDQo+IEkgdGhpbmsgdGhlIGFib3ZlIGFkZHJlc3NlcyBteSBwb2ludCBhcyBpdCBjYW4g YmUgdXNlZCB0byBlbnN1cmUgdW5pcXVlIExTUCBhc3NvY2lhdGlvbiBpbiBhbGwgY2FzZXMuICBC VFcgaXQgYWxzbyBhbGlnbnMgdmVyeSBuaWNlbHkgd2l0aCB0aGUgZXhpc3RpbmcgZGVmaW5pdGlv biBvZiB0aGUgYXNzb2NpYXRpb24gb2JqZWN0cy4NCj4gDQo+IDxSRz4gVGhpcyBzb3VuZHMgZ29v ZC4NCj4gDQo+IFRoYW5rcywNCj4gUmFrZXNoDQo+IA0KPiANCj4gVG8gYWRkcmVzcyB3aGF0IEkg c3VzcGVjdCBpcyB5b3VyIGNvbmNlcm4sIDMuMi44IGNhbiB0aGVuIGJlY29tZSBzb21ldGhpbmcg bGlrZSAoZmVlbCBmcmVlIHRvIHJldmlzZSk6DQo+IA0KPiAgIDMuMi44ICBNUExTLVRQIEFzc29j aWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1AgSWRlbnRpZmllcnMNCj4gDQo+ICAgW1JGQzYzNzBdIGRl ZmluZXMgdGhlIExTUCBhc3NvY2lhdGVkIGlkZW50aWZpZXJzIGJhc2VkIG9uIHRoZQ0KPiAgIHNp Z25hbGluZyBwYXJhbWV0ZXJzIG9mIGVhY2ggdW5pZGlyZWN0aW9uYWwgTFNQLiBUaGUgY29tYmlu YXRpb24NCj4gICBvZiBlYWNoIHVuaWRpcmVjdGlvbmFsIExTUCdzIHBhcmFtZXRlcnMgaXMgdXNl ZCB0byBpZGVudGlmeSB0aGUNCj4gICBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQLiAgVXNp bmcgdGhlIG1lY2hhbmlzbXMgZGVmaW5lZCBpbg0KPiAgIHRoaXMgZG9jdW1lbnQsIGFueSBub2Rl IHRoYXQgaXMgYWxvbmcgdGhlIHBhdGggb2YgYm90aA0KPiAgIHVuaWRpcmVjdGlvbmFsIExTUHMg Y2FuIGlkZW50aWZ5IHdoaWNoIHBhaXIgb2YgdW5pZGlyZWN0aW9uYWwgTFNQcw0KPiAgIHN1cHBv cnQgYW4gQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUCBhcyB3ZWxsIGFzIHRoZSBzaWduYWxp bmcNCj4gICBwYXJhbWV0ZXJzIHJlcXVpcmVkIGJ5IFtSRkM2MzcwXS4gIE5vdGUgdGhhdCB0aGUg TFNQIGVuZC1wb2ludHMNCj4gICB3aWxsIGFsd2F5cyBiZSB0aGUgcGF0aCBvZiBib3RoIHVuaWRp cmVjdGlvbmFsIExTUHMuDQo+IA0KPiBMb3UNCj4gDQo+IE9uIDgvMjcvMjAxMiAxMDoyMCBQTSwg emhhbmcuZmVpM0B6dGUuY29tLmNuIHdyb3RlOg0KPj4NCj4+IFRoYW5rIHlvdSBsb3UNCj4+DQo+ PiBIb3cgYWJvdXQgY2hhbmdpbmcgdGhlIGRlc2NyaXB0aW9ucyBpbiBwYXJhZ3JhcGggMy4yLjgN Cj4+DQo+PiAgICBJbiBzb21lIHNjZW5hcmlvcywgYSBub2RlIHRoYXQgaXMgdGhlIGFzc29jaWF0 aW9uIHNvdXJjZSBNQVkgbmVlZCB0bw0KPj4gICBsZWFybiBhYm91dCB0aGUgR2xvYmFsX0lEIFtS RkM2MzcwXSBvZiB0aGUgcGVlciBub2RlLCB3aGljaCBjYW4gYmUNCj4+ICAgZG9uZSBieSBpbnNl cnRpbmcgdGhlIEFTU09DSUFUSU9OIG9iamVjdCB3aXRoIEFzc29jaWF0aW9uIFR5cGUgIkxTUA0K Pj4gICBpZGVudGlmaWVycyIgaW4gdGhlIG91dGdvaW5nIFBhdGggbWVzc2FnZSBhbmQgYmVpbmcg Y2FycmllZCBiYWNrIGluDQo+PiAgIHRoZSBSZXN2IG1lc3NhZ2UsIGFzIGRlZmluZWQgaW4gW0kt RCwgZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC0NCj4+ICAgcnN2cHRlLWV4dC10dW5uZWwtbnVt XS4NCj4+DQo+PiBpbnRvDQo+Pg0KPj4gICAgSW4gc29tZSBzY2VuYXJpb3MsIGEgbm9kZSB0aGF0 IGlzIHRoZSBhc3NvY2lhdGlvbiBzb3VyY2UgTUFZIG5lZWQgdG8NCj4+ICAgbGVhcm4gYWJvdXQg dGhlIEdsb2JhbF9JRCBbUkZDNjM3MF0gb2YgdGhlIHBlZXIgbm9kZS4gQWx0aG91Z2ggdGhlDQo+ PiAgICBzY29wZSBvZiB0aGUgZHJhZnQgW0ktRCwNCj4+IGRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMt dHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtXQ0KPj4gICAgaXMgbGltaXRlZCB0byB0aGUgY28tcm91 dGVkIGJpZGlyZWN0aW9uYWwgTFNQLCB0aGUgZGVmaW5lZCANCj4+IHByb2NlZHVyZXMgY2FuDQo+ PiAgICBiZSByZXVzZWQgaGVyZSBhbHNvLiBUaGUgQVNTT0NJQVRJT04gb2JqZWN0IHdpdGggQXNz b2NpYXRpb24gVHlwZSAiTFNQDQo+PiAgIElkZW50aWZpZXJzIiBpcyBpbnNlcnRlZCBpbiB0aGUg b3V0Z29pbmcgUGF0aCBtZXNzYWdlIGF0IHRoZSBhc3NvY2lhdGlvbg0KPj4gICAgc291cmNlIGFu ZCBjYXJyaWVkIGJhY2sgaW4gdGhlIGNvcnJlc3BvbmRpbmcgUmVzdiBtZXNzYWdlLiBBbGwgdGhl IA0KPj4gZmllbGRzDQo+PiAgICBvZiB0aGUgQVNTT0NJQVRJT04gb2JqZWN0IGV4Y2VwdCB0aGUg QXNzb2NpYXRpb24gVHlwZSBpbiB0aGUgUGF0aCANCj4+IG1lc3NhZ2UNCj4+ICAgIGNhbiBiZSBp Z25vcmVkIGJ5IHRoZSByZWNlaXZlciBhbmQgdGhlIEdsb2JhbF9JRCBvZiB0aGUgcGVlciBub2Rl IA0KPj4gaXMgcHVzaGVkDQo+PiAgICBpbnRvIHRoZSBmaWVsZCBvZiB0aGUgR2xvYmFsIEFzc29j aWF0aW9uIFNvdXJjZSBpbiB0aGUgUmVzdiBtZXNzYWdlLg0KPj4NCj4+IEJlc3QgcmVnYXJkcw0K Pj4NCj4+IEZlaQ0KPj4NCj4+DQo+PiAqTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4qDQo+ Pg0KPj4gMjAxMi0wOC0yOCAwMjozMA0KPj4NCj4+IAkNCj4+IMrVvP7Iyw0KPj4gCXpoYW5nLmZl aTNAenRlLmNvbS5jbg0KPj4gs63LzQ0KPj4gCSJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYu b3JnPiwgIlJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIg0KPj4gPHJnYW5kaGlAY2lzY28uY29tPg0K Pj4g1vfM4g0KPj4gCVJlOiBbQ0NBTVBdIFJldmlldyBSZXF1ZXN0IEZvciBDaGFuZ2VzIGluIA0K Pj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQu dHh0DQo+Pg0KPj4NCj4+IAkNCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gRmVpLA0KPj4gICAgICAg ICAgICAgICAgIFRoZSBwcm9ibGVtIG9ubHkgZXhpc3RzIGluIHRoZSBkb3VibGUgc2lkZWQgDQo+ PiBwcm92aXNpb2luZyBjYXNlLCBzbyBubyBuZWVkIHRvIGNvbXBsaWNhdGUgdGhlIHNpbmdsZSBz aWRlZCANCj4+IHByb3Zpc2lvbmluZyBjYXNlLg0KPj4NCj4+IExvdQ0KPj4NCj4+DQo+PiBPbiA4 LzI2LzIwMTIgOTowMyBQTSwgemhhbmcuZmVpM0B6dGUuY29tLmNuIHdyb3RlOg0KPj4+IFRoZSBh ZG1pbmlzdHJhdGl2ZQ0KPj4+IGFwcHJvYWNoIGNhbiBpbnRlZ3JhdGUgYm90aCBtb2RlbHMsIHdp bGwgYmUgYSBnb29kIGlkZWEuDQo+Pg0KPj4NCg== From zhang.fei3@zte.com.cn Tue Aug 28 09:33:51 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69B721F8593 for ; Tue, 28 Aug 2012 09:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.114 X-Spam-Level: X-Spam-Status: No, score=-95.114 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb898G1IgTvk for ; Tue, 28 Aug 2012 09:33:50 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD1E21F8525 for ; Tue, 28 Aug 2012 09:33:49 -0700 (PDT) Received: from [10.30.3.21] by mx5.zte.com.cn with surfront esmtp id 232556255862908(version=TLSv1/SSLv3 cipher=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA bits=128 verify=NO); Wed, 29 Aug 2012 00:27:22 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7SGXUY3001151; Wed, 29 Aug 2012 00:33:31 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <50327601.2060502@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: 0C7ABA84:6365F90D-48257A68:00598BBE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Wed, 29 Aug 2012 00:33:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-29 00:33:32, Serialize complete at 2012-08-29 00:33:32 Content-Type: multipart/alternative; boundary="=_alternative 005ADEA748257A68_=" X-MAIL: mse02.zte.com.cn q7SGXUY3001151 Cc: venkat.mahalingams@gmail.com, ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:33:52 -0000 This is a multipart message in MIME format. --=_alternative 005ADEA748257A68_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TG91DQoNCldlIGhhdmUgcmVjZWl2ZWQgY29tbWVudHMgb2ZmbGluZS9vbmxpbmUgYW5kIGFkZHJl c3NlZCB0aGVtIGludG8gdGhlIGRyYWZ0IA0Kdi0wMyBmcm9tIHRoZSBwb2xsaW5nIHZlcnNpb24g MDIsIHRoZW4gdXBkYXRlZCB0aGUgZHJhZnQgdG8gdi0wNCBhY2NvcmRpbmcgDQp0byB0aGUgY29t bWVudHMgcmVjZWl2ZWQgc2luY2UgSUVURjg0IG1lZXRpbmcgYW5kIHB1c2hlZCB0aGUgcHJvcG9z YWwgaW50byANCnRoZSBtYWlsaW5nbGlzdCBhbHNvIHRvIGhlYXIgbW9yZSBvcGluaW9ucy4NCg0K VGhlIGF1dGhvcnMgdGhpbmsgd2UgaGF2ZSBhZGRyZXNzZWQgYWxsIHRoZSBjb21tZW50cyBhbmQg dGhpcyBkcmFmdCBpcyANCnJlYWR5IGZvciBXRyBjb25zaWRlcmF0aW9uIG5vdy4NCg0KQW55IHN1 Z2dlc3Rpb24/IA0KDQpCZXN0IHJlZ2FyZHMgOikNCg0KRmVpDQoNCg0KDQpMb3UgQmVyZ2VyIDxs YmVyZ2VyQGxhYm4ubmV0PiANCjIwMTItMDgtMjEgMDE6MzgNCg0KytW8/sjLDQp6aGFuZy5mZWkz QHp0ZS5jb20uY24NCrOty80NCmNjYW1wQGlldGYub3JnDQrW98ziDQpSZTogW0NDQU1QXSBJLUQg QWN0aW9uOiANCmRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVt LTA0LnR4dA0KDQoNCg0KDQoNCg0KRmVpLA0KICAgICAgICAgICAgICAgICBUbyByZXNwb25kIHRv IHlvdXIgcHJvY2VkdXJlIHBvaW50Og0KDQpPbiA4LzE3LzIwMTIgMzoyNyBBTSwgemhhbmcuZmVp M0B6dGUuY29tLmNuIHdyb3RlOg0KPiBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhpcyBkcmFmdCBz aG91bGQgZm9sbG93IHRoZSB0aGUgcHJvY2VkdXJlcw0KPiBkZWZpbmVkIGZvciBXRyBkb2N1bWVu dHMgb3Igbm90Lg0KDQpJbmRpdmlkdWFsIGRyYWZ0cyBhcmUgY29tcGxldGVseSB1bmRlciB0aGUg Y29udHJvbCBvZiB0aGUgYXV0aG9ycy4gIE9mDQpjb3Vyc2UsIHRoZXkgbWF5IGNob29zZSB0byBs aXN0ZW4gdG8gZmVlZGJhY2sgb2YgV0cgcGFydGljaXBhbnRzIGluIGhvcGUNCm9mIGdldHRpbmcg dGhlaXIgZHJhZnQgYWNjZXB0ZWQgYXMgYSBXRyBkcmFmdC4uLi4NCg0KTG91DQoNCg0KDQo= --=_alternative 005ADEA748257A68_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxvdTwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2UgaGF2ZSByZWNlaXZlZCBjb21tZW50 cyBvZmZsaW5lL29ubGluZQ0KYW5kIGFkZHJlc3NlZCB0aGVtIGludG8gdGhlIGRyYWZ0IHYtMDMg ZnJvbSB0aGUgcG9sbGluZyB2ZXJzaW9uIDAyLCB0aGVuDQp1cGRhdGVkIHRoZSBkcmFmdCB0byB2 LTA0IGFjY29yZGluZyB0byB0aGUgY29tbWVudHMgcmVjZWl2ZWQgc2luY2UgSUVURjg0DQptZWV0 aW5nIGFuZCBwdXNoZWQgdGhlIHByb3Bvc2FsIGludG8gdGhlIG1haWxpbmdsaXN0IGFsc28gdG8g aGVhciBtb3JlDQpvcGluaW9ucy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlRoZSBhdXRob3JzIHRoaW5rIHdlIGhhdmUgYWRkcmVzc2VkDQphbGwgdGhl IGNvbW1lbnRzIGFuZCB0aGlzIGRyYWZ0IGlzIHJlYWR5IGZvciBXRyBjb25zaWRlcmF0aW9uIG5v dy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFueSBz dWdnZXN0aW9uPyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkJlc3QgcmVnYXJkcyA6KTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+RmVpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjxiPkxvdSBCZXJnZXIgJmx0O2xiZXJnZXJAbGFibi5uZXQmZ3Q7PC9iPg0KPC9m b250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDgtMjEgMDE6Mzg8 L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ emhhbmcuZmVpM0B6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5jY2FtcEBpZXRmLm9yZzwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtemhhbmctY2Nh bXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDQudHh0PC9mb250PjwvdGFibGU+DQo8 YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwv dGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5GZWksPGJyPg0KICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClRvIHJl c3BvbmQgdG8geW91ciBwcm9jZWR1cmUgcG9pbnQ6PGJyPg0KPGJyPg0KT24gOC8xNy8yMDEyIDM6 MjcgQU0sIHpoYW5nLmZlaTNAenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7IEkgYW0gbm90IHN1 cmUgd2hldGhlciB0aGlzIGRyYWZ0IHNob3VsZCBmb2xsb3cgdGhlIHRoZSBwcm9jZWR1cmVzPGJy Pg0KJmd0OyBkZWZpbmVkIGZvciBXRyBkb2N1bWVudHMgb3Igbm90Ljxicj4NCjxicj4NCkluZGl2 aWR1YWwgZHJhZnRzIGFyZSBjb21wbGV0ZWx5IHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBhdXRo b3JzLiAmbmJzcDtPZjxicj4NCmNvdXJzZSwgdGhleSBtYXkgY2hvb3NlIHRvIGxpc3RlbiB0byBm ZWVkYmFjayBvZiBXRyBwYXJ0aWNpcGFudHMgaW4gaG9wZTxicj4NCm9mIGdldHRpbmcgdGhlaXIg ZHJhZnQgYWNjZXB0ZWQgYXMgYSBXRyBkcmFmdC4uLi48YnI+DQo8YnI+DQpMb3U8YnI+DQo8YnI+ DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 005ADEA748257A68_=-- From elisa.bellagamba@ericsson.com Wed Aug 29 03:13:53 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B7421F85A7 for ; Wed, 29 Aug 2012 03:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXSVCjEehPBY for ; Wed, 29 Aug 2012 03:13:52 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 30D7121F8581 for ; Wed, 29 Aug 2012 03:13:51 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-a4-503deb5c8135 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 22.F1.11467.C5BED305; Wed, 29 Aug 2012 12:13:48 +0200 (CEST) Received: from ESESSCMS0365.eemea.ericsson.se ([169.254.1.246]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 29 Aug 2012 12:13:48 +0200 From: Elisa Bellagamba To: "ccamp@ietf.org" Date: Wed, 29 Aug 2012 12:13:47 +0200 Thread-Topic: [CCAMP] Comments on Fault OAM Configuration (draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08) Thread-Index: AQHNZb6Whbfk59sgCEWkiDX95wuk0Zc7U7YggDV9xwA= Message-ID: <666A6B6D38439F49A7FB8E0FE839CA0635793C1BCA@ESESSCMS0365.eemea.ericsson.se> References: <6477E10CC7D76444A479B9AC31F262A943828A352A@ESESSCMS0365.eemea.ericsson.se> In-Reply-To: <6477E10CC7D76444A479B9AC31F262A943828A352A@ESESSCMS0365.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_666A6B6D38439F49A7FB8E0FE839CA0635793C1BCAESESSCMS0365e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGfG3VjfmtW2AwdzbBhZP5txgsTiw4Ruj xb+5c5gtLk2Yymxxe0oTowOrx4fjJ9k8pvzeyOqxZMlPJo9Z09vYAliiuGxSUnMyy1KL9O0S uDKmLzvDXvAkomLtszPMDYyTfboYOTkkBEwkFp89xghhi0lcuLeeDcQWEjjFKHFhk3UXIxeQ PZdRYvfboyxdjBwcbAJmEusWlYPUiAioSpy5eZERpIZZ4D6jxNcNT5hBEixAiW9H+lhAbGGB DImbuzvZIRoyJb4f288EYVtJvHr5HyzOKxAusfHfLjaQ+UJA9rL+WpAwp0CExMENC1hBbEag 276fWgPWyiwgLnHryXwmiJsFJJbsOc8MYYtKvHz8D6peVOJO+3pGiPp8iSfvpjJBrBKUODnz CcsERtFZSEbNQlI2C0kZRFxP4sbUKWwQtrbEsoWvmSFsXYkZ/w6xIIsvYGRfxSicm5iZk15u qJdalJlcXJyfp1ecuokRGJsHt/zW3cF46pzIIUZpDhYlcV6upP3+QgLpiSWp2ampBalF8UWl OanFhxiZODilGhj5z5vcUG7Lmtv+mePs1CTRsCS/BZo9E4wVWbWDesO+n2mX80z/eDTd6+Fe S2+Bjak3rsuev6pdrPKg7c7OlvL5pS5fGmRfdtuU/9jUWpR7/ZSfTOPvF/tv5JyYmt3nJ8O9 6WE8g430pbSG5NxfU9YbvGA0zulcfOloc1GGQ9nhT9uXT+dr/qHEUpyRaKjFXFScCABO2oTC mwIAAA== Cc: "dward@cisco.com" Subject: Re: [CCAMP] Comments on Fault OAM Configuration (draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 10:13:53 -0000 --_000_666A6B6D38439F49A7FB8E0FE839CA0635793C1BCAESESSCMS0365e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, please find George's comment resolved here http://diffchecker.com/v44hA973. Best Regards, Elisa and Pontus ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G= eorge Swallow (swallow) Sent: Thursday, July 19, 2012 4:57 PM To: ccamp@ietf.org Subject: [CCAMP] Comments on Fault OAM Configuration (draft-ietf-ccamp-rsvp= -te-mpls-tp-oam-ext-08) Authors - Some comments just on the FM parts for now. Section 3.1.3. Configuration of Fault Management Signals The first three paragraphs of this section have nothing to do with Fault OA= M except the last phrase of the first paragraph, "and Fault Management Sign= al handling." The text in the first paragraph needs to be moved above the PM and Fault se= ctions. The second and third paragraphs belong in the PM section. The forth paragraph needs some work, but I defer on suggesting rewording un= til we decide the issues below. Section 3.5. MPLS OAM FMS sub-TLV 1. The way the section is written, it appears to be concerned with what si= gnals are produced by endpoints (as opposed to how endpoints will react to = received FM OAM). In that case, I don't see the point in having an "D" fla= g. LDI is a flag carried on the AIS message. If a implementation supports= the LDI flag it will set it appropriately. If it doesn't it will never se= t it. What configuration is needed? 2. Why do we need independent configuration of the L and A flags. Under w= hat circumstances would an operator want one and not the other? Remember t= hat options cost real $$$ to develop (small) and test (not so small since y= ou have to do all combinations and often test against multiple releases inc= luding interoperability with other vendors). 3. I believe operators will want to set FM timers on a node-wide basis (or= perhaps a card-wide basis). Generally I see no point in one end of a TP L= SP telling the other how this timer should be set. Further there is no nee= d for consistency in the two directions. If it were up to me I would drop = it. I suppose that is some rare circumstances if the End Service is MPLS-TP a c= ustomer (client of the SP) might want something special. So if folks want t= o retain it, then I suggest another flag that says timer field valid. The d= efault setting of the flag would be 0, I.e. no timer. 4. The draft correctly states that it is not intended to configure mid-poi= nt behavior of the server MEP. But I do believe it is worthwhile to have a= n FM subscription flag in the object for server layer MEPs to examine and d= etermine if the LSP would like any AIS/LKR messages that the server layer p= roduces sent on this LSP. This should be a SHOULD. Ie. At each hop of an= LSP, nodes SHOULD examine the FM subscription flag. If the flag is set th= en the server MEPs at this node SHOULD insert FM messages as appropriate in= this LSP. If the flag is not set these MEPs SHOULD NOT insert FM messages= . ...George --_000_666A6B6D38439F49A7FB8E0FE839CA0635793C1BCAESESSCMS0365e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hello,=
 =
please find George's= comment=20 resolved here http://diffchecker.com/v44hA973.
 =
Best=20 Regards,
Elisa and=20 Pontus
 

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of George Swallow=20 (swallow)
Sent: Thursday, July 19, 2012 4:57 PM
To:=20 ccamp@ietf.org
Subject: [CCAMP] Comments on Fault OAM Configurati= on=20 (draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08)

Auth= ors=20 -

Some= comments=20 just on the FM parts for now.

Section 3.1.3. Configuration of Fault Management=20 Signals

The first three paragra= phs of=20 this section have nothing to do with Fault OAM except the last phrase of th= e=20 first paragraph, "and Fault Management Signal=20 handling."

The = text in the=20 first paragraph needs to be moved above the PM and Fault sections. The seco= nd=20 and third paragraphs belong in the PM section.

The = forth=20 paragraph needs some work, but I defer on suggesting rewording until we dec= ide=20 the issues below.
<=
SPAN class=3Dm_h>Section 3.5.  MPLS OAM FMS sub-TLV
1.  The way the section is written, it appears to be concerned =
with what signals are produced by endpoints (as opposed to how endpoints wi=
ll react to received FM OAM).  In that case, I don't see the point in havin=
g an "D" flag.  LDI is a flag carried on the AIS message.  If a implementat=
ion supports the LDI flag it will set it appropriately.  If it doesn't it w=
ill never set it.  What configuration is needed?
2.  Why d=
o we need independent configuration of the L and A flags.  Under what circu=
mstances would an operator want one and not the other?  Remember that optio=
ns cost real $$$ to develop (small) and test (not so small since you have t=
o do all combinations and often test against multiple releases including in=
teroperability with other vendors).
3.  I believe operators will =
want to set FM timers on a node-wide basis (or perhaps a card-wide basis). =
 Generally I see no point in one end of a TP LSP telling the other how this=
 timer should be set.  Further there is no need for consistency in the two =
directions.  If it were up to me I would drop it.
I supp= ose that=20 is some rare circumstances if the End Service is MPLS-TP a customer (client= of=20 the SP) might want something special. So if folks want to retain it, then I= =20 suggest another flag that says timer field valid. The default setting of th= e=20 flag would be 0, I.e. no timer. 
=
4.  The draft correctly states that it is not intended to configure mid-poi=
nt behavior of the server MEP.  But I do believe it is worthwhile to have a=
n FM subscription flag in the object for server layer MEPs to examine and d=
etermine if the LSP would like any AIS/LKR messages that the server layer p=
roduces sent on this LSP.  This should be a SHOULD.  Ie.  At each hop of an=
 LSP, nodes SHOULD examine the FM subscription flag.  If the flag is set th=
en the server MEPs at this node SHOULD insert FM messages as appropriate in=
 this LSP.  If the flag is not set these MEPs SHOULD NOT insert FM messages=
.
=85George



--_000_666A6B6D38439F49A7FB8E0FE839CA0635793C1BCAESESSCMS0365e_-- From diego.caviglia@ericsson.com Wed Aug 29 08:15:47 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEF321F86BA for ; Wed, 29 Aug 2012 08:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KH3957-Z0b4K for ; Wed, 29 Aug 2012 08:15:47 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 415EB21F868A for ; Wed, 29 Aug 2012 08:15:45 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-cd-503e3220fc98 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F1.30.11467.0223E305; Wed, 29 Aug 2012 17:15:45 +0200 (CEST) Received: from ESESSCMS0353.eemea.ericsson.se ([169.254.1.215]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 29 Aug 2012 17:15:33 +0200 From: Diego Caviglia To: "ccamp@ietf.org" , "ccamp-ads@tools.ietf.org" , "draft-ietf-ccamp-lmp-behavior-negotiation@tools.ietf.org" Date: Wed, 29 Aug 2012 17:15:31 +0200 Thread-Topic: Regarding IPR on draft-ietf-ccamp-lmp-behavior-negotiation Thread-Index: Ac2ApEoJpN/5/6CeT0ege3yy+aNrwwFTwsggAAFoGlA= Message-ID: <8BB4A0BBE54F3548A50D281C391C38E317161F5279@ESESSCMS0353.eemea.ericsson.se> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+Jvra6ikV2AwfMt7BazvmlaPJlzg8Vi 2ZMOZgdmjyVLfjJ5fLn8mS2AKYrLJiU1J7MstUjfLoErY+p1g4KPfBWntuxmbmBcxtPFyMkh IWAiMfPLfGYIW0ziwr31bF2MXBxCAqcYJW6cWcUM4SxklJh+cBYTSBWbgJHEro6ZLCAJEYGb jBI7Pm8Acjg4WARUJXZt9QCpERZwl/jSvZcNxBYR8JBY/HQ2I4RtJTHzxRYwm1cgXKKtcQpY qxCQ/WqyO0iYUyBC4s3xw2AljAKyEhN2LwKzmQXEJW49mc8EcaiAxJI956GOFpV4+fgfK0S9 jMSvTd9YIep1JBbs/sQGYWtLLFv4mhliraDEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilE4 NzEzJ73cUC+1KDO5uDg/T684dRMjMFIObvmtu4Px1DmRQ4zSHCxK4rxcSfv9hQTSE0tSs1NT C1KL4otKc1KLDzEycXBKNTBq3o3sieQtMHJrs9hqWH0/mPcNc97zfResd4TkHXuUdO5bs3hh w/QnjYaMfg/2+j4I3frDif/o0XWmaWecDA12qvQFR3auaZr71ubj/SeSWpdmOrhPUvaYXV8s eWHxpHb99zuen8peel7102Ufn0+i0zIbP/xQOKD1JvneDl6FKf+WLTcwOpGnxFKckWioxVxU nAgA5TQ8qmICAAA= Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-lmp-behavior-negotiation X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 15:15:47 -0000 Hi I'm not aware of any IPR=20 BR D -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A Sent: Wednesday, August 22, 2012 4:26 PM To: draft-ietf-ccamp-lmp-behavior-negotiation@tools.ietf.org Cc: ccamp@ietf.org; ccamp-ads@tools.ietf.org Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-lmp-behavior-negotiation *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Authors, Contributors, (CCAMP) In preparation of this document for Last Call: Are you aware of any IPR that applies to draft-ietf-ccamp-lmp-behavior-nego= tiation? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor, please answer the ab= ove by responding to this email regardless of whether or not you are aware = of any relevant IPR. This document will not advance to the next stage until= a response has been received from each author and listed contributor. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please s= ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik= i/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your respons= e. _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From db3546@att.com Wed Aug 29 11:16:53 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B2011E80E0 for ; Wed, 29 Aug 2012 11:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKRy4ATgmgmY for ; Wed, 29 Aug 2012 11:16:53 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 00D6821E8040 for ; Wed, 29 Aug 2012 11:16:52 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 49c5e305.0.989925.00-480.2759838.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 29 Aug 2012 18:16:52 +0000 (UTC) X-MXL-Hash: 503e5c9441b418c2-d72e4df2d1e58b099d51e9700697b23c45f5de01 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7TIGqM5010735 for ; Wed, 29 Aug 2012 14:16:52 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7TIGjx3010706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2012 14:16:45 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Wed, 29 Aug 2012 14:16:32 -0400 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0318.001; Wed, 29 Aug 2012 14:16:26 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: WG Last Call on draft-ietf-ccamp-lmp-behavior-negotiation Thread-Index: Ac2GEmcNhEdnElFZQr2X0TGuCZZzqg== Date: Wed, 29 Aug 2012 18:16:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=RWEAq7CW3jcA:10 a=MN7BWCt9QyEA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=ZZzAehfQNmMA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:1] X-AnalysisOut: [0 a=wy_sr4TPKgEA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=_sz0ea] X-AnalysisOut: [Qmvu4_uaGU_9EA:9 a=CjuIK1q_8ugA:10] Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-lmp-behavior-negotiation X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 18:16:53 -0000 CCAMP, This starts a two-week (ends Sept. 13th) working group last call on draft-i= etf-ccamp-lmp-behavior-negotiation. Please send your comments to the CCAMP mailing list. Deborah and Lou From swallow@cisco.com Wed Aug 29 11:48:22 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA6721F86D9 for ; Wed, 29 Aug 2012 11:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.576 X-Spam-Level: X-Spam-Status: No, score=-110.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNnAoVjZaMB3 for ; Wed, 29 Aug 2012 11:48:20 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDD421F86C4 for ; Wed, 29 Aug 2012 11:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19141; q=dns/txt; s=iport; t=1346266100; x=1347475700; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Dis4t5m6zADMmScpQC7LD2R7rrbozJ9yCg5Ngqmqpj4=; b=Ggk6umyqfJEUj3YcCCi3Zoqt+kv+pvoYfH7vnsq5MqW3q43Foaj3RgkQ khnUUr2hU2im6iYG2OAjB0ZMQmH6uH132IDCv9hwM3v77730kxGCn290H 5I0HsYoiuqkBSmLyMqeyi4JRHk7nRSu4QzMA3H7UpxQfC2flYzdjdyg64 w=; X-IronPort-AV: E=Sophos;i="4.80,335,1344211200"; d="scan'208,217";a="116488916" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 29 Aug 2012 18:48:19 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7TImJ3n021720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Aug 2012 18:48:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Wed, 29 Aug 2012 13:48:19 -0500 From: "George Swallow (swallow)" To: Elisa Bellagamba , "ccamp@ietf.org" Thread-Topic: [CCAMP] Comments on Fault OAM Configuration (draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08) Thread-Index: AQHNZb6Whbfk59sgCEWkiDX95wuk0Zc7U7YggDV9xwCAAKF5AA== Date: Wed, 29 Aug 2012 18:48:18 +0000 Message-ID: In-Reply-To: <666A6B6D38439F49A7FB8E0FE839CA0635793C1BCA@ESESSCMS0365.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.32.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19148.001 x-tm-as-result: No--49.483400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC63B04EB87Cswallowciscocom_" MIME-Version: 1.0 Cc: "dward@cisco.com" Subject: Re: [CCAMP] Comments on Fault OAM Configuration (draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 18:48:22 -0000 --_000_CC63B04EB87Cswallowciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Elisa - Though we've moved in the right direction, I don't consider my I said I wou= ld have more detailed comments this week. Here they are: OLD: Signal Flags should be processed at intermediate nodes as they MAY not only affect end-points only. They are used to enable the following signals at end points: NEW: FMS Signal Flags are used to enable the FMS signals at end point MEPs an= d the Server MEPs of the links over which the LSP is forwarded. In this docum= ent only the S flag pertains to Server MEPs. The following flags are defined: OLD: - S: Indicate to a server MEP that its should transmit AIS and LKR si= gnals on the client LSP as well as one the server LSP. Default value is 0= (disabled). NEW: - S: Indicate to a server MEP that its should transmit AIS and LKR si= gnals on the client LSP. Default value is 0 (disabled). OLD: Refresh Timer: indicates the refresh timer of fault indication messag= es. If the edge LSR receiving the Path message can not support such value, = it can reply back with a higher interval. The refresh timer interval is giv= en in steps of 0.5 seconds, giving a timer interval range of between 0.5 se= conds (1) to circa 1 hour (8191). NEW: Refresh Timer: indicates the refresh timer of fault indication messag= es. If the edge LSR receiving the Path message can not support such value, it c= an reply back with a higher interval. [The rest of the text contradicts the Fault Management RFC. Either del= ete it or align it. My preference is to delete.] Comment: There should be some text to say that when both working and protect paths a= re signaled, both LSPs SHOULD be signaled with identical settings of the E = flag, T flag and the refresh timer. [Note I say SHOULD here only because i= t is beyond the control of GMPLS procedures to control this.] =85George From: Elisa Bellagamba > Date: Wednesday, August 29, 2012 6:13 AM To: "ccamp@ietf.org" > Cc: Pontus Sk=F6ldstr=F6m >, Attila Takacs >, "dward@cisco.com" >, Loa Andersson >, = George Swallow > Subject: RE: [CCAMP] Comments on Fault OAM Configuration (draft-ietf-ccamp-= rsvp-te-mpls-tp-oam-ext-08) Hello, please find George's comment resolved here http://diffchecker.com/v44hA973. Best Regards, Elisa and Pontus ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of George Swallow (swallow) Sent: Thursday, July 19, 2012 4:57 PM To: ccamp@ietf.org Subject: [CCAMP] Comments on Fault OAM Configuration (draft-ietf-ccamp-rsvp= -te-mpls-tp-oam-ext-08) Authors - Some comments just on the FM parts for now. Section 3.1.3. Configuration of Fault Management Signals The first three paragraphs of this section have nothing to do with Fault OA= M except the last phrase of the first paragraph, "and Fault Management Sign= al handling." The text in the first paragraph needs to be moved above the PM and Fault se= ctions. The second and third paragraphs belong in the PM section. The forth paragraph needs some work, but I defer on suggesting rewording un= til we decide the issues below. Section 3.5. MPLS OAM FMS sub-TLV 1. The way the section is written, it appears to be concerned with what si= gnals are produced by endpoints (as opposed to how endpoints will react to = received FM OAM). In that case, I don't see the point in having an "D" fla= g. LDI is a flag carried on the AIS message. If a implementation supports= the LDI flag it will set it appropriately. If it doesn't it will never se= t it. What configuration is needed? 2. Why do we need independent configuration of the L and A flags. Under w= hat circumstances would an operator want one and not the other? Remember t= hat options cost real $$$ to develop (small) and test (not so small since y= ou have to do all combinations and often test against multiple releases inc= luding interoperability with other vendors). 3. I believe operators will want to set FM timers on a node-wide basis (or= perhaps a card-wide basis). Generally I see no point in one end of a TP L= SP telling the other how this timer should be set. Further there is no nee= d for consistency in the two directions. If it were up to me I would drop = it. I suppose that is some rare circumstances if the End Service is MPLS-TP a c= ustomer (client of the SP) might want something special. So if folks want t= o retain it, then I suggest another flag that says timer field valid. The d= efault setting of the flag would be 0, I.e. no timer. 4. The draft correctly states that it is not intended to configure mid-poi= nt behavior of the server MEP. But I do believe it is worthwhile to have a= n FM subscription flag in the object for server layer MEPs to examine and d= etermine if the LSP would like any AIS/LKR messages that the server layer p= roduces sent on this LSP. This should be a SHOULD. Ie. At each hop of an= LSP, nodes SHOULD examine the FM subscription flag. If the flag is set th= en the server MEPs at this node SHOULD insert FM messages as appropriate in= this LSP. If the flag is not set these MEPs SHOULD NOT insert FM messages= . =85George --_000_CC63B04EB87Cswallowciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Elisa -

Though we've moved in the right direction, I don't consider my I said = I would have more detailed comments this week.  Here they are:

OLD:

   Signal Flags should be processed at intermediate nodes as= they
   MAY not only affect end-points only.  They are used = to enable the
   following signals at end points:

NEW:

   FMS Signal Flags are used to enable the FMS sig= nals at end point MEPs and the 
   Server MEPs of the links over which the LSP is forwarded.=  In this document only the S flag
   pertains to Server MEPs.

   The following flags are defined:

OLD:
      
      - S: Indicate to a server MEP that its should tra= nsmit AIS and LKR signals on 
           the client LSP as well as one= the server LSP. Default value is 0 (disabled).

NEW:
      
      - S: Indicate to a server MEP that its should tra= nsmit AIS and LKR signals on 
           the client LSP. Default value= is 0 (disabled).

OLD:

      Refresh Timer: indicates the refresh timer of fault indication= messages. If the edge LSR receiving the Path message can not support such = value, it can reply back with a higher interval. The refresh timer interval is given in steps of 0.5 seconds, giving a timer interval r= ange of between 0.5 seconds (1) to circa 1 hour (8191).

NEW:

      Refresh Timer: indicates the refresh timer of fault indicat= ion messages.
If the edge LSR= receiving the Path message can not support such value, it can reply back w= ith a higher interval.

    [The rest of the text contradicts the Fault Management R= FC.  Either delete it or align it.  My preference is to delete.]<= /div>

Comment:

There should be some text to say that when both working and protect pa= ths are signaled, both LSPs SHOULD be signaled with identical settings of t= he E flag, T flag and the refresh timer.  [Note I say SHOULD here only= because it is beyond the control of GMPLS procedures to control this.]

=85George

From: Elisa Bellagamba <elisa.bellagamba@ericsson.com= >
Date: Wednesday, August 29, 2012 6:= 13 AM
To: "ccamp@ietf.org" <cca= mp@ietf.org>
Cc: Pontus Sk=F6ldstr=F6m <Pontus.Skoldstrom@acreo.se>= , Attila Takacs <Attila.Ta= kacs@ericsson.com>, "dward@c= isco.com" <dward@cisco.com>, Loa Anders= son <loa@pi.nu>, George Swallow <= swallow@cisco.com>
Subject: RE: [CCAMP] Comments on Fa= ult OAM Configuration (draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08)

&nbs= p;
Hello= ,
 
pleas= e find George's comment resolved here http://diffchec= ker.com/v44hA973.
 
Best = Regards,
Elisa= and Pontus
 

From: ccamp-bounces@ietf.org [mailt= o:ccamp-bounces@ietf.org] On Behalf Of George Swallow (swallow)
Sent: Thursday, July 19, 2012 4:57 PM
To: ccamp@ietf.org
Subject: [CCAMP] Comments on Fault OAM Configuration (draft-ietf-cca= mp-rsvp-te-mpls-tp-oam-ext-08)

Authors = -

Some comme= nts just on the FM parts for now.

Section&nb= sp;3.1.3. Confi= guration of Fault Management Signals

The first three paragraph= s of this section have nothing to do with Fault OAM except the last phrase of the first paragraph, "and Fault Management Sign= al handling."

The text in the first paragraph needs to be moved above the PM and = Fault sections. The second and third paragraphs belong in the PM section.

The forth paragrap= h needs some work, but I defer on suggesting rewording until we decide the = issues below.
Section 3.5.  MPLS OAM FMS sub-TLV
1.  The way the section is written, it appears to =
be concerned with what signals are produced by endpoints (as opposed to how=
 endpoints will react to received FM OAM).  In that case, I don't see the p=
oint in having an "D" flag.  LDI is a flag carried on the AIS mes=
sage.  If a implementation supports the LDI flag it will set it appropriate=
ly.  If it doesn't it will never set it.  What configuration is needed?
2.  Why do we need independent configuration of the L and A flags.  Un=
der what circumstances would an operator want one and not the other?  Remem=
ber that options cost real $$$ to develop (small) and test (not so small si=
nce you have to do all combinations and often test against multiple release=
s including interoperability with other vendors).
3.  I believe operators will want to set FM timers on a node-wide basi=
s (or perhaps a card-wide basis).  Generally I see no point in one end of a=
 TP LSP telling the other how this timer should be set.  Further there is n=
o need for consistency in the two directions.  If it were up to me I w=
ould drop it.
I suppose that is some rare circumstances if the End Service is MP= LS-TP a customer (client of the SP) might want something special. So if fol= ks want to retain it, then I suggest another flag that says timer field valid. The default setting of the flag = would be 0, I.e. no timer. 
4.  The draft correctly states that it is not intended to configure mi=
d-point behavior of the server MEP.  But I do believe it is worthwhile to h=
ave an FM subscription flag in the object for server layer MEPs to examine =
and determine if the LSP would like any AIS/LKR messages that the server la=
yer produces sent on this LSP.  This should be a SHOULD.  Ie.  At each hop =
of an LSP, nodes SHOULD examine the FM subscription flag.  If the flag is s=
et then the server MEPs at this node SHOULD insert FM messages as appropria=
te in this LSP.  If the flag is not set these MEPs SHOULD NOT insert FM mes=
sages.
=85George



 --_000_CC63B04EB87Cswallowciscocom_-- From rgandhi@cisco.com Fri Aug 31 06:49:37 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3D321F860D for ; Fri, 31 Aug 2012 06:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.905 X-Spam-Level: X-Spam-Status: No, score=-8.905 tagged_above=-999 required=5 tests=[AWL=1.694, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7bFdppUtpPp for ; Fri, 31 Aug 2012 06:49:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B218D21F85EA for ; Fri, 31 Aug 2012 06:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=692; q=dns/txt; s=iport; t=1346420976; x=1347630576; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=o+n61xj9PX1/8EbRyriFTv/QSQnA/CsOLlkKgQodoYM=; b=ONCvP7bqDd6yiqT2lqpujZaWyZDzEkh5HfMJWrdoadMq6OVWJVFPBEdE 6eecN+0+sTU17Uq7R419wOGYkkkujQysyJxCd25pxn/C7MCPUrzJi7KXV ydmshtJEmWH8jHTM+5Wyqe3fRO09sK9UmLvPr9xknKg4PWEznUzRIkjru g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANe/QFCtJXG8/2dsb2JhbABFuxaBB4IiAQQSASc/EgEWFBRCJgEEDg0ah2ucKqApkSpgA6QLgWeCYw X-IronPort-AV: E=Sophos;i="4.80,347,1344211200"; d="scan'208";a="116981611" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 31 Aug 2012 13:49:36 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7VDnaH0031294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Aug 2012 13:49:36 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Fri, 31 Aug 2012 08:49:36 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger Thread-Topic: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac2Hf3Os+VLHAQPjT0mEShgHpTx4wg== Date: Fri, 31 Aug 2012 13:49:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.244.16] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19152.000 x-tm-as-result: No--34.135400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 13:49:37 -0000 Hi Lou, Fei, When an (originating) ingress node is provisioned with "5 (TBD) Single Sid= ed Associated Bidirectional LSPs (A)" and wishes to control both forward a= nd reverse LSPs by adding "REVERSE_LSP" object, I would think that the ing= ress node needs to know about the signaling (path) errors (such as soft pre= emption or admission failure) on the reverse LSP. Is there any text somewh= ere in an RFC/draft that describes how a mid-point node can send the signal= ing (path) error to the originating ingress node for the reverse LSP? Is th= ere an assumption to use RSVP_NOTIFY message? Sorry if I had missed any pre= vious discussion on this topic. Thanks, Rakesh From internet-drafts@ietf.org Fri Aug 31 22:43:32 2012 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AC311E80D2; Fri, 31 Aug 2012 22:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2s0JLGjQUXQP; Fri, 31 Aug 2012 22:43:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550FD11E80AD; Fri, 31 Aug 2012 22:43:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120901054332.3570.9697.idtracker@ietfa.amsl.com> Date: Fri, 31 Aug 2012 22:43:32 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-dpm-08.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 05:43:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Label Switched Path (LSP) Data Path Delay Metrics in Gen= eralized MPLS/ MPLS-TE Networks Author(s) : Weiqiang Sun Guoying Zhang Filename : draft-ietf-ccamp-dpm-08.txt Pages : 34 Date : 2012-08-31 Abstract: When setting up a label switched path (LSP) in Generalized MPLS and MPLS/TE networks, the completion of the signaling process does not necessarily mean that the cross connection along the LSP have been programmed accordingly and in a timely manner. Meanwhile, the completion of signaling process may be used by LSP users or applications that control their use as indication that data path has become usable. The existence of the inconsistency between the signaling messages and cross connection programing, and the possible failure of cross connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the way in which LSPs are used and to make applications or tools that depend on and use LSPs more robust. This document defines a series of performance metrics to evaluate the connectivity of data path in the signaling process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-dpm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-dpm-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-dpm-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/