From owner-ccamp@ops.ietf.org Tue Mar 1 13:54:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27432 for ; Tue, 1 Mar 2005 13:54:55 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6CXH-0002o7-FM for ccamp-archive@ietf.org; Tue, 01 Mar 2005 13:56:00 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6CLg-0008eq-KC for ccamp-data@psg.com; Tue, 01 Mar 2005 18:44:00 +0000 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6CLe-0008eF-0X for ccamp@ops.ietf.org; Tue, 01 Mar 2005 18:43:58 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id j21Ib2kw028069; Tue, 1 Mar 2005 10:37:02 -0800 (PST) Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id j21Iasra028002; Tue, 1 Mar 2005 10:36:55 -0800 (PST) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.2/8.13.2) with ESMTP id j21IamMI004978; Tue, 1 Mar 2005 10:36:48 -0800 (PST) Received: from PHOENIX (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id j21Iaex03746; Tue, 1 Mar 2005 10:36:42 -0800 (PST) From: "Richard Rabbat" To: , , "'Sadler, Jonathan B.'" Cc: "'Ong, Lyndon'" , "'Adrian Farrel'" , "'Richard Rabbat'" , , "'Greg Bernstein'" Subject: question about RFC 3946 Date: Tue, 1 Mar 2005 10:36:16 -0800 Message-ID: <004701c51e8d$91e6a100$473ba485@PHOENIX> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01C51E4A.83C36100" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec This is a multi-part message in MIME format. ------=_NextPart_000_0048_01C51E4A.83C36100 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Dimitri, Eric, Jonathan,=20 I have a question about RFC 3946. =20 I'm trying to figure out how to understand text about setting NCC and = RCC=20 values for STS-3c and VC-4. Here's the context: =20 Quoting from RFC 3946: =20 Note 1: when requesting a SONET STS-Nc SPE with N=3D3*X, the Elementary Signal to use must always be an STS-3c_SPE signal type and the value of NCC must always be equal to X. This allows also facilitating the interworking between SONET and SDH. In particular, it means that the contiguous concatenation of three STS-1 SPEs can not be requested because according to this specification, this type of signal must be coded using the STS-3c SPE signal type. =20 Note 1 implies that for SONET STS-3c SPE, NCC =3D1 =20 Note 2: when requesting a transparent STS-N/STM-N signal limited to a single contiguously concatenated STS-Nc_SPE/VC-4-Nc, the signal type must be STS-N/STM-N, RCC with flag 1 and NCC set to 1. =20 Note 2 seems to imply that for STS-3c_SPE/VC-4-1c, RCC =3D NCC =3D 1 =20 Then later on: =20 The NCC value must be consistent with the type of contiguous concatenation being requested in the RCC field. In particular, this field is irrelevant if no contiguous concatenation is requested (RCC =3D 0), in that case it must be set to zero when sent, and should be ignored when received. A RCC value different from 0 must imply a number of contiguous components greater than 1. =20 Given that RCC must be different from 0, the last sentence literally=20 says that an RCC value of 1 (thus different from 0) must imply that NCC = > 1. =20 Going on to the examples of Annex 1: 1. A VC-4 signal is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1 and T with value 0 to a VC-4 Elementary Signal. ... 8. An STS-3c SPE signal is formed by the application of RCC with value 1 (standard contiguous concatenation), NCC with value 1, NVC with value 0, MT with value 1 and T with value 0 to an STS- 3c SPE Elementary Signal. =20 So, what values of NCC and RCC should one use for STS-3c/VC-4? -- Option 1-a: Set NCC =3D RCC =3D 1 for STS-3c and VC-4. Example 1 of the annex is not = the RFC text and should not be followed. =20 Option 1-b: Set NCC =3D RCC =3D 0 for STS-3c and VC-4. Example 8 of the annex is not = the RFC text and should not be followed. =20 Option 2: Set NCC =3D RCC =3D 0 for VC-4 and NCC =3D RCC =3D 1 for STS-3c AND = convert these values when moving between SDH and SONET domains =20 Option 3: Find some NCC-RCC combination that satisfies: " A RCC value different from 0 must imply a number of contiguous components greater than 1." =20 I sent email to Greg Bernstein, and he is of the opinion that options = 1-a or 1-b are best. If you also agree, we may need an errata along the lines: =20 Those would be the suggested changes. =20 FROM: The NCC value must be consistent with the type of contiguous concatenation being requested in the RCC field. In particular, this field is irrelevant if no contiguous concatenation is requested (RCC =3D 0), in that case it must be set to zero when sent, and should be ignored when received. A RCC value different from 0 must imply a number of contiguous components greater than 1. TO: The NCC value must be consistent with the type of contiguous concatenation being requested in the RCC field. In particular, this field is irrelevant if no contiguous concatenation is requested (RCC =3D 0), in that case it must be set to zero when sent, and should be ignored when received. A RCC value different from 0 must imply a number of contiguous components greater than or equal to 1. ^^^^^^^^^^^^<- for = option 1.a FROM: 1. A VC-4 signal is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1 and T with value 0 to a VC-4 Elementary Signal. =20 8. An STS-3c SPE signal is formed by the application of RCC with value 1 (standard contiguous concatenation), NCC with value 1, NVC with value 0, MT with value 1 and T with value 0 to an STS- 3c SPE Elementary Signal. TO: 1. A VC-4 signal and an STS-3c SPE signal are formed by the application of RCC with value i, NCC with value i, NVC with value 0, MT with value 1 and T with value 0 to a VC-4 Elementary Signal and an STS-3c SPE Elementary Signal respectively. (RR: To replace i with 0 if we choose option 1a and 1 for option = 1b) =20 8. An STS-3c SPE signal is formed as shown in example 1. RFC 3946's example 8 is now deprecated. In order to support earlier versions of the standard, a node should accept RFC 3946-compliant values of NCC =3D RCC =3D !i = when receiving them until all known implementations have updated their code to the Errata.=20 (RR: make sure we accept the other value) Looking forward to your answer. Richard. =20 =20 =20 =20 =20 ------=_NextPart_000_0048_01C51E4A.83C36100 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Hi Dimitri,=20 Eric, Jonathan,
I have a=20 question about RFC 3946.
 
I'm trying to figure out = how to=20 understand text about setting NCC and RCC 
values for STS-3c and VC-4. Here's=20 the context:
 
Quoting from RFC = 3946:
 
   Note 1: when = requesting a=20 SONET STS-Nc SPE with N=3D3*X, the
      = Elementary=20 Signal to use must always be an STS-3c_SPE signal=20 type
      and the value of NCC must always = be equal=20 to X.  This allows also
      = facilitating the=20 interworking between SONET and SDH.  = In
     =20 particular, it means that the contiguous concatenation of=20 three
      STS-1 SPEs can not be requested = because=20 according to this
      specification, this = type of=20 signal must be coded using the STS-3c
      = SPE=20 signal type.
 
Note 1 implies that for SONET = STS-3c SPE,=20 NCC =3D1
 
   Note 2: when = requesting a=20 transparent STS-N/STM-N signal
      limited = to a=20 single contiguously concatenated=20 STS-Nc_SPE/VC-4-Nc,
      the signal type = must be=20 STS-N/STM-N, RCC with flag 1 and NCC = set
      to=20 1.
 
Note 2 seems to imply that for=20 STS-3c_SPE/VC-4-1c, RCC =3D NCC =3D 1
 
Then later on:
 
   The NCC value must = be=20 consistent with the type of contiguous
   concatenation = being=20 requested in the RCC field.  In particular, this
   = field is=20 irrelevant if no contiguous concatenation is requested = (RCC
   =3D=20 0), in that case it must be set to zero when sent, and should = be
  =20 ignored when received.  A RCC value different from 0 must imply=20 a
   number of contiguous components greater than = 1.
 
Given=20 that RCC must be different from 0,=20 the last sentence literally
says that an RCC value of 1 = (thus different=20 from 0) must imply that NCC > 1.
 
Going on to the examples of = Annex=20 1:
   1.   A VC-4 signal is formed by the = application of=20 RCC with value 0,
        NCC with = value=20 0, NVC with value 0, MT with value 1 and T=20 with
        value 0 to a VC-4 = Elementary=20 Signal.
...
   8.   An STS-3c SPE signal is = formed by=20 the application of RCC = with
        value=20 1 (standard contiguous concatenation), NCC with value=20 1,
        NVC with value 0, MT = with value=20 1 and T with value 0 to an = STS-
        3c=20 SPE Elementary Signal.
 
So, what values of NCC and RCC = should one=20 use for STS-3c/VC-4?
--
Option 1-a:
Set NCC =3D RCC =3D 1 for = STS-3c and VC-4.=20 Example 1 of the annex is not the
RFC=20 text and should not be followed.
 
Option 1-b:
Set NCC =3D RCC =3D 0 for STS-3c and VC-4. = Example 8 of the annex is not the
RFC text and should not be = followed.
 
Option 2:
Set NCC =3D RCC = =3D 0 for VC-4 and=20 NCC =3D RCC =3D 1 for STS-3c AND convert these
values when moving = between SDH and=20 SONET domains
 
Option 3:
Find some NCC-RCC = combination=20 that satisfies:
"  A RCC value different from 0 must imply=20 a
   number of contiguous components greater than = 1."
 
I sent email=20 to Greg Bernstein, and he is of the opinion that options 1-a or 1-b are=20 best.
If you also=20 agree, we may need an errata along the lines:
 
Those would=20 be the suggested changes.
 
FROM:
   The NCC value must be = consistent=20 with the type of contiguous
   concatenation being = requested in the=20 RCC field.  In particular, this
   field is irrelevant = if no=20 contiguous concatenation is requested (RCC
   =3D 0), in = that case it=20 must be set to zero when sent, and should be
   ignored = when=20 received.  A RCC value different from 0 must imply = a
   number=20 of contiguous components greater than 1.
TO:
   The NCC = value=20 must be consistent with the type of contiguous
   = concatenation=20 being requested in the RCC field.  In particular, = this
  =20 field is irrelevant if no contiguous concatenation is requested=20 (RCC
   =3D 0), in that case it must be set to zero when = sent, and=20 should be
   ignored when received.  A RCC value = different=20 from 0 must imply a
   number of contiguous components = greater than=20 or equal to=20 1.
           &= nbsp;           &n= bsp;           &nb= sp;           =20 ^^^^^^^^^^^^<- for option 1.a
FROM:
   1.   = A VC-4=20 signal is formed by the application of RCC with value=20 0,
        NCC with value 0, NVC = with=20 value 0, MT with value 1 and T=20 with
        value 0 to a VC-4 = Elementary=20 Signal.
 
  =20 8.   An STS-3c SPE signal is formed by the application of RCC=20 with
        value 1 (standard = contiguous=20 concatenation), NCC with value = 1,
       =20 NVC with value 0, MT with value 1 and T with value 0 to an=20 STS-
        3c SPE Elementary=20 Signal.
TO:
   1.   A VC-4 signal and an = STS-3c SPE=20 signal are formed by the
       =20 application of RCC with value i, NCC with value i, NVC=20 with
        value 0, MT with = value 1 and=20 T with value 0 to a VC-4=20 Elementary
        Signal and an = STS-3c=20 SPE Elementary Signal respectively.
       &nbs= p;(RR: To=20 replace i with 0 if we choose option 1a and 1 for option=20 1b)
 
  =20 8.   An STS-3c SPE signal is formed as shown in example 1. RFC = 3946's
        example 8 is now=20 deprecated.
        In order to = support=20 earlier versions of the standard, a=20 node
        should accept RFC=20 3946-compliant values of NCC =3D RCC =3D !i=20 when
        receiving them until = all=20 known implementations have = updated
       =20 their code to the Errata.
        = (RR: make=20 sure we accept the other value)
Looking=20 forward to your answer.
Richard.
 
 
 
 
 
------=_NextPart_000_0048_01C51E4A.83C36100-- From owner-ccamp@ops.ietf.org Tue Mar 1 14:05:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29371 for ; Tue, 1 Mar 2005 14:05:10 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ChD-0003R7-Qf for ccamp-archive@ietf.org; Tue, 01 Mar 2005 14:06:16 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6Cad-000BwM-CO for ccamp-data@psg.com; Tue, 01 Mar 2005 18:59:27 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6Cac-000Bvr-4t for ccamp@ops.ietf.org; Tue, 01 Mar 2005 18:59:26 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j21IvW9C019563; Tue, 1 Mar 2005 19:57:52 +0100 To: "Richard Rabbat" Cc: , , "'Sadler, Jonathan B.'" , "'Ong, Lyndon'" , "'Adrian Farrel'" , "'Richard Rabbat'" , , "'Greg Bernstein'" From: Dimitri.Papadimitriou@alcatel.be Subject: Re: question about RFC 3946 MIME-Version: 1.0 Date: Tue, 1 Mar 2005 19:57:32 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 03/01/2005 19:58:00 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a richard: "greater" does not mean "strictly greater" it means "greater or equal" So, what values of NCC and RCC should one use for STS-3c/VC-4? for STS-3c: An STS-3c SPE signal is formed by the application of RCC with value 1 (standard contiguous concatenation), NCC with value 1, NVC with value 0, MT with value 1 and T with value 0 to an STS- 3c SPE Elementary Signal. for VC-4: A VC-4 signal is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1 and T with value 0 to a VC-4 Elementary Signal. do not know if this clarifies - hint: Note 2 refers to transparent STS-N/STM-N signals (signal type 7->12) From owner-ccamp@ops.ietf.org Tue Mar 1 14:57:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04392 for ; Tue, 1 Mar 2005 14:57:26 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6DVk-0004af-PM for ccamp-archive@ietf.org; Tue, 01 Mar 2005 14:58:33 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6DNy-000NdI-7o for ccamp-data@psg.com; Tue, 01 Mar 2005 19:50:26 +0000 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D6DNw-000Ncv-FD for ccamp@ops.ietf.org; Tue, 01 Mar 2005 19:50:24 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id j21JkuiL025259; Tue, 1 Mar 2005 11:46:56 -0800 (PST) Received: from fujitsu7i.fnanic.fujitsu.com ([133.164.253.7]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id j21Jkr9s025241; Tue, 1 Mar 2005 11:46:53 -0800 (PST) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsu7i.fnanic.fujitsu.com (8.13.2/8.13.2) with ESMTP id j21JkcUo009728; Tue, 1 Mar 2005 11:46:38 -0800 (PST) Received: from PHOENIX (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id j21JkQx12751; Tue, 1 Mar 2005 11:46:27 -0800 (PST) From: "Richard Rabbat" To: Cc: , "'Sadler, Jonathan B.'" , "'Ong, Lyndon'" , "'Adrian Farrel'" , , "'Greg Bernstein'" Subject: RE: question about RFC 3946 Date: Tue, 1 Mar 2005 11:46:02 -0800 Message-ID: <005901c51e97$537cf400$473ba485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: Importance: Normal X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Dimitri, Thanks for the answer. Now, STS-3c and VC-4 share the same signal type. Should they still be formed differently? Richard. > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Tuesday, March 01, 2005 10:58 AM > To: Richard Rabbat > Cc: Dimitri.Papadimitriou@alcatel.be; > eric_mannie@hotmail.com; 'Sadler, Jonathan B.'; 'Ong, > Lyndon'; 'Adrian Farrel'; 'Richard Rabbat'; > ccamp@ops.ietf.org; 'Greg Bernstein' > Subject: Re: question about RFC 3946 > > > > richard: > > "greater" does not mean "strictly greater" it means "greater or equal" > > So, what values of NCC and RCC should one use for STS-3c/VC-4? > > for STS-3c: > An STS-3c SPE signal is formed by the application of RCC with > value 1 (standard contiguous concatenation), NCC with value 1, > NVC with value 0, MT with value 1 and T with value 0 > to an STS- > 3c SPE Elementary Signal. > > for VC-4: > A VC-4 signal is formed by the application of RCC > with value 0, > NCC with value 0, NVC with value 0, MT with value 1 and T with > value 0 to a VC-4 Elementary Signal. > > do not know if this clarifies - > > hint: Note 2 refers to transparent STS-N/STM-N signals > (signal type 7->12) > > > > > > From owner-ccamp@ops.ietf.org Tue Mar 1 15:17:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07209 for ; Tue, 1 Mar 2005 15:17:16 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Dp0-00052M-Cw for ccamp-archive@ietf.org; Tue, 01 Mar 2005 15:18:22 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6Dfs-0001rd-6z for ccamp-data@psg.com; Tue, 01 Mar 2005 20:08:56 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6Dfn-0001r9-1L for ccamp@ops.ietf.org; Tue, 01 Mar 2005 20:08:52 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 01 Mar 2005 15:23:27 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,127,1107752400"; d="scan'208"; a="38880727:sNHT21279672" Received: from zaliwxp (che-vpn-cluster-1-210.cisco.com [10.86.240.210]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j21K8S1j006643; Tue, 1 Mar 2005 15:08:29 -0500 (EST) Message-Id: <200503012008.j21K8S1j006643@rtp-core-1.cisco.com> From: "Zafar Ali" To: "'Richard Rabbat'" , "'Adrian Farrel'" , Subject: RE: Draft status updated on alternate CCAMP web page Date: Tue, 1 Mar 2005 15:08:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUaovD8B+NmdnguQaCdiCl+oOdUdQD9lc3w In-Reply-To: <003b01c51aa1$e408b580$483ba485@PHOENIX> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Hi Richard, Re: the ID (draft-shiomoto-ccamp-gmpls-addressing-00), I did find it quite useful and IMO we should pursue this further in CCAMP. Having said that, I would like to point that there are a number of ID-es that are currently NOT in Adrian's list and I think this has to do with his comment in the original email (quoting Adrian): "I have yet to update the section that covers personal drafts related to CCAMP." Adrian, please correct me/ add/ del. Thanks Regards... Zafar > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Richard Rabbat > Sent: Thursday, February 24, 2005 1:52 PM > To: 'Adrian Farrel'; ccamp@ops.ietf.org > Subject: RE: Draft status updated on alternate CCAMP web page > > Adrian, > Can you add > http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls > -addressing-00 > .txt > to your draft tracker? > > We sent out email about it and have received feedback > off-list. We're planning on discussing this draft in > Minneapolis and would love to have more on-list discussions. > As you can see from the list of contributors, there is > enormous interest in this draft and we hope it serves as a > basis for thoughtful discussions. > Best, > Richard, Rajiv and Kohei. > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > Sent: Monday, February 21, 2005 10:35 AM > > To: Adrian Farrel; ccamp@ops.ietf.org > > Subject: Re: Draft status updated on alternate CCAMP web page > > > > > > So, I can't type. > > Want to make something of it? > > http://www.olddog.co.uk/ccamp-drafts.htm > > > > (Thanks Jean-Louis) > > > > Adrian > > > > ----- Original Message ----- > > From: "Adrian Farrel" > > To: > > Sent: Monday, February 21, 2005 12:32 PM > > Subject: Draft status updated on alternate CCAMP web page > > > > > > > I have updated http://www.oldog.co.uk/ccamp-drafts.htm to > > indicate the > > > current status of all CCAMP drafts. I have yet to update > the section > > that > > > covers personal drafts related to CCAMP. > > > > > > Adrian > > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Wed Mar 2 17:03:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03074 for ; Wed, 2 Mar 2005 17:03:21 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6bxP-0004WU-QW for ccamp-archive@ietf.org; Wed, 02 Mar 2005 17:04:41 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6bkw-000L3T-Er for ccamp-data@psg.com; Wed, 02 Mar 2005 21:51:46 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6bkr-000Kxs-Rm for ccamp@ops.ietf.org; Wed, 02 Mar 2005 21:51:42 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Mar 2005 22:51:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Date: Wed, 2 Mar 2005 22:51:40 +0100 Message-ID: Thread-Topic: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Thread-Index: AcUfcYD///LTML9cQJ2kXP1XFm9NVwAACgAg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 02 Mar 2005 21:51:40.0131 (UTC) FILETIME=[03DA7B30:01C51F72] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Hi all, Here is a new draft evaluating current GMPLS protocols wrt MRN requirements. Your comments on this new draft would be highly appreciated. Best Regards, JL To: i-d-announce at ietf.org=20 Subject: I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt=20 From: Internet-Drafts at ietf.org=20 Date: Tue, 15 Feb 2005 10:14:38 -0500=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Evaluation of existing GMPLS Protocols against Multi Region Networks Author(s) : J. Le Roux, et al. Filename : draft-leroux-ccamp-gmpls-mrn-eval-00.txt Pages : 11 Date : 2005-2-14 =09 This document provides an evaluation of Generalized Multi-Protocol=20 Label Switching (GMPLS) protocols and mechanisms against the=20 requirements for Multi Region Networks (MRN). =20 In addition, this document identifies areas where additional=20 protocol extensions or procedures are needed to satisfy the=20 requirements of Multi Region Networks, and provides guidelines for=20 potential extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mrn-eval-00 .txt From owner-ccamp@ops.ietf.org Thu Mar 3 14:56:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06899 for ; Thu, 3 Mar 2005 14:56:05 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6wRz-0001oW-A5 for ccamp-archive@ietf.org; Thu, 03 Mar 2005 14:57:35 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6wFy-000HZc-MW for ccamp-data@psg.com; Thu, 03 Mar 2005 19:45:10 +0000 Received: from [68.142.200.148] (helo=web30805.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D6wFw-000HZ0-Bj for ccamp@ops.ietf.org; Thu, 03 Mar 2005 19:45:08 +0000 Received: (qmail 53952 invoked by uid 60001); 3 Mar 2005 19:45:04 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=whz4O0VjfNchE7E6GgZw3683yEuAYRgyM6ER/RcFpsO51lUigqpmkiq7/02/XZ8LFI1HshXWRKNkeGqdmWVVpcaLWFdgqXTz5Z5d3GuTNX2ASqFVfSyB3xI4d3h2mFHQCTK0F1RTIIJjvVbaiw8lvgnOQHAkxifhnhRMqwiqKgI= ; Message-ID: <20050303194504.53945.qmail@web30805.mail.mud.yahoo.com> Received: from [68.100.80.11] by web30805.mail.mud.yahoo.com via HTTP; Thu, 03 Mar 2005 11:45:03 PST Date: Thu, 3 Mar 2005 11:45:03 -0800 (PST) From: Igor Bryskin Subject: Re: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt To: LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,FORGED_YAHOO_RCVD autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b JL, I have a couple of comments/suggestions. 1. The draft says that currently GMPLS does not have a mechanism to provision virtual FAs. I don’t think this is correct – I believe we could use the same mechanism as was suggested in draft-ietf-ccamp-gmpls-recovery-e2e-signaling (section 9.3) for signaling of Secondary LSPs 2. I agree that we need TE link adaptation capabilities to be advertised along with other TE link attributes such as switching capabilities, protection capabilities, etc. I suggest also adding TE link termination capabilities to this list, i.e. decoupling of these capabilities from adaptation capabilities: to terminate LSP in a particular layer and to adopt into it LSPs of one or more higher layers are separate resources and could be considered separately in the inter-layer path computations; 3. Everything that is said about regions, region boundaries, etc. is also applicable for layers contained within regions. I suggest to do what we have already done in the PCE WG documents and presentations: replace word region with word layer everywhere apart from where signaling specific aspects are discussed. Thanks, Igor --- LE ROUX Jean-Louis RD-CORE-LAN wrote: > > Hi all, > > Here is a new draft evaluating current GMPLS > protocols wrt MRN > requirements. > Your comments on this new draft would be highly > appreciated. > > Best Regards, > > JL > > To: i-d-announce at ietf.org > Subject: I-D > ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt > From: Internet-Drafts at ietf.org > Date: Tue, 15 Feb 2005 10:14:38 -0500 > > A New Internet-Draft is available from the on-line > Internet-Drafts > directories. > > > Title : Evaluation of existing GMPLS Protocols > against > Multi Region Networks > Author(s) : J. Le Roux, et al. > Filename : draft-leroux-ccamp-gmpls-mrn-eval-00.txt > Pages : 11 > Date : 2005-2-14 > > This document provides an evaluation of Generalized > Multi-Protocol > Label Switching (GMPLS) protocols and mechanisms > against the > requirements for Multi Region Networks (MRN). > In addition, this document identifies areas where > additional > protocol extensions or procedures are needed to > satisfy the > requirements of Multi Region Networks, and > provides guidelines for > potential extensions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mrn-eval-00 > .txt > > > > > __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From owner-ccamp@ops.ietf.org Thu Mar 3 21:29:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11855 for ; Thu, 3 Mar 2005 21:29:46 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D72b2-0001P2-4b for ccamp-archive@ietf.org; Thu, 03 Mar 2005 21:31:20 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D72RO-0003rS-F6 for ccamp-data@psg.com; Fri, 04 Mar 2005 02:21:22 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D72RL-0003qk-Qf; Fri, 04 Mar 2005 02:21:20 +0000 Message-ID: <4227C61E.2000205@psg.com> Date: Fri, 04 Mar 2005 03:21:18 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Bryskin CC: LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org Subject: Re: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt References: <20050303194504.53945.qmail@web30805.mail.mud.yahoo.com> In-Reply-To: <20050303194504.53945.qmail@web30805.mail.mud.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 8bit igor - i let to jl the opportunit to respond in much more in details but here below some hints: > I have a couple of comments/suggestions. > > 1. The draft says that currently GMPLS does not have a > mechanism to provision virtual FAs. I don’t think this > is correct – I believe we could use the same mechanism > as was suggested in > draft-ietf-ccamp-gmpls-recovery-e2e-signaling (section > 9.3) for signaling of Secondary LSPs there is no mechanism to setup/delete "virtual FAs" as part of GMPLS signaling protocol today the secondary LSP concept, even if the latter may look similar to the virtual FA concept - note: this is explicitly mentioned as part of the recovery document however, the advertisement of the corr. TE link must be identical to what currently exist for fully provisioned FAs > 2. I agree that we need TE link adaptation > capabilities to be advertised along with other TE link > attributes such as switching capabilities, protection > capabilities, etc. I suggest also adding TE link > termination capabilities to this list, i.e. decoupling > of these capabilities from adaptation capabilities: > to terminate LSP in a particular layer and to adopt > into it LSPs of one or more higher layers are separate > resources and could be considered separately in the > inter-layer path computations; would you let us know what is missing in terms of termination capabilities - before we expand on this ? > 3. Everything that is said about regions, region > boundaries, etc. is also applicable for layers > contained within regions. I suggest to do what we have > already done in the PCE WG documents and > presentations: replace word region with word layer > everywhere apart from where signaling specific aspects > are discussed. i suggest you take a look at section 3.1 of it may help in understand the region vs layer concepts > Thanks, > Igor > > > > --- LE ROUX Jean-Louis RD-CORE-LAN > wrote: > > > > >>Hi all, >> >>Here is a new draft evaluating current GMPLS >>protocols wrt MRN >>requirements. >>Your comments on this new draft would be highly >>appreciated. >> >>Best Regards, >> >>JL >> >>To: i-d-announce at ietf.org >>Subject: I-D >>ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt >>From: Internet-Drafts at ietf.org >>Date: Tue, 15 Feb 2005 10:14:38 -0500 >> >>A New Internet-Draft is available from the on-line >>Internet-Drafts >>directories. >> >> >> Title : Evaluation of existing GMPLS Protocols >>against >>Multi Region Networks >> Author(s) : J. Le Roux, et al. >> Filename : draft-leroux-ccamp-gmpls-mrn-eval-00.txt >> Pages : 11 >> Date : 2005-2-14 >> >>This document provides an evaluation of Generalized >>Multi-Protocol >> Label Switching (GMPLS) protocols and mechanisms >>against the >> requirements for Multi Region Networks (MRN). >> In addition, this document identifies areas where >>additional >> protocol extensions or procedures are needed to >>satisfy the >> requirements of Multi Region Networks, and >>provides guidelines for >> potential extensions. >> >>A URL for this Internet-Draft is: >> > > http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mrn-eval-00 > >>.txt >> >> >> >> >> > > > > > > > __________________________________ > Celebrate Yahoo!'s 10th Birthday! > Yahoo! Netrospective: 100 Moments of the Web > http://birthday.yahoo.com/netrospective/ > > > . > From owner-ccamp@ops.ietf.org Fri Mar 4 04:44:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20295 for ; Fri, 4 Mar 2005 04:44:47 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D79O4-0005Eh-Vk for ccamp-archive@ietf.org; Fri, 04 Mar 2005 04:46:25 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D79D3-000PBi-Pp for ccamp-data@psg.com; Fri, 04 Mar 2005 09:35:01 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D79D1-000PBC-8v for ccamp@ops.ietf.org; Fri, 04 Mar 2005 09:34:59 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Mar 2005 10:34:55 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Date: Fri, 4 Mar 2005 10:35:10 +0100 Message-ID: Thread-Topic: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Thread-Index: AcUgKYHELyJ/qyG8QG2tPdoiCwZ9BAAaRajw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" , X-OriginalArrivalTime: 04 Mar 2005 09:34:55.0653 (UTC) FILETIME=[6CC1ED50:01C5209D] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Hi Igor,=20 Thanks for these comments Please see inline >-----Message d'origine----- >De : Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 >Envoy=E9 : jeudi 3 mars 2005 20:45 >=C0 : LE ROUX Jean-Louis RD-CORE-LAN; ccamp@ops.ietf.org >Objet : Re: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt=20 > > >JL, > >I have a couple of comments/suggestions. > >1. The draft says that currently GMPLS does not have a >mechanism to provision virtual FAs. I don't think this >is correct - I believe we could use the same mechanism >as was suggested in=20 >draft-ietf-ccamp-gmpls-recovery-e2e-signaling (section >9.3) for signaling of Secondary LSPs I wouldn't be so expeditious... Actually we could use a similar mechanism but definitely not the same. Secondary LSP are dedicated to Shared Meshed Restoration. IMHO this would be bad to use the Protection object for soft-FAs. = Semantics are pretty different... >2. I agree that we need TE link adaptation >capabilities to be advertised along with other TE link=20 >attributes such as switching capabilities, protection=20 >capabilities, etc. I suggest also adding TE link termination=20 >capabilities to this list, i.e. decoupling of these=20 >capabilities from adaptation capabilities:=20 >to terminate LSP in a particular layer and to adopt >into it LSPs of one or more higher layers are separate=20 >resources and could be considered separately in the=20 >inter-layer path computations; I agree that our curent terminology may be confusing What we call Internal Adapatation Capability actually refers to = Termination capabilities. See the MRN requirement draft (version 01) for an example. >3. Everything that is said about regions, region >boundaries, etc. is also applicable for layers >contained within regions. I suggest to do what we have >already done in the PCE WG documents and >presentations: replace word region with word layer >everywhere apart from where signaling specific aspects >are discussed. See section 3 of the requirement draft. Actually what we define for region also applies to layers, but we prefer = to keep the term region here at the time being. Again, thanks a lot for these comments, Regards, JL > >Thanks, >Igor > =20 > > >--- LE ROUX Jean-Louis RD-CORE-LAN=20 > wrote: > > > >>=20 >> Hi all, >>=20 >> Here is a new draft evaluating current GMPLS >> protocols wrt MRN >> requirements. >> Your comments on this new draft would be highly >> appreciated. >>=20 >> Best Regards, >>=20 >> JL >>=20 >> To: i-d-announce at ietf.org >> Subject: I-D >> ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt=20 >> From: Internet-Drafts at ietf.org=20 >> Date: Tue, 15 Feb 2005 10:14:38 -0500=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>=20 >>=20 >> Title : Evaluation of existing GMPLS Protocols >> against >> Multi Region Networks >> Author(s) : J. Le Roux, et al. >> Filename : draft-leroux-ccamp-gmpls-mrn-eval-00.txt >> Pages : 11 >> Date : 2005-2-14 >> =09 >> This document provides an evaluation of Generalized Multi-Protocol >> Label Switching (GMPLS) protocols and mechanisms >> against the=20 >> requirements for Multi Region Networks (MRN). =20 >> In addition, this document identifies areas where >> additional=20 >> protocol extensions or procedures are needed to >> satisfy the=20 >> requirements of Multi Region Networks, and >> provides guidelines for=20 >> potential extensions. >>=20 >> A URL for this Internet-Draft is: >> >http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mr n-eval-00 > .txt >=20 >=20 >=20 >=20 > =09 =09 __________________________________=20 Celebrate Yahoo!'s 10th Birthday!=20 Yahoo! Netrospective: 100 Moments of the Web=20 http://birthday.yahoo.com/netrospective/ From owner-ccamp@ops.ietf.org Fri Mar 4 08:33:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17571 for ; Fri, 4 Mar 2005 08:33:25 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7CxM-0002ct-N7 for ccamp-archive@ietf.org; Fri, 04 Mar 2005 08:35:05 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7Cp4-000EVS-4K for ccamp-data@psg.com; Fri, 04 Mar 2005 13:26:30 +0000 Received: from [68.142.200.148] (helo=web30805.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D7Coz-000EV0-2F for ccamp@ops.ietf.org; Fri, 04 Mar 2005 13:26:25 +0000 Received: (qmail 8411 invoked by uid 60001); 4 Mar 2005 13:26:24 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=l9Aw2FKYoriDOx2y5pEGlsqaU7LHcHLEnIIxrllwOH1Ld5S1ts7XRFdOF94ta00r5rFsoGtD1ZnoHwbnouwgx6xWa53xuvMnnWwFpDqFxYqq3+weOXKfXtGkUsTKsQ3eh3DZy0UCymEw2UU7NZkzu41kmd/AvDzS+HsQddW2Pdc= ; Message-ID: <20050304132624.8409.qmail@web30805.mail.mud.yahoo.com> Received: from [68.100.80.11] by web30805.mail.mud.yahoo.com via HTTP; Fri, 04 Mar 2005 05:26:24 PST Date: Fri, 4 Mar 2005 05:26:24 -0800 (PST) From: Igor Bryskin Subject: Re: RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt To: LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,FORGED_YAHOO_RCVD autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 JL, Please, see my comments in-line Igor --- LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Igor, > > Thanks for these comments > > Please see inline > > > >-----Message d'origine----- > >De : Igor Bryskin [mailto:i_bryskin@yahoo.com] > >Envoyé : jeudi 3 mars 2005 20:45 > >À : LE ROUX Jean-Louis RD-CORE-LAN; > ccamp@ops.ietf.org > >Objet : Re: TR : I-D > ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt > > > > > >JL, > > > >I have a couple of comments/suggestions. > > > >1. The draft says that currently GMPLS does not > have a > >mechanism to provision virtual FAs. I don't think > this > >is correct - I believe we could use the same > mechanism > >as was suggested in > >draft-ietf-ccamp-gmpls-recovery-e2e-signaling > (section > >9.3) for signaling of Secondary LSPs > > I wouldn't be so expeditious... > Actually we could use a similar mechanism but > definitely not the same. > Secondary LSP are dedicated to Shared Meshed > Restoration. > IMHO this would be bad to use the Protection object > for soft-FAs. Semantics > are pretty different... > IB>>Well, are they? They give you a way to signal a requirement not to commit resources for an LSP until further notice and also to require their commitment when it becomes necessary. Why not to allow working LSP to be signaled as Secondary according to the mentioned draft? Then it would be possible even to signal protected virtual FAs, which is not as stupid as it may sound :=) > > >2. I agree that we need TE link adaptation > >capabilities to be advertised along with other TE > link > >attributes such as switching capabilities, > protection > >capabilities, etc. I suggest also adding TE link > termination > >capabilities to this list, i.e. decoupling of these > > >capabilities from adaptation capabilities: > >to terminate LSP in a particular layer and to adopt > >into it LSPs of one or more higher layers are > separate > >resources and could be considered separately in the > > >inter-layer path computations; > > I agree that our curent terminology may be confusing > What we call Internal Adapatation Capability > actually refers to Termination capabilities. > See the MRN requirement draft (version 01) for an Ø example. IB>> My point is that termination and adaptation capabilities are separate things. For instance, the fact that a link can terminate lambdas means the it has certain number of available transceivers, while the fact whether these lambdas can carry particular tributary signals depends, say, on whether SIM cards of appropriate type could be cross-connected to the transceivers. In fact, link termination bandwidth is shared between multiple adaptation functions. The bottom line is I think it would be good idea to advertise them separately. > > > >3. Everything that is said about regions, region > >boundaries, etc. is also applicable for layers > >contained within regions. I suggest to do what we > have > >already done in the PCE WG documents and > >presentations: replace word region with word layer > >everywhere apart from where signaling specific > aspects > >are discussed. > > See section 3 of the requirement draft. > Actually what we define for region also applies to > layers, but we prefer to Ø keep the term region here at the time being. IB>> And my question is why to do so, if FAs and everything to do with VNT is about layers, including those that start and stop in the middle of the region, that is, far away from region boundaries? Furthermore, when you say things like creating FA in the lower region to carry LSP for the higher region, it is not clear what do you mean by that in the case when the lower region contains multiple layers. Igor > > Again, thanks a lot for these comments, > > Regards, > > JL > > > > >Thanks, > >Igor > > > > > > > >--- LE ROUX Jean-Louis RD-CORE-LAN > > wrote: > > > > > > > >> > >> Hi all, > >> > >> Here is a new draft evaluating current GMPLS > >> protocols wrt MRN > >> requirements. > >> Your comments on this new draft would be highly > >> appreciated. > >> > >> Best Regards, > >> > >> JL > >> > >> To: i-d-announce at ietf.org > >> Subject: I-D > >> ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt > >> From: Internet-Drafts at ietf.org > >> Date: Tue, 15 Feb 2005 10:14:38 -0500 > >> > >> A New Internet-Draft is available from the > on-line Internet-Drafts > >> directories. > >> > >> > >> Title : Evaluation of existing GMPLS Protocols > >> against > >> Multi Region Networks > >> Author(s) : J. Le Roux, et al. > >> Filename : > draft-leroux-ccamp-gmpls-mrn-eval-00.txt > >> Pages : 11 > >> Date : 2005-2-14 > >> > >> This document provides an evaluation of > Generalized Multi-Protocol > >> Label Switching (GMPLS) protocols and > mechanisms > >> against the > >> requirements for Multi Region Networks (MRN). > > >> In addition, this document identifies areas > where > >> additional > >> protocol extensions or procedures are needed > to > >> satisfy the > >> requirements of Multi Region Networks, and > >> provides guidelines for > >> potential extensions. > >> > >> A URL for this Internet-Draft is: > >> > >http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mr > n-eval-00 > > .txt > > > > > > > > > > > > > > > > __________________________________ > Celebrate Yahoo!'s 10th Birthday! > Yahoo! Netrospective: 100 Moments of the Web > http://birthday.yahoo.com/netrospective/ > __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From owner-ccamp@ops.ietf.org Fri Mar 4 09:07:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20659 for ; Fri, 4 Mar 2005 09:07:27 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7DUG-0003Uw-Ry for ccamp-archive@ietf.org; Fri, 04 Mar 2005 09:09:07 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7DLB-000L61-Hu for ccamp-data@psg.com; Fri, 04 Mar 2005 13:59:41 +0000 Received: from [64.208.49.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7DL8-000L5T-RN for ccamp@ops.ietf.org; Fri, 04 Mar 2005 13:59:39 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j24DxP9C024907; Fri, 4 Mar 2005 14:59:30 +0100 To: Igor Bryskin Cc: LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Date: Fri, 4 Mar 2005 14:59:24 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 03/04/2005 14:59:32 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,HTML_20_30, HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_BASE64_TEXT,MIME_HTML_ONLY, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 4.8 (++++) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: base64 PFA+aWdvciAtIGEgc2hvcnQgaGludCBjb25jZXJuaW5nIHRoZSBmaXJzdCBwb2ludDxCUj48QlI+ PEZPTlQgU0laRT0yPjxCPklnb3IgQnJ5c2tpbiAmbHQ7aV9icnlza2luQHlhaG9vLmNvbSZndDs8 L0I+PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+U2VudCBieTogb3duZXItY2NhbXBAb3BzLmlldGYu b3JnPC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+MDMvMDQvMjAwNSAwNToyNiBQU1Q8L0ZPTlQ+PEJS PjxCUj4gPEZPTlQgU0laRT0yPlRvOjwvRk9OVD4gPEZPTlQgU0laRT0yPkxFIFJPVVggSmVhbi1M b3VpcyBSRC1DT1JFLUxBTiAmbHQ7amVhbmxvdWlzLmxlcm91eEBmcmFuY2V0ZWxlY29tLmNvbSZn dDssIGNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZPTlQ+ IDxCUj4gPEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPlN1YmplY3Q6 PC9GT05UPiA8Rk9OVCBTSVpFPTI+UmU6IFJFIDogVFIgOiBJLUQgQUNUSU9OOmRyYWZ0LWxlcm91 eC1jY2FtcC1nbXBscy1tcm4tZXZhbC0wMC50eHQ8L0ZPTlQ+PEJSPiA8QlI+PEJSPjwvUD48UD48 Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SkwsPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFD RT0iTW9ub3NwYWNlLENvdXJpZXIiPlBsZWFzZSwgc2VlIG15IGNvbW1lbnRzIGluLWxpbmU8QlI+ PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SWdvcjxCUj48L0ZPTlQ+ PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4tLS0gTEUgUk9VWCBKZWFuLUxvdWlz IFJELUNPUkUtTEFOPEJSPiZsdDtqZWFubG91aXMubGVyb3V4QGZyYW5jZXRlbGVjb20uY29tJmd0 OyB3cm90ZTo8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0 OyBIaSBJZ29yLDxCUj4mZ3Q7PEJSPiZndDsgVGhhbmtzIGZvciB0aGVzZSBjb21tZW50czxCUj4m Z3Q7PEJSPiZndDsgUGxlYXNlIHNlZSBpbmxpbmU8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgJmd0 Oy0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxCUj4mZ3Q7ICZndDtEZSA6IElnb3IgQnJ5c2tp biBbbWFpbHRvOmlfYnJ5c2tpbkB5YWhvby5jb21dPEJSPiZndDsgJmd0O0Vudm95JmVhY3V0ZTsg OiBqZXVkaSAzIG1hcnMgMjAwNSAyMDo0NTxCUj4mZ3Q7ICZndDsmQWdyYXZlOyA6IExFIFJPVVgg SmVhbi1Mb3VpcyBSRC1DT1JFLUxBTjs8QlI+Jmd0OyBjY2FtcEBvcHMuaWV0Zi5vcmc8QlI+Jmd0 OyAmZ3Q7T2JqZXQgOiBSZTogVFIgOiBJLUQ8QlI+Jmd0OyBBQ1RJT046ZHJhZnQtbGVyb3V4LWNj YW1wLWdtcGxzLW1ybi1ldmFsLTAwLnR4dDxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZn dDsgJmd0O0pMLDxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7SSBoYXZlIGEgY291cGxlIG9mIGNv bW1lbnRzL3N1Z2dlc3Rpb25zLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7MS5UaGUgZHJhZnQg c2F5cyB0aGF0IGN1cnJlbnRseSBHTVBMUyBkb2VzIG5vdDxCUj4mZ3Q7IGhhdmUgYTxCUj4mZ3Q7 ICZndDttZWNoYW5pc20gdG8gcHJvdmlzaW9uIHZpcnR1YWwgRkFzLiBJIGRvbid0IHRoaW5rPEJS PiZndDsgdGhpczxCUj4mZ3Q7ICZndDtpcyBjb3JyZWN0IC0gSSBiZWxpZXZlIHdlIGNvdWxkIHVz ZSB0aGUgc2FtZTxCUj4mZ3Q7IG1lY2hhbmlzbTxCUj4mZ3Q7ICZndDthcyB3YXMgc3VnZ2VzdGVk IGluPEJSPiZndDsgJmd0O2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtcmVjb3ZlcnktZTJlLXNpZ25h bGluZzxCUj4mZ3Q7IChzZWN0aW9uPEJSPiZndDsgJmd0OzkuMykgZm9yIHNpZ25hbGluZyBvZiBT ZWNvbmRhcnkgTFNQczxCUj4mZ3Q7PEJSPiZndDsgSSB3b3VsZG4ndCBiZSBzbyBleHBlZGl0aW91 cy4uLjxCUj4mZ3Q7IEFjdHVhbGx5IHdlIGNvdWxkIHVzZSBhIHNpbWlsYXIgbWVjaGFuaXNtIGJ1 dDxCUj4mZ3Q7IGRlZmluaXRlbHkgbm90IHRoZSBzYW1lLjxCUj4mZ3Q7IFNlY29uZGFyeSBMU1Ag YXJlIGRlZGljYXRlZCB0byBTaGFyZWQgTWVzaGVkPEJSPiZndDsgUmVzdG9yYXRpb24uPEJSPiZn dDsgSU1ITyB0aGlzIHdvdWxkIGJlIGJhZCB0byB1c2UgdGhlIFByb3RlY3Rpb24gb2JqZWN0PEJS PiZndDsgZm9yIHNvZnQtRkFzLiBTZW1hbnRpY3M8QlI+Jmd0OyBhcmUgcHJldHR5IGRpZmZlcmVu dC4uLjxCUj4mZ3Q7PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi PklCJmd0OyZndDtXZWxsLCBhcmUgdGhleT8gVGhleSBnaXZlIHlvdSBhIHdheSB0byBzaWduYWwg YTxCUj5yZXF1aXJlbWVudCBub3QgdG8gY29tbWl0IHJlc291cmNlcyBmb3IgYW4gTFNQIHVudGls PEJSPmZ1cnRoZXIgbm90aWNlIGFuZCBhbHNvIHRvIHJlcXVpcmUgdGhlaXIgY29tbWl0bWVudDxC Uj53aGVuIGl0IGJlY29tZXMgbmVjZXNzYXJ5LiBXaHkgbm90IHRvIGFsbG93IHdvcmtpbmc8QlI+ TFNQIHRvIGJlIHNpZ25hbGVkIGFzIFNlY29uZGFyeSBhY2NvcmRpbmcgdG8gdGhlPEJSPm1lbnRp b25lZCBkcmFmdD8gVGhlbiBpdCB3b3VsZCBiZSBwb3NzaWJsZSBldmVuIHRvPEJSPnNpZ25hbCBw cm90ZWN0ZWQgdmlydHVhbCBGQXMsIHdoaWNoIGlzIG5vdCBhcyBzdHVwaWQ8QlI+YXMgaXQgbWF5 IHNvdW5kIDo9KTxCUj48L0ZPTlQ+PEJSPkRQJmd0OyBiZWNhdXNlIGl0IHdvdWxkIHJlcXVpcmUg Y29uc2lkZXJpbmcgd29ya2luZyBzZWNvbmRhcmllcyAtIHRoaXMgY29tYmluYXRpb24gaXMgcHJl Y2x1ZGVkIGFzIGl0IGRvZXMgbm90IG1ha2UgYW55IHNlbnNlIChzZWUgdGhlIGRvY3VtZW50LCBh IGJpdCBhIHNpbmdsZSBzZW1hbnRpYykgd2hpbGUgdGhlIGNvbWJpbmF0aW9uIHByb3RlY3Rpbmcg c2Vjb25kYXJ5IGlzIGFscmVhZHkgZGV0ZXJtaW5lZCBhcyBzYWlkIGJ5IEpMICh0aGlzIGlzIHN0 cmljdGx5IHJlbGF0ZWQgdG8gYSBwcm90ZWN0aW9uIG9iamVjdCkgLSBhbnkgb3RoZXIgc2VtYW50 aWMgb3ZlcmxvYWQgd291bGQgYmUgY29uc2lkZXJlZCBoZXJlIGFzIGEgYmFkIHByb3RvY29sIGRl c2lnbiBwcmFjdGljZSAtIHRoZXJlZm9yZSBpdCBpcyBtdWNoIGFwcHJvcHJpYXRlIHRvIGNvbnNp ZGVyIGEgc3BlY2lmaWMgZm9yIGRpc3Rpbmd1aXNoaW5nIGJvdGggdmlydHVhbCBmcm9tIG5vbi12 aXJ0dWFsIEZBcyBhbmQgbWFrZSB1c2Ugb2YgdGhlIHByb3RlY3Rpb24gb2JqZWN0IGFzIGRlZmlu ZWQgaW4gdGhlIGVuZC10by1lbmQgcmVjb3ZlcnkgZG9jdW1lbnQgYXMgcmVxdWlyZWQgaS5lLiBw cm90ZWN0ZWQgb3Igbm90IHZpcnR1YWwgRkFzLCBwcm90ZWN0ZWQgb3Igbm90IEZBLUxTUHMsIGV0 Yy4gPC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj48QlI+Jmd0OyAmZ3Q7Mi5J IGFncmVlIHRoYXQgd2UgbmVlZCBURSBsaW5rIGFkYXB0YXRpb248QlI+Jmd0OyAmZ3Q7Y2FwYWJp bGl0aWVzIHRvIGJlIGFkdmVydGlzZWQgYWxvbmcgd2l0aCBvdGhlciBURTxCUj4mZ3Q7IGxpbms8 QlI+Jmd0OyAmZ3Q7YXR0cmlidXRlcyBzdWNoIGFzIHN3aXRjaGluZyBjYXBhYmlsaXRpZXMsPEJS PiZndDsgcHJvdGVjdGlvbjxCUj4mZ3Q7ICZndDtjYXBhYmlsaXRpZXMsIGV0Yy4gSSBzdWdnZXN0 IGFsc28gYWRkaW5nIFRFIGxpbms8QlI+Jmd0OyB0ZXJtaW5hdGlvbjxCUj4mZ3Q7ICZndDtjYXBh YmlsaXRpZXMgdG8gdGhpcyBsaXN0LCBpLmUuIGRlY291cGxpbmcgb2YgdGhlc2U8QlI+Jmd0OzxC Uj4mZ3Q7ICZndDtjYXBhYmlsaXRpZXMgZnJvbSBhZGFwdGF0aW9uIGNhcGFiaWxpdGllczo8QlI+ Jmd0OyAmZ3Q7dG8gdGVybWluYXRlIExTUCBpbiBhIHBhcnRpY3VsYXIgbGF5ZXIgYW5kIHRvIGFk b3B0PEJSPiZndDsgJmd0O2ludG8gaXQgTFNQcyBvZiBvbmUgb3IgbW9yZSBoaWdoZXIgbGF5ZXJz IGFyZTxCUj4mZ3Q7IHNlcGFyYXRlPEJSPiZndDsgJmd0O3Jlc291cmNlcyBhbmQgY291bGQgYmUg Y29uc2lkZXJlZCBzZXBhcmF0ZWx5IGluIHRoZTxCUj4mZ3Q7PEJSPiZndDsgJmd0O2ludGVyLWxh eWVyIHBhdGggY29tcHV0YXRpb25zOzxCUj4mZ3Q7PEJSPiZndDsgSSBhZ3JlZSB0aGF0IG91ciBj dXJlbnQgdGVybWlub2xvZ3kgbWF5IGJlIGNvbmZ1c2luZzxCUj4mZ3Q7IFdoYXQgd2UgY2FsbCBJ bnRlcm5hbCBBZGFwYXRhdGlvbiBDYXBhYmlsaXR5PEJSPiZndDsgYWN0dWFsbHkgcmVmZXJzIHRv IFRlcm1pbmF0aW9uIGNhcGFiaWxpdGllcy48QlI+Jmd0OyBTZWUgdGhlIE1STiByZXF1aXJlbWVu dCBkcmFmdCAodmVyc2lvbiAwMSkgZm9yIGFuPEJSPiZPc2xhc2g7ZXhhbXBsZS48QlI+PC9GT05U PjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SUImZ3Q7Jmd0OyBNeSBwb2ludCBp cyB0aGF0IHRlcm1pbmF0aW9uIGFuZCBhZGFwdGF0aW9uPEJSPmNhcGFiaWxpdGllcyBhcmUgc2Vw YXJhdGUgdGhpbmdzLiBGb3IgaW5zdGFuY2UsIHRoZTxCUj5mYWN0IHRoYXQgYSBsaW5rIGNhbiB0 ZXJtaW5hdGUgbGFtYmRhcyBtZWFucyB0aGUgaXQ8QlI+aGFzIGNlcnRhaW4gbnVtYmVyIG9mIGF2 YWlsYWJsZSB0cmFuc2NlaXZlcnMsIHdoaWxlPEJSPnRoZSBmYWN0IHdoZXRoZXIgdGhlc2UgbGFt YmRhcyBjYW4gY2FycnkgcGFydGljdWxhcjxCUj50cmlidXRhcnkgc2lnbmFscyBkZXBlbmRzLCBz YXksIG9uIHdoZXRoZXIgU0lNIGNhcmRzPEJSPm9mIGFwcHJvcHJpYXRlIHR5cGUgY291bGQgYmUg Y3Jvc3MtY29ubmVjdGVkIHRvIHRoZTxCUj50cmFuc2NlaXZlcnMuIEluIGZhY3QsIGxpbmsgdGVy bWluYXRpb24gYmFuZHdpZHRoIGlzPEJSPnNoYXJlZCBiZXR3ZWVuIG11bHRpcGxlIGFkYXB0YXRp b24gZnVuY3Rpb25zLiBUaGU8QlI+Ym90dG9tIGxpbmUgaXMgSSB0aGluayBpdCB3b3VsZCBiZSBn b29kIGlkZWEgdG88QlI+YWR2ZXJ0aXNlIHRoZW0gc2VwYXJhdGVseS48QlI+PC9GT05UPjxCUj48 Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgJmd0OzMu RXZlcnl0aGluZyB0aGF0IGlzIHNhaWQgYWJvdXQgcmVnaW9ucywgcmVnaW9uPEJSPiZndDsgJmd0 O2JvdW5kYXJpZXMsIGV0Yy4gaXMgYWxzbyBhcHBsaWNhYmxlIGZvciBsYXllcnM8QlI+Jmd0OyAm Z3Q7Y29udGFpbmVkIHdpdGhpbiByZWdpb25zLiBJIHN1Z2dlc3QgdG8gZG8gd2hhdCB3ZTxCUj4m Z3Q7IGhhdmU8QlI+Jmd0OyAmZ3Q7YWxyZWFkeSBkb25lIGluIHRoZSBQQ0UgV0cgZG9jdW1lbnRz IGFuZDxCUj4mZ3Q7ICZndDtwcmVzZW50YXRpb25zOiByZXBsYWNlIHdvcmQgcmVnaW9uIHdpdGgg d29yZCBsYXllcjxCUj4mZ3Q7ICZndDtldmVyeXdoZXJlIGFwYXJ0IGZyb20gd2hlcmUgc2lnbmFs aW5nIHNwZWNpZmljPEJSPiZndDsgYXNwZWN0czxCUj4mZ3Q7ICZndDthcmUgZGlzY3Vzc2VkLjxC Uj4mZ3Q7PEJSPiZndDsgU2VlIHNlY3Rpb24gMyBvZiB0aGUgcmVxdWlyZW1lbnQgZHJhZnQuPEJS PiZndDsgQWN0dWFsbHkgd2hhdCB3ZSBkZWZpbmUgZm9yIHJlZ2lvbiBhbHNvIGFwcGxpZXMgdG88 QlI+Jmd0OyBsYXllcnMsIGJ1dCB3ZSBwcmVmZXIgdG88QlI+Jk9zbGFzaDtrZWVwIHRoZSB0ZXJt IHJlZ2lvbiBoZXJlIGF0IHRoZSB0aW1lIGJlaW5nLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9 Ik1vbm9zcGFjZSxDb3VyaWVyIj5JQiZndDsmZ3Q7IEFuZCBteSBxdWVzdGlvbiBpcyB3aHkgdG8g ZG8gc28sIGlmIEZBcyBhbmQ8QlI+ZXZlcnl0aGluZyB0byBkbyB3aXRoIFZOVCBpcyBhYm91dCBs YXllcnMsIGluY2x1ZGluZzxCUj50aG9zZSB0aGF0IHN0YXJ0IGFuZCBzdG9wIGluIHRoZSBtaWRk bGUgb2YgdGhlIHJlZ2lvbiw8QlI+dGhhdCBpcywgZmFyIGF3YXkgZnJvbSByZWdpb24gYm91bmRh cmllcz8gRnVydGhlcm1vcmUsPEJSPndoZW4geW91IHNheSB0aGluZ3MgbGlrZSBjcmVhdGluZyBG QSBpbiB0aGUgbG93ZXI8QlI+cmVnaW9uIHRvIGNhcnJ5IExTUCBmb3IgdGhlIGhpZ2hlciByZWdp b24sIGl0IGlzIG5vdDxCUj5jbGVhciB3aGF0IGRvIHlvdSBtZWFuIGJ5IHRoYXQgaW4gdGhlIGNh c2Ugd2hlbiB0aGU8QlI+bG93ZXIgcmVnaW9uIGNvbnRhaW5zIG11bHRpcGxlIGxheWVycy48QlI+ PC9GT05UPjwvUD48UD4mbmJzcDs8L1A+PFA+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy aWVyIj5JZ29yPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPiZn dDs8QlI+Jmd0OyBBZ2FpbiwgdGhhbmtzIGEgbG90IGZvciB0aGVzZSBjb21tZW50cyw8QlI+Jmd0 OzxCUj4mZ3Q7IFJlZ2FyZHMsPEJSPiZndDs8QlI+Jmd0OyBKTDxCUj4mZ3Q7PEJSPiZndDsgJmd0 OzxCUj4mZ3Q7ICZndDtUaGFua3MsPEJSPiZndDsgJmd0O0lnb3I8QlI+Jmd0OyAmZ3Q7PEJSPiZn dDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7LS0tIExFIFJPVVggSmVhbi1Mb3VpcyBS RC1DT1JFLUxBTjxCUj4mZ3Q7ICZndDsmbHQ7amVhbmxvdWlzLmxlcm91eEBmcmFuY2V0ZWxlY29t LmNvbSZndDsgd3JvdGU6PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJS PiZndDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7Jmd0OyBIaSBhbGwsPEJSPiZndDsgJmd0OyZndDs8 QlI+Jmd0OyAmZ3Q7Jmd0OyBIZXJlIGlzIGEgbmV3IGRyYWZ0IGV2YWx1YXRpbmcgY3VycmVudCBH TVBMUzxCUj4mZ3Q7ICZndDsmZ3Q7IHByb3RvY29scyB3cnQgTVJOPEJSPiZndDsgJmd0OyZndDsg cmVxdWlyZW1lbnRzLjxCUj4mZ3Q7ICZndDsmZ3Q7IFlvdXIgY29tbWVudHMgb24gdGhpcyBuZXcg ZHJhZnQgd291bGQgYmUgaGlnaGx5PEJSPiZndDsgJmd0OyZndDsgYXBwcmVjaWF0ZWQuPEJSPiZn dDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7Jmd0OyBCZXN0IFJlZ2FyZHMsPEJSPiZndDsgJmd0OyZn dDs8QlI+Jmd0OyAmZ3Q7Jmd0OyBKTDxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0OyZndDsg VG86IGktZC1hbm5vdW5jZSBhdCBpZXRmLm9yZzxCUj4mZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IEkt RDxCUj4mZ3Q7ICZndDsmZ3Q7IEFDVElPTjpkcmFmdC1sZXJvdXgtY2NhbXAtZ21wbHMtbXJuLWV2 YWwtMDAudHh0PEJSPiZndDsgJmd0OyZndDsgRnJvbTogSW50ZXJuZXQtRHJhZnRzIGF0IGlldGYu b3JnPEJSPiZndDsgJmd0OyZndDsgRGF0ZTogVHVlLCAxNSBGZWIgMjAwNSAxMDoxNDozOCAtMDUw MDxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0OyZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlPEJSPiZndDsgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8QlI+ Jmd0OyAmZ3Q7Jmd0OyBkaXJlY3Rvcmllcy48QlI+Jmd0OyAmZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDsm Z3Q7PEJSPiZndDsgJmd0OyZndDsgVGl0bGU6IEV2YWx1YXRpb24gb2YgZXhpc3RpbmcgR01QTFMg UHJvdG9jb2xzPEJSPiZndDsgJmd0OyZndDsgYWdhaW5zdDxCUj4mZ3Q7ICZndDsmZ3Q7IE11bHRp IFJlZ2lvbiBOZXR3b3JrczxCUj4mZ3Q7ICZndDsmZ3Q7IEF1dGhvcihzKTogSi4gTGUgUm91eCwg ZXQgYWwuPEJSPiZndDsgJmd0OyZndDsgRmlsZW5hbWU6PEJSPiZndDsgZHJhZnQtbGVyb3V4LWNj YW1wLWdtcGxzLW1ybi1ldmFsLTAwLnR4dDxCUj4mZ3Q7ICZndDsmZ3Q7IFBhZ2VzOiAxMTxCUj4m Z3Q7ICZndDsmZ3Q7IERhdGU6IDIwMDUtMi0xNDxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0 OyZndDsgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhbiBldmFsdWF0aW9uIG9mPEJSPiZndDsgR2Vu ZXJhbGl6ZWQgTXVsdGktUHJvdG9jb2w8QlI+Jmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7TGFi ZWwgU3dpdGNoaW5nIChHTVBMUykgcHJvdG9jb2xzIGFuZDxCUj4mZ3Q7IG1lY2hhbmlzbXM8QlI+ Jmd0OyAmZ3Q7Jmd0OyBhZ2FpbnN0IHRoZTxCUj4mZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDty ZXF1aXJlbWVudHMgZm9yIE11bHRpIFJlZ2lvbiBOZXR3b3JrcyAoTVJOKS48QlI+Jmd0OzxCUj4m Z3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtJbiBhZGRpdGlvbiwgdGhpcyBkb2N1bWVudCBpZGVu dGlmaWVzIGFyZWFzPEJSPiZndDsgd2hlcmU8QlI+Jmd0OyAmZ3Q7Jmd0OyBhZGRpdGlvbmFsPEJS PiZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwO3Byb3RvY29sIGV4dGVuc2lvbnMgb3IgcHJvY2Vk dXJlcyBhcmUgbmVlZGVkPEJSPiZndDsgdG88QlI+Jmd0OyAmZ3Q7Jmd0OyBzYXRpc2Z5IHRoZTxC Uj4mZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtyZXF1aXJlbWVudHMgb2YgTXVsdGkgUmVnaW9u IE5ldHdvcmtzLCBhbmQ8QlI+Jmd0OyAmZ3Q7Jmd0OyBwcm92aWRlcyBndWlkZWxpbmVzIGZvcjxC Uj4mZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtwb3RlbnRpYWwgZXh0ZW5zaW9ucy48QlI+Jmd0 OyAmZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDsmZ3Q7IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0 IGlzOjxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDs8QlI+Jmd0O2h0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxlcm91eC1jY2FtcC1nbXBscy1tcjxCUj4mZ3Q7IG4tZXZh bC0wMDxCUj4mZ3Q7ICZndDsgLnR4dDxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsg Jmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJS PiZndDs8QlI+Jmd0OzxCUj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 QlI+Jmd0OyBDZWxlYnJhdGUgWWFob28hJ3MgMTB0aCBCaXJ0aGRheSE8QlI+Jmd0OyBZYWhvbyEg TmV0cm9zcGVjdGl2ZTogMTAwIE1vbWVudHMgb2YgdGhlIFdlYjxCUj4mZ3Q7IDxBIEhSRUY9aHR0 cDovL2JpcnRoZGF5LnlhaG9vLmNvbS9uZXRyb3NwZWN0aXZlLz5odHRwOi8vYmlydGhkYXkueWFo b28uY29tL25ldHJvc3BlY3RpdmUvPC9BPjxCUj4mZ3Q7PEJSPjwvRk9OVD48QlI+PEJSPjxCUj48 QlI+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPEJSPkNlbGVicmF0ZSBZYWhvbyEncyAxMHRoIEJpcnRoZGF5ITxCUj5Z YWhvbyEgTmV0cm9zcGVjdGl2ZTogMTAwIE1vbWVudHMgb2YgdGhlIFdlYjxCUj48QSBIUkVGPWh0 dHA6Ly9iaXJ0aGRheS55YWhvby5jb20vbmV0cm9zcGVjdGl2ZS8+aHR0cDovL2JpcnRoZGF5Lnlh aG9vLmNvbS9uZXRyb3NwZWN0aXZlLzwvQT48L0ZPTlQ+PC9QPg== From owner-ccamp@ops.ietf.org Fri Mar 4 11:09:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01992 for ; Fri, 4 Mar 2005 11:09:41 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7FOa-0006Ez-Oz for ccamp-archive@ietf.org; Fri, 04 Mar 2005 11:11:23 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7FGO-000L53-Ho for ccamp-data@psg.com; Fri, 04 Mar 2005 16:02:52 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7FGI-000KUx-8K for ccamp@ops.ietf.org; Fri, 04 Mar 2005 16:02:46 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id CD629E0001BB; Fri, 4 Mar 2005 16:02:34 +0000 (GMT) Received: from Puppy ([212.43.203.25] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Mar 2005 16:02:07 +0000 Message-ID: <007501c520d3$b9d8f940$19cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Zafar Ali" , "'Richard Rabbat'" , References: <200503012008.j21K8S1j006643@rtp-core-1.cisco.com> Subject: Re: Draft status updated on alternate CCAMP web page Date: Fri, 4 Mar 2005 15:40:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 04 Mar 2005 16:02:08.0485 (UTC) FILETIME=[849AC150:01C520D3] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Hi, When something is left entirely undone, no-one objects. When something is half done, everyone demands perfection. Contrary to popular opinion, I am only human. I hope to complete this task before Minneapolis. Adrian ----- Original Message ----- From: "Zafar Ali" To: "'Richard Rabbat'" ; "'Adrian Farrel'" ; Sent: Tuesday, March 01, 2005 8:08 PM Subject: RE: Draft status updated on alternate CCAMP web page > Hi Richard, > > Re: the ID (draft-shiomoto-ccamp-gmpls-addressing-00), I did find it quite > useful and IMO we should pursue this further in CCAMP. > > Having said that, I would like to point that there are a number of ID-es > that are currently NOT in Adrian's list and I think this has to do with his > comment in the original email (quoting Adrian): "I have yet to update the > section that covers personal drafts related to CCAMP." Adrian, please > correct me/ add/ del. > > Thanks > > Regards... Zafar > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Richard Rabbat > > Sent: Thursday, February 24, 2005 1:52 PM > > To: 'Adrian Farrel'; ccamp@ops.ietf.org > > Subject: RE: Draft status updated on alternate CCAMP web page > > > > Adrian, > > Can you add > > http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls > > -addressing-00 > > .txt > > to your draft tracker? > > > > We sent out email about it and have received feedback > > off-list. We're planning on discussing this draft in > > Minneapolis and would love to have more on-list discussions. > > As you can see from the list of contributors, there is > > enormous interest in this draft and we hope it serves as a > > basis for thoughtful discussions. > > Best, > > Richard, Rajiv and Kohei. > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > > Sent: Monday, February 21, 2005 10:35 AM > > > To: Adrian Farrel; ccamp@ops.ietf.org > > > Subject: Re: Draft status updated on alternate CCAMP web page > > > > > > > > > So, I can't type. > > > Want to make something of it? > > > http://www.olddog.co.uk/ccamp-drafts.htm > > > > > > (Thanks Jean-Louis) > > > > > > Adrian > > > > > > ----- Original Message ----- > > > From: "Adrian Farrel" > > > To: > > > Sent: Monday, February 21, 2005 12:32 PM > > > Subject: Draft status updated on alternate CCAMP web page > > > > > > > > > > I have updated http://www.oldog.co.uk/ccamp-drafts.htm to > > > indicate the > > > > current status of all CCAMP drafts. I have yet to update > > the section > > > that > > > > covers personal drafts related to CCAMP. > > > > > > > > Adrian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Fri Mar 4 11:50:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04936 for ; Fri, 4 Mar 2005 11:50:36 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7G2A-00074U-9H for ccamp-archive@ietf.org; Fri, 04 Mar 2005 11:52:19 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7FtJ-0006y1-9b for ccamp-data@psg.com; Fri, 04 Mar 2005 16:43:05 +0000 Received: from [67.102.145.11] (helo=dcserver.movaz.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7Fsr-0006qb-W1 for ccamp@ops.ietf.org; Fri, 04 Mar 2005 16:42:40 +0000 Received: from ib (unknown [172.16.24.122]) by dcserver.movaz.com (Postfix on SuSE Linux 7.3 (i386)) with SMTP id E4509972; Fri, 4 Mar 2005 11:42:31 -0500 (EST) Message-ID: <00a201c520d9$290913e0$7a1810ac@movaz.com> Reply-To: "Igor Bryskin" From: "Igor Bryskin" To: , "Kireeti Kompella" Cc: Subject: A philosophical question about FA and FA-LSP Date: Fri, 4 Mar 2005 11:42:31 -0500 Organization: Movaz Networks MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009F_01C520AF.4003BE80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 This is a multi-part message in MIME format. ------=_NextPart_000_009F_01C520AF.4003BE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 I have a question to Kireti and Yakov. =20 This is from draft-ietf-ccamp-gmpls-routing-09.txt:=20 =20 Traditionally, a TE link is advertised as an adjunct to a "regular" = link, i.e., a routing adjacency is brought up on the link, and when = the link is up, both the properties of the link used for Shortest Path = First (SPF) computations (basically, the SPF metric) and the TE = properties of the link are then advertised. GMPLS challenges this = notion in three ways. First, links that are not capable of sending = and receiving on a packet-by-packet basis may yet have TE properties; = however, a routing adjacency cannot be brought up on such links. = Second, a Label Switched Path can be advertised as a point-to-point TE = link (see [LSP-HIER]); thus, an advertised TE link may be between a = pair of nodes that don't have a routing adjacency with each other. = Finally, a number of links may be advertised as a single TE link = (perhaps for improved scalability), so again, there is no longer a = one-to-one association of a regular routing adjacency and a TE link. = Thus we have a more general notion of a TE link. A TE link is a = "logical" link that has TE properties. . My question is: can I draw a = conclusion from the above that it is not required anymore for an FA to = be advertised into the same instance of IGP-TE as was used for the = advertising of the FA-LSP constituent TE links. In other words, if an = LSP created by one instance of the control plane (say, L1VPN Provider) = and advertised as a TE link into another instance of the control plane = (say, VPN), would/should such TE link be treated anyhow different from = the LSP advertised into the same instance of control plane. Thanks,Igor=20 =20 =20 ------=_NextPart_000_009F_01C520AF.4003BE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

I have a question to = Kireti and=20 Yakov.

 

This is from =
draft-ietf-ccamp-gmpls-routing-09.txt:

 

 

Traditionally, a TE link is advertised as an adjunct to a =
"regular"
   link, i.e., a routing =
adjacency is brought up on the link, and =
when
   the link is up, both the =
properties of the link used for =
Shortest
   Path First (SPF) =
computations (basically, the SPF metric) and the =
TE
   properties of the link =
are then advertised.
 
   GMPLS challenges this notion in three =
ways.  First, links that =
are
   not capable of sending =
and receiving on a packet-by-packet basis =
may
   yet have TE properties; =
however, a routing adjacency cannot =
be
   brought up on such =
links.  Second, a Label =
Switched Path can be
   advertised as a point-to-point TE link (see =
[LSP-HIER]); thus, an
   advertised TE link may be between a pair of =
nodes that don't have a
   routing adjacency with each other.  Finally, a number of links may =
be
   advertised as a single =
TE link (perhaps for improved scalability), =
so
   again, there is no =
longer a one-to-one association of a =
regular
   routing adjacency and a =
TE link.
 
   Thus we have a more general notion of a TE =
link.  A TE link is =
a
   "logical" link that has =
TE properties. =85
 
My =
question is:  can I draw a conclusion from the above that it is not =
required anymore for an FA to be advertised into the same instance of =
IGP-TE as was used for the advertising of the FA-LSP constituent TE =
links.
 In other words, if an =
LSP created by one instance of the control plane (say, L1VPN Provider) =
and advertised as a TE link into another instance of the control plane =
(say, VPN), would/should such TE link be treated 
anyhow different from the LSP advertised =
into the same instance of control =
plane.
 
Thanks,
Igor

 

 

 

------=_NextPart_000_009F_01C520AF.4003BE80-- From owner-ccamp@ops.ietf.org Fri Mar 4 12:59:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14593 for ; Fri, 4 Mar 2005 12:59:31 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7H6t-0001IT-VQ for ccamp-archive@ietf.org; Fri, 04 Mar 2005 13:01:15 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7Gzy-000KhU-BU for ccamp-data@psg.com; Fri, 04 Mar 2005 17:54:02 +0000 Received: from [66.129.224.36] (helo=kummer.juniper.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7Gzx-000KhF-Gc for ccamp@ops.ietf.org; Fri, 04 Mar 2005 17:54:01 +0000 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j24HrTXg072052; Fri, 4 Mar 2005 09:53:29 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j24HrTIV072049; Fri, 4 Mar 2005 09:53:29 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 4 Mar 2005 09:53:29 -0800 (PST) From: Kireeti Kompella To: Igor Bryskin cc: yakov@juniper.net, ccamp@ops.ietf.org Subject: Re: A philosophical question about FA and FA-LSP In-Reply-To: <00a201c520d9$290913e0$7a1810ac@movaz.com> Message-ID: <20050304094707.A72012@kummer.juniper.net> References: <00a201c520d9$290913e0$7a1810ac@movaz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Fri, 4 Mar 2005, Igor Bryskin wrote: > I have a question to Kireti and Yakov. ... > My question is: can I draw a conclusion from the above that it is > not required anymore for an FA to be advertised into the same > instance of IGP-TE as was used for the advertising of the FA-LSP > constituent TE links. Correct -- LSPs created in IGP A can be advertised as TE links in IGP B. This can be used (say) for inter-area signaling. > In other words, if an LSP created by one instance of the control > plane (say, L1VPN Provider) and advertised as a TE link into another > instance of the control plane (say, VPN), would/should such TE link > be treated anyhow different from the LSP advertised into the same > instance of control plane. The advertisement into the VPN control plane is just a TE link for the VPN IGP-TE. Kireeti. ------- From owner-ccamp@ops.ietf.org Fri Mar 4 13:13:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16444 for ; Fri, 4 Mar 2005 13:13:12 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7HKA-0001sG-5l for ccamp-archive@ietf.org; Fri, 04 Mar 2005 13:14:55 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7HCr-000NgM-NV for ccamp-data@psg.com; Fri, 04 Mar 2005 18:07:21 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7HCp-000Ng4-Kc for ccamp@ops.ietf.org; Fri, 04 Mar 2005 18:07:19 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 129D865D2; Fri, 4 Mar 2005 13:07:19 -0500 (EST) Message-ID: <00ad01c520e5$013fdf90$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Kireeti Kompella" Cc: , References: <00a201c520d9$290913e0$7a1810ac@movaz.com> <20050304094707.A72012@kummer.juniper.net> Subject: Re: A philosophical question about FA and FA-LSP Date: Fri, 4 Mar 2005 13:07:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Hi, My question was what is (if any) special about FA TE link apart from the fact that it is dynamically created/destroyed? Igor ----- Original Message ----- From: "Kireeti Kompella" To: "Igor Bryskin" Cc: ; Sent: Friday, March 04, 2005 12:53 PM Subject: Re: A philosophical question about FA and FA-LSP > On Fri, 4 Mar 2005, Igor Bryskin wrote: > > > I have a question to Kireti and Yakov. > ... > > My question is: can I draw a conclusion from the above that it is > > not required anymore for an FA to be advertised into the same > > instance of IGP-TE as was used for the advertising of the FA-LSP > > constituent TE links. > > Correct -- LSPs created in IGP A can be advertised as TE links in IGP B. > This can be used (say) for inter-area signaling. > > > In other words, if an LSP created by one instance of the control > > plane (say, L1VPN Provider) and advertised as a TE link into another > > instance of the control plane (say, VPN), would/should such TE link > > be treated anyhow different from the LSP advertised into the same > > instance of control plane. > > The advertisement into the VPN control plane is just a TE link for the > VPN IGP-TE. > > Kireeti. > ------- > From owner-ccamp@ops.ietf.org Fri Mar 4 13:45:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19728 for ; Fri, 4 Mar 2005 13:45:27 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7HpN-0002iz-Ui for ccamp-archive@ietf.org; Fri, 04 Mar 2005 13:47:11 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7HjE-0003AF-9r for ccamp-data@psg.com; Fri, 04 Mar 2005 18:40:48 +0000 Received: from [66.129.224.36] (helo=kummer.juniper.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7HjD-00039i-EO for ccamp@ops.ietf.org; Fri, 04 Mar 2005 18:40:47 +0000 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j24IejXg072300; Fri, 4 Mar 2005 10:40:45 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j24IejoU072297; Fri, 4 Mar 2005 10:40:45 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 4 Mar 2005 10:40:45 -0800 (PST) From: Kireeti Kompella To: Igor Bryskin cc: yakov@juniper.net, ccamp@ops.ietf.org Subject: Re: A philosophical question about FA and FA-LSP In-Reply-To: <00ad01c520e5$013fdf90$7a1810ac@movaz.com> Message-ID: <20050304100910.R72177@kummer.juniper.net> References: <00a201c520d9$290913e0$7a1810ac@movaz.com> <20050304094707.A72012@kummer.juniper.net> <00ad01c520e5$013fdf90$7a1810ac@movaz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Fri, 4 Mar 2005, Igor Bryskin wrote: > My question was what is (if any) special about FA TE link apart from > the fact that it is dynamically created/destroyed? Actually, an FA TE link doesn't have to be dynamically created/destroyed. What's special? Nothing really. A "normal" TE link usually has a (single) physical interface associated with it; an FA TE link is usually multi-hop. A "normal" TE link usually is accompanied by an IGP adjacency (at least, in the packet domain); an FA TE link usually doesn't. But from the point of view of the IGP, or an LSR in that IGP, they can't tell an FA TE link from any other TE link. Kireeti. ------- From owner-ccamp@ops.ietf.org Fri Mar 4 14:03:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20949 for ; Fri, 4 Mar 2005 14:03:34 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7I6t-000379-QV for ccamp-archive@ietf.org; Fri, 04 Mar 2005 14:05:16 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7Hzy-0007s0-6o for ccamp-data@psg.com; Fri, 04 Mar 2005 18:58:06 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7Hzu-0007jk-1Z for ccamp@ops.ietf.org; Fri, 04 Mar 2005 18:58:02 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Mar 2005 19:56:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Date: Fri, 4 Mar 2005 19:56:22 +0100 Message-ID: Thread-Topic: RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Thread-Index: AcUgvc80KlMsDPzJSDi5II1t1/lYvgAKySNw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" , X-OriginalArrivalTime: 04 Mar 2005 18:56:07.0784 (UTC) FILETIME=[D2E95E80:01C520EB] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Content-Transfer-Encoding: quoted-printable Igor, Please see inline Regards, JL >-----Message d'origine----- >De : Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 >Envoy=E9 : vendredi 4 mars 2005 14:26 >=C0 : LE ROUX Jean-Louis RD-CORE-LAN; ccamp@ops.ietf.org >Objet : Re: RE : TR : I-D=20 >ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt=20 > > >JL, > >Please, see my comments in-line > >Igor > >--- LE ROUX Jean-Louis RD-CORE-LAN=20 > wrote: > >> Hi Igor, >>=20 >> Thanks for these comments >>=20 >> Please see inline >>=20 >>=20 >> >-----Message d'origine----- >> >De : Igor Bryskin [mailto:i_bryskin@yahoo.com] >> >Envoy=E9 : jeudi 3 mars 2005 20:45 >> >=C0 : LE ROUX Jean-Louis RD-CORE-LAN; >> ccamp@ops.ietf.org >> >Objet : Re: TR : I-D >> ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt >> > >> > >> >JL, >> > >> >I have a couple of comments/suggestions. >> > >> >1. The draft says that currently GMPLS does not >> have a >> >mechanism to provision virtual FAs. I don't think >> this >> >is correct - I believe we could use the same >> mechanism >> >as was suggested in >> >draft-ietf-ccamp-gmpls-recovery-e2e-signaling >> (section >> >9.3) for signaling of Secondary LSPs >>=20 >> I wouldn't be so expeditious... >> Actually we could use a similar mechanism but >> definitely not the same. >> Secondary LSP are dedicated to Shared Meshed >> Restoration. >> IMHO this would be bad to use the Protection object >> for soft-FAs. Semantics >> are pretty different... >>=20 > >IB>>Well, are they? They give you a way to signal a >requirement not to commit resources for an LSP until >further notice and also to require their commitment >when it becomes necessary. Why not to allow working >LSP to be signaled as Secondary according to the >mentioned draft? Then it would be possible even to >signal protected virtual FAs, which is not as stupid >as it may sound :=3D) Sorry but this sounds really bad... Please let me know then how do you signal protected virtual FAs? > >>=20 >> >2. I agree that we need TE link adaptation >> >capabilities to be advertised along with other TE >> link >> >attributes such as switching capabilities, >> protection >> >capabilities, etc. I suggest also adding TE link >> termination >> >capabilities to this list, i.e. decoupling of these >>=20 >> >capabilities from adaptation capabilities: >> >to terminate LSP in a particular layer and to adopt >> >into it LSPs of one or more higher layers are >> separate >> >resources and could be considered separately in the >>=20 >> >inter-layer path computations; >>=20 >> I agree that our curent terminology may be confusing >> What we call Internal Adapatation Capability >> actually refers to Termination capabilities. >> See the MRN requirement draft (version 01) for an >=D8 example. > >IB>> My point is that termination and adaptation >capabilities are separate things. For instance, the >fact that a link can terminate lambdas means the it >has certain number of available transceivers, while >the fact whether these lambdas can carry particular >tributary signals depends, say, on whether SIM cards >of appropriate type could be cross-connected to the=20 >transceivers. In fact, link termination bandwidth is shared=20 >between multiple adaptation functions. The bottom line is I=20 >think it would be good idea to advertise them separately. > IMHO all what is missing in GMPLS-RTG is the advertisement of the = internal termination capabilities (a.k.a internal adaptation capability = in our draft...).=20 This is useful only when doing inter-region path computation.=20 IMHO we just need to find an appropriate terminology. >>=20 >>=20 >> >3. Everything that is said about regions, region >> >boundaries, etc. is also applicable for layers >> >contained within regions. I suggest to do what we >> have >> >already done in the PCE WG documents and >> >presentations: replace word region with word layer everywhere apart=20 >> >from where signaling specific >> aspects >> >are discussed. >>=20 >> See section 3 of the requirement draft. >> Actually what we define for region also applies to >> layers, but we prefer to >=D8 keep the term region here at the time being. > >IB>> And my question is why to do so, if FAs and >everything to do with VNT is about layers, including >those that start and stop in the middle of the region, >that is, far away from region boundaries? Furthermore, >when you say things like creating FA in the lower >region to carry LSP for the higher region, it is not >clear what do you mean by that in the case when the >lower region contains multiple layers. You are right this applies also to multi-layers. We will clarify in next revision, but note that this is already = clarified in the=20 MRN req draft (see section 3). Thanks again, JL > >Igor > >>=20 >> Again, thanks a lot for these comments, >>=20 >> Regards, >>=20 >> JL >>=20 >> > >> >Thanks, >> >Igor >> > =20 >> > >> > >> >--- LE ROUX Jean-Louis RD-CORE-LAN >> > wrote: >> > >> > >> > >> >>=20 >> >> Hi all, >> >>=20 >> >> Here is a new draft evaluating current GMPLS >> >> protocols wrt MRN >> >> requirements. >> >> Your comments on this new draft would be highly appreciated. >> >>=20 >> >> Best Regards, >> >>=20 >> >> JL >> >>=20 >> >> To: i-d-announce at ietf.org >> >> Subject: I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt >> >> From: Internet-Drafts at ietf.org=20 >> >> Date: Tue, 15 Feb 2005 10:14:38 -0500=20 >> >>=20 >> >> A New Internet-Draft is available from the >> on-line Internet-Drafts >> >> directories. >> >>=20 >> >>=20 >> >> Title : Evaluation of existing GMPLS Protocols >> >> against >> >> Multi Region Networks >> >> Author(s) : J. Le Roux, et al. >> >> Filename : >> draft-leroux-ccamp-gmpls-mrn-eval-00.txt >> >> Pages : 11 >> >> Date : 2005-2-14 >> >> =09 >> >> This document provides an evaluation of >> Generalized Multi-Protocol >> >> Label Switching (GMPLS) protocols and >> mechanisms >> >> against the=20 >> >> requirements for Multi Region Networks (MRN). >> =20 >> >> In addition, this document identifies areas >> where >> >> additional=20 >> >> protocol extensions or procedures are needed >> to >> >> satisfy the=20 >> >> requirements of Multi Region Networks, and >> >> provides guidelines for=20 >> >> potential extensions. >> >>=20 >> >> A URL for this Internet-Draft is: >> >> >> >>http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mr >> n-eval-00 >> > .txt >> >=20 >> >=20 >> >=20 >> >=20 >> > >>=20 >>=20 >>=20 >> =09 >> =09 >> __________________________________ >> Celebrate Yahoo!'s 10th Birthday!=20 >> Yahoo! Netrospective: 100 Moments of the Web=20 >> http://birthday.yahoo.com/netrospective/ >> > > > >=09 > =09 >__________________________________=20 >Celebrate Yahoo!'s 10th Birthday!=20 >Yahoo! Netrospective: 100 Moments of the Web=20 >http://birthday.yahoo.com/netrospective/ > From owner-ccamp@ops.ietf.org Fri Mar 4 14:26:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23114 for ; Fri, 4 Mar 2005 14:26:49 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7ITO-0003eO-Qc for ccamp-archive@ietf.org; Fri, 04 Mar 2005 14:28:32 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7INp-000Cs9-Ou for ccamp-data@psg.com; Fri, 04 Mar 2005 19:22:45 +0000 Received: from [66.129.224.36] (helo=kummer.juniper.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7INo-000Crw-Sn for ccamp@ops.ietf.org; Fri, 04 Mar 2005 19:22:45 +0000 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j24JMhXg072600; Fri, 4 Mar 2005 11:22:43 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j24JMh7j072597; Fri, 4 Mar 2005 11:22:43 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 4 Mar 2005 11:22:43 -0800 (PST) From: Kireeti Kompella To: Igor Bryskin cc: yakov@juniper.net, ccamp@ops.ietf.org Subject: Re: A philosophical question about FA and FA-LSP In-Reply-To: <20050304100910.R72177@kummer.juniper.net> Message-ID: <20050304112107.F72451@kummer.juniper.net> References: <00a201c520d9$290913e0$7a1810ac@movaz.com> <20050304094707.A72012@kummer.juniper.net> <00ad01c520e5$013fdf90$7a1810ac@movaz.com> <20050304100910.R72177@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 On Fri, 4 Mar 2005, Kireeti Kompella wrote: > But from the point of view of the IGP, or an LSR in that IGP, they > can't tell an FA TE link from any other TE link. Correction: it has been pointed out that the above statement about LSRs applies to all LSRs except those at the two ends of the FA LSP. Kireeti. ------- From owner-ccamp@ops.ietf.org Fri Mar 4 15:34:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01107 for ; Fri, 4 Mar 2005 15:34:13 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7JWe-0005Hq-P4 for ccamp-archive@ietf.org; Fri, 04 Mar 2005 15:35:57 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7JP4-000Pms-KI for ccamp-data@psg.com; Fri, 04 Mar 2005 20:28:06 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7JP0-000Pk7-8I for ccamp@ops.ietf.org; Fri, 04 Mar 2005 20:28:02 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 39C70E0000E1; Fri, 4 Mar 2005 20:27:54 +0000 (GMT) Received: from Puppy ([212.43.203.127] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Mar 2005 20:15:41 +0000 Message-ID: <058e01c520f7$26698e30$19cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Richard Rabbat" , Cc: , , "'Sadler, Jonathan B.'" , "'Ong, Lyndon'" , "'Richard Rabbat'" , , "'Greg Bernstein'" References: Subject: Re: question about RFC 3946 Date: Fri, 4 Mar 2005 19:26:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 04 Mar 2005 20:15:42.0332 (UTC) FILETIME=[F0C393C0:01C520F6] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Hi, Whatever technical answer we end up with, can we stick with the phrases "strictly greater" and "greater or equal" as appropriate, and avoid the (apparently) ambiguous "greater". Thanks, Adrian ----- Original Message ----- From: To: "Richard Rabbat" Cc: ; ; "'Sadler, Jonathan B.'" ; "'Ong, Lyndon'" ; "'Adrian Farrel'" ; "'Richard Rabbat'" ; ; "'Greg Bernstein'" Sent: Tuesday, March 01, 2005 6:57 PM Subject: Re: question about RFC 3946 > > richard: > > "greater" does not mean "strictly greater" it means "greater or equal" > > So, what values of NCC and RCC should one use for STS-3c/VC-4? > > for STS-3c: > An STS-3c SPE signal is formed by the application of RCC with > value 1 (standard contiguous concatenation), NCC with value 1, > NVC with value 0, MT with value 1 and T with value 0 to an STS- > 3c SPE Elementary Signal. > > for VC-4: > A VC-4 signal is formed by the application of RCC with value 0, > NCC with value 0, NVC with value 0, MT with value 1 and T with > value 0 to a VC-4 Elementary Signal. > > do not know if this clarifies - > > hint: Note 2 refers to transparent STS-N/STM-N signals (signal type 7->12) > > > > > > > From owner-ccamp@ops.ietf.org Fri Mar 4 16:30:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05708 for ; Fri, 4 Mar 2005 16:30:30 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7KP8-0006Zk-HQ for ccamp-archive@ietf.org; Fri, 04 Mar 2005 16:32:15 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7KIs-000A6f-AV for ccamp-data@psg.com; Fri, 04 Mar 2005 21:25:46 +0000 Received: from [68.142.200.150] (helo=web30807.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D7KIr-000A6T-AY for ccamp@ops.ietf.org; Fri, 04 Mar 2005 21:25:45 +0000 Received: (qmail 3561 invoked by uid 60001); 4 Mar 2005 21:25:44 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=v5G7BiV3M0/ttfSBJZRNwKMjgDqMF4T9KKWTYkcSQ+9e7T8MfRvm1q7pqCFTjiURMCoM23Z+Cd8wrYzcNw8spuR7uJ6Mu2KdDk3EdXerHbyFIamkGl4wQlH6sLUWHmz0w/3m55lhXQYrbf9bO22VbLg819qR1/kxaNNZfGlbDZo= ; Message-ID: <20050304212544.3559.qmail@web30807.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30807.mail.mud.yahoo.com via HTTP; Fri, 04 Mar 2005 13:25:44 PST Date: Fri, 4 Mar 2005 13:25:44 -0800 (PST) From: Igor Bryskin Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt To: LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1320231352-1109971544=:2579" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00, FORGED_YAHOO_RCVD,HTML_50_60,HTML_MESSAGE autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.3 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 --0-1320231352-1109971544=:2579 Content-Type: text/plain; charset=us-ascii >> >> I wouldn't be so expeditious... >> Actually we could use a similar mechanism but >> definitely not the same. >> Secondary LSP are dedicated to Shared Meshed >> Restoration. >> IMHO this would be bad to use the Protection object >> for soft-FAs. Semantics >> are pretty different... >> > >IB>>Well, are they? They give you a way to signal a >requirement not to commit resources for an LSP until >further notice and also to require their commitment >when it becomes necessary. Why not to allow working >LSP to be signaled as Secondary according to the >mentioned draft? Then it would be possible even to >signal protected virtual FAs, which is not as stupid >as it may sound :=) Sorry but this sounds really bad... Please let me know then how do you signal protected virtual FAs? IB>> You signal both working and protection LSPs of the FA as Secondary. At the time when you decide to make FA “real” you re-signal working or both LSPs (depending on protection type) as Primary. Don’t see why this wouldn’t work. Igor --------------------------------- Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web --0-1320231352-1109971544=:2579 Content-Type: text/html; charset=us-ascii

>>
>> I wouldn't be so expeditious...
>> Actually we could use a similar mechanism but
>> definitely not the same.
>> Secondary LSP are dedicated to Shared Meshed
>> Restoration.
>> IMHO this would be bad to use the Protection object
>> for soft-FAs. Semantics
>> are pretty different...
>>
>
>IB>>Well, are they? They give you a way to signal a
>requirement not to commit resources for an LSP until
>further notice and also to require their commitment
>when it becomes necessary. Why not to allow working
>LSP to be signaled as Secondary according to the
>mentioned draft? Then it would be possible even to
>signal protected virtual FAs, which is not as stupid
>as it may sound :=)

Sorry but this sounds really bad...
Please let me know then how do you signal protected virtual FAs?

IB>> You signal both working and protection LSPs of the FA as Secondary. At the time when you decide to make FA “real” you re-signal working or both LSPs (depending on protection type) as Primary. Don’t see why this wouldn’t work.

Igor

Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web --0-1320231352-1109971544=:2579-- From owner-ccamp@ops.ietf.org Fri Mar 4 17:29:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11787 for ; Fri, 4 Mar 2005 17:29:56 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7LKf-00081y-VT for ccamp-archive@ietf.org; Fri, 04 Mar 2005 17:31:42 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7L8l-000KW5-MV for ccamp-data@psg.com; Fri, 04 Mar 2005 22:19:23 +0000 Received: from [68.142.200.149] (helo=web30806.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D7L8j-000KVr-Lm for ccamp@ops.ietf.org; Fri, 04 Mar 2005 22:19:21 +0000 Received: (qmail 69510 invoked by uid 60001); 4 Mar 2005 22:19:20 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=DtxrKT8R6VQU9aRPkJ0XphvKDtZZDdct/0+9EdNXHYtQoZ8b3zIs4KdZ83ZmqZtmOVITo/+gCPtVyfj0RfSN8dNFzPjZ/GN/bmdf06yum5KO1YuodHxGXCmVVdMphWtO5aH2seBEHEilwUJa39j7AhvSHRgtwkEbKb3j4GScNaE= ; Message-ID: <20050304221920.69508.qmail@web30806.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30806.mail.mud.yahoo.com via HTTP; Fri, 04 Mar 2005 14:19:20 PST Date: Fri, 4 Mar 2005 14:19:20 -0800 (PST) From: Igor Bryskin Subject: Re: A philosophical question about FA and FA-LSP To: Kireeti Kompella , Igor Bryskin Cc: yakov@juniper.net, ccamp@ops.ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-154085893-1109974760=:69340" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00, FORGED_YAHOO_RCVD,HTML_30_40,HTML_MESSAGE autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.0 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 --0-154085893-1109974760=:69340 Content-Type: text/plain; charset=us-ascii Thanks, Kireeti Kireeti Kompella wrote: On Fri, 4 Mar 2005, Kireeti Kompella wrote: > But from the point of view of the IGP, or an LSR in that IGP, they > can't tell an FA TE link from any other TE link. Correction: it has been pointed out that the above statement about LSRs applies to all LSRs except those at the two ends of the FA LSP. Kireeti. ------- --------------------------------- Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web --0-154085893-1109974760=:69340 Content-Type: text/html; charset=us-ascii
Thanks, Kireeti
 

Kireeti Kompella <kireeti@juniper.net> wrote:
On Fri, 4 Mar 2005, Kireeti Kompella wrote:

> But from the point of view of the IGP, or an LSR in that IGP, they
> can't tell an FA TE link from any other TE link.

Correction: it has been pointed out that the above statement about
LSRs applies to all LSRs except those at the two ends of the FA LSP.

Kireeti.
-------

Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web --0-154085893-1109974760=:69340-- From owner-ccamp@ops.ietf.org Fri Mar 4 17:55:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13571 for ; Fri, 4 Mar 2005 17:55:55 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Ljo-00005A-NI for ccamp-archive@ietf.org; Fri, 04 Mar 2005 17:57:41 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7Ldb-0000DI-EO for ccamp-data@psg.com; Fri, 04 Mar 2005 22:51:15 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7LdS-0000Bw-83 for ccamp@ops.ietf.org; Fri, 04 Mar 2005 22:51:06 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j24Mp49B006485; Fri, 4 Mar 2005 23:51:04 +0100 To: Igor Bryskin Cc: LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org From: Dimitri.Papadimitriou@alcatel.be Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt MIME-Version: 1.0 Date: Fri, 4 Mar 2005 23:51:02 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 03/04/2005 23:51:04 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 >> I wouldn't be so expeditious... >> Actually we could use a similar mechanism but >> definitely not the same. >> Secondary LSP are dedicated to Shared Meshed >> Restoration. >> IMHO this would be bad to use the Protection object >> for soft-FAs. Semantics >> are pretty different... >> > >IB>>Well, are they? They give you a way to signal a >requirement not to commit resources for an LSP until >further notice and also to require their commitment >when it becomes necessary. Why not to allow working >LSP to be signaled as Secondary according to the >mentioned draft? Then it would be possible even to >signal protected virtual FAs, which is not as stupid >as it may sound :=) Sorry but this sounds really bad... Please let me know then how do you signal protected virtual FAs? IB>> You signal both working and protection LSPs of the FA as Secondary. At the time when you decide to make FA "real" you re-signal working or both LSPs (depending on protection type) as Primary. Don't see why this wouldn't work. DP> because what do you do in case the primary (virtual) FA-LSP fails ? you are simply going to activate the secondary (virtual) FA-LSP which is in clear opposition with the notion of virtual-FA - the reason is again because you are trying to use one bit i.e. S to say something in a context (protection object) for which it has not been designed for From owner-ccamp@ops.ietf.org Fri Mar 4 18:09:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15356 for ; Fri, 4 Mar 2005 18:09:33 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Lwy-0000Wv-Uq for ccamp-archive@ietf.org; Fri, 04 Mar 2005 18:11:19 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7LrD-0003Vf-9B for ccamp-data@psg.com; Fri, 04 Mar 2005 23:05:19 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7LrC-0003VQ-A6 for ccamp@ops.ietf.org; Fri, 04 Mar 2005 23:05:18 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 7F1C510CC; Fri, 4 Mar 2005 18:05:17 -0500 (EST) Message-ID: <002101c5210e$a1a2d8b0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Igor Bryskin" , Cc: "LE ROUX Jean-Louis RD-CORE-LAN" , References: Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Date: Fri, 4 Mar 2005 18:05:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit > > > >IB>>Well, are they? They give you a way to signal a > >requirement not to commit resources for an LSP until > >further notice and also to require their commitment > >when it becomes necessary. Why not to allow working > >LSP to be signaled as Secondary according to the > >mentioned draft? Then it would be possible even to > >signal protected virtual FAs, which is not as stupid > >as it may sound :=) > > Sorry but this sounds really bad... > Please let me know then how do you signal protected virtual FAs? > > IB>> You signal both working and protection LSPs of the FA as Secondary. At > the time when you decide to make FA "real" you re-signal working or both > LSPs (depending on protection type) as Primary. Don't see why this wouldn't > work. > > DP> because what do you do in case the primary (virtual) FA-LSP fails ? you > are simply going to activate the secondary (virtual) FA-LSP which is in > clear > opposition with the notion of virtual-FA - the reason is again because you > are trying to use one bit i.e. S to say something in a context (protection > object) for which it has not been designed for > IB>> Oh-Oh, what do you mean by "primary (virtual) FA-LSP fails" and "you are simply going to activate the secondary (virtual) FA-LSP "? I activate protection LSP if I have a failure in the *data plane* of the working LSP. But working LSP of the virtual FA does not have any data plane yet, there is nothing that can trigger the protection LSP activation and switchover. Igor From owner-ccamp@ops.ietf.org Fri Mar 4 18:30:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18681 for ; Fri, 4 Mar 2005 18:30:37 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7MHO-0001CC-90 for ccamp-archive@ietf.org; Fri, 04 Mar 2005 18:32:23 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7MBP-0007BH-6j for ccamp-data@psg.com; Fri, 04 Mar 2005 23:26:11 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7MBN-0007As-2Z for ccamp@ops.ietf.org; Fri, 04 Mar 2005 23:26:09 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j24NPv9B008808; Sat, 5 Mar 2005 00:26:01 +0100 To: "Igor Bryskin" Cc: "Igor Bryskin" , , "LE ROUX Jean-Louis RD-CORE-LAN" , MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Date: Sat, 5 Mar 2005 00:25:55 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 03/05/2005 00:26:00 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,HTML_20_30, HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_BASE64_TEXT,MIME_HTML_ONLY, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 4.8 (++++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: base64 PFA+Jm5ic3A7PEJSPjxCUj48Rk9OVCBTSVpFPTI+PEI+JnF1b3Q7SWdvciBCcnlza2luJnF1b3Q7 ICZsdDtpYnJ5c2tpbkBtb3Zhei5jb20mZ3Q7PC9CPjwvRk9OVD48QlI+PEZPTlQgU0laRT0yPlNl bnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+PEZPTlQgU0laRT0yPjAz LzA0LzIwMDUgMTg6MDUgRVNUPC9GT05UPjxCUj48QlI+IDxGT05UIFNJWkU9Mj5Ubzo8L0ZPTlQ+ IDxGT05UIFNJWkU9Mj4mcXVvdDtJZ29yIEJyeXNraW4mcXVvdDsgJmx0O2lfYnJ5c2tpbkB5YWhv by5jb20mZ3Q7LCBEaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENBVEVMPC9GT05U PjxCUj4gPEZPTlQgU0laRT0yPmNjOjwvRk9OVD4gPEZPTlQgU0laRT0yPiZxdW90O0xFIFJPVVgg SmVhbi1Mb3VpcyBSRC1DT1JFLUxBTiZxdW90OyAmbHQ7amVhbmxvdWlzLmxlcm91eEBmcmFuY2V0 ZWxlY29tLmNvbSZndDssICZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PC9GT05UPjxCUj4gPEZP TlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPlN1YmplY3Q6PC9GT05UPiA8 Rk9OVCBTSVpFPTI+UmU6IFJFIDogUkUgOiBUUiA6IEktRCBBQ1RJT046ZHJhZnQtbGVyb3V4LWNj YW1wLWdtcGxzLW1ybi1ldmFsLTAwLnR4dDwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQPjxGT05U IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7SUImZ3Q7Jmd0 O1dlbGwsIGFyZSB0aGV5PyBUaGV5IGdpdmUgeW91IGEgd2F5IHRvIHNpZ25hbCBhPEJSPiZndDsg Jmd0O3JlcXVpcmVtZW50IG5vdCB0byBjb21taXQgcmVzb3VyY2VzIGZvciBhbiBMU1AgdW50aWw8 QlI+Jmd0OyAmZ3Q7ZnVydGhlciBub3RpY2UgYW5kIGFsc28gdG8gcmVxdWlyZSB0aGVpciBjb21t aXRtZW50PEJSPiZndDsgJmd0O3doZW4gaXQgYmVjb21lcyBuZWNlc3NhcnkuIFdoeSBub3QgdG8g YWxsb3cgd29ya2luZzxCUj4mZ3Q7ICZndDtMU1AgdG8gYmUgc2lnbmFsZWQgYXMgU2Vjb25kYXJ5 IGFjY29yZGluZyB0byB0aGU8QlI+Jmd0OyAmZ3Q7bWVudGlvbmVkIGRyYWZ0PyBUaGVuIGl0IHdv dWxkIGJlIHBvc3NpYmxlIGV2ZW4gdG88QlI+Jmd0OyAmZ3Q7c2lnbmFsIHByb3RlY3RlZCB2aXJ0 dWFsIEZBcywgd2hpY2ggaXMgbm90IGFzIHN0dXBpZDxCUj4mZ3Q7ICZndDthcyBpdCBtYXkgc291 bmQgOj0pPEJSPiZndDs8QlI+Jmd0OyBTb3JyeSBidXQgdGhpcyBzb3VuZHMgcmVhbGx5IGJhZC4u LjxCUj4mZ3Q7IFBsZWFzZSBsZXQgbWUga25vdyB0aGVuIGhvdyBkbyB5b3Ugc2lnbmFsIHByb3Rl Y3RlZCB2aXJ0dWFsIEZBcz88QlI+Jmd0OzxCUj4mZ3Q7IElCJmd0OyZndDsgWW91IHNpZ25hbCBi b3RoIHdvcmtpbmcgYW5kIHByb3RlY3Rpb24gTFNQcyBvZiB0aGUgRkEgYXMgU2Vjb25kYXJ5LjxC Uj5BdDxCUj4mZ3Q7IHRoZSB0aW1lIHdoZW4geW91IGRlY2lkZSB0byBtYWtlIEZBICZxdW90O3Jl YWwmcXVvdDsgeW91IHJlLXNpZ25hbCB3b3JraW5nIG9yIGJvdGg8QlI+Jmd0OyBMU1BzIChkZXBl bmRpbmcgb24gcHJvdGVjdGlvbiB0eXBlKSBhcyBQcmltYXJ5LiBEb24ndCBzZWUgd2h5IHRoaXM8 QlI+d291bGRuJ3Q8QlI+Jmd0OyB3b3JrLjxCUj4mZ3Q7PEJSPiZndDsgRFAmZ3Q7IGJlY2F1c2Ug d2hhdCBkbyB5b3UgZG8gaW4gY2FzZSB0aGUgcHJpbWFyeSAodmlydHVhbCkgRkEtTFNQIGZhaWxz ID88QlI+eW91PEJSPiZndDsgYXJlIHNpbXBseSBnb2luZyB0byBhY3RpdmF0ZSB0aGUgc2Vjb25k YXJ5ICh2aXJ0dWFsKSBGQS1MU1Agd2hpY2ggaXMgaW48QlI+Jmd0OyBjbGVhcjxCUj4mZ3Q7IG9w cG9zaXRpb24gd2l0aCB0aGUgbm90aW9uIG9mIHZpcnR1YWwtRkEgLSB0aGUgcmVhc29uIGlzIGFn YWluIGJlY2F1c2UgeW91PEJSPiZndDsgYXJlIHRyeWluZyB0byB1c2Ugb25lIGJpdCBpLmUuIFMg dG8gc2F5IHNvbWV0aGluZyBpbiBhIGNvbnRleHQgKHByb3RlY3Rpb248QlI+Jmd0OyBvYmplY3Qp IGZvciB3aGljaCBpdCBoYXMgbm90IGJlZW4gZGVzaWduZWQgZm9yPEJSPiZndDs8QlI+PC9GT05U PjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SUImZ3Q7Jmd0OyBPaC1PaCwgd2hh dCBkbyB5b3UgbWVhbiBieSAmcXVvdDtwcmltYXJ5ICh2aXJ0dWFsKSBGQS1MU1AgZmFpbHMmcXVv dDsgYW5kICZuYnNwOyZxdW90O3lvdTxCUj5hcmUgc2ltcGx5IGdvaW5nIHRvIGFjdGl2YXRlIHRo ZSBzZWNvbmRhcnkgKHZpcnR1YWwpIEZBLUxTUCAmcXVvdDs/ICZuYnNwO0kgYWN0aXZhdGU8QlI+ cHJvdGVjdGlvbiBMU1AgaWYgSSBoYXZlIGEgZmFpbHVyZSBpbiB0aGUgKmRhdGEgcGxhbmUqIG9m IHRoZSB3b3JraW5nIExTUC48QlI+QnV0IHdvcmtpbmcgTFNQIG9mIHRoZSB2aXJ0dWFsIEZBIGRv ZXMgbm90IGhhdmUgYW55IGRhdGEgcGxhbmUgeWV0LCB0aGVyZSBpczxCUj5ub3RoaW5nIHRoYXQg Y2FuIHRyaWdnZXIgdGhlIHByb3RlY3Rpb24gTFNQIGFjdGl2YXRpb24gYW5kIHN3aXRjaG92ZXIu PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkRQJmd0OyBidXQg dGhleSBhcmUgYXNzb2NpYXRlZCB0byByZXNvdXJjZXMgdGhleSBkbyBub3QgdXNlIC0gYW5kIHRo ZSBjb250cm9sIHBsYW5lIHJvbGUgaXMgdG8gZW5zdXJlIHRoYXQgd2hlbiB0aGV5IG5lZWQgdG8g YmUgYWN0aXZhdGVkIHJlc291cmNlcyBjYW4gYmUgdXNlZCAtIHRoZSBxdWVzdGlvbiBKTCByYWlz ZXMgaXMgdGhlIHByb2JsZW0gb2YgJnF1b3Q7aG93IGRvIGkgcHJvdGVjdCBhIHZpcnR1YWwgRkEm cXVvdDsgYW5kIHRoZSByZXNwb25zZSBpcyBpZiB5b3UgYXJlIHVzaW5nIHRoZSBTIGJpdCBmb3Ig dGVsbGluZyBpIGFtIGEgdmlydHVhbCBGQSB5b3UgY2FuIG5vdCB1c2UgaXQgYW55bW9yZSB0byBl bnN1cmUgcHJvdGVjdGlvbiBvZiBhIHByaW1hcnkgKGFuZCBldmVuIGxlc3MgYSBzZWNvbmRhcnkg ISkgLSB0aGlzIHNhaWQgYW4gc2Vjb25kYXJ5IExTUCBleGlzdHMgb25seSB3aXRoaW4gdGhlIGNv bnRleHQgb2YgaXRzIHByaW1hcnk8L0ZPTlQ+PC9QPjxQPiZuYnNwOzwvUD48UD48Rk9OVCBGQUNF PSJNb25vc3BhY2UsQ291cmllciI+PEJSPjwvRk9OVD48L1A+ From owner-ccamp@ops.ietf.org Sat Mar 5 05:40:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01660 for ; Sat, 5 Mar 2005 05:40:26 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Wje-00071C-BZ for ccamp-archive@ietf.org; Sat, 05 Mar 2005 05:42:17 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7WYx-0001Nv-Lr for ccamp-data@psg.com; Sat, 05 Mar 2005 10:31:11 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7WYt-0001MT-8j for ccamp@ops.ietf.org; Sat, 05 Mar 2005 10:31:07 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 1D10EE0001FE; Sat, 5 Mar 2005 10:30:56 +0000 (GMT) Received: from Puppy ([212.43.203.222] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 5 Mar 2005 10:27:39 +0000 Message-ID: <0a3701c5216e$2c2c0a10$19cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lam, Hing-Kam \(Kam\)" Cc: "'Kireeti Kompella'" , "Scott Bradner" , , "Bill Fenner" , , Subject: GMPLS Signaling Procedure for Egress Control Date: Sat, 5 Mar 2005 09:57:24 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 05 Mar 2005 10:27:40.0769 (UTC) FILETIME=[F5BA0D10:01C5216D] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit To: Mr. Kam Lam, rapporteur ITU-T Question 14/15 Cc: Mr. Scott Bradner, IETF liaison coordinator with the ITU-T Alex Zinin and Bill Fenner, IETF Routing Area Directors From: Adrian Farrel and Kireeti Kompella, IETF CCAMP working group chairs Subject: GMPLS Signaling Procedure for Egress Control For: Information Dear Mr. Lam We would like to inform Question 14/15 of the publication of a new GMPLS RFC. RFC 4003 (ftp://ftp.rfc-editor.org/in-notes/rfc4003.txt) "GMPLS Signaling Procedure for Egress Control" describes the procedures for control of egress ports and labels such as might be used to establish soft permanent LSPs. The abstract is as follows. This document clarifies the procedures for the control of the label used on an output/downstream interface of the egress node of a Label Switched Path (LSP). This control is also known as "Egress Control". Support for Egress Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Signaling. This document clarifies the specification of GMPLS Signaling and does not modify GMPLS signaling mechanisms and procedures. The need for clarification of these procedures was first raised by your Question, and CCAMP is grateful for the questions and discussion that led to the production of this RFC. Best regards, Adrian Farrel and Kireeti Kompella From owner-ccamp@ops.ietf.org Sat Mar 5 05:50:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02602 for ; Sat, 5 Mar 2005 05:50:57 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Wts-0007Hg-IH for ccamp-archive@ietf.org; Sat, 05 Mar 2005 05:52:48 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7Wmm-0004fq-Ju for ccamp-data@psg.com; Sat, 05 Mar 2005 10:45:28 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7Wmj-0004fW-Ln for ccamp@ops.ietf.org; Sat, 05 Mar 2005 10:45:25 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 09E66E0002EB for ; Sat, 5 Mar 2005 10:45:18 +0000 (GMT) Received: from Puppy ([212.43.203.222] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 5 Mar 2005 10:37:10 +0000 Message-ID: <0a6001c5216f$81cdecd0$19cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Nortel folk on this list Date: Sat, 5 Mar 2005 10:38:31 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 05 Mar 2005 10:37:13.0575 (UTC) FILETIME=[4B254F70:01C5216F] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit If there are any Nortel folk out there you might want to notify everyone else you know in Nortel that a large number of Nortel addresses are failing to receive CCAMP email because the company has changed its email address. You are kindly requested to remove your old addresses and add yourself using the the new ones. Thanks, Adrian From owner-ccamp@ops.ietf.org Sat Mar 5 07:12:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07425 for ; Sat, 5 Mar 2005 07:12:46 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7YB4-0000Pa-RK for ccamp-archive@ietf.org; Sat, 05 Mar 2005 07:14:39 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7Y1h-000OF3-Oo for ccamp-data@psg.com; Sat, 05 Mar 2005 12:04:58 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7Y1f-000OEc-Gj for ccamp@ops.ietf.org; Sat, 05 Mar 2005 12:04:55 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 85ECEE000250 for ; Sat, 5 Mar 2005 12:04:48 +0000 (GMT) Received: from Puppy ([212.43.203.177] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 5 Mar 2005 12:01:39 +0000 Message-ID: <0b6c01c5217b$4dfb3550$19cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Status of draft-ietf-ccamp-transport-lmp Date: Sat, 5 Mar 2005 11:59:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 05 Mar 2005 12:01:40.0976 (UTC) FILETIME=[178D5700:01C5217B] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Authors, Can you tell me: Does this version of the draft address all of the issues raised in the WG last call and the IETF liaison? Or do you plan a further revision? Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Monday, February 21, 2005 8:26 PM Subject: I-D ACTION:draft-ietf-ccamp-transport-lmp-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : A Transport Network View of LMP > Author(s) : D. Fedyk, et al. > Filename : draft-ietf-ccamp-transport-lmp-01.txt > Pages : 17 > Date : 2005-2-21 > > The Link Management Protocol (LMP) has been developed as part of the > Generalized MPLS (GMPLS) protocol suite to manage Traffic > Engineering (TE) resources and links. The GMPLS control plane > (routing and signaling) uses TE links for establishing Label > Switched Paths (LSPs). This memo describes the relationship of the > LMP procedures to 'discovery' as defined in the International > Telecommunication Union (ITU-T), and on-going ITU-T work. This > document provides an overview of LMP in the context of the ITU-T > Automatically Switched Optical Networks (ASON) and transport network > terminology and relates it to the ITU-T discovery work to promote a > common understanding for progressing the work of IETF and ITU-T. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-transport-lmp-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-transport-lmp-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-ccamp@ops.ietf.org Sat Mar 5 09:19:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17772 for ; Sat, 5 Mar 2005 09:19:04 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7a9I-0003VG-Qi for ccamp-archive@ietf.org; Sat, 05 Mar 2005 09:20:57 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7a0x-000H76-Tt for ccamp-data@psg.com; Sat, 05 Mar 2005 14:12:19 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7a0w-000H6l-KJ; Sat, 05 Mar 2005 14:12:18 +0000 Message-ID: <4229BE41.50004@psg.com> Date: Sat, 05 Mar 2005 15:12:17 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Status of draft-ietf-ccamp-transport-lmp References: <0b6c01c5217b$4dfb3550$19cb2bd4@Puppy> In-Reply-To: <0b6c01c5217b$4dfb3550$19cb2bd4@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit hi adrian - i did ask a question concerning the introduction of the term "unidirectional" for which i did not receive any clear answer - but this is an "internal comment" unrelated to comments/questions from the previous last call/liaisons/etc. thanks, - dimitri. Adrian Farrel wrote: > Authors, > > Can you tell me: Does this version of the draft address all of the issues > raised in the WG last call and the IETF liaison? > Or do you plan a further revision? > > Thanks, > Adrian > ----- Original Message ----- > From: > To: > Cc: > Sent: Monday, February 21, 2005 8:26 PM > Subject: I-D ACTION:draft-ietf-ccamp-transport-lmp-01.txt > > > >>A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >>This draft is a work item of the Common Control and Measurement Plane > > Working Group of the IETF. > >>Title : A Transport Network View of LMP >>Author(s) : D. Fedyk, et al. >>Filename : draft-ietf-ccamp-transport-lmp-01.txt >>Pages : 17 >>Date : 2005-2-21 >> >>The Link Management Protocol (LMP) has been developed as part of the >> Generalized MPLS (GMPLS) protocol suite to manage Traffic >> Engineering (TE) resources and links. The GMPLS control plane >> (routing and signaling) uses TE links for establishing Label >> Switched Paths (LSPs). This memo describes the relationship of the >> LMP procedures to 'discovery' as defined in the International >> Telecommunication Union (ITU-T), and on-going ITU-T work. This >> document provides an overview of LMP in the context of the ITU-T >> Automatically Switched Optical Networks (ASON) and transport network >> terminology and relates it to the ITU-T discovery work to promote a >> common understanding for progressing the work of IETF and ITU-T. >> >>A URL for this Internet-Draft is: >> > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-01.txt > >>To remove yourself from the I-D Announcement list, send a message to >>i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > >>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>to change your subscription settings. >> >> >>Internet-Drafts are also available by anonymous FTP. Login with the > > username > >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >>"get draft-ietf-ccamp-transport-lmp-01.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >>mailserv@ietf.org. >>In the body type: >>"FILE /internet-drafts/draft-ietf-ccamp-transport-lmp-01.txt". >> >>NOTE: The mail server at ietf.org can return the document in >>MIME-encoded form by using the "mpack" utility. To use this >>feature, insert the command "ENCODING mime" before the "FILE" >>command. To decode the response(s), you will need "munpack" or >>a MIME-compliant mail reader. Different MIME-compliant mail readers >>exhibit different behavior, especially when dealing with >>"multipart" MIME messages (i.e. documents which have been split >>up into multiple messages), so check your local documentation on >>how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> > > > > > . > From owner-ccamp@ops.ietf.org Sat Mar 5 09:36:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18914 for ; Sat, 5 Mar 2005 09:36:39 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7aQJ-0003qc-Vs for ccamp-archive@ietf.org; Sat, 05 Mar 2005 09:38:32 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7aK1-000PQE-Te for ccamp-data@psg.com; Sat, 05 Mar 2005 14:32:01 +0000 Received: from [68.142.200.149] (helo=web30806.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D7aJy-000PPv-Nx for ccamp@ops.ietf.org; Sat, 05 Mar 2005 14:31:58 +0000 Received: (qmail 15454 invoked by uid 60001); 5 Mar 2005 14:31:58 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=LAuZJwcYhl7fZX7+DoPjENXM5HaUk0reCo2tH3S1OXRfEtpuyThe5HSF4zZ8pOYKNMjo/FtqL1vRlpyY7h1sBc1huoxgDhp2wfAa5IcclsbgOAG5fvxCADvNx0odLuAUsZLaLHuyfZ0VcmTarclpbF28IDr/Qks5db0CzRvSx2g= ; Message-ID: <20050305143158.15452.qmail@web30806.mail.mud.yahoo.com> Received: from [68.100.80.11] by web30806.mail.mud.yahoo.com via HTTP; Sat, 05 Mar 2005 06:31:57 PST Date: Sat, 5 Mar 2005 06:31:57 -0800 (PST) From: Igor Bryskin Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt To: Dimitri.Papadimitriou@alcatel.be, Igor Bryskin Cc: Igor Bryskin , Dimitri.Papadimitriou@alcatel.be, LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,FORGED_YAHOO_RCVD autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Dimitri, See at the bottom > > > >IB>>Well, are they? They give you a way to signal a > >requirement not to commit resources for an LSP until > >further notice and also to require their commitment > >when it becomes necessary. Why not to allow working > >LSP to be signaled as Secondary according to the > >mentioned draft? Then it would be possible even to > >signal protected virtual FAs, which is not as stupid > >as it may sound :=) > > Sorry but this sounds really bad... > Please let me know then how do you signal protected virtual FAs? > > IB>> You signal both working and protection LSPs of the FA as Secondary. At > the time when you decide to make FA "real" you re-signal working or both > LSPs (depending on protection type) as Primary. Don't see why this wouldn't > work. > > DP> because what do you do in case the primary (virtual) FA-LSP fails ? you > are simply going to activate the secondary (virtual) FA-LSP which is in > clear > opposition with the notion of virtual-FA - the reason is again because you > are trying to use one bit i.e. S to say something in a context (protection > object) for which it has not been designed for > IB>> Oh-Oh, what do you mean by "primary (virtual) FA-LSP fails" and "you are simply going to activate the secondary (virtual) FA-LSP "? I activate protection LSP if I have a failure in the *data plane* of the working LSP. But working LSP of the virtual FA does not have any data plane yet, there is nothing that can trigger the protection LSP activation and switchover. DP> but they are associated to resources they do not use - and the control plane role is to ensure that when they need to be activated resources can be used - the question JL raises is the problem of "how do i protect a virtual FA" and the response is if you are using the S bit for telling i am a virtual FA you can not use it anymore to ensure protection of a primary (and even less a secondary !) - this said an secondary LSP exists only within the context of its primary IB>>Here is what I have in mind. A network operator configures a mesh of virtual FAs. Working FA LSPs are signaled as Secondary. Once they are established the FA TE link ends are advertised. Resources for these LSPs are allocated on the links the LSPs are going through, however, they are not committed (not bound into cross-connects). Two or more virtual FA LSPs may share the resources on common links. This is especially true for those of them that are unlikely to become real at the same time. Furthermore, polices could be such that virtual FA LSP resources could be allowed to get pre-empted by real (not necessarily FA-) LSPs. The mentioned resources also could be involved in mesh restoration schemes and even be bound into extra traffic LSPs. When a virtual FA transforms into real FA, its working FA-LSP is re-signaled as Primary. At this time, the allocated resources are bound into FA-LSP cross-connects. Naturally, all other LSPs – virtual or real – that share resources with the FA-LSP in question are notified and need to be recomputed and/or re-signaled. A virtual FA could be provisioned as protected in a sense that when it becomes real it will have a certain protection scheme already in place. Path computation for backup LSPs of virtual FAs is performed just like of real FAs, that is, by assuming that associated working LSPs are Primary (fully built) LSPs. Regardless of the protection type backup LSPs of virtual FAs are always signaled as Secondary. At the time when a virtual FA is transformed into real one (that is, when its working LSP becomes Primary) its backup LSP(s) may be activated as well (e.g. 1+1 protection) or may be left Secondary until the working LSP data plane failure is detected (e.g. shared protection). Igor __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-ccamp@ops.ietf.org Sat Mar 5 10:05:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21138 for ; Sat, 5 Mar 2005 10:05:46 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7asT-0004Xz-2T for ccamp-archive@ietf.org; Sat, 05 Mar 2005 10:07:40 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7ajg-000CAp-U5 for ccamp-data@psg.com; Sat, 05 Mar 2005 14:58:32 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7ajf-000C9O-Tz; Sat, 05 Mar 2005 14:58:32 +0000 Message-ID: <4229C915.7030308@psg.com> Date: Sat, 05 Mar 2005 15:58:29 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kireeti Kompella CC: Igor Bryskin , yakov@juniper.net, ccamp@ops.ietf.org Subject: Re: A philosophical question about FA and FA-LSP References: <00a201c520d9$290913e0$7a1810ac@movaz.com> <20050304094707.A72012@kummer.juniper.net> <00ad01c520e5$013fdf90$7a1810ac@movaz.com> <20050304100910.R72177@kummer.juniper.net> In-Reply-To: <20050304100910.R72177@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit hi kireeti, >>My question was what is (if any) special about FA TE link apart from >>the fact that it is dynamically created/destroyed? > > > Actually, an FA TE link doesn't have to be dynamically > created/destroyed. > > What's special? Nothing really. A "normal" TE link usually has a > (single) physical interface associated with it; an FA TE link is > usually multi-hop. A "normal" TE link usually is accompanied by an > IGP adjacency (at least, in the packet domain); an FA TE link usually > doesn't. but if a couple this with your answer "Correct -- LSPs created in IGP A can be advertised as TE links in IGP B. This can be used (say) for inter-area signaling." don't you have now an adjacency accompanying the TE link advertisement in IGP B - therefore why is there a need to rename the canonical inheritance i.e. why not just speak in that case about a TE link or a "hierarchical TE link" as it was the case in one of the earlier versions of the LSP-HIER document and keep the FA concept when dealing with a unique instance ? thanks, - dimitri > But from the point of view of the IGP, or an LSR in that IGP, they > can't tell an FA TE link from any other TE link. > > Kireeti. > ------- > > > . > From owner-ccamp@ops.ietf.org Sat Mar 5 10:08:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21647 for ; Sat, 5 Mar 2005 10:08:56 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7avZ-0004cj-Dx for ccamp-archive@ietf.org; Sat, 05 Mar 2005 10:10:49 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7aoM-000Efh-0C for ccamp-data@psg.com; Sat, 05 Mar 2005 15:03:22 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7aoK-000EUw-J6; Sat, 05 Mar 2005 15:03:20 +0000 Message-ID: <4229CA36.6000505@psg.com> Date: Sat, 05 Mar 2005 16:03:18 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Bryskin CC: Dimitri.Papadimitriou@alcatel.be, Igor Bryskin , LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt References: <20050305143158.15452.qmail@web30806.mail.mud.yahoo.com> In-Reply-To: <20050305143158.15452.qmail@web30806.mail.mud.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 8bit igor - i will provide a detailed answer concerning a clean method to deal with "virtual FAs" that does not rely on the use of the protection object (and therefore would deliver a clean method to provide signaling for protected "virtual FAs" hopefully we can discuss this during this IETF meeting, thanks, - dimitri. Igor Bryskin wrote: > Dimitri, > > See at the bottom > > >>>IB>>Well, are they? They give you a way to signal a >>>requirement not to commit resources for an LSP > > until > >>>further notice and also to require their commitment >>>when it becomes necessary. Why not to allow working >>>LSP to be signaled as Secondary according to the >>>mentioned draft? Then it would be possible even to >>>signal protected virtual FAs, which is not as > > stupid > >>>as it may sound :=) >> >>Sorry but this sounds really bad... >>Please let me know then how do you signal protected > > virtual FAs? > >>IB>> You signal both working and protection LSPs of > > the FA as Secondary. > At > >>the time when you decide to make FA "real" you > > re-signal working or both > >>LSPs (depending on protection type) as Primary. > > Don't see why this > wouldn't > >>work. >> >>DP> because what do you do in case the primary > > (virtual) FA-LSP fails ? > you > >>are simply going to activate the secondary (virtual) > > FA-LSP which is in > >>clear >>opposition with the notion of virtual-FA - the > > reason is again because you > >>are trying to use one bit i.e. S to say something in > > a context (protection > >>object) for which it has not been designed for >> > > > IB>> Oh-Oh, what do you mean by "primary (virtual) > FA-LSP fails" and "you > are simply going to activate the secondary (virtual) > FA-LSP "? I activate > protection LSP if I have a failure in the *data plane* > of the working LSP. > But working LSP of the virtual FA does not have any > data plane yet, there is > nothing that can trigger the protection LSP activation > and switchover. > > DP> but they are associated to resources they do not > use - and the control plane role is to ensure that > when they need to be activated resources can be used - > the question JL raises is the problem of "how do i > protect a virtual FA" and the response is if you are > using the S bit for telling i am a virtual FA you can > not use it anymore to ensure protection of a primary > (and even less a secondary !) - this said an secondary > LSP exists only within the context of its primary > > IB>>Here is what I have in mind. > > A network operator configures a mesh of virtual FAs. > Working FA LSPs are signaled as Secondary. Once they > are established the FA TE link ends are advertised. > Resources for these LSPs are allocated on the links > the LSPs are going through, however, they are not > committed (not bound into cross-connects). Two or more > virtual FA LSPs may share the resources on common > links. This is especially true for those of them that > are unlikely to become real at the same time. > Furthermore, polices could be such that virtual FA LSP > resources could be allowed to get pre-empted by real > (not necessarily FA-) LSPs. The mentioned resources > also could be involved in mesh restoration schemes and > even be bound into extra traffic LSPs. > > When a virtual FA transforms into real FA, its working > FA-LSP is re-signaled as Primary. At this time, the > allocated resources are bound into FA-LSP > cross-connects. Naturally, all other LSPs – virtual or > real – that share resources with the FA-LSP in > question are notified and need to be recomputed and/or > re-signaled. > > A virtual FA could be provisioned as protected in a > sense that when it becomes real it will have a certain > protection scheme already in place. Path computation > for backup LSPs of virtual FAs is performed just like > of real FAs, that is, by assuming that associated > working LSPs are Primary (fully built) LSPs. > Regardless of the protection type backup LSPs of > virtual FAs are always signaled as Secondary. At the > time when a virtual FA is transformed into real one > (that is, when its working LSP becomes Primary) its > backup LSP(s) may be activated as well (e.g. 1+1 > protection) or may be left Secondary until the working > LSP data plane failure is detected (e.g. shared > protection). > > Igor > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > . > From owner-ccamp@ops.ietf.org Sat Mar 5 11:28:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27779 for ; Sat, 5 Mar 2005 11:28:52 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7cAu-0006Mc-Kl for ccamp-archive@ietf.org; Sat, 05 Mar 2005 11:30:47 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7c2x-000Q0k-GB for ccamp-data@psg.com; Sat, 05 Mar 2005 16:22:31 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7c2t-000Q0N-Gk for ccamp@ops.ietf.org; Sat, 05 Mar 2005 16:22:27 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id B8B94E0000D8; Sat, 5 Mar 2005 16:22:24 +0000 (GMT) Received: from Puppy ([212.43.203.157] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 5 Mar 2005 16:21:26 +0000 Message-ID: <0de601c5219f$988f1e00$19cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" , "Tove Madsen" Subject: Agenda on-line Date: Sat, 5 Mar 2005 16:22:49 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 05 Mar 2005 16:21:27.0093 (UTC) FILETIME=[619A0E50:01C5219F] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Hi, Kireeti has submitted the agenda to the Secretariat so you should be able to see it on their web site. I have placed an HTML version on the alternative CCAMP pages at http://www.olddog.co.uk/ccamp.htm You'll also find a template for your slides there in case you need something to start with and some reminders of what you should be talking about. Would the presenters please send me their slides before midnight on Monday. (No slides, no presentation :-) Thanks, Adrian From owner-ccamp@ops.ietf.org Sat Mar 5 12:52:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03376 for ; Sat, 5 Mar 2005 12:52:06 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7dTW-00089M-BZ for ccamp-archive@ietf.org; Sat, 05 Mar 2005 12:54:02 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7dLo-000GxV-ST for ccamp-data@psg.com; Sat, 05 Mar 2005 17:46:04 +0000 Received: from [66.129.224.36] (helo=kummer.juniper.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D7dLo-000Gx5-2N; Sat, 05 Mar 2005 17:46:04 +0000 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j25HjwXg079220; Sat, 5 Mar 2005 09:45:58 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j25HjtKw079217; Sat, 5 Mar 2005 09:45:55 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Sat, 5 Mar 2005 09:45:55 -0800 (PST) From: Kireeti Kompella To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be cc: Igor Bryskin , yakov@juniper.net, ccamp@ops.ietf.org Subject: Re: A philosophical question about FA and FA-LSP In-Reply-To: <4229C915.7030308@psg.com> Message-ID: <20050305093157.A79191@kummer.juniper.net> References: <00a201c520d9$290913e0$7a1810ac@movaz.com> <20050304094707.A72012@kummer.juniper.net> <00ad01c520e5$013fdf90$7a1810ac@movaz.com> <20050304100910.R72177@kummer.juniper.net> <4229C915.7030308@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Sat, 5 Mar 2005, dimitri papadimitriou wrote: > > What's special? Nothing really. A "normal" TE link usually has a > > (single) physical interface associated with it; an FA TE link is > > usually multi-hop. A "normal" TE link usually is accompanied by an > > IGP adjacency (at least, in the packet domain); an FA TE link usually > > doesn't. > > but if a couple this with your answer "Correct -- LSPs created in IGP A > can be advertised as TE links in IGP B. This can be used (say) for > inter-area signaling." don't you have now an adjacency accompanying the > TE link advertisement in IGP B Not necessarily. Say you have: IGP B - X == IGP A == Y - IGP B X and Y participate in both IGPs; X has an LSP to Y, and advertises it into IGP B. All's fine. I'm guessing you are referring to the fact that IGP B appears partitioned? Well, to connect up the piece on the right with the piece on the left, one can: a) create an adjacency over the FA LSP (only possible if LSP is PSC) b) have a virtual link (OSPF) from X to Y c) have some other "backdoor" connection between the two parts. > - therefore why is there a need to rename > the canonical inheritance i.e. why not just speak in that case about a > TE link or a "hierarchical TE link" as it was the case in one of the > earlier versions of the LSP-HIER document and keep the FA concept when > dealing with a unique instance ? You can call it what you like :-) "FA" in particular refers to the idea that the "adjacency" is primarily for forwarding, and not necessarily for the control plane. However, the latter is not ruled out (as in case (a) above.) Kireeti. ------- From owner-ccamp@ops.ietf.org Sat Mar 5 13:56:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07494 for ; Sat, 5 Mar 2005 13:56:26 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7eTj-00013B-Ik for ccamp-archive@ietf.org; Sat, 05 Mar 2005 13:58:21 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7eMd-0003bn-Bl for ccamp-data@psg.com; Sat, 05 Mar 2005 18:50:59 +0000 Received: from [68.142.200.153] (helo=web30810.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D7eMc-0003bP-60 for ccamp@ops.ietf.org; Sat, 05 Mar 2005 18:50:58 +0000 Received: (qmail 87308 invoked by uid 60001); 5 Mar 2005 18:50:54 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=y4CYz/xM+wVfrTxVflmwKoigseGLCu509ypm9ibzfdfdhXRr6rk2euW3HFD94AVuWddaqc2EGm430rKJQEG3YIiLcgIviWlSn2kz6iO9v9T/fkX0UvKwqpjuMqos8UHo6dJn4Mou9oJIabNX2dtGD0t6FMR0G7BKl7UvD6Oge3Q= ; Message-ID: <20050305185054.87306.qmail@web30810.mail.mud.yahoo.com> Received: from [68.100.80.11] by web30810.mail.mud.yahoo.com via HTTP; Sat, 05 Mar 2005 10:50:54 PST Date: Sat, 5 Mar 2005 10:50:54 -0800 (PST) From: Igor Bryskin Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Cc: Dimitri.Papadimitriou@alcatel.be, Igor Bryskin , LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org In-Reply-To: <4229CA36.6000505@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00, FORGED_YAHOO_RCVD autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Excellent. Looking forward to the discussion. Hopefully, I’ll get to understand what is not clean about the mechanism I suggested. Before we start the discussion, I’d like to make clear that all I am asking is a capability to provision working LSPs as Secondary LSPs. Note that this is a generic mechanism, and signaling of virtual FAs is one of possibly many applications that can make use of it. For example, on many occasions I hear a requirement from service providers to provide a way of provisioning a service when part of network resources are not in place yet with actual service activation after all resources are installed. This is necessary to make sure that resources that are in place are not “grabbed” by other dynamically provisioned services. This problem could be easily solved by the suggested mechanism. Lastly, despite what you and JL are saying, provisioning of virtual FAs has a lot to do with recovery. It is usually a MUST requirement for FAs to be protected. In this case if you provision virtual FA as unprotected, and, while it is transformed into real FA, try to compute/provision protection LSP, the computation may fail despite that two disjoint paths do exist and could be determined if they were computed at the same time. Therefore, it should be possible to compute working and protection (possibly multiple as in case of segment protection) path(s) for virtual FA and signal them, associating them together, without committing network resource for neither of them. See you in Minneapolis, Igor --- dimitri papadimitriou wrote: > igor - i will provide a detailed answer concerning a > clean method to > deal with "virtual FAs" that does not rely on the > use of the protection > object (and therefore would deliver a clean method > to provide signaling > for protected "virtual FAs" > > hopefully we can discuss this during this IETF > meeting, > > thanks, > - dimitri. > > Igor Bryskin wrote: > > > Dimitri, > > > > See at the bottom > > > > > >>>IB>>Well, are they? They give you a way to signal > a > >>>requirement not to commit resources for an LSP > > > > until > > > >>>further notice and also to require their > commitment > >>>when it becomes necessary. Why not to allow > working > >>>LSP to be signaled as Secondary according to the > >>>mentioned draft? Then it would be possible even > to > >>>signal protected virtual FAs, which is not as > > > > stupid > > > >>>as it may sound :=) > >> > >>Sorry but this sounds really bad... > >>Please let me know then how do you signal > protected > > > > virtual FAs? > > > >>IB>> You signal both working and protection LSPs > of > > > > the FA as Secondary. > > At > > > >>the time when you decide to make FA "real" you > > > > re-signal working or both > > > >>LSPs (depending on protection type) as Primary. > > > > Don't see why this > > wouldn't > > > >>work. > >> > >>DP> because what do you do in case the primary > > > > (virtual) FA-LSP fails ? > > you > > > >>are simply going to activate the secondary > (virtual) > > > > FA-LSP which is in > > > >>clear > >>opposition with the notion of virtual-FA - the > > > > reason is again because you > > > >>are trying to use one bit i.e. S to say something > in > > > > a context (protection > > > >>object) for which it has not been designed for > >> > > > > > > IB>> Oh-Oh, what do you mean by "primary (virtual) > > FA-LSP fails" and "you > > are simply going to activate the secondary > (virtual) > > FA-LSP "? I activate > > protection LSP if I have a failure in the *data > plane* > > of the working LSP. > > But working LSP of the virtual FA does not have > any > > data plane yet, there is > > nothing that can trigger the protection LSP > activation > > and switchover. > > > > DP> but they are associated to resources they do > not > > use - and the control plane role is to ensure that > > when they need to be activated resources can be > used - > > the question JL raises is the problem of "how do i > > protect a virtual FA" and the response is if you > are > > using the S bit for telling i am a virtual FA you > can > > not use it anymore to ensure protection of a > primary > > (and even less a secondary !) - this said an > secondary > > LSP exists only within the context of its primary > > > > IB>>Here is what I have in mind. > > > > A network operator configures a mesh of virtual > FAs. > > Working FA LSPs are signaled as Secondary. Once > they > > are established the FA TE link ends are > advertised. > > Resources for these LSPs are allocated on the > links > > the LSPs are going through, however, they are not > > committed (not bound into cross-connects). Two or > more > > virtual FA LSPs may share the resources on common > > links. This is especially true for those of them > that > > are unlikely to become real at the same time. > > Furthermore, polices could be such that virtual FA > LSP > > resources could be allowed to get pre-empted by > real > > (not necessarily FA-) LSPs. The mentioned > resources > > also could be involved in mesh restoration schemes > and > > even be bound into extra traffic LSPs. > > > > When a virtual FA transforms into real FA, its > working > > FA-LSP is re-signaled as Primary. At this time, > the > > allocated resources are bound into FA-LSP > > cross-connects. Naturally, all other LSPs – > virtual or > > real – that share resources with the FA-LSP in > > question are notified and need to be recomputed > and/or > > re-signaled. > > > > A virtual FA could be provisioned as protected in > a > > sense that when it becomes real it will have a > certain > > protection scheme already in place. Path > computation > > for backup LSPs of virtual FAs is performed just > like > > of real FAs, that is, by assuming that associated > > working LSPs are Primary (fully built) LSPs. > > Regardless of the protection type backup LSPs of > > virtual FAs are always signaled as Secondary. At > the > > time when a virtual FA is transformed into real > one > > (that is, when its working LSP becomes Primary) > its > > backup LSP(s) may be activated as well (e.g. 1+1 > > protection) or may be left Secondary until the > working > > LSP data plane failure is detected (e.g. shared > > protection). > > > > Igor > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > > > . > > > > __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From owner-ccamp@ops.ietf.org Sat Mar 5 17:02:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21207 for ; Sat, 5 Mar 2005 17:02:45 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7hO4-00051b-Nx for ccamp-archive@ietf.org; Sat, 05 Mar 2005 17:04:43 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D7hEw-000CDI-07 for ccamp-data@psg.com; Sat, 05 Mar 2005 21:55:14 +0000 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7hEp-000CAI-UN for ccamp@ops.ietf.org; Sat, 05 Mar 2005 21:55:08 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 9DF5BE0001A4; Sat, 5 Mar 2005 21:55:01 +0000 (GMT) Received: from Puppy ([212.43.203.46] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 5 Mar 2005 21:50:51 +0000 Message-ID: <0e6501c521cd$9d8e05f0$19cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , "Igor Bryskin" Cc: , "Igor Bryskin" , "LE ROUX Jean-Louis RD-CORE-LAN" , References: <20050305143158.15452.qmail@web30806.mail.mud.yahoo.com> <4229CA36.6000505@psg.com> Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Date: Sat, 5 Mar 2005 16:30:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 05 Mar 2005 21:50:52.0756 (UTC) FILETIME=[66DAE140:01C521CD] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: 8bit Why are we talking about signaling virtual FA LSPs? I thought the point of a virtual FA was that it was entirely putative. Seems like you are talking about something more solid than a virtual FA LSP. Adrian ----- Original Message ----- From: "dimitri papadimitriou" To: "Igor Bryskin" Cc: ; "Igor Bryskin" ; "LE ROUX Jean-Louis RD-CORE-LAN" ; Sent: Saturday, March 05, 2005 3:03 PM Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt > igor - i will provide a detailed answer concerning a clean method to > deal with "virtual FAs" that does not rely on the use of the protection > object (and therefore would deliver a clean method to provide signaling > for protected "virtual FAs" > > hopefully we can discuss this during this IETF meeting, > > thanks, > - dimitri. > > Igor Bryskin wrote: > > > Dimitri, > > > > See at the bottom > > > > > >>>IB>>Well, are they? They give you a way to signal a > >>>requirement not to commit resources for an LSP > > > > until > > > >>>further notice and also to require their commitment > >>>when it becomes necessary. Why not to allow working > >>>LSP to be signaled as Secondary according to the > >>>mentioned draft? Then it would be possible even to > >>>signal protected virtual FAs, which is not as > > > > stupid > > > >>>as it may sound :=) > >> > >>Sorry but this sounds really bad... > >>Please let me know then how do you signal protected > > > > virtual FAs? > > > >>IB>> You signal both working and protection LSPs of > > > > the FA as Secondary. > > At > > > >>the time when you decide to make FA "real" you > > > > re-signal working or both > > > >>LSPs (depending on protection type) as Primary. > > > > Don't see why this > > wouldn't > > > >>work. > >> > >>DP> because what do you do in case the primary > > > > (virtual) FA-LSP fails ? > > you > > > >>are simply going to activate the secondary (virtual) > > > > FA-LSP which is in > > > >>clear > >>opposition with the notion of virtual-FA - the > > > > reason is again because you > > > >>are trying to use one bit i.e. S to say something in > > > > a context (protection > > > >>object) for which it has not been designed for > >> > > > > > > IB>> Oh-Oh, what do you mean by "primary (virtual) > > FA-LSP fails" and "you > > are simply going to activate the secondary (virtual) > > FA-LSP "? I activate > > protection LSP if I have a failure in the *data plane* > > of the working LSP. > > But working LSP of the virtual FA does not have any > > data plane yet, there is > > nothing that can trigger the protection LSP activation > > and switchover. > > > > DP> but they are associated to resources they do not > > use - and the control plane role is to ensure that > > when they need to be activated resources can be used - > > the question JL raises is the problem of "how do i > > protect a virtual FA" and the response is if you are > > using the S bit for telling i am a virtual FA you can > > not use it anymore to ensure protection of a primary > > (and even less a secondary !) - this said an secondary > > LSP exists only within the context of its primary > > > > IB>>Here is what I have in mind. > > > > A network operator configures a mesh of virtual FAs. > > Working FA LSPs are signaled as Secondary. Once they > > are established the FA TE link ends are advertised. > > Resources for these LSPs are allocated on the links > > the LSPs are going through, however, they are not > > committed (not bound into cross-connects). Two or more > > virtual FA LSPs may share the resources on common > > links. This is especially true for those of them that > > are unlikely to become real at the same time. > > Furthermore, polices could be such that virtual FA LSP > > resources could be allowed to get pre-empted by real > > (not necessarily FA-) LSPs. The mentioned resources > > also could be involved in mesh restoration schemes and > > even be bound into extra traffic LSPs. > > > > When a virtual FA transforms into real FA, its working > > FA-LSP is re-signaled as Primary. At this time, the > > allocated resources are bound into FA-LSP > > cross-connects. Naturally, all other LSPs – virtual or > > real – that share resources with the FA-LSP in > > question are notified and need to be recomputed and/or > > re-signaled. > > > > A virtual FA could be provisioned as protected in a > > sense that when it becomes real it will have a certain > > protection scheme already in place. Path computation > > for backup LSPs of virtual FAs is performed just like > > of real FAs, that is, by assuming that associated > > working LSPs are Primary (fully built) LSPs. > > Regardless of the protection type backup LSPs of > > virtual FAs are always signaled as Secondary. At the > > time when a virtual FA is transformed into real one > > (that is, when its working LSP becomes Primary) its > > backup LSP(s) may be activated as well (e.g. 1+1 > > protection) or may be left Secondary until the working > > LSP data plane failure is detected (e.g. shared > > protection). > > > > Igor > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > > > . > > > > > From owner-ccamp@ops.ietf.org Sun Mar 6 13:34:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08605 for ; Sun, 6 Mar 2005 13:34:19 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D80c8-0001Yz-Lc for ccamp-archive@ietf.org; Sun, 06 Mar 2005 13:36:29 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D80Tq-000LKt-Oo for ccamp-data@psg.com; Sun, 06 Mar 2005 18:27:54 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D80Tp-000LKd-MC; Sun, 06 Mar 2005 18:27:53 +0000 Message-ID: <422B4BA7.3090300@psg.com> Date: Sun, 06 Mar 2005 19:27:51 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kireeti Kompella CC: dimitri.papadimitriou@alcatel.be, Igor Bryskin , yakov@juniper.net, ccamp@ops.ietf.org Subject: Re: A philosophical question about FA and FA-LSP References: <00a201c520d9$290913e0$7a1810ac@movaz.com> <20050304094707.A72012@kummer.juniper.net> <00ad01c520e5$013fdf90$7a1810ac@movaz.com> <20050304100910.R72177@kummer.juniper.net> <4229C915.7030308@psg.com> <20050305093157.A79191@kummer.juniper.net> In-Reply-To: <20050305093157.A79191@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit hi - see in-line: Kireeti Kompella wrote: > On Sat, 5 Mar 2005, dimitri papadimitriou wrote: > > >>>What's special? Nothing really. A "normal" TE link usually has a >>>(single) physical interface associated with it; an FA TE link is >>>usually multi-hop. A "normal" TE link usually is accompanied by an >>>IGP adjacency (at least, in the packet domain); an FA TE link usually >>>doesn't. >> >>but if a couple this with your answer "Correct -- LSPs created in IGP A >>can be advertised as TE links in IGP B. This can be used (say) for >>inter-area signaling." don't you have now an adjacency accompanying the >>TE link advertisement in IGP B > > > Not necessarily. Say you have: > > IGP B - X == IGP A == Y - IGP B > > X and Y participate in both IGPs; X has an LSP to Y, and advertises it > into IGP B. All's fine. > > I'm guessing you are referring to the fact that IGP B appears > partitioned? Well, to connect up the piece on the right with the > piece on the left, one can: > a) create an adjacency over the FA LSP (only possible if LSP is PSC) ok but is that not another adjacency accompanying the TE link advertisement for (or in) IGP B as stated in my previous reply ? > b) have a virtual link (OSPF) from X to Y > c) have some other "backdoor" connection between the two parts. the same applying for the other cases >>- therefore why is there a need to rename >>the canonical inheritance i.e. why not just speak in that case about a >>TE link or a "hierarchical TE link" as it was the case in one of the >>earlier versions of the LSP-HIER document and keep the FA concept when >>dealing with a unique instance ? > > You can call it what you like :-) "FA" in particular refers to the > idea that the "adjacency" is primarily for forwarding, and not > necessarily for the control plane. However, the latter is not ruled > out (as in case (a) above.) initially the term has been introduced to implicitly allow for the creation of a forwarding adjacency *without introducing a control plane adjacency* solving the facto scaling of the control plane both in terms of routing (creation of a data plane adjacency does not trigger creation of a routing adjacency therefore the number of routing adjacencies remains constant independently of the number of data plane adjacencies) and signaling (resulting from the LSP nesting operations), and the inherent problem associated to the so-called "unknown adjacency" problem that was also the achille heel of the IPoverATM approach where one had to create a full-mesh of VCs to determine the reachable end-points from the IP level i do believe we are in agreement on this point - if not please let me know - now on the issue concerning not ruling out case a) as described here above how do you position this with the following paragraph in the LSP-Hierarchy document " It is expected that FAs will not be used for establishing ISIS/OSPF peering relation between the routers at the ends of the adjacency." probably we do not have to preclude this but it would be advisable to consider a self-consistent terminology to describe the sub-cases we are dealing with thanks, - dimitri. > Kireeti. > ------- > > . > From owner-ccamp@ops.ietf.org Sun Mar 6 16:37:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28886 for ; Sun, 6 Mar 2005 16:37:48 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D83Ti-0006cx-5C for ccamp-archive@ietf.org; Sun, 06 Mar 2005 16:39:58 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D83LC-0009VG-7L for ccamp-data@psg.com; Sun, 06 Mar 2005 21:31:10 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D83L9-0009Uv-VS; Sun, 06 Mar 2005 21:31:08 +0000 Message-ID: <422B7697.9010600@psg.com> Date: Sun, 06 Mar 2005 22:31:03 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN CC: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Content-Transfer-Encoding: 8bit hi jean-louis the below discussion raises the issue that the decoupling of the control from the (data plane) resource admission control (driven by the Min/Max LSP bandwidith) raises the issue of the control plane saturation due to LSPs that do not reserve any bandwith/or allow for bandwidth reuse such low priority LSPs and therefore the #LSPs actually processed by the control plane can become much higher than the number of LSPs that could result from the Min LSP bandwidth parameter - this is a nice side effect of part of bunch of other control plane processing issues such prioritized treatment of control messages, concurrent requests, etc. i think the problem statement is rather scoped, however the solution scope seems to me to be raising correlation issue and further relationship with the data plane resource re-optimization issues we were discussing on this list a couple of times - i could sum'up this in one sentence is it suitable to flood the state of the signaling control engine using flooding or is the intention to consider this as an additional constraint - note that in the former case flooding provides you a notification mechanism after occurrence but does not deliver any avoidance mechanism - this said is that really a "router capability" or do you mean here the capability to provide "control plane saturation tracking" ? therefore, it would be probably advisable to be a bit less expeditive in terms of solution thanks, - dimitri. LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Adrian, > > Thanks a lot for these comments > > Please see inline > > Regards > > JL > > > > >> -----Message d'origine----- De : Adrian Farrel >> [mailto:adrian@olddog.co.uk] Envoyé : mardi 1 février 2005 19:41 À >> : LE ROUX Jean-Louis RD-CORE-LAN Cc : ccamp@ops.ietf.org Objet : >> Re: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt >> >> >> Jean-Louis, >> >> Thanks for this draft. >> >> A couple of immediate thoughts. >> >> 1. What is wrong with using Error Code 23? > > > Error code 23 is used for "System Errors". IMHO the saturation > semantic defined here is quite different. > > > >> 2. Will implementations really want to confess to the reason that >> they are unable to handle more LSPs? It seems to me that it would >> be a remarkably honest implementation that implemented this draft. >> > > > Bascially the draft proposes to handle properly control plane > saturation cases. If you want to handle these cases you need a > dedicated error code, this would allow Head-end LSRs to take > appropriate actions. > > >> Isn't it more likely that the LSR would claim an admission control >> error? 3. > > > Saturation is not and admission control problem > > >> "The head-end should not reroute already established LSPs passing >> through the saturated node." Why ever not? Surely this is local >> policy, and the ingress may know that the only way to route its new >> and projected LSPs is to move some of the existing ones. > > > Stability is better, the LSR is already supporting a set of TE-LSPs, > it is saturated, why would you want to move these LSPs? > > 4. Why is saturation a good thing to advertise in the > >> IGP? If an LSR wishes to prevent new LSPs being routed through it, >> it should withdraw bandwidth just as it would if the signaling >> elements of the control plane had failed. 5. > > > But what about 0 bandwidth LSPs? A head-end may select a node with 0 > bandwidth available, when computing the path of a 0 bandwidth LSP. So > withdrawing bandwidth is not sufficient to handle properly control > plane saturations > > > >> Much of the draft restates default behavior (e.g. what to do when >> you receive a Path message). This is interesting information for >> the reader, but I am not sure that it is right to present it here. >> > > > Agree > > 6. Why does the new Error Codes have three Error Values, > >> but the Saturation TLV only have one bit defined? > > > Good point, we need to define 3 flags > > >> 7. Section 5.2. All "MUST" should be "SHOULD" I think. > > > Why? This is IMHO a mandatory behavior for an implementation > compliant with this draft. > > >> My main question is why you need this draft. It seems that you can >> already achieve all of these features using existing protocol >> elements. > > > I think that this would be cleaner with these light signaling and > routing extensions. > > >> At most you might want to write a one page BCP to say what a >> transit or egress LSP should do when it cannot handle a new LSP >> because of some internal resource shortage other than an admission >> control problem. > > > But the problem is that we consider that when a transit or egress LSR > cannot handle a new LSP because of some internal resource shortage > other than an admission control problem, it should notify the head > end about its saturation, and if you want proper reaction you need a > specific notification...thus dedicated error code points are required > > > Again thanks a lot for these comments > > Regards > > JL > > > >> Cheers, Adrian >> >> >> ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN" >> To: >> Sent: Tuesday, February 01, 2005 7:21 AM Subject: TR: I-D >> ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt >> >> >> Hi all, >> >> We just posted a new draft related to (G)MPLS-TE control plane >> resource shortages. Your comments/feedbacks on this draft are >> welcome. >> >> Regards, >> >> JL >> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Procedure to handle (G)MPLS-TE control plane saturation >> Author(s) : J. Le Roux, et al. Filename : >> draft-leroux-ccamp-ctrl-saturation-00.txt Pages : 10 Date : >> 2005-1-31 >> >> This document defines extensions to RSVP-TE (Resource Reservation >> Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to >> signal control plane resources saturation, when an LSR runs out of >> control plane resources available to support a new LSP. Such >> notification may serve as trigger for the impacted Head-end LSR to >> take appropriate actions. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-sat > > uration-0 0.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the > body of the message. You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce to change your > subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then "get > draft-leroux-ccamp-ctrl-saturation-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: mailserv at ietf.org. In the body type: "FILE > /internet-drafts/draft-leroux-ccamp-ctrl-saturation-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this feature, > insert the command "ENCODING mime" before the "FILE" command. To > decode the response(s), you will need "munpack" or a MIME-compliant > mail reader. Different MIME-compliant mail readers exhibit different > behavior, especially when dealing with "multipart" MIME messages > (i.e. documents which have been split up into multiple messages), so > check your local documentation on how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > 0.txt> > 0.txt> > > > > > . > From owner-ccamp@ops.ietf.org Sun Mar 6 23:04:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02699 for ; Sun, 6 Mar 2005 23:04:55 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D89WP-00073b-4N for ccamp-archive@ietf.org; Sun, 06 Mar 2005 23:07:10 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D84hK-000HGQ-2Y for ccamp-data@psg.com; Sun, 06 Mar 2005 22:58:06 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D84hH-000HG2-L0 for ccamp@ops.ietf.org; Sun, 06 Mar 2005 22:58:03 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 06 Mar 2005 14:58:00 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j26MvrZV021452; Sun, 6 Mar 2005 14:57:54 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-1-153.cisco.com [10.86.240.153]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA13737; Sun, 6 Mar 2005 14:57:51 -0800 (PST) In-Reply-To: <422B7697.9010600@psg.com> References: <422B7697.9010600@psg.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <606d83edd8741dc6ef3e2b32627907ac@cisco.com> Content-Transfer-Encoding: quoted-printable Cc: adrian@olddog.co.uk, LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org From: JP Vasseur Subject: Re: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt Date: Sun, 6 Mar 2005 17:58:07 -0500 To: dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: quoted-printable Hi Dimitri, On Mar 6, 2005, at 4:31 PM, dimitri papadimitriou wrote: > hi jean-louis > > the below discussion raises the issue that the decoupling of the =20 > control from the (data plane) resource admission control (driven by =20= > the Min/Max LSP bandwidith) raises the issue of the control plane =20 > saturation due to LSPs that do not reserve any bandwith/or allow for =20= > bandwidth reuse such low priority LSPs and therefore the #LSPs =20 > actually processed by the control plane can become much higher than =20= > the number of LSPs that could result from the Min LSP bandwidth =20 > parameter - this is a nice side effect of part of bunch of other =20 > control plane processing issues such prioritized treatment of control =20= > messages, concurrent requests, etc. > > i think the problem statement is rather scoped, however the solution =20= > scope seems to me to be raising correlation issue and further =20 > relationship with the data plane resource re-optimization issues we =20= > were discussing on this list a couple of times - i could sum'up this =20= > in one sentence is it suitable to flood the state of the signaling =20 > control engine using flooding or is the intention to consider this as =20= > an additional constraint - note that in the former case flooding =20 > provides you a notification mechanism after occurrence but does not =20= > deliver any avoidance mechanism - > it provides a notification mechanism that a head-end should consider as =20= a constraint. > this said is that really a "router capability" or do you mean here the = =20 > capability to provide "control plane saturation tracking" ? > the later. > therefore, it would be probably advisable to be a bit less expeditive =20= > in terms of solution > "expeditive" ? Thanks. JP. > thanks, > - dimitri. > > LE ROUX Jean-Louis RD-CORE-LAN wrote: > >> Hi Adrian, >> Thanks a lot for these comments >> Please see inline >> Regards >> JL >>> -----Message d'origine----- De : Adrian Farrel >>> [mailto:adrian@olddog.co.uk] Envoy=E9 : mardi 1 f=E9vrier 2005 19:41 = =C0 >>> : LE ROUX Jean-Louis RD-CORE-LAN Cc : ccamp@ops.ietf.org Objet : >>> Re: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt >>> Jean-Louis, >>> Thanks for this draft. >>> A couple of immediate thoughts. >>> 1. What is wrong with using Error Code 23? >> Error code 23 is used for "System Errors". IMHO the saturation >> semantic defined here is quite different. >>> 2. Will implementations really want to confess to the reason that >>> they are unable to handle more LSPs? It seems to me that it would >>> be a remarkably honest implementation that implemented this draft. >> Bascially the draft proposes to handle properly control plane >> saturation cases. If you want to handle these cases you need a >> dedicated error code, this would allow Head-end LSRs to take >> appropriate actions. >>> Isn't it more likely that the LSR would claim an admission control >>> error? 3. >> Saturation is not and admission control problem >>> "The head-end should not reroute already established LSPs passing >>> through the saturated node." Why ever not? Surely this is local =20 >>> policy, and the ingress may know that the only way to route its new >>> and projected LSPs is to move some of the existing ones. >> Stability is better, the LSR is already supporting a set of TE-LSPs, >> it is saturated, why would you want to move these LSPs? >> 4. Why is saturation a good thing to advertise in the >>> IGP? If an LSR wishes to prevent new LSPs being routed through it, >>> it should withdraw bandwidth just as it would if the signaling >>> elements of the control plane had failed. 5. >> But what about 0 bandwidth LSPs? A head-end may select a node with 0 >> bandwidth available, when computing the path of a 0 bandwidth LSP. So >> withdrawing bandwidth is not sufficient to handle properly control >> plane saturations >>> Much of the draft restates default behavior (e.g. what to do when >>> you receive a Path message). This is interesting information for the = =20 >>> reader, but I am not sure that it is right to present it here. >> Agree >> 6. Why does the new Error Codes have three Error Values, >>> but the Saturation TLV only have one bit defined? >> Good point, we need to define 3 flags >>> 7. Section 5.2. All "MUST" should be "SHOULD" I think. >> Why? This is IMHO a mandatory behavior for an implementation >> compliant with this draft. >>> My main question is why you need this draft. It seems that you can >>> already achieve all of these features using existing protocol >>> elements. >> I think that this would be cleaner with these light signaling and >> routing extensions. >>> At most you might want to write a one page BCP to say what a >>> transit or egress LSP should do when it cannot handle a new LSP >>> because of some internal resource shortage other than an admission >>> control problem. >> But the problem is that we consider that when a transit or egress LSR >> cannot handle a new LSP because of some internal resource shortage >> other than an admission control problem, it should notify the head >> end about its saturation, and if you want proper reaction you need a >> specific notification...thus dedicated error code points are required >> Again thanks a lot for these comments >> Regards >> JL >>> Cheers, Adrian >>> ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN" >>> To: Sent: = =20 >>> Tuesday, February 01, 2005 7:21 AM Subject: TR: I-D >>> ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt >>> Hi all, >>> We just posted a new draft related to (G)MPLS-TE control plane =20 >>> resource shortages. Your comments/feedbacks on this draft are >>> welcome. >>> Regards, >>> JL >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> Title : Procedure to handle (G)MPLS-TE control plane saturation =20 >>> Author(s) : J. Le Roux, et al. Filename : >>> draft-leroux-ccamp-ctrl-saturation-00.txt Pages : 10 Date : >>> 2005-1-31 >>> This document defines extensions to RSVP-TE (Resource Reservation =20= >>> Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to >>> signal control plane resources saturation, when an LSR runs out of >>> control plane resources available to support a new LSP. Such =20 >>> notification may serve as trigger for the impacted Head-end LSR to =20= >>> take appropriate actions. >>> A URL for this Internet-Draft is: =20 >>> http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-sat >> uration-0 0.txt >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request at ietf.org with the word unsubscribe in the >> body of the message. You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your >> subscription settings. >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then "get >> draft-leroux-ccamp-ctrl-saturation-00.txt". >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> Internet-Drafts can also be obtained by e-mail. >> Send a message to: mailserv at ietf.org. In the body type: "FILE >> /internet-drafts/draft-leroux-ccamp-ctrl-saturation-00.txt". >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this feature, >> insert the command "ENCODING mime" before the "FILE" command. To >> decode the response(s), you will need "munpack" or a MIME-compliant >> mail reader. Different MIME-compliant mail readers exhibit different >> behavior, especially when dealing with "multipart" MIME messages >> (i.e. documents which have been split up into multiple messages), so >> check your local documentation on how to manipulate these messages. >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > saturation-0 >> 0.txt> >> > saturation-0 >> 0.txt> >> . > From owner-ccamp@ops.ietf.org Mon Mar 7 00:01:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08893 for ; Mon, 7 Mar 2005 00:01:51 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8APP-0000Au-PZ for ccamp-archive@ietf.org; Mon, 07 Mar 2005 00:04:06 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8AGN-00065c-3r for ccamp-data@psg.com; Mon, 07 Mar 2005 04:54:39 +0000 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8AGM-00063j-2B for ccamp@ops.ietf.org; Mon, 07 Mar 2005 04:54:38 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 234ABE00005C; Mon, 7 Mar 2005 01:25:57 +0000 (GMT) Received: from Puppy ([130.129.133.164] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Mar 2005 01:25:38 +0000 Message-ID: <006801c522b4$c7517830$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Kireeti Kompella" , "Tomonori TAKEDA" , Cc: "Igor Bryskin" , References: <5.1.1.9.2.20050223211659.05f66e28@imf.m.ecl.ntt.co.jp> <20050227160327.D51887@kummer.juniper.net> Subject: Re: What is happenning to CCAMP WG recharter ? Date: Sun, 6 Mar 2005 18:34:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 07 Mar 2005 01:25:38.0898 (UTC) FILETIME=[9201DB20:01C522B4] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Alex has been press-ganged into coming to the CCAMP meeting. He will be able to explain where we stand and what the next steps are. Thanks for pursuing this. Adrian ----- Original Message ----- From: "Kireeti Kompella" To: "Tomonori TAKEDA" Cc: "Igor Bryskin" ; ; Sent: Monday, February 28, 2005 12:04 AM Subject: Re: What is happenning to CCAMP WG recharter ? > On Wed, 23 Feb 2005, Tomonori TAKEDA wrote: > > > The same question arises to me. I thought we had good amount of discussion > > about new charter items. Is there any open issue? > > It's on the ADs' plate. > > Alex? Bill? > > Kireeti. > ------- > > From owner-ccamp@ops.ietf.org Mon Mar 7 16:00:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03337 for ; Mon, 7 Mar 2005 16:00:56 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8PNk-0006YL-E7 for ccamp-archive@ietf.org; Mon, 07 Mar 2005 16:03:19 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8PEa-000KqY-Lv for ccamp-data@psg.com; Mon, 07 Mar 2005 20:53:48 +0000 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8PEY-000Kpv-DA for ccamp@ops.ietf.org; Mon, 07 Mar 2005 20:53:46 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 32E0AE00023D for ; Mon, 7 Mar 2005 20:53:36 +0000 (GMT) Received: from Puppy ([130.129.133.164] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Mar 2005 20:52:14 +0000 Message-ID: <016101c52357$c29c0960$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: CCAMP Draft status page Date: Mon, 7 Mar 2005 20:50:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 07 Mar 2005 20:52:15.0602 (UTC) FILETIME=[8B4B4520:01C52357] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Hi, I have had a go at updating this. http://www.olddog.co.uk/ccamp.htm If there are errors please shout, but not until after this week because I will simply not find your message in all the rest of the noise! Thanks, Adrian From owner-ccamp@ops.ietf.org Mon Mar 7 20:13:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03045 for ; Mon, 7 Mar 2005 20:13:46 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8TKV-0005by-P1 for ccamp-archive@ietf.org; Mon, 07 Mar 2005 20:16:12 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8T59-000Crm-Jw for ccamp-data@psg.com; Tue, 08 Mar 2005 01:00:19 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8T54-000Cqw-Le for ccamp@ops.ietf.org; Tue, 08 Mar 2005 01:00:15 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 01:59:57 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 8 Mar 2005 01:59:29 +0100 Message-ID: Thread-Topic: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt Thread-Index: AcUik9dvC+GJY5kCSi+DcYbYzFCuDwA5G+Lg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , Cc: , X-OriginalArrivalTime: 08 Mar 2005 00:59:57.0482 (UTC) FILETIME=[25AA30A0:01C5237A] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Content-Transfer-Encoding: quoted-printable Hi dimitri Thanks for these comments Please see inline Regards JL >-----Message d'origine----- >De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 >Envoy=E9 : dimanche 6 mars 2005 22:31 >=C0 : LE ROUX Jean-Louis RD-CORE-LAN >Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org >Objet : Re: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt > > >hi jean-louis > >the below discussion raises the issue that the decoupling of=20 >the control=20 >from the (data plane) resource admission control (driven by=20 >the Min/Max=20 >LSP bandwidith) raises the issue of the control plane=20 >saturation due to=20 >LSPs that do not reserve any bandwith/or allow for bandwidth=20 >reuse such=20 >low priority LSPs and therefore the #LSPs actually processed by the=20 >control plane can become much higher than the number of LSPs=20 >that could=20 >result from the Min LSP bandwidth parameter - this is a nice=20 >side effect=20 >of part of bunch of other control plane processing issues such=20 >prioritized treatment of control messages, concurrent requests, etc. > >i think the problem statement is rather scoped, however the solution=20 >scope seems to me to be raising correlation issue and further=20 >relationship with the data plane resource re-optimization=20 >issues we were=20 >discussing on this list a couple of times - i could sum'up this in one=20 >sentence is it suitable to flood the state of the signaling control=20 >engine using flooding or is the intention to consider this as an=20 >additional constraint -=20 Yes, in a way, this can be seen as an additional constraint. A head-end should avoid a saturated LSR when computing a path of a new = LSP. >note that in the former case flooding provides=20 >you a notification mechanism after occurrence but does not deliver any=20 >avoidance mechanism - Yes it does.=20 An LSR could anticipate the saturation, by setting the Saturation bit = once a threshold is reached. This is a local decision. > >this said is that really a "router capability" or do you mean here the=20 >capability to provide "control plane saturation tracking" ? No this is not a router capability, this is a control plane status. > >therefore, it would be probably advisable to be a bit less=20 >expeditive in=20 >terms of solution This a light and simple solution that IMHO solves the problem... Thanks JL > >thanks, >- dimitri. > >LE ROUX Jean-Louis RD-CORE-LAN wrote: > >> Hi Adrian, >>=20 >> Thanks a lot for these comments >>=20 >> Please see inline >>=20 >> Regards >>=20 >> JL >>=20 >>=20 >>=20 >>=20 >>> -----Message d'origine----- De : Adrian Farrel=20 >>> [mailto:adrian@olddog.co.uk] Envoy=E9 : mardi 1 f=E9vrier 2005 19:41 = =C0 >>> : LE ROUX Jean-Louis RD-CORE-LAN Cc : ccamp@ops.ietf.org Objet : >>> Re: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt >>>=20 >>>=20 >>> Jean-Louis, >>>=20 >>> Thanks for this draft. >>>=20 >>> A couple of immediate thoughts. >>>=20 >>> 1. What is wrong with using Error Code 23? >>=20 >>=20 >> Error code 23 is used for "System Errors". IMHO the saturation=20 >> semantic defined here is quite different. >>=20 >>=20 >>=20 >>> 2. Will implementations really want to confess to the reason that=20 >>> they are unable to handle more LSPs? It seems to me that it=20 >would be=20 >>> a remarkably honest implementation that implemented this draft. >>>=20 >>=20 >>=20 >> Bascially the draft proposes to handle properly control plane=20 >> saturation cases. If you want to handle these cases you need a=20 >> dedicated error code, this would allow Head-end LSRs to take=20 >> appropriate actions. >>=20 >>=20 >>> Isn't it more likely that the LSR would claim an admission control=20 >>> error? 3. >>=20 >>=20 >> Saturation is not and admission control problem >>=20 >>=20 >>> "The head-end should not reroute already established LSPs passing=20 >>> through the saturated node." Why ever not? Surely this is local=20 >>> policy, and the ingress may know that the only way to route its new=20 >>> and projected LSPs is to move some of the existing ones. >>=20 >>=20 >> Stability is better, the LSR is already supporting a set of TE-LSPs,=20 >> it is saturated, why would you want to move these LSPs? >>=20 >> 4. Why is saturation a good thing to advertise in the >>=20 >>> IGP? If an LSR wishes to prevent new LSPs being routed=20 >through it, it=20 >>> should withdraw bandwidth just as it would if the signaling=20 >elements=20 >>> of the control plane had failed. 5. >>=20 >>=20 >> But what about 0 bandwidth LSPs? A head-end may select a node with 0=20 >> bandwidth available, when computing the path of a 0=20 >bandwidth LSP. So=20 >> withdrawing bandwidth is not sufficient to handle properly control=20 >> plane saturations >>=20 >>=20 >>=20 >>> Much of the draft restates default behavior (e.g. what to=20 >do when you=20 >>> receive a Path message). This is interesting information for the=20 >>> reader, but I am not sure that it is right to present it here. >>>=20 >>=20 >>=20 >> Agree >>=20 >> 6. Why does the new Error Codes have three Error Values, >>=20 >>> but the Saturation TLV only have one bit defined? >>=20 >>=20 >> Good point, we need to define 3 flags >>=20 >>=20 >>> 7. Section 5.2. All "MUST" should be "SHOULD" I think. >>=20 >>=20 >> Why? This is IMHO a mandatory behavior for an implementation=20 >compliant=20 >> with this draft. >>=20 >>=20 >>> My main question is why you need this draft. It seems that you can=20 >>> already achieve all of these features using existing protocol=20 >>> elements. >>=20 >>=20 >> I think that this would be cleaner with these light signaling and=20 >> routing extensions. >>=20 >>=20 >>> At most you might want to write a one page BCP to say what=20 >a transit=20 >>> or egress LSP should do when it cannot handle a new LSP because of=20 >>> some internal resource shortage other than an admission control=20 >>> problem. >>=20 >>=20 >> But the problem is that we consider that when a transit or=20 >egress LSR=20 >> cannot handle a new LSP because of some internal resource shortage=20 >> other than an admission control problem, it should notify=20 >the head end=20 >> about its saturation, and if you want proper reaction you need a=20 >> specific notification...thus dedicated error code points are required >>=20 >>=20 >> Again thanks a lot for these comments >>=20 >> Regards >>=20 >> JL >>=20 >>=20 >>=20 >>> Cheers, Adrian >>>=20 >>>=20 >>> ----- Original Message ----- From: "LE ROUX Jean-Louis=20 >RD-CORE-LAN" =20 >>> To: >>> Sent: Tuesday, February 01, 2005 7:21 AM Subject: TR: I-D=20 >>> ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt >>>=20 >>>=20 >>> Hi all, >>>=20 >>> We just posted a new draft related to (G)MPLS-TE control plane >>> resource shortages. Your comments/feedbacks on this draft are >>> welcome. >>>=20 >>> Regards, >>>=20 >>> JL >>>=20 >>>=20 >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>> directories. >>>=20 >>>=20 >>> Title : Procedure to handle (G)MPLS-TE control plane saturation >>> Author(s) : J. Le Roux, et al. Filename : >>> draft-leroux-ccamp-ctrl-saturation-00.txt Pages : 10 Date : >>> 2005-1-31 >>>=20 >>> This document defines extensions to RSVP-TE (Resource Reservation >>> Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to >>> signal control plane resources saturation, when an LSR runs out of >>> control plane resources available to support a new LSP. Such=20 >>> notification may serve as trigger for the impacted Head-end LSR to=20 >>> take appropriate actions. >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-sat >>=20 >> uration-0 0.txt >>=20 >> To remove yourself from the I-D Announcement list, send a message to=20 >> i-d-announce-request at ietf.org with the word unsubscribe=20 >in the body=20 >> of the message. You can also visit=20 >> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your=20 >> subscription settings. >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP. Login with the=20 >> username "anonymous" and a password of your e-mail address. After=20 >> logging in, type "cd internet-drafts" and then "get=20 >> draft-leroux-ccamp-ctrl-saturation-00.txt". >>=20 >> A list of Internet-Drafts directories can be found in=20 >> http://www.ietf.org/shadow.html or=20 >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >>=20 >> Internet-Drafts can also be obtained by e-mail. >>=20 >> Send a message to: mailserv at ietf.org. In the body type: "FILE=20 >> /internet-drafts/draft-leroux-ccamp-ctrl-saturation-00.txt". >>=20 >> NOTE: The mail server at ietf.org can return the document in=20 >> MIME-encoded form by using the "mpack" utility. To use this=20 >feature,=20 >> insert the command "ENCODING mime" before the "FILE" command. To=20 >> decode the response(s), you will need "munpack" or a MIME-compliant=20 >> mail reader. Different MIME-compliant mail readers exhibit=20 >different=20 >> behavior, especially when dealing with "multipart" MIME=20 >messages (i.e.=20 >> documents which have been split up into multiple messages), so check=20 >> your local documentation on how to manipulate these messages. >>=20 >>=20 >> Below is the data which will enable a MIME compliant mail reader=20 >> implementation to automatically retrieve the ASCII version of the=20 >> Internet-Draft.=20 >>=20 >> -0 >> 0.txt> >>=20 > 0.txt> >=20 >=20 >=20 >=20 > . >=20 From owner-ccamp@ops.ietf.org Tue Mar 8 03:53:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29499 for ; Tue, 8 Mar 2005 03:53:35 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8aVX-0006oq-Di for ccamp-archive@ietf.org; Tue, 08 Mar 2005 03:56:03 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8aKK-000BzU-QC for ccamp-data@psg.com; Tue, 08 Mar 2005 08:44:28 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8aKI-000BzB-KG for ccamp@ops.ietf.org; Tue, 08 Mar 2005 08:44:26 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 8AE31E000296 for ; Tue, 8 Mar 2005 08:44:15 +0000 (GMT) Received: from Puppy ([130.129.67.16] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 08:30:36 +0000 Message-ID: <012c01c523b9$517e70d0$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Agenda and slides on line Date: Tue, 8 Mar 2005 08:31:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 08 Mar 2005 08:30:36.0412 (UTC) FILETIME=[1A1F7BC0:01C523B9] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Agenda and slides on line at http://www.olddog.co.uk/62/ccamp.htm All there except... Status and plans for CCAMP re-charter Alex Zinin. No slides received. draft-vasseur-ccamp-automesh-00.txt JP Vasseur. Slides received but corrupt draft-ietf-ccamp-rsvp-restart-ext-01.txt Arun Satyanarayana. No slides received draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt Dimitri Papdimitriou. No slides received Presenters listed above must use their own laptops. Cheers, Adrian From owner-ccamp@ops.ietf.org Tue Mar 8 05:40:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08997 for ; Tue, 8 Mar 2005 05:40:35 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8cB7-0000my-0O for ccamp-archive@ietf.org; Tue, 08 Mar 2005 05:43:05 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8c2L-000NoJ-94 for ccamp-data@psg.com; Tue, 08 Mar 2005 10:34:01 +0000 Received: from [217.32.164.139] (helo=smtp5.smtp.bt.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8c2H-000No1-8Z for ccamp@ops.ietf.org; Tue, 08 Mar 2005 10:33:57 +0000 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 8 Mar 2005 10:33:54 +0000 Received: from i2km11-ukbr.domain1.systemhost.net ([193.113.197.28]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Mar 2005 10:33:54 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Date: Tue, 8 Mar 2005 10:33:54 -0000 Message-ID: Thread-Topic: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Thread-Index: AcUjylMWrzJFN4+1Edm5TAAwBQ7M6w== From: To: X-OriginalArrivalTime: 08 Mar 2005 10:33:54.0290 (UTC) FILETIME=[539A1520:01C523CA] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Colleagues, I am trying to understand section 7.4 (Separation of Control and Data = Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better. The draft states: "PSC-capable nodes implementing an OOB control plane (perhaps to = communicate with an optical switch) MUST NOT use the OOB control plane = for data traffic. For example, in the case of MPLS service running on = top of a GMPLS LSP, if the peer PSC device is reachable via both the = control plane and the data plane, control protocols such as LDP MUST NOT = form adjacencies over the control plane interfaces. This may be = provided by a combination of implementation features and deployment = guidelines." So, if the control plane is OOB why must control protocols (such as LDP) = NOT form adjacencies over the control plane interfaces? This implies = that LDP (for e.g.) MUST form its adjacencies over the data plane = interfaces and therefore LDP is not running OOB (and therefore the = control plane is not entirely OOB). Thanks Ben --=20 Ben Niven-Jenkins Networking Specialist, BT Exact e-mail: benjamin.niven-jenkins@bt.com tel: +44(0) 1473 648225 mob: +44(0) 7918 077205 pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, = UK BT Exact is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British = Telecommunications which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or the = entity named above. If you are not the intended recipient be aware that = any disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately.=20 Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. From owner-ccamp@ops.ietf.org Tue Mar 8 08:08:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20973 for ; Tue, 8 Mar 2005 08:08:14 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8eU0-0003y5-I0 for ccamp-archive@ietf.org; Tue, 08 Mar 2005 08:10:45 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8eIL-000EAd-WC for ccamp-data@psg.com; Tue, 08 Mar 2005 12:58:42 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8eII-000EA7-IR for ccamp@ops.ietf.org; Tue, 08 Mar 2005 12:58:38 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 08 Mar 2005 07:58:38 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (shaqzilla.cisco.com [161.44.70.33]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j28CwY1j015095; Tue, 8 Mar 2005 07:58:35 -0500 (EST) Received: from shaqzilla.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j28CwYKe032217; Tue, 8 Mar 2005 07:58:34 -0500 Received: (from ashokn@localhost) by shaqzilla.cisco.com (8.12.11/8.12.11/Submit) id j28CwY2t032215; Tue, 8 Mar 2005 07:58:34 -0500 Date: Tue, 8 Mar 2005 07:58:33 -0500 From: Ashok Narayanan To: benjamin.niven-jenkins@bt.com Cc: ccamp@ops.ietf.org Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Message-ID: <20050308125833.GA32112@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 > > I am trying to understand section 7.4 (Separation of Control and Data Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > > The draft states: > "PSC-capable nodes implementing an OOB control plane (perhaps to > communicate with an optical switch) MUST NOT use the OOB control > plane for data traffic. For example, in the case of MPLS service > running on top of a GMPLS LSP, if the peer PSC device is reachable > via both the control plane and the data plane, control protocols > such as LDP MUST NOT form adjacencies over the control plane > interfaces. This may be provided by a combination of implementation > features and deployment guidelines." > > So, if the control plane is OOB why must control protocols (such as > LDP) NOT form adjacencies over the control plane interfaces? This > implies that LDP (for e.g.) MUST form its adjacencies over the data > plane interfaces and therefore LDP is not running OOB (and therefore > the control plane is not entirely OOB). > That's an interesting question. The draft focuses on GMPLS/TE deployments and the use of an out-of-band control channel as a matter of necessity (i.e. because optical switches are not capable of handling in-band control traffic). Consider the general deployment of a core of optical switches surrounded by GMPLS/TE routers at the edge. From the perspective of this network (optical switches, edge routers, and the links in between), that statement translates to: _ The GMPLS/TE control plane between the edge routers and the optical switches in the core is entirely out-of-band - All other protocols between the edge routers MUST be entirely in-band. The control plane network may well be a series of point-to-point GRE tunnels overlaid on some other low-bandwidth network (actually this is what the draft recommends). Ordinarily one would establish a GRE tunnel between each pair of neighbors so they can talk to each other. But this means that signalling messages going from edge router to edge router actually have to be routed through the control planes of intermediate switches. The two alternatives to avoid this (to create a full mesh of GRE tunnels - at least between all the edge routers - or to not use GRE at all if the control plane is switched Ethernet, and therefore to essentially permit a full mesh of OSPF peers) are not really palatable (and in the case of SDCC, not usable). The optical switches in the core should not be in the business of routing packets. Sometimes they have to (e.g. Notify messages), but they are not designed for this purpose and should not be deployed as such. And practically speaking the control network is expected to be a low-bandwidth network that can "just get the job done". A single 10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle the control traffic for a GMPLS/TE network, but will probably fail if we want to use it to peer LDP or BGP for 10,000 prefixes/labels between the edge routers. The best current practice is therefore to use the low-bandwidth control network between routers and switches for GMPLS/TE signaling (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical TE LSPs signalled between edge routers to do other L3 protocols between them. The issue of a separated control plane between PSC edge routers for different L3 protocols for administrative reasons is an interesting one. Nothing precludes you from creating multiple parallel LSPs between edge routers and using one of them to carry control traffic between the two edge routers on behalf of all the others; that would still satisfy this requirement. Alternatively, one could engineer a more beefy control plane network so that it can in fact carry all the control plane traffic (BGP, LDP etc.) but that is not the BCP today based on available implementations. -Ashok On Tue, Mar 08, 2005 at 10:33:54AM -0000, benjamin.niven-jenkins@bt.com wrote: > Colleagues, > > I am trying to understand section 7.4 (Separation of Control and Data Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > > The draft states: > "PSC-capable nodes implementing an OOB control plane (perhaps to communicate with an optical switch) MUST NOT use the OOB control plane for data traffic. For example, in the case of MPLS service running on top of a GMPLS LSP, if the peer PSC device is reachable via both the control plane and the data plane, control protocols such as LDP MUST NOT form adjacencies over the control plane interfaces. This may be provided by a combination of implementation features and deployment guidelines." > > So, if the control plane is OOB why must control protocols (such as LDP) NOT form adjacencies over the control plane interfaces? This implies that LDP (for e.g.) MUST form its adjacencies over the data plane interfaces and therefore LDP is not running OOB (and therefore the control plane is not entirely OOB). > > Thanks > Ben > > > -- > Ben Niven-Jenkins > Networking Specialist, BT Exact > > e-mail: benjamin.niven-jenkins@bt.com > tel: +44(0) 1473 648225 > mob: +44(0) 7918 077205 > > pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, UK > > BT Exact is a trademark of British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > > This electronic message contains information from British Telecommunications which may be privileged or confidential. The information is intended to be for the use of the individual(s) or the entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. > > Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. -- --- Asok the Intern ---------------------------------------- Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) From owner-ccamp@ops.ietf.org Tue Mar 8 08:19:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21755 for ; Tue, 8 Mar 2005 08:19:33 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8eex-0004Bu-Hk for ccamp-archive@ietf.org; Tue, 08 Mar 2005 08:22:04 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8eXP-000GUt-9D for ccamp-data@psg.com; Tue, 08 Mar 2005 13:14:15 +0000 Received: from [217.32.164.150] (helo=smtp2.smtp.bt.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8eXK-000GUA-Dy for ccamp@ops.ietf.org; Tue, 08 Mar 2005 13:14:12 +0000 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 8 Mar 2005 13:14:08 +0000 Received: from i2km11-ukbr.domain1.systemhost.net ([193.113.197.28]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Mar 2005 13:14:08 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Date: Tue, 8 Mar 2005 13:14:08 -0000 Message-ID: Thread-Topic: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Thread-Index: AcUj3pQ6K1Bv7p0MQvGsa0GkGiUFAgAAPyaw From: To: X-OriginalArrivalTime: 08 Mar 2005 13:14:08.0702 (UTC) FILETIME=[B63CEDE0:01C523E0] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: quoted-printable Ashok, Thanks for the explanation. If I understand correctly what you are = saying is that the best current practice is to use an OOB control plane = for the non-PSC layer networks and an in-band control plane for the PSC = layer networks. So one must avoid using the control plane network (of a = non-PSC layer network) for the transfer of data (or control) plane = packets from the PSC layer network's control & data planes. Fine, I = agree that is the BCP, but I don't believe the current draft articulates = that intent very well and section 7.4 probably needs expanding (IMO one = or two paragraphs is probably not enough to discuss/address/detail OOB = Vs in-band properly and unambiguously), for example it is not IMO clear = from the current text that you are talking about 2 separate control = plane networks - one OOB (for non-PSC layer networks/nodes) and one = inband (for PSC layer networks/nodes). Thanks Ben > -----Original Message----- > From: Ashok Narayanan [mailto:ashokn@cisco.com] > Sent: 08 March 2005 12:59 > To: Niven-jenkins,B,Ben,XDE73 R > Cc: ccamp@ops.ietf.org > Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt >=20 >=20 > >=20 > > I am trying to understand section 7.4 (Separation of=20 > Control and Data Plane Traffic) of=20 > draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > >=20 > > The draft states: > > "PSC-capable nodes implementing an OOB control plane (perhaps to > > communicate with an optical switch) MUST NOT use the OOB control > > plane for data traffic. For example, in the case of MPLS service > > running on top of a GMPLS LSP, if the peer PSC device is reachable > > via both the control plane and the data plane, control protocols > > such as LDP MUST NOT form adjacencies over the control plane > > interfaces. This may be provided by a combination of implementation > > features and deployment guidelines." > >=20 > > So, if the control plane is OOB why must control protocols (such as > > LDP) NOT form adjacencies over the control plane interfaces? This > > implies that LDP (for e.g.) MUST form its adjacencies over the data > > plane interfaces and therefore LDP is not running OOB (and therefore > > the control plane is not entirely OOB). > >=20 >=20 > That's an interesting question. The draft focuses on GMPLS/TE > deployments and the use of an out-of-band control channel as a matter > of necessity (i.e. because optical switches are not capable of > handling in-band control traffic). Consider the general deployment of > a core of optical switches surrounded by GMPLS/TE routers at the > edge. From the perspective of this network (optical switches, edge > routers, and the links in between), that statement translates to: >=20 > _ The GMPLS/TE control plane between the edge routers and the optical > switches in the core is entirely out-of-band >=20 > - All other protocols between the edge routers MUST be=20 > entirely in-band. >=20 > The control plane network may well be a series of point-to-point GRE > tunnels overlaid on some other low-bandwidth network (actually this is > what the draft recommends). Ordinarily one would establish a GRE > tunnel between each pair of neighbors so they can talk to each other. > But this means that signalling messages going from edge router to edge > router actually have to be routed through the control planes of > intermediate switches. The two alternatives to avoid this (to create a > full mesh of GRE tunnels - at least between all the edge routers - or > to not use GRE at all if the control plane is switched Ethernet, and > therefore to essentially permit a full mesh of OSPF peers) are not > really palatable (and in the case of SDCC, not usable). The optical > switches in the core should not be in the business of routing > packets. Sometimes they have to (e.g. Notify messages), but they are > not designed for this purpose and should not be deployed as such. >=20 > And practically speaking the control network is expected to be a > low-bandwidth network that can "just get the job done". A single > 10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle the > control traffic for a GMPLS/TE network, but will probably fail if we > want to use it to peer LDP or BGP for 10,000 prefixes/labels between > the edge routers. >=20 > The best current practice is therefore to use the low-bandwidth > control network between routers and switches for GMPLS/TE signaling > (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical TE LSPs > signalled between edge routers to do other L3 protocols between them. >=20 > The issue of a separated control plane between PSC edge routers for > different L3 protocols for administrative reasons is an interesting > one. Nothing precludes you from creating multiple parallel LSPs > between edge routers and using one of them to carry control traffic > between the two edge routers on behalf of all the others; that would > still satisfy this requirement. Alternatively, one could engineer a > more beefy control plane network so that it can in fact carry all the > control plane traffic (BGP, LDP etc.) but that is not the BCP today > based on available implementations. >=20 > -Ashok >=20 > On Tue, Mar 08, 2005 at 10:33:54AM -0000,=20 > benjamin.niven-jenkins@bt.com wrote: > > Colleagues, > >=20 > > I am trying to understand section 7.4 (Separation of=20 > Control and Data Plane Traffic) of=20 > draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > >=20 > > The draft states: > > "PSC-capable nodes implementing an OOB control plane=20 > (perhaps to communicate with an optical switch) MUST NOT use=20 > the OOB control plane for data traffic. For example, in the=20 > case of MPLS service running on top of a GMPLS LSP, if the=20 > peer PSC device is reachable via both the control plane and=20 > the data plane, control protocols such as LDP MUST NOT form=20 > adjacencies over the control plane interfaces. This may be=20 > provided by a combination of implementation features and=20 > deployment guidelines." > >=20 > > So, if the control plane is OOB why must control protocols=20 > (such as LDP) NOT form adjacencies over the control plane=20 > interfaces? This implies that LDP (for e.g.) MUST form its=20 > adjacencies over the data plane interfaces and therefore LDP=20 > is not running OOB (and therefore the control plane is not=20 > entirely OOB). > >=20 > > Thanks > > Ben > >=20 > >=20 > > --=20 > > Ben Niven-Jenkins > > Networking Specialist, BT Exact > >=20 > > e-mail: benjamin.niven-jenkins@bt.com > > tel: +44(0) 1473 648225 > > mob: +44(0) 7918 077205 > >=20 > > pp34/161 B81 Callisto House, Adastral Park, Martlesham,=20 > Ipswich IP5 3RE, UK > >=20 > > BT Exact is a trademark of British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ > > Registered in England no. 1800000 > >=20 > > This electronic message contains information from British=20 > Telecommunications which may be privileged or confidential.=20 > The information is intended to be for the use of the=20 > individual(s) or the entity named above. If you are not the=20 > intended recipient be aware that any disclosure, copying,=20 > distribution or use of the contents of this information is=20 > prohibited. If you have received this electronic message in=20 > error, please notify us by telephone or email (to the numbers=20 > or address above) immediately.=20 > >=20 > > Activity and use of the British Telecommunications plc=20 > email system is monitored to secure its effective operation=20 > and for other lawful business purposes. Communications using=20 > this system will also be monitored and may be recorded to=20 > secure effective operation and for other lawful business purposes. >=20 > --=20 >=20 >=20 >=20 > --- Asok the Intern ---------------------------------------- > Ashok Narayanan > IOS Network Protocols, Cisco Systems > 1414 Mass Ave, Boxborough MA 01719 > Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) >=20 From owner-ccamp@ops.ietf.org Tue Mar 8 08:27:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22237 for ; Tue, 8 Mar 2005 08:27:00 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8em8-0004JV-8F for ccamp-archive@ietf.org; Tue, 08 Mar 2005 08:29:30 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8eeO-000HNb-4B for ccamp-data@psg.com; Tue, 08 Mar 2005 13:21:28 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8eeL-000HNL-Rc for ccamp@ops.ietf.org; Tue, 08 Mar 2005 13:21:25 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2005 05:21:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (shaqzilla.cisco.com [161.44.70.33]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j28DLMjI005981; Tue, 8 Mar 2005 08:21:23 -0500 (EST) Received: from shaqzilla.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j28DLMEf032424; Tue, 8 Mar 2005 08:21:22 -0500 Received: (from ashokn@localhost) by shaqzilla.cisco.com (8.12.11/8.12.11/Submit) id j28DLMub032422; Tue, 8 Mar 2005 08:21:22 -0500 Date: Tue, 8 Mar 2005 08:21:22 -0500 From: Ashok Narayanan To: benjamin.niven-jenkins@bt.com Cc: ccamp@ops.ietf.org Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Message-ID: <20050308132122.GB32112@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Ben, Thanks for the comment. We'll try to clarify this in the next version. -Ashok On Tue, Mar 08, 2005 at 01:14:08PM -0000, benjamin.niven-jenkins@bt.com wrote: > Ashok, > > Thanks for the explanation. If I understand correctly what you are saying is that the best current practice is to use an OOB control plane for the non-PSC layer networks and an in-band control plane for the PSC layer networks. So one must avoid using the control plane network (of a non-PSC layer network) for the transfer of data (or control) plane packets from the PSC layer network's control & data planes. Fine, I agree that is the BCP, but I don't believe the current draft articulates that intent very well and section 7.4 probably needs expanding (IMO one or two paragraphs is probably not enough to discuss/address/detail OOB Vs in-band properly and unambiguously), for example it is not IMO clear from the current text that you are talking about 2 separate control plane networks - one OOB (for non-PSC layer networks/nodes) and one inband (for PSC layer networks/nodes). > > Thanks > Ben > > > -----Original Message----- > > From: Ashok Narayanan [mailto:ashokn@cisco.com] > > Sent: 08 March 2005 12:59 > > To: Niven-jenkins,B,Ben,XDE73 R > > Cc: ccamp@ops.ietf.org > > Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt > > > > > > > > > > I am trying to understand section 7.4 (Separation of > > Control and Data Plane Traffic) of > > draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > > > > > > The draft states: > > > "PSC-capable nodes implementing an OOB control plane (perhaps to > > > communicate with an optical switch) MUST NOT use the OOB control > > > plane for data traffic. For example, in the case of MPLS service > > > running on top of a GMPLS LSP, if the peer PSC device is reachable > > > via both the control plane and the data plane, control protocols > > > such as LDP MUST NOT form adjacencies over the control plane > > > interfaces. This may be provided by a combination of implementation > > > features and deployment guidelines." > > > > > > So, if the control plane is OOB why must control protocols (such as > > > LDP) NOT form adjacencies over the control plane interfaces? This > > > implies that LDP (for e.g.) MUST form its adjacencies over the data > > > plane interfaces and therefore LDP is not running OOB (and therefore > > > the control plane is not entirely OOB). > > > > > > > That's an interesting question. The draft focuses on GMPLS/TE > > deployments and the use of an out-of-band control channel as a matter > > of necessity (i.e. because optical switches are not capable of > > handling in-band control traffic). Consider the general deployment of > > a core of optical switches surrounded by GMPLS/TE routers at the > > edge. From the perspective of this network (optical switches, edge > > routers, and the links in between), that statement translates to: > > > > _ The GMPLS/TE control plane between the edge routers and the optical > > switches in the core is entirely out-of-band > > > > - All other protocols between the edge routers MUST be > > entirely in-band. > > > > The control plane network may well be a series of point-to-point GRE > > tunnels overlaid on some other low-bandwidth network (actually this is > > what the draft recommends). Ordinarily one would establish a GRE > > tunnel between each pair of neighbors so they can talk to each other. > > But this means that signalling messages going from edge router to edge > > router actually have to be routed through the control planes of > > intermediate switches. The two alternatives to avoid this (to create a > > full mesh of GRE tunnels - at least between all the edge routers - or > > to not use GRE at all if the control plane is switched Ethernet, and > > therefore to essentially permit a full mesh of OSPF peers) are not > > really palatable (and in the case of SDCC, not usable). The optical > > switches in the core should not be in the business of routing > > packets. Sometimes they have to (e.g. Notify messages), but they are > > not designed for this purpose and should not be deployed as such. > > > > And practically speaking the control network is expected to be a > > low-bandwidth network that can "just get the job done". A single > > 10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle the > > control traffic for a GMPLS/TE network, but will probably fail if we > > want to use it to peer LDP or BGP for 10,000 prefixes/labels between > > the edge routers. > > > > The best current practice is therefore to use the low-bandwidth > > control network between routers and switches for GMPLS/TE signaling > > (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical TE LSPs > > signalled between edge routers to do other L3 protocols between them. > > > > The issue of a separated control plane between PSC edge routers for > > different L3 protocols for administrative reasons is an interesting > > one. Nothing precludes you from creating multiple parallel LSPs > > between edge routers and using one of them to carry control traffic > > between the two edge routers on behalf of all the others; that would > > still satisfy this requirement. Alternatively, one could engineer a > > more beefy control plane network so that it can in fact carry all the > > control plane traffic (BGP, LDP etc.) but that is not the BCP today > > based on available implementations. > > > > -Ashok > > > > On Tue, Mar 08, 2005 at 10:33:54AM -0000, > > benjamin.niven-jenkins@bt.com wrote: > > > Colleagues, > > > > > > I am trying to understand section 7.4 (Separation of > > Control and Data Plane Traffic) of > > draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > > > > > > The draft states: > > > "PSC-capable nodes implementing an OOB control plane > > (perhaps to communicate with an optical switch) MUST NOT use > > the OOB control plane for data traffic. For example, in the > > case of MPLS service running on top of a GMPLS LSP, if the > > peer PSC device is reachable via both the control plane and > > the data plane, control protocols such as LDP MUST NOT form > > adjacencies over the control plane interfaces. This may be > > provided by a combination of implementation features and > > deployment guidelines." > > > > > > So, if the control plane is OOB why must control protocols > > (such as LDP) NOT form adjacencies over the control plane > > interfaces? This implies that LDP (for e.g.) MUST form its > > adjacencies over the data plane interfaces and therefore LDP > > is not running OOB (and therefore the control plane is not > > entirely OOB). > > > > > > Thanks > > > Ben > > > > > > > > > -- > > > Ben Niven-Jenkins > > > Networking Specialist, BT Exact > > > > > > e-mail: benjamin.niven-jenkins@bt.com > > > tel: +44(0) 1473 648225 > > > mob: +44(0) 7918 077205 > > > > > > pp34/161 B81 Callisto House, Adastral Park, Martlesham, > > Ipswich IP5 3RE, UK > > > > > > BT Exact is a trademark of British Telecommunications plc > > > Registered office: 81 Newgate Street London EC1A 7AJ > > > Registered in England no. 1800000 > > > > > > This electronic message contains information from British > > Telecommunications which may be privileged or confidential. > > The information is intended to be for the use of the > > individual(s) or the entity named above. If you are not the > > intended recipient be aware that any disclosure, copying, > > distribution or use of the contents of this information is > > prohibited. If you have received this electronic message in > > error, please notify us by telephone or email (to the numbers > > or address above) immediately. > > > > > > Activity and use of the British Telecommunications plc > > email system is monitored to secure its effective operation > > and for other lawful business purposes. Communications using > > this system will also be monitored and may be recorded to > > secure effective operation and for other lawful business purposes. > > > > -- > > > > > > > > --- Asok the Intern ---------------------------------------- > > Ashok Narayanan > > IOS Network Protocols, Cisco Systems > > 1414 Mass Ave, Boxborough MA 01719 > > Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) > > -- --- Asok the Intern ---------------------------------------- Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) From owner-ccamp@ops.ietf.org Tue Mar 8 08:27:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22273 for ; Tue, 8 Mar 2005 08:27:24 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8emW-0004K0-DI for ccamp-archive@ietf.org; Tue, 08 Mar 2005 08:29:54 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8ecT-000H9K-LT for ccamp-data@psg.com; Tue, 08 Mar 2005 13:19:29 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8ecR-000H91-Iz for ccamp@ops.ietf.org; Tue, 08 Mar 2005 13:19:27 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 08 Mar 2005 05:22:39 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,146,1107763200"; e="0x8004021A'u"; d="ppt'32?scan'32,208,32"; a="165747822:sNHsT77354567228" Subject: [WARNING: A/V UNSCANNABLE] Re: Agenda and slides on line Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j28DIuZV024198; Tue, 8 Mar 2005 05:18:57 -0800 (PST) Received: from [10.84.119.235] (rtp-vpn1-301.cisco.com [10.82.225.45]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA19560; Tue, 8 Mar 2005 05:18:55 -0800 (PST) In-Reply-To: <012c01c523b9$517e70d0$a4858182@Puppy> References: <012c01c523b9$517e70d0$a4858182@Puppy> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/mixed; boundary=Apple-Mail-2-984250060 Message-Id: <2e7a83c89f2b8b8b4c498eb31a1be32c@cisco.com> Cc: From: JP Vasseur Date: Tue, 8 Mar 2005 07:19:12 -0600 To: "Adrian Farrel" X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f5e3f76ec5b90a46b9b8bc53da20ed8e --Apple-Mail-2-984250060 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Mar 8, 2005, at 2:31 AM, Adrian Farrel wrote: > Agenda and slides on line at http://www.olddog.co.uk/62/ccamp.htm > > All there except... > > Status and plans for CCAMP re-charter > Alex Zinin. No slides received. > > draft-vasseur-ccamp-automesh-00.txt > JP Vasseur. Slides received but corrupt > => --Apple-Mail-2-984250060 Content-Type: application/vnd.ms-powerpoint; x-mac-type=534C4438; x-unix-mode=0644; x-mac-creator=50505433; name="IETF-62-draft-vasseur-ccamp-automesh-00.ppt" Content-Disposition: attachment; filename=IETF-62-draft-vasseur-ccamp-automesh-00.ppt Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAPwAAAAAAAAAA EAAAQgAAAAEAAAD+////AAAAAEAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////PQAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAD+/////v///zsAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAA/v///zwAAAA+AAAA/v////7///////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////wBS AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAACAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAAA2tC6nI8UB IwAAAEAGAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAA2D8AAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAABELAAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAFAAAAAAAADwDo Az4kAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAAkE vAEAAAAACgQEAAAAVAAAAA8A1w84AAAAAADTDwQAAAA8AAAAAAC6DyQAAABqAHYAYQBzAHMAZQB1 AHIAQABjAGkAcwBjAG8ALgBjAG8AbQAPANcPTgAAAAAA0w8EAAAAPwAAAAAAug86AAAAeQBhAHMA dQBrAGEAdwBhAC4AcwBlAGkAcwBoAG8AQABsAGEAYgAuAG4AdAB0AC4AYwBvAC4AagBwAA8A1w9Y AAAAAADTDwQAAABEAAAAAAC6D0QAAABqAGUAYQBuAGwAbwB1AGkAcwAuAGwAZQByAG8AdQB4AEAA ZgByAGEAbgBjAGUAdABlAGwAZQBjAG8AbQAuAGMAbwBtAA8A1w80AAAAAADTDwQAAABGAAAAAAC6 DyAAAABwAG0AYQBiAGUAeQBAAHEAdwBlAHMAdAAuAGMAbwBtAA8A1w82AAAAAADTDwQAAABHAAAA AAC6DyIAAABwAHAAcwBlAG4AYQBrAEAAYwBpAHMAYwBvAC4AYwBvAG0ADwDXDzgAAAAAANMPBAAA AEgAAAAAALoPJAAAAHMAcAByAGUAdgBpAGQAaQBAAGMAaQBzAGMAbwAuAGMAbwBtAA8A8gP6AQAA LwDIDwwAAAAwANIPBAAAAAEAAAAPANUHMAEAAAAAtw9EAAAAQQByAGkAYQBsAAAAbgBnAHMAAABv AGQAZQAgAP+/CNz/vzDYAAAQAAkBEEn/vwjc/78w2AEAF7ZAAVxQVpFsIwAABAAQALcPRAAAAEEA cgBpAGEAbAAgAFUAbgBpAGMAbwBkAGUAIABNAFMAAAAw2AAAEAAJARBJ/78I3P+/MNgBABe2QAFc UFaRbCOAAAYiIAC3D0QAAABXAGkAbgBnAGQAaQBuAGcAcwAAAG8AZABlACAATQBTAAAAMNgAABAA CQEQSf+/CNz/vzDYAQAXtkABXFBWkWwjAgAEADAAtw9EAAAAVABpAG0AZQBzAAAAbgBnAHMAAABv AGQAZQAgAE0AUwAAADDYAAAQAAkBEEn/vwjc/78w2AEAF7ZAAVxQVpFsIwAABAAAAKQPCgAAAIAA YAAAAP////8AAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD/ /T8AAAAiIAAAZAAAAAD/AABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA////////EgAAAAAB AAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsE4AAA AA8AAPDYAAAAAAAG8IAAAAACPAAADwAAABUAAAAFAAAAAQAAAAcAAAADAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAFAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAADAAAAAAAAAAEAAAABAAAAAkAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAACAAAABAAAAIMAC/AwAAAAgQEEAAAIgwEAAAAIhkEAAAAA vwEQABAAwAEBAAAIxUEAAAAA/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDw DxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQBxsQAAAfABQEHAAAAAAAFQQUAAAA upOw9gDKmjutB5THAMqaOwEBAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABnAAAAZAAAAGcA AABkAAAAALBuAQAAAAAAAAAAUNj/vwAAAACwDg8BkP7//5D///8BAAAAcAD7AwgAAAAAAAAAcAgA AHAA+wMIAAAAAQAAAEALAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAALDY/78CAAAA AKUGAQAAAABnAAAAAMqaOwAAAAAAAAAAAAEAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAf AAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAALDY/78CAAAAAKUGAQAAAAAUAAAAAMqaOwAA AAAAAAAAAAEAAA8AiBPcDgAADwCKE7gAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTmAAA AA8Asw+QAAAAEACvDwgAAAAAAQAABQAAAAAAsQ8oAAAAAAAABAAAAAAAAAAEAQAAAAAAAAQCAAAA AAAABAMAAAAAAAAEBAAAABAArw8IAAAACQEAAAEAAAAAALEPOAAAAAAAAAQAAAAAAAAABAEAAAAA AAAEAgAAAAAAAAQDAAAAAAAABAQAAAAAAAAEBQAAAAAAAAQGAAAADwCKE6QBAAAAALoPDgAAAF8A XwBfAFAAUABUADkAAACLE4YBAAAPAK4PfgEAABAArw8IAAAAAAEAAAUAAAAAAKwPUAAAAAAAAAAA ABAAAAAAAAAAAAAAAAAAAAAQAAEAAAAAAAAAAAAAAAAAEAACAAAAAAAAAAAAAAAAABAAAwAAAAAA AAAAAAAAAAAQAAQAAAAAAAAAEACvDwgAAAAIAQAAAQAAAAAArA80AAAAAAAAAgAAAAAAAAAAAAAA AAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAArw8IAAAACQEAAAEAAAAAAKwP dAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAQAAEAAAAAAAAAAAAAAAAAEAACAAAAAAAAAAAAAAAA ABAAAwAAAAAAAAAAAAAAAAAQAAQAAAAAAAAAAACAAv//AAAAABAABQAAAAAAAAAAAAAAAAAQAAYA AAAAAAAAEACvDwgAAAADAQAAAQAAAAAArA8mAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAPAIoTaAAAAAAAug8UAAAAXwBfAF8AUABQAFQAMgAwADAAMQAAAIsTRAAAAA8A iBc8AAAAAACJFzQAAAAAAAAAAAAAAAAAAABYAgAAAAEBAAEBAAABAQEAAQAAAAAAAAAI3AAAAAAA AAAAAACAAgHgDwCKE/gLAAAAALoPFgAAAF8AXwBfAFAAUABUAE0AYQBjADEAMQAAAIsT0gsAAEAA GhBmBQAABQAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgA AAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAA AAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEA cgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBn AHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEA AAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAA AAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAA AQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAA AAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgA eQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAA AAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAA AQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEF AAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAA AAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAA AAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAA AAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEB AAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQA AABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAA ACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAAB BwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAg AAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAA AAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAA AAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4A bwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAA AAAAAAAEAAAADgAJABEAAAAaAAEAABwQFAEAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAA AAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAA AQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAA BAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBv AHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAA AAAAAAQAAAAOAAkAEQAAABoAAQ8AGxBABQAAEACvDwgAAAAAAQAABQAAAAAAGRDEAQAAAAAAAAAA AAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAA AAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAAB AAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAA AAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5 AAAAAAEGAAAABAAUAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAAAAAInAAA AAAAAAIAAACcAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAHgAAAAHAAAABAAAAAAAAAEA AAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAA AAEGAAAABAAUAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAQAK8PCAAAAAkB AAABAAAAAAAZEEwDAAAAAAAAAAAAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAA AQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAAB AAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAA AAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBw AGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQA AAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAAB AAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMA AAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAA AAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkA cABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAUAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAA ABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgA AAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAA AQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkA YQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBh AHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAA AAAAPwDZDwwAAAAAANoPBAAAAAAAJQAPAPAP9Q4AAAAA8wMUAAAAAwAAAAAAAAACAAAAAAEAAAAA AAAAAJ8PBAAAAAYAAAAAAKgPsQAAAFJvdXRpbmcgZXh0ZW5zaW9ucyBmb3IgZGlzY292ZXJ5IG9m IE11bHRpcHJvdG9jb2wgKE1QTFMpIExhYmVsIFN3aXRjaCALICAgICAgICAgICAgICAgUm91dGVy IChMU1IpIFRyYWZmaWMgRW5naW5lZXJpbmcgKFRFKSBtZXNoIG1lbWJlcnNoaXAgCwtkcmFmdC12 YXNzZXVyLWNjYW1wLWF1dG9tZXNoLTAwLnR4dAAAoQ86AAAAsgAAAAAAAAAAAIsAAAABAAIAAQAc AAEAAAAABAAAAAQCAAAAAAgCAAAIIAAkAAAAAAwDAAAMAQAYABAAnw8EAAAABQAAAAAAqA9lAQAA SmVhbi1QaGlsaXBwZSBWYXNzZXVyIChqdmFzc2V1ckBjaXNjby5jb20pDSAgICAgICAgICAgICAg ICAgICAgICAgICBKZWFuIExvdWlzIExlIFJvdXggKGplYW5sb3Vpcy5sZXJvdXhAZnJhbmNldGVs ZWNvbS5jb20pDSAgICAgICAgICAgICAgICAgICAgICAgICBQZXRlciBQc2VuYWsgKHBwc2VuYWtA Y2lzY28uY29tKQ0gICAgICAgICAgICAgICAgICAgICAgICAgU3RlZmFubyBQcmV2aWRpIChzcHJl dmlkaUBjaXNjby5jb20pIA0gICAgICAgIFNlaXNobyBZYXN1a2F3YSAoeWFzdWthd2Euc2Vpc2hv QGxhYi5udHQuY28uanApIA0gICAgICAgICAgICAgICAgICAgICAgICAgUGF1bCBNYWJleSAocG1h YmV5QHF3ZXN0LmNvbSkNAAChD3oAAAArAAAAAAAAEAAAUADKAAAAAAAAGAAAAABQADkAAAAAAAAQ AABQADcAAAAAAAAYAAAAAFAAAQAAAAAAABAAAFAAfAAAAAAAAgAUABkAAAAABAIAAAQUACEAAAAA CAIAAAgUAD0AAAAADAIAAAwUAHMAAAAAEAIAABAUAAAAqg86AQAAFwAAAAAAAAASAAAAAAAAAAEA AAAAAAAAGgAAAAEAAAAAABQAAAAAAAAACQAAAAEAAAABAAEAAAAAAAAAFAAAAAEAAAABAAQAAAAA AAAAAQAAAAAAAAAaAAAAAQAAAAAABgAAAAAAAAAHAAAAAQAAAAEAAQAAAAAAAAARAAAAAAAAAAEA AAAAAAAAGgAAAAEAAAAAABEAAAAAAAAAEgAAAAAAAAALAAAAAAAAAAcAAAABAAAAAQAKAAAAAAAA AAgAAAABAAAAAQABAAAAAAAAAAoAAAABAAAAAQABAAAAAAAAAAMAAAABAAAAAQAEAAAAAAAAAAIA AAABAAAAAQABAAAAAAAAABsAAAABAAAAAAAFAAAAAAAAAAYAAAABAAAAAQABAAAAAAAAABAAAAAA AAAAAwAAAAAAAAAPAPIPGAAAAAAA8w8QAAAAAAAAADwAAAAEAAAACAAA8wAA3w8IAAAAFwAAACkA AAAPAPIPGAAAAAAA8w8QAAAAAAAAAEQAAAAEAAAACAAA8wAA3w8IAAAAWAAAAHoAAAAPAPIPGAAA AAAA8w8QAAAAAAAAAEcAAAAEAAAACAAA8wAA3w8IAAAAowAAALQAAAAPAPIPGAAAAAAA8w8QAAAA AAAAAEgAAAAEAAAACAAA8wAA3w8IAAAA4AAAAPIAAAAPAPIPGAAAAAAA8w8QAAAAAAAAAD8AAAAE AAAACAAA8wAA3w8IAAAADgEAACsBAAAPAPIPGAAAAAAA8w8QAAAAAAAAAEYAAAAEAAAACAAA8wAA 3w8IAAAAUwEAAGMBAAAAAPMDFAAAAAsAAAAEAAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACo DwoAAABCYWNrZ3JvdW5kEACfDwQAAAABAAAAAACoD1wBAAANZHJhZnQtdmFzc2V1ci1jY2FtcC1y b3V0ZXItaW5mby0wMC50eHQgKENDQU1QKQ0gICAgIERlc2NyaWJlcyBleHRlbnNpb25zIHRvIE1Q TFMgVHJhZmZpYyBFbmdpbmVlcmluZyByb3V0aW5nIGZvciB0aGUgYWR2ZXJ0aXNlbWVudCBvZiBU cmFmZmljIEVuZ2luZWVyaW5nIFJvdXRlciBJbmZvcm1hdGlvbiBhbmQgY2FwYWJpbGl0aWVzLiBU aGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIGZ1bmN0aW9uYWwgZGVzY3JpcHRpb24gb2YgdGhlc2Ug ZXh0ZW5zaW9ucyB3aGVyZWFzIHByb3RvY29sIHNwZWNpZmljIGZvcm1hdHMgYW5kIG1lY2hhbmlz bXMgYXJlIGRlc2NyaWJlZCBpbiBzZXBhcmF0ZSBkb2N1bWVudHMuIAkAAKEPbgAAAAEAAAABAJMQ AAACAOAAAgBQAC8AAAAAALIQAAADAOAAAgAAAAABUAAtAQAAAAAhEAAAAAAAAAABUAABAAAAAAAC ABIANAAAAAAEggAABAIAFAAmAQAAAAiCAAAIAgAQAAIAAAAADIIAAAwCABQAAACqDxwAAAABAAAA AQAAAAAAWQEAAAAAAAADAAAAAQAAAAAAAADzAxQAAAAPAAAAAAAAAAIAAAAJAQAAAAAAAAAAnw8E AAAAAAAAAAAAqA8WAAAAUXVpY2sgb3ZlcnZpZXcvc3VtbWFyeRAAnw8EAAAAAQAAAAAAqA8cAwAA VGhlcmUgYXJlIG5vdyB0d28gZHJhZnRzOg1kcmFmdC12YXNzZXVyLWNjYW1wLWF1dG8tbWVzaC0w MC50eHQNZHJhZnQtdmFzc2V1ci1jY2FtcC10ZS1ub2RlLWNhcC0wMC50eHQNVGhlIFBDRSBkaXNj b3ZlcnkgYXNwZWN0cyB3aWxsIGJlIGRpc2N1c3NlZCBpbiB0aGUgUENFIFdHDQ1UaGUgc2V0IHVw IG9mIGEgZnVsbCBtZXNoIG9mIE1QTFMgVEUgTFNQcyBhbW9uZyBhIHNldCBvZiBMYWJlbCBTd2l0 Y2ggUm91dGVyIChMU1IpIGlzIGNvbW1vbiBkZXBsb3ltZW50IHNjZW5hcmlvIG9mIE1QTFMgVHJh ZmZpYyBFbmdpbmVlcmluZyBlaXRoZXIgZm9yIGJhbmR3aWR0aCBvcHRpbWl6YXRpb24sIGJhbmR3 aWR0aCBndWFyYW50ZWVzIG9yIGZhc3QgcmVyb3V0aW5nIHdpdGggTVBMUyBGYXN0IFJlcm91dGUu IFN1Y2ggZGVwbG95bWVudCByZXF1aXJlcyB0aGUgY29uZmlndXJhdGlvbiBvZiBwb3RlbnRpYWxs eSBhIGxhcmdlIG51bWJlciBvZiBURSBMU1BzIChvbiB0aGUgb3JkZXIgb2YgdGhlIHNxdWFyZSBv ZiB0aGUgbnVtYmVyIExTUnMpLiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBJR1AgICAgICAgICAg KE9TUEYgYW5kIElTLUlTKSB0cmFmZmljIGVuZ2luZWVyaW5nIGV4dGVuc2lvbnMgc28gYXMgdG8g cHJvdmlkZSBhbiBhdXRvbWF0aWMgZGlzY292ZXJ5IG9mIHRoZSBzZXQgb2YgTFNScyBtZW1iZXJz IG9mIGEgbWVzaCwgbGVhZGluZyB0byBhbiBhdXRvbWF0aWMgbWVjaGFuaXNtIHRvIHNldCB1cCBU RSBMU1AgbWVzaChlcykgKGFsc28gcmVmZXJyZWQgdG8gYXMgYSBURSBtZXNoLWdyb3VwKS4gDQAA oQ+MAAAAGgAAAAAAABAAAFoAhwAAAAEAABAAAFoAewIAAAAAshAAAAMAIiADAAAAAAFaAAEAAAAA AAAQAABaABoAAAAAAAIAGAAlAAAAAAQCAAAEFAAnAAAAAAgCAAAIFAA5AAAAAAwCAAAMFAACAAAA ABACAAAQFAB7AgAAAhQCAAIUGAABAAAAABgCAAAYGAAAAKoPqgAAAGUAAAAAAAAAAQAAAAEAAAAA AIAAAAAAAAAAAQAAAAEAAAAAADoAAAAAAAAAAQAAAAEAAAAAAEMAAAAAAAAAAQAAAAEAAAAAAEIA AAAAAAAAAQAAAAEAAAAAAEIAAAAAAAAAAQAAAAEAAAAAAEQAAAAAAAAAAQAAAAEAAAAAAEwAAAAA AAAAAQAAAAEAAAAAAHIAAAAAAAAAAgAAAAEAAAABACsAAAAAAAAAAADzAxQAAAAIAAAAAAAAAAIA AAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8TAAAAUHJvcG9zZWQgbmV4dCBzdGVwcwAAoQ8UAAAA FAAAAAAAAAAAABQAAAAAAAIAKAAQAJ8PBAAAAAEAAAAAAKAPnAEAAA0ARABlAGYAaQBuAGkAdABl AGwAeQAgAG4AbwB0ACAAYQAgAG4AZQB3ACAASQBEACAAIQANAFAAcgBlAHQAdAB5ACAAcwB0AHIA YQBpAGcAaAB0AGYAbwByAHcAYQByAGQAIABkAHIAYQBmAHQAIAAmICAAbgBvACAAbwB1AHQAcwB0 AGEAbgBkAGkAbgBnACAAaQBzAHMAdQBlAHMAIABhAHMAIABmAGEAcgAgAGEAcwAgAE8AUwBQAEYA LwBJAFMASQBTACAAaQBzACAAYwBvAG4AYwBlAHIAbgBlAGQALAANAEkAbQBwAGwAZQBtAGUAbgB0 AGEAdABpAG8AbgBzACAAZQB4AGkAcwB0AHMALAAgAHQAZQBjAGgAbgBvAGwAbwBnAHkAIABkAGUA cABsAG8AeQBlAGQALgANAE4AbwAgAE0AYQBqAG8AcgAgAHAAbABhAG4AbgBlAGQAIABjAGgAYQBu AGcAZQBzAA0ATQBhAGsAZQAgAGkAdAAgAGEAIABXAEcAIABkAG8AYwB1AG0AZQBuAHQAPwAAAKEP RAAAAAEAAAAAAAAAAAAaAAAAAACyAAAAAwAiIAMAAAAAAbQAAAAAAAAAAAABAAAAAAAAABoAAAAC BAAAAgS0AAAAAAgAAAAIAACqDxIAAAABAAAAAQAAAAAAzgAAAAAAAAAAAOoDAAAAAA8A+APaCQAA AgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAAA9MBgAPAHIAAAAP///wAAAAAAgICAAAAAAAC7 4OMAMzOZAACZmQCZzAAAYADwByAAAAD///8AAAAAAJaWlgAAAAAA+99TAP+ZZgDMMwAAmWYAAGAA 8AcgAAAA////AAAAAACAgIAAAAAAAJnM/wDMzP8AMzPMAK9n/wBgAPAHIAAAAN728QAAAAAAlpaW AAAAAAD///8Ajcb/AABmzAAAqAAAYADwByAAAAD//9kAAAAAAHd3dwAAAAAA///3ADPMzAD/UFAA /5kAAGAA8AcgAAAAAICAAP///wAAWlgA//+ZAABkYgBtb8cAAP//AAD/AABgAPAHIAAAAIAAAAD/ //8AXB8AAN/SkwDMMwAAvnlgAP//mQDTohkAYADwByAAAAAAAJkA////AAAzZgDM//8AM2bMAACw AABmzP8A/+cBAGAA8AcgAAAAAAAAAP///wAzZpkA4+vxAAAzmQBGiksAZsz/APDlAABgAPAHIAAA AGhrXQD///8Ad3d3ANHRywCQkIIAgJ6oAP/MZgDp3LkAYADwByAAAABmZpkA////AD4+XAD///8A YFl7AGZm/wCZzP8A//+ZAGAA8AcgAAAAUj4mAP///wAtIBUA38CNAIx7cACPXy8AzLQAAIyeoAAA AKMPPgAAAAEA//0/AAAAIiAAAGQAAAAA/wEAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP// /////ywAAAAAAwAAEACjD3wAAAAFAP/9PwABACIgAABkAAAAAP8AAGQAFAAAANgAAABAAgAAAAAH AAAA///vAAAAAAD///////8gAAAAAAEAAIAFAAATINQBIAEAAAIAHACABQAAIiDQAkACAAACABgA gAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAAIACjD24AAAAFAP/9PwAAACIgAABkAAAAAP8A AGQAHgAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8MAAAAAAEAAAAFAAAgASABAAAAAAAF AABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEJAAAAAAEAAAAA AAAAAQABCQAAAAABACABAAAAAAIAAQkAAAAAAQBAAgAAAAADAAEJAAAAAAEAYAMAAAAABAABCQAA AAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAFAAAAAAAAAAAAAgAcAAEAAAAA AAAAAgAYAAIAAAAAAAAAAgAUAAMAAAAAAAAAAgASAAQAAAAAAAAAAgASAIAAow8+AAAABQAAAAAA AAAAAAIAGAABAAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAAAAAAAAIAEAAEAAAAAAAAAAIAEAAP AAwEDAUAAA8AAvAEBQAAEAAI8AgAAAAGAAAABgQAAA8AA/CcBAAADwAE8CgAAAABAAnwEAAAAAAA AAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8NIAAAASAArwCAAAAAIEAAAACgAAkwAL 8DYAAAB/AAEABQCAAHBKewmHAAEAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIA AAgAABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAABANQADwAN8FQAAAAAAJ8PBAAA AAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxlAACiDwYAAAAhAAAA AAAAAKoPCgAAACEAAAABAAAAAAAPAATwFgEAABIACvAIAAAAAwQAAAAKAACDAAvwMAAAAH8AAQAF AIAAsE17CYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAA8AMgAWAV Ew8PABHwEAAAAAAAwwsIAAAAAQAAAAIA1AAPAA3wngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xp Y2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZv dXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAA AAQAAACqDwoAAABTAAAAAQAAAAAADwAE8LYAAAASAArwCAAAAAQEAAAACgAAgwAL8DAAAAB/AAEA BQCAAGBUewmBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAF4PIAFg BooQDwAR8BAAAAAAAMMLCAAAAAIAAAAHAdQADwAN8D4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoA AAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAOAAAA+A8EAAAAAAAAAA8ABPDuAAAAEgAK8AgAAAAF BAAAAAoAAIMAC/AwAAAAfwABAAUAgADwWXsJgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkA AQICAAAIAAAQ8AgAAABeD3cGNhCKEA8AEfAQAAAAAADDCwgAAAADAAAACQLUAA8ADfB2AAAAAACf DwQAAAAEAAAAAACoDyIAAAA2MnRoIElFVEYsIE1pbm5lYXBvbGlzLCBNYXJjaCAyMDA1AAChDxYA AAAjAAAAAAAACAAAAQAjAAAAAAACAA4AAACqDxoAAAAXAAAAAAAAAAEAAAABAAAAAAALAAAAAAAA AA8ABPC4AAAAEgAK8AgAAAAGBAAAAAoAAIMAC/AwAAAAfwABAAUAgABQX3sJgQEEAAAIgwEAAAAI vwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABeDyAQYBWKEA8AEfAQAAAAAADDCwgAAAAE AAAACALUAA8ADfBAAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAIA AgAAAAAAAgAOAAAA2A8EAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEA AAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8A AAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBf AFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAmKDDASBAIY8gALoPHAAAAEQAZQBmAGEAdQBsAHQA IABEAGUAcwBpAGcAbgAPAO4DJAIAAAIA7wMYAAAAAAAAAA8QAAAAAAAAAAAAgAAAAAAHAPdgDwAM BJQBAAAPAALwjAEAADAACPAIAAAAAwAAAAMIAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA AAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPByAAAAEgAK8AgAAAACCAAAIAIAAFMAC/Ae AAAAfwAAAAQAgADwIX0JvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAAB6A2AAgBYYBw8AEfAQAAAA AADDCwgAAAAAAAAADwDUAA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMIAAAg AgAAUwAL8B4AAAB/AAAABACAAPCMegm/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPAJAADwFUAO DwAR8BAAAAAAAMMLCAAAAAEAAAAQANQADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAI AAAAAQgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAA AA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAJigwwHAxiKP DwDuA5EKAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwD3YA8ADARBCgAADwAC8DkKAABA AAjwCAAAAAYAAAAIKAAADwAD8NEJAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIA CvAIAAAAACgAAAUAAAAPAATwcgAAABIACvAIAAAAAigAACACAABTAAvwHgAAAH8AAAAEAIAAAExu C78BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAAAAnAWcV0AIPABHwEAAAAAAAwwsIAAAAAAAAAA0A 1AAPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADKAAAIAIAAFMAC/AeAAAAfwAA AAQAgABgQWwLvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAAAQAgAAJhaHDw8AEfAQAAAAAADDCwgA AAABAAAADgDUAA8ADfAMAAAAAACeDwQAAAABAAAADwAE8JEDAAASAArwCAAAAAYoAAAACgAAgwAL 8DAAAAB/AAAABQCAALBdawuBAQQAAAiDAQAAAAi/AQAAEQDAAQEAAAj/AQAACQABAgIAAAgAABDw CAAAANAFAABACzAPDwAR8KAAAAAPAIgTmAAAAA8AihOQAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5 AAAAixNyAAAAAACsD2oAAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAIA AAAAAAAAAAAADwAN8IkCAAAAAJ8PBAAAAAEAAAAAAKgPfwEAAA1kcmFmdC12YXNzZXVyLW9zcGYt dGUtY2Fwcy0wMC50eHQgKE9TUEYpDQlUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBPU1BGIHRyYWZm aWMgZW5naW5lZXJpbmcgY2FwYWJpbGl0eSBUTFZzIHJlbGF0ZWQgdG8gdmFyaW91cyBNUExTIFRy YWZmaWMgRW5naW5lZXJpbmcgY2FwYWJpbGl0aWVzLiBUaGVzZSBPU1BGIFRFIGNhcGFiaWxpdHkg VExWcyBhcmUgY2FycmllZCB3aXRoaW4gdGhlIE9TUEYgcm91dGVyIGluZm9ybWF0aW9uIExTQSAo b3BhcXVlIHR5cGUgb2YgNCwgb3BhcXVlIElEIG9mIDApIHNwZWNpZmllZCBpbiBkcmFmdC1pZXRm LW9zcGYtY2FwLTAyLnR4dC4NZHJhZnQtdmFzc2V1ci1pc2lzLXRlLWNhcHMtMDAudHh0IChJUy1J UykNCUlTLUlTIHNwZWNpZmljcw0JAAChD9QAAAABAAAAAQCTEAAAAgDgAAIAUAApAAAAAACyEAAA AwDgAAIAAAAAAVAAGQEAAAAAIRAAAAAAAAAAAVAAKgAAAAAAshAAAAMA4AACAAAAAAFQABMAAAAA ALMQAAACAOAAAgAAAAABUAABAAAAAACCAAIADgApAAAAAASCAAAEAgAUAP0AAAAACIIAAAgCABAA GgAAAAEMggABDAIAEAACAAAAABCCAAAQAgAQACsAAAAAFIIAABQCABQAEAAAAAAYggAAGAIADwAC AAAAAByCAAAcAgAUAAAAqg8SAAAAAQAAAAEAAAAAAH8BAAAAAAAADwAE8GQAAABCAQrwCAAAAAco AACACgAAowAL8DwAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADAAYAAAADLAdSUAADR AQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAGAJ4ArADGAJDwAE8KAEAAASAArwCAAAAAgoAAAACgAA gwAL8DAAAAB/AAAABQCAAMC2aguBAQQAAAiDAQAAAAi/AQAAEQDAAQEAAAj/AQAACQABAgIAAAgA ABDwCAAAAMAGcAuAFjcODwAR8G4AAAAPAIgTZgAAAA8AihNeAAAAAAC6Dw4AAABfAF8AXwBQAFAA VAA5AAAAixNAAAAAAACsDzgAAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAgAAAAAA AAAAAAAAAAACAAAAAAAAAAAAAA8ADfDKAwAAAACfDwQAAAABAAAAAACgDxoDAAAgACAAIAAgACAA IABUAEUAIABUAEwAVgAgAHIAZQBsAGEAdABlAGQAIAB0AG8AIAB2AGEAcgBpAG8AdQBzACAAYwBh AHAAYQBiAGkAbABpAHQAaQBlAHMAIABmAHUAbgBjAHQAaQBvAG4AYQBsAGkAdABpAGUAcwANAFAA QwBFACAAKABQAGEAdABoACAAQwBvAG0AcAB1AHQAYQB0AGkAbwBuACAARQBsAGUAbQBlAG4AdAAp ACAAZABpAHMAYwBvAHYAZQByAHkAOgAgAHUAcwBlAGQAIABpAG4AIAB2AGEAcgBpAG8AdQBzACAA YwBvAG4AdABlAHgAdABzACAAcwB1AGMAaAAgAGEAcwAgAEkAbgB0AGUAcgAtAGQAbwBtAGEAaQBu ACwAIABDAFAAVQAgAGkAbgB0AGUAbgBzAGkAdgBlACAAVABFACAATABTAFAAIABwAGEAdABoACAA YwBvAG0AcAB1AHQAYQB0AGkAbwBuACAAKABOAFAALQBjAG8AbQBwAGwAZQB0AGUAIABwAGIAcwAs ACAAJiApACwAIABHAE0AUABMAFMALAAgACYgIAANAFQARQAtAE0ARQBTAEgALQBHAFIATwBVAFAA OgAgAGEAbABsAG8AdwBzACAAZgBvAHIAIABhAHUAdABvAC0AZABpAHMAYwBvAHYAZQByAHkAIABv AGYAIABUAEUAIABtAGUAcwBoACAAZwByAG8AdQBwACAAbQBlAG0AYgBlAHIAcwANAFQARQAtAE4A TwBEAEUALQBDAEEAUAA6ACAAdQBzAGUAZAAgAG8AZgAgAHQAaABlACAAYQBkAHYAZQByAHQAaQBz AGUAbQBlAG4AdAAgAG8AZgAgAGMAbwBuAHQAcgBvAGwAIABhAG4AZAAgAGQAYQB0AGEAIABwAGwA YQBuAGUAIABuAG8AZABlACAAYwBhAHAAYQBiAGkAbABpAHQAaQBlAHMAIAAoAGUALgBnAC4AIABQ ADIATQBQACAAVABFACAAYwBhAHAAYQBiAGwAZQAgAG4AbwBkAGUAKQANAAAAoQ9oAAAAPQAAAAEA kxAAAAIA4AACAFAAUAEAAAEAkgAAAAMA4AACAAEAAAABAJMQAAACAOAAAgBQAAYAAAAAAIIAAgAO ADcAAAABBIIAAQQCAA4AnwAAAAAIggAACAIADgCyAAAAAAwCAAAMDgAAAKoPJAAAAAYAAAABAAAA AADDAAAAAAAAAAMAAAABAAAAAQDCAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABKAAAAAwAAIMAC/Aw AAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAA AAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8A7gPwAQAAAgDvAxgAAAABAAAADQ4A AAAAAAAAAACAAAAAAAcA92APAAwEoAEAAA8AAvCYAQAAIAAI8AgAAAADAAAAAzgAAA8AA/AwAQAA DwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAA4AAAFAAAADwAE8HgAAAAS AArwCAAAAAI4AAAgAgAAYwAL8CQAAAB/AAAABACAAJAefAm/AQAAAQD/AQAAAQABAwIEAACIAwAA AAAAABDwCAAAAAAAJwFnFdACDwAR8BAAAAAAAMMLCAAAAAAAAAANANQADwAN8AwAAAAAAJ4PBAAA AAAAAAAPAATweAAAABIACvAIAAAAAzgAACACAABjAAvwJAAAAH8AAAAEAIAAICB8Cb8BAAABAP8B AAABAAEDAwQAAIgDAAAAAAAAEPAIAAAAcAIWAIAWXw8PABHwEAAAAAAAwwsIAAAAAQAAAA4A1AAP AA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABOAAAAAwAAIMAC/AwAAAAgQEAAAAI gwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAA AICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8A7gMkAgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACA AAAAAAcA92APAAwElAEAAA8AAvCMAQAAUAAI8AgAAAADAAAAAxQAAA8AA/AkAQAADwAE8CgAAAAB AAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAUAAAFAAAADwAE8HIAAAASAArwCAAAAAIU AAAgAgAAUwAL8B4AAAB/AAAABACAAGBnbgu/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAK0AAABg FZcCDwAR8BAAAAAAAMMLCAAAAAAAAAANANQADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIA CvAIAAAAAxQAACACAABTAAvwHgAAAH8AAAAEAIAA0DNuC78BAAABAP8BAAABAAEDAwQAAAAAEPAI AAAAcAJgAOIVdg4PABHwEAAAAAAAwwsIAAAAAQAAAA4A1AAPAA3wDAAAAAAAng8EAAAAAQAAAA8A BPBIAAAAEgAK8AgAAAABFAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwES ABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkA mcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4I AAAAnKDDAaA8vrIQABEQYwAAAAAGAAB4nLtwXvDBwo1SDxnQgB0DM8O//5wMbEhijFAMBgIMQPn/ /0FMGA0C/0fBkAJ/gfjfQDtiFAwYYAhCz/mkASYGVpQ8j1ex2Ra95cpHGf8RUkciINp+GoGhbD8A 0NTyeQAAchcwAAAAAQAwAAAAAABGJAAAKC4AAAgAEADlPAAACwAQAFQwAAAPABAA7ToAABIAEAAR PwAAAAD1DxwAAAAAAQAA6RUAAwAAAAB8PwAAAQAAABIAAAABANwwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAA AAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAA /v////7///////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////v8AAAMKAQAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQ k5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rgADAAC8AgAAEAAAAAEAAACIAAAAAwAAAJAAAAAP AAAAqAAAAAQAAAC4AAAABgAAAMAAAAAHAAAAyAAAAAgAAADQAAAACQAAANgAAAAKAAAA4AAAABcA AADoAAAACwAAAPAAAAAQAAAA+AAAABMAAAAAAQAAFgAAAAgBAAANAAAAEAEAAAwAAABaAgAAAgAA ABAnAAAeAAAADwAAAE9uLXNjcmVlbiBTaG93AAAeAAAABwAAAE9sZGRvZwABAwAAANg/AAADAAAA IwAAAAMAAAAEAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAABCwALAAAAAAAAAAsAAAAA AAAACwAAAAAAAAALAAAAAAAAAB4QAAAJAAAABgAAAEFyaWFsABEAAABBcmlhbCBVbmljb2RlIE1T AAoAAABXaW5nZGluZ3MABgAAAFRpbWVzAA8AAABEZWZhdWx0IERlc2lnbgCyAAAAUm91dGluZyBl eHRlbnNpb25zIGZvciBkaXNjb3Zlcnkgb2YgTXVsdGlwcm90b2NvbCAoTVBMUykgTGFiZWwgU3dp dGNoICAgICAgICAgICAgICAgICD+/wAAAwoBAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCr kQgAKyez2TAAAAAULAAACwAAAAEAAABgAAAAAgAAAGgAAAAEAAAAeAAAAAgAAACIAAAACQAAAJwA AAASAAAAqAAAAAoAAADIAAAADAAAANQAAAANAAAA4AAAAA8AAADsAAAAEQAAAPQAAAACAAAAECcA AB4AAAAIAAAAU2xpZGUgMQAeAAAACAAAACBBZHJpYW4AHgAAAAsAAABKUCBWYXNzZXVyAHseAAAA BAAAADEyOAAeAAAAFQAAAE1pY3Jvc29mdCBQb3dlclBvaW50AAAAAkAAAABAcxaK3AEAAEAAAACA P1GRmKDDAUAAAAAApk552SPFAQMAAABjAQAARwAAABgrAAD+////UElDVCsQAAAAAACHALQAEQL/ DAD//gAAAEgAAABIAAAAAAAAAIcAtAAAAAAAHgABAAoAAAAAAIcAtACaAAAA/4LQAAAAAACHALQA AAAEAAAAAABIAAAASAAAABAAIAAEAAgAAAAgAAgRcAAveiwAAAAAAIcAtAAAAAAAhwC0AAAADIH/ gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B /4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/ gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B /4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/ gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wCdgf/D//4A9/8BAADx/wAA9/8AAPT/ AAD3/wEAAOb/BgD/AAD//wD9/wMA/wAA9v8AAPb/AADU//4A9/8BAADx/wAA9/8AAPT/AAD3/wEA AOb/BgD/AAD//wD9/wMA/wAA9v8AAPb/AADU//4A9/8BAADx/wAA9/8AAPT/AAD3/wEAAOb/BgD/ AAD//wD9/wMA/wAA9v8AAPb/AADe/wGNgf/D/woA//8A/wAA/wD///wAA/8A///+AAH///4ABP// AAD//gAD/wD///4AFf8AAP8A/wD//wAA/wAA/wAA/wD/AP/9AAz/AAD/AAD/AAD/AP///QAO/wD/ /wD/AAD/AAD/AAD//gAB///7AAT/AP8A//4ADv8AAP8AAP//AAD/AAD/ANT/CgD//wD/AAD/AP// /AAD/wD///4AAf///gAE//8AAP/+AAP/AP///gAV/wAA/wD/AP//AAD/AAD/AAD/AP8A//0ADP8A AP8AAP8AAP8A///9AA7/AP//AP8AAP8AAP8AAP/+AAH///sABP8A/wD//gAO/wAA/wAA//8AAP8A AP8A1P8KAP//AP8AAP8A///8AAP/AP///gAB///+AAT//wAA//4AA/8A///+ABX/AAD/AP8A//8A AP8AAP8AAP8A/wD//QAM/wAA/wAA/wAA/wD///0ADv8A//8A/wAA/wAA/wAA//4AAf//+wAE/wD/ AP/+AA7/AAD/AAD//wAA/wAA/wDe/wGQgf/D//4ACf8A//8AAP//AP/9AAn/AAD//wD/AP///gAP /wAA//8AAP8AAP//AAD///4AAv8AAP3/AwAA///+AAP/AP///gAO//8A//8A//8AAP8AAP///gAL /wD/AP//AP8A/wD//QAE//8AAP/9AAD//QAQ//8A/wAA//8AAP//AP//AADU//4ACf8A//8AAP// AP/9AAn/AAD//wD/AP///gAP/wAA//8AAP8AAP//AAD///4AAv8AAP3/AwAA///+AAP/AP///gAO //8A//8A//8AAP8AAP///gAL/wD/AP//AP8A/wD//QAE//8AAP/9AAD//QAQ//8A/wAA//8AAP// AP//AADU//4ACf8A//8AAP//AP/9AAn/AAD//wD/AP///gAP/wAA//8AAP8AAP//AAD///4AAv8A AP3/AwAA///+AAP/AP///gAO//8A//8A//8AAP8AAP///gAL/wD/AP//AP8A/wD//QAE//8AAP/9 AAD//QAQ//8A/wAA//8AAP//AP//AADe/wGNgf/D/wwA/wD/AP//AAD//wD//gAH//8AAP//AP/+ AAP/AAD//AAD//8A//0AGf//AAD//wD/AAD//wAA//8AAP//AP//AAD//gAG//8A//8A//sADf// AAD/AP//AP8A/wD//QAE//8AAP/+ABb//wAA/wD//wD/AAD//wAA//8A//8AANT/DAD/AP8A//8A AP//AP/+AAf//wAA//8A//4AA/8AAP/8AAP//wD//QAZ//8AAP//AP8AAP//AAD//wAA//8A//8A AP/+AAb//wD//wD/+wAN//8AAP8A//8A/wD/AP/9AAT//wAA//4AFv//AAD/AP//AP8AAP//AAD/ /wD//wAA1P8MAP8A/wD//wAA//8A//4AB///AAD//wD//gAD/wAA//wAA///AP/9ABn//wAA//8A /wAA//8AAP//AAD//wD//wAA//4ABv//AP//AP/7AA3//wAA/wD//wD/AP8A//0ABP//AAD//gAW //8AAP8A//8A/wAA//8AAP//AP//AADe/wFsgf/D/wQA/wAA//4AAP/+AAD//gAD//8A//4AAf// /gAE/wD/AP/+AAH///wAAP/9AAH///0AA///AP/9AP7/+gAD/wAA//4AA/8AAP/+AAX//wAA///+ AAT/AP8A//4AAP/9AAD/+gAB///+AAL/AP/+AAP/AAD//QDU/wQA/wAA//4AAP/+AAD//gAD//8A //4AAf///gAE/wD/AP/+AAH///wAAP/9AAH///0AA///AP/9AP7/+gAD/wAA//4AA/8AAP/+AAX/ /wAA///+AAT/AP8A//4AAP/9AAD/+gAB///+AAL/AP/+AAP/AAD//QDU/wQA/wAA//4AAP/+AAD/ /gAD//8A//4AAf///gAE/wD/AP/+AAH///wAAP/9AAH///0AA///AP/9AP7/+gAD/wAA//4AA/8A AP/+AAX//wAA///+AAT/AP8A//4AAP/9AAD/+gAB///+AAL/AP/+AAP/AAD//QDe/wAogf+w//0A wP8AAOv/AACq//0AwP8AAOv/AACq//0AwP8AAOv/AADH/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B /4H/sf8AiIH/k//+AAP//wD//gAB/wD+//0A/v8AAPz/AAD7/wIA///+APz/AgD/AP7/AACC//4A A///AP/+AAH/AP7//QD+/wAA/P8AAPv/AgD///4A/P8CAP8A/v8AAIL//gAD//8A//4AAf8A/v/9 AP7/AAD8/wAA+/8CAP///gD8/wIA/wD+/wAAvP8AqYH/k//+AAz/AAD/AP8A/wD//wAA/v8DAP// AP7//gAD/wD///4ACP8AAP//AP8A//0AAP/+AAH/AIT//gAM/wAA/wD/AP8A//8AAP7/AwD//wD+ //4AA/8A///+AAj/AAD//wD/AP/9AAD//gAB/wCE//4ADP8AAP8A/wD/AP//AAD+/wMA//8A/v/+ AAP/AP///gAI/wAA//8A/wD//QAA//4AAf8Avv8ArIH/lP8DAP8A//4AAP/+AAH/AP7//gAE/wD/ /wD9//4AB/8AAP//AP///QAN/wD/AAD/AAD//wAA/wCG/wMA/wD//gAA//4AAf8A/v/+AAT/AP// AP3//gAH/wAA//8A///9AA3/AP8AAP8AAP//AAD/AIb/AwD/AP/+AAD//gAB/wD+//4ABP8A//8A /f/+AAf/AAD//wD///0ADf8A/wAA/wAA//8AAP8Av/8AqYH/lP8DAP8A//4AAf8A/v8NAP//AP// AP8A//8A///9AAH///wABf8A//8A//wACP8AAP//AP//AIb/AwD/AP/+AAH/AP7/DQD//wD//wD/ AP//AP///QAB///8AAX/AP//AP/8AAj/AAD//wD//wCG/wMA/wD//gAB/wD+/w0A//8A//8A/wD/ /wD///0AAf///AAF/wD//wD//AAI/wAA//8A//8Av/8AoIH/lP8DAP8A//4AAf8A/v/+AAD//gAD /wD///cAAP/+AAH///4ACP8A/wD/AP8A//4AAv//AIb/AwD/AP/+AAH/AP7//gAA//4AA/8A///3 AAD//gAB///+AAj/AP8A/wD/AP/+AAL//wCG/wMA/wD//gAB/wD+//4AAP/+AAP/AP//9wAA//4A Af///gAI/wD/AP8A/wD//gAC//8Av/8AIIH/k/8AAPD/AACB/+D/AADw/wAAgf/g/wAA8P8AAJr/ AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AKyB/67//gD3/wAA+v8C AP8A/v/+AAD//gAD/wD///0A+/8DAP8AAPz//gD5/wAA9f8AAPf//AAA//0As//+APf/AAD6/wIA /wD+//4AAP/+AAP/AP///QD7/wMA/wAA/P/+APn/AAD1/wAA9//8AAD//QCz//4A9/8AAPr/AgD/ AP7//gAA//4AA/8A///9APv/AwD/AAD8//4A+f8AAPX/AAD3//wAAP/9ANL/AS2B/67/CgD//wD/ AAD/AP///gAA//4ACf8A/wD/AP//AAD+/wUA//8A/wD+/wMA/wD/+QAM/wAA//8A//8A/wD///wA Bv8A//8AAP/+AAb/AAD/AP///gAI//8A//8A//8A/v8AALT/CgD//wD/AAD/AP///gAA//4ACf8A /wD/AP//AAD+/wUA//8A/wD+/wMA/wD/+QAM/wAA//8A//8A/wD///wABv8A//8AAP/+AAb/AAD/ AP///gAI//8A//8A//8A/v8AALT/CgD//wD/AAD/AP///gAA//4ACf8A/wD/AP//AAD+/wUA//8A /wD+/wMA/wD/+QAM/wAA//8A//8A/wD///wABv8A//8AAP/+AAb/AAD/AP///gAI//8A//8A//8A /v8AANP/ASSB/67//gAU/wD//wAA//8A/wAA//8AAP8A//8A/v/+AAD//gAC//8A/v8JAP8AAP// AP8A//4A/f/8AAT/AAD///0AB/8AAP//AP///AAH/wAA//8A/wD+/wIA///+AAH/ALT//gAU/wD/ /wAA//8A/wAA//8AAP8A//8A/v/+AAD//gAC//8A/v8JAP8AAP//AP8A//4A/f/8AAT/AAD///0A B/8AAP//AP///AAH/wAA//8A/wD+/wIA///+AAH/ALT//gAU/wD//wAA//8A/wAA//8AAP8A//8A /v/+AAD//gAC//8A/v8JAP8AAP//AP8A//4A/f/8AAT/AAD///0AB/8AAP//AP///AAH/wAA//8A /wD+/wIA///+AAH/ANP/ASeB/67/DAD/AP8A//8AAP//AP/8ABL//wD//wD//wD//wD/AP8A//8A /v8DAP8A//4AAv8A//4A/f8JAP//AP//AAD///4AAf//+QAL/wAA//8AAP//AP8A/v8DAP//AP7/ AAC0/wwA/wD/AP//AAD//wD//AAS//8A//8A//8A//8A/wD/AP//AP7/AwD/AP/+AAL/AP/+AP3/ CQD//wD//wAA///+AAH///kAC/8AAP//AAD//wD/AP7/AwD//wD+/wAAtP8MAP8A/wD//wAA//8A //wAEv//AP//AP//AP//AP8A/wD//wD+/wMA/wD//gAC/wD//gD9/wkA//8A//8AAP///gAB///5 AAv/AAD//wAA//8A/wD+/wMA//8A/v8AANP/ATmB/67/BAD/AAD//gAA//4AAv8A//4ABP//AP// /gAA//4ABv8A/wAA/wD+/wMA/wD//gAJ/wD/AAD/AAD///0AA///AP/8AAb//wD/AAD//gAG/wAA //8A//4AAf8A/v8CAP///gAB/wC0/wQA/wAA//4AAP/+AAL/AP/+AAT//wD///4AAP/+AAb/AP8A AP8A/v8DAP8A//4ACf8A/wAA/wAA///9AAP//wD//AAG//8A/wAA//4ABv8AAP//AP/+AAH/AP7/ AgD///4AAf8AtP8EAP8AAP/+AAD//gAC/wD//gAE//8A///+AAD//gAG/wD/AAD/AP7/AwD/AP/+ AAn/AP8AAP8AAP///QAD//8A//wABv//AP8AAP/+AAb/AAD//wD//gAB/wD+/wIA///+AAH/ANP/ AEyB/5n/AAD0/wAA5f/9AO///QAC//8A+f8AAJ7/AAD0/wAA5f/9AO///QAC//8A+f8AAJ7/AAD0 /wAA5f/9AO///QAC//8A+f8AANL/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wA4gf+E/wAA 7v8AAPb/AAD+/wAAgf/y/wAA7v8AAPb/AAD+/wAAgf/y/wAA7v8AAPb/AAD+/wAAu/8ApoH/kP8J AP8A/wD//wAA//4ACv8A//8A/wD/AP///gAJ/wD/AP8A/wD///4AAP/9AAb/AP8AAP8Agf8JAP8A /wD//wAA//4ACv8A//8A/wD/AP///gAJ/wD/AP8A/wD///4AAP/9AAb/AP8AAP8Agf8JAP8A/wD/ /wAA//4ACv8A//8A/wD/AP///gAJ/wD/AP8A/wD///4AAP/9AAb/AP8AAP8Avv8AqYH/kP8eAAD/ AP8AAP//AP//AAD/AP8AAP8A/wAA//8AAP8A//4ABP8AAP///gAE//8AAP/9AAH/AIL/HgAA/wD/ AAD//wD//wAA/wD/AAD/AP8AAP//AAD/AP/+AAT/AAD///4ABP//AAD//QAB/wCC/x4AAP8A/wAA //8A//8AAP8A/wAA/wD/AAD//wAA/wD//gAE/wAA///+AAT//wAA//0AAf8Av/8AnYH/kP8EAP// AP/9AAD//gAI//8A/wD//wD//AAH//8A/wAA///8AAH///4AAf///gAC//8Agv8EAP//AP/9AAD/ /gAI//8A/wD//wD//AAH//8A/wAA///8AAH///4AAf///gAC//8Agv8EAP//AP/9AAD//gAI//8A /wD//wD//AAH//8A/wAA///8AAH///4AAf///gAC//8Av/8AjoH/kP8GAP//AP8A//sACv//AP8A //8A/wD//gAD//8A//wAAP/+AAD//QAB///7AIL/BgD//wD/AP/7AAr//wD/AP//AP8A//4AA/// AP/8AAD//gAA//0AAf//+wCC/wYA//8A/wD/+wAK//8A/wD//wD/AP/+AAP//wD//AAA//4AAP/9 AAH///sAv/8AFoH/gf/f/wAAgf/O/wAAgf/O/wAAvP8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B /7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/ sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x /wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ANIH/p/8AAP7/AADF/wAA/P/7AJr/AAD+/wAA xf8AAPz/+wCa/wAA/v8AAMX/AAD8//sAwP8A5YH/qP/+AAD//QD+/wwA/wAA/wD/AP8A/wD//gD9 /wUA//8A///+AAD//gD9/wIAAP/+AAr/AP8AAP8A/wD///4A/f8GAP8AAP8A//sAov/+AAD//QD+ /wwA/wAA/wD/AP8A/wD//gD9/wUA//8A///+AAD//gD9/wIAAP/+AAr/AP8AAP8A/wD///4A/f8G AP8AAP8A//sAov/+AAD//QD+/wwA/wAA/wD/AP8A/wD//gD9/wUA//8A///+AAD//gD9/wIAAP/+ AAr/AP8AAP8A/wD///4A/f8GAP8AAP8A//sAx/8A3IH/qf8EAP8A///+AAD//AAE/wD/AP/8AAP/ AAD//QAC//8A/v/7AAD//gAI/wAA/wAA/wD/+QAD/wAA//wACv8AAP8A/wD//wAAov8EAP8A///+ AAD//AAE/wD/AP/8AAP/AAD//QAC//8A/v/7AAD//gAI/wAA/wAA/wD/+QAD/wAA//wACv8AAP8A /wD//wAAov8EAP8A///+AAD//AAE/wD/AP/8AAP/AAD//QAC//8A/v/7AAD//gAI/wAA/wAA/wD/ +QAD/wAA//wACv8AAP8A/wD//wAAxv8AlIH/qf/+AAX/AAD/AAD9//MA/f/4AP7/AQAA/v/4AAH/ AP7/+wAB/wD9/wQA//8A//oAo//+AAX/AAD/AAD9//MA/f/4AP7/AQAA/v/4AAH/AP7/+wAB/wD9 /wQA//8A//oAo//+AAX/AAD/AAD9//MA/f/4AP7/AQAA/v/4AAH/AP7/+wAB/wD9/wQA//8A//oA x/8AFoH/gf/+/wAAgf/O/wAAgf/O/wAAnf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB /4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/ gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B /4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wBhgf+e/wQAAP8A//4A+v8AAOX/ AADy/wEAAP7/AADp/wAAqP8EAAD/AP/+APr/AADl/wCZ8v8BmZn+/wCZ6f8AAKj/BAAA/wD//gD6 /wAA5f8AmfL/AZmZ/v8Amen/AADX/wDlgf+m/wMA/wD//gAC/wD/9wAP/wD/AP8A/wD/AP8A/wAA //4A9P8MAAD//wD/AP8A/wAA//sADP8AAP8A/wD/AP//AP/+AAH/APj/AACw/wMA/wD//gAC/wD/ 9wAP/wD/AP8A/wD/AP8A/wAA//4A9P8MmZn//5n/mf+Z/5mZ//uZDP+Zmf+Z/5n/mf//mf/+mQH/ mfj/AACw/wMA/wD//gAC/wD/9wAP/wD/AP8A/wD/AP8A/wAA//4A9P8MmZn//5n/mf+Z/5mZ//uZ DP+Zmf+Z/5n/mf//mf/+mQH/mfj/AADX/wCggf+m//cAAP/7AAL/AP/8AAH///cAAf8A9P/+AAD/ 9AAD/wAA//0AB/8A/wAA/wD//QD4/wAAsP/3AAD/+wAC/wD//AAB///3AAH/APT//pkA//SZA/+Z mf/9mQf/mf+Zmf+Z//2Z+P8AALD/9wAA//sAAv8A//wAAf//9wAB/wD0//6ZAP/0mQP/mZn//ZkH /5n/mZn/mf/9mfj/AADX/wBcgf+n//oABv//AP//AP/4AAP//wD/9gAB/wD0/9IAsf/6AAb//wD/ /wD/+AAD//8A//YAAf8A9P/TmQAAsf/6AAb//wD//wD/+AAD//8A//YAAf8A9P/TmQAA1/8AJoH/ lv8CAP8A4P/SAKD/AgD/AOD/05kAAKD/AgD/AOD/05kAANf/AAyB/4H/gf+B/4H/sf8AlIH/n/8A APz/AAD+/wAA/f/+AOz/AAD7/wAA/f8AAPf/AAD2/wQAAP//APb/AADh/wAAyf8AAPz/AAD+/wAA /f/+AOz/AJn7/wCZ/f8Amff/AJn2/wSZmf//mfb/AJnh/wAAyf8AAPz/AAD+/wAA/f/+AOz/AJn7 /wCZ/f8Amff/AJn2/wSZmf//mfb/AJnh/wAA9/8BLYH/p/8DAP8A//4AGv8A//8AAP8A/wD/AP// AP8A/wD/AAD/AP//APT/AwD/AP/9AAb/AAD/AP8A+f8BAP/8AAL/AP/2AAz/AP8AAP8AAP8A/wD/ /gAB/wD0/wEA//4ABP8A//8A0f8DAP8A//4AGv8A//8AAP8A/wD/AP//AP8A/wD/AAD/AP//APT/ A5n/mf/9mQb/mZn/mf+Z+f8Bmf/8mQL/mf/2mQz/mf+Zmf+Zmf+Z/5n//pkB/5n0/wGZ//6ZBP+Z //8A0f8DAP8A//4AGv8A//8AAP8A/wD/AP//AP8A/wD/AAD/AP//APT/A5n/mf/9mQb/mZn/mf+Z +f8Bmf/8mQL/mf/2mQz/mf+Zmf+Zmf+Z/5n//pkB/5n0/wGZ//6ZBP+Z//8A9/8A7oH/p//6AAT/ AP8A//wAAv8A//wACP8A/wAA/wD/APT/+AAA//wA+f/8AAP/AAD//QAA//4AAP/9AAD/+AAC/wD/ /QD1/wMA/wD//QAC//8A0f/6AAT/AP8A//wAAv8A//wACP8A/wAA/wD/APT/+JkA//yZ+f/8mQP/ mZn//ZkA//6ZAP/9mQD/+JkC/5n//Zn1/wOZ/5n//ZkC//8A0f/6AAT/AP8A//wAAv8A//wACP8A /wAA/wD/APT/+JkA//yZ+f/8mQP/mZn//ZkA//6ZAP/9mQD/+JkC/5n//Zn1/wOZ/5n//ZkC//8A 9/8AWYH/qP/6AAH///gAAP/9AAL/AP/7AAL//wD0/6wA0v/6AAH///gAAP/9AAL/AP/7AAL//wD0 /62ZAADS//oAAf//+AAA//0AAv8A//sAAv//APT/rZkAAPf/ABaB/4H/+P+sAKL/rZkAAKL/rZkA APf/AAyB/4H/gf+B/4H/sf8AYYH/qP8BAAD1/wEAAPj/AADt/wAA/v8BAAD+/wAA6P8AAJ//AQAA 9f8BAAD4/wAA7f8Amf7/AZmZ/v8Amej/AACf/wEAAPX/AQAA+P8AAO3/AJn+/wGZmf7/AJno/wAA xP8A1oH/qP8GAP8A/wAA//4A/f8FAP8A/wD//gAC/wAA+/8BAP/9AAL/AP/+AAP/AAD//AAM/wAA /wD/AP8A//8A//4AAf8A9/8AAJ//BgD/AP8AAP/+AP3/BQD/AP8A//4AAv8AAPv/AQD//ZkC/5n/ /pkD/5mZ//yZDP+Zmf+Z/5n/mf//mf/+mQH/mff/AACf/wYA/wD/AAD//gD9/wUA/wD/AP/+AAL/ AAD7/wEA//2ZAv+Z//6ZA/+Zmf/8mQz/mZn/mf+Z/5n//5n//pkB/5n3/wAAxP8Ar4H/qP8CAAD/ +wD8/wIAAP/7AAD//gD8/wUA/wD/AP/7AAD/+wAD/wAA//0AB/8A/wAA/wD//QD3/wAAn/8CAAD/ +wD8/wIAAP/7AAD//gD8/wUA/5n/mf/7mQD/+5kD/5mZ//2ZB/+Z/5mZ/5n//Zn3/wAAn/8CAAD/ +wD8/wIAAP/7AAD//gD8/wUA/5n/mf/7mQD/+5kD/5mZ//2ZB/+Z/5mZ/5n//Zn3/wAAxP8AWYH/ qP8CAP//+wD8/wIA///8AAD//QD8/wEA/9EAn/8CAP//+wD8/wIA///8AAD//QD8/wEA/9KZAACf /wIA///7APz/AgD///wAAP/9APz/AQD/0pkAAMT/ABiB/4b/0QCB//3/0pkAAIH//f/SmQAAxP8A DIH/gf+B/4H/gf+x/wB5gf+n/wAA/P8AAPv/AQAA+/8DAP//AOz/BwD//wD//wAA/v8AAOn/AACg /wAA/P8AAPv/AQAA+/8DAP//AOz/B5n//5n//5mZ/v8Amen/AACg/wAA/P8AAPv/AQAA+/8DAP// AOz/B5n//5n//5mZ/v8Amen/AADG/wC+gf+o/wcA//8A/wAA//4ABP8A/wD//AAG/wD/AAD/APb/ +gAC/wD/+gAM/wAA/wD/AP8A//8A//4AAf8A+P8AAKH/BwD//wD/AAD//gAE/wD/AP/8AAb/AP8A AP8A9v/6mQL/mf/6mQz/mZn/mf+Z/5n//5n//pkB/5n4/wAAof8HAP//AP8AAP/+AAT/AP8A//wA Bv8A/wAA/wD2//qZAv+Z//qZDP+Zmf+Z/5n/mf//mf/+mQH/mfj/AADG/wCXgf+n//sAAP/9AAD/ /gAA//gAAf8A9//+AAD/9QAD/wAA//0AB/8A/wAA/wD//QD4/wAAoP/7AAD//QAA//4AAP/4AAH/ APf//pkA//WZA/+Zmf/9mQf/mf+Zmf+Z//2Z+P8AAKD/+wAA//0AAP/+AAD/+AAB/wD3//6ZAP/1 mQP/mZn//ZkH/5n/mZn/mf/9mfj/AADG/wBTgf+o//cABv8AAP8A///+AAD//AAB/wD3/9MAof/3 AAb/AAD/AP///gAA//wAAf8A9//UmQAAof/3AAb/AAD/AP///gAA//wAAf8A9//UmQAAxv8AGIH/ gv/TAIH/+//UmQAAgf/7/9SZAADG/wAMgf+B/4H/gf+B/7H/AJSB/6f/AAD+/wMA//8A+f8AAPn/ AADo/wAA7f8DAP//APz/BgAA/wD//wDp/wAA/f8AAMP/AAD+/wMA//8A+f8AAPn/AADo/wCZ7f8D mf//mfz/BpmZ/5n//5np/wCZ/f8AAMP/AAD+/wMA//8A+f8AAPn/AADo/wCZ7f8Dmf//mfz/BpmZ /5n//5np/wCZ/f8AAOn/AR6B/6j/AAD+/wIAAP/+AAH/APz/DAD/AP8A/wAA/wD//wD+/wMAAP8A +v8LAP//AP8AAP8A//8A/v8BAAD4/wQA/wAA//4AAP/6AAD//gD5//0A/f8CAP8A/f/+AAL//wDE /wAA/v8CAAD//gAB/wD8/wwA/wD/AP8AAP8A//8A/v8DAAD/APr/C5n//5n/mZn/mf//mf7/AZmZ +P8Emf+Zmf/+mQD/+pkA//6Z+f/9mf3/Apn/mf3//pkC//8AxP8AAP7/AgAA//4AAf8A/P8MAP8A /wD/AAD/AP//AP7/AwAA/wD6/wuZ//+Z/5mZ/5n//5n+/wGZmfj/BJn/mZn//pkA//qZAP/+mfn/ /Zn9/wKZ/5n9//6ZAv//AOn/AOuB/6f/9wAB/wD8/wIA///6AAD//QAD/wD/APr/AgAA//oAAP/9 AAH/APn/9wAA//4AB/8AAP8AAP8A+v/9AP7/BAD/AP8A/v8FAAD/AP8Aw//3AAH/APz/AgD///oA AP/9AAP/AP8A+v8CmZn/+pkA//2ZAf+Z+f/3mQD//pkH/5mZ/5mZ/5n6//2Z/v8Emf+Z/5n+/wWZ mf+Z/wDD//cAAf8A/P8CAP//+gAA//0AA/8A/wD6/wKZmf/6mQD//ZkB/5n5//eZAP/+mQf/mZn/ mZn/mfr//Zn+/wSZ/5n/mf7/BZmZ/5n/AOn/AFmB/6j/+AAC/wAA+/8BAP/3AAH///4AAf8A+v+2 AMT/+AAC/wAA+/8BAP/3AAH///4AAf8A+v+3mQAAxP/4AAL/AAD7/wEA//cAAf///gAB/wD6/7eZ AADp/wAWgf+B//z/tgCY/7eZAACY/7eZAADp/wAMgf+B/4H/gf+B/7H/AGSB/6j/AQAA/P8AAP3/ BgD//wD//wDt/wAA+v8BAADk/wAAnP8BAAD8/wAA/f8GAP//AP//AO3/AJn6/wGZmeT/AACc/wEA APz/AAD9/wYA//8A//8A7f8Amfr/AZmZ5P8AAMH/ANOB/6j/BwD/AP8AAP8A/f8EAP//AP/+AAL/ AAD7/wEA//0AAv8A//4AA/8AAP/8AAH/AP7/CAAA/wAA//8A//4AAf8A+P8AAJz/BwD/AP8AAP8A /f8EAP//AP/+AAL/AAD7/wEA//2ZAv+Z//6ZA/+Zmf/8mQH/mf7/CJmZ/5mZ//+Z//6ZAf+Z+P8A AJz/BwD/AP8AAP8A/f8EAP//AP/+AAL/AAD7/wEA//2ZAv+Z//6ZA/+Zmf/8mQH/mf7/CJmZ/5mZ //+Z//6ZAf+Z+P8AAMH/AKCB/6j/AwAA///9AP3//QAD/wAA//0A/P8DAP8A//0AA/8AAP/6AAD/ 9gAE/wD/AP/9APj/AACc/wMAAP///QD9//0AA/8AAP/9APz/AwD/mf/9mQP/mZn/+pkA//aZBP+Z /5n//Zn4/wAAnP8DAAD///0A/f/9AAP/AAD//QD8/wMA/5n//ZkD/5mZ//qZAP/2mQT/mf+Z//2Z +P8AAMH/AFaB/6j/AgD///wA/f8CAP//+gAB/wD8/wEA/9EAnP8CAP///AD9/wIA///6AAH/APz/ AQD/0pkAAJz/AgD///wA/f8CAP//+gAB/wD8/wEA/9KZAADB/wAggf+S/wAA+f/RAIb/AAD5/9KZ AACG/wAA+f/SmQAAwf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8A DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8AdoH/jv/7AAf//wAA/wD/AP7/AwD/AAD2/wAA+/8C AP8A/P8CAP//+QCH//sAB///AAD/AP8A/v8DAP8AAPb/AAD7/wIA/wD8/wIA///5AIf/+wAH//8A AP8A/wD+/wMA/wAA9v8AAPv/AgD/APz/AgD///kAxv8AW4H/jv8CAAD//QAA//0ABP8AAP//8QD7 //cAAf//+gCH/wIAAP/9AAD//QAE/wAA///xAPv/9wAB///6AIf/AgAA//0AAP/9AAT/AAD///EA +//3AAH///oAxv8AhYH/jv/+AAb/AAD//wAA/v8AAP7/BgAA/wD/AP/3APz/AgAA//sAA///AP/7 AIf//gAG/wAA//8AAP7/AAD+/wYAAP8A/wD/9wD8/wIAAP/7AAP//wD/+wCH//4ABv8AAP//AAD+ /wAA/v8GAAD/AP8A//cA/P8CAAD/+wAD//8A//sAxv8ALoH/gf8C//8A9f8AAPz/AACB/+H/AAD1 /wAA/P8AAIH/4f8AAPX/AAD8/wAAr/8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/ gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B /4H/gf+x/wD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUm91 dGVyIChMU1IpIFRyYWZmaWMgRW5naW5lZXJpbmcgKFRFKSBtZXNoIG1lbWJlcnNoaXAgICBkcmFm dC12YXNzZXVyLWNjYW1wLWF1dG9tZXNoLTAwLnR4dAALAAAAQmFja2dyb3VuZAAXAAAAUXVpY2sg b3ZlcnZpZXcvc3VtbWFyeQAUAAAAUHJvcG9zZWQgbmV4dCBzdGVwcwAMEAAABgAAAB4AAAALAAAA Rm9udHMgVXNlZAADAAAABAAAAB4AAAAQAAAARGVzaWduIFRlbXBsYXRlAAMAAAABAAAAHgAAAA0A AABTbGlkZSBUaXRsZXMAAwAAAAQAAAAAAPACAAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAA AQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAAABAnAABBAAAAqAIAACQAAAADAAAABwAAAAMAAAAG AAAAAwAAAAAAAAADAAAABwAAAB8AAAAaAAAAbQBhAGkAbAB0AG8AOgBqAHYAYQBzAHMAZQB1AHIA QABjAGkAcwBjAG8ALgBjAG8AbQAAAB8AAAABAAAAAAAAAAMAAAAHAAAAAwAAAAYAAAADAAAAAAAA AAMAAAAHAAAAHwAAACUAAABtAGEAaQBsAHQAbwA6AHkAYQBzAHUAawBhAHcAYQAuAHMAZQBpAHMA aABvAEAAbABhAGIALgBuAHQAdAAuAGMAbwAuAGoAcAAAAAAAHwAAAAEAAAAAAAAAAwAAAAcAAAAD AAAABgAAAAMAAAAAAAAAAwAAAAcAAAAfAAAAKgAAAG0AYQBpAGwAdABvADoAagBlAGEAbgBsAG8A dQBpAHMALgBsAGUAcgBvAHUAeABAAGYAcgBhAG4AYwBlAHQAZQBsAGUAYwBvAG0ALgBjAG8AbQAA AB8AAAABAAAAAAAAAAMAAAAHAAAAAwAAAAYAAAADAAAAAAAAAAMAAAAHAAAAHwAAABgAAABtAGEA aQBsAHQAbwA6AHAAbQBhAGIAZQB5AEAAcQB3AGUAcwB0AC4AYwBvAG0AAAAfAAAAAQAAAAAAAAAD AAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAAAZAAAAbQBhAGkAbAB0AG8AOgBwAHAA cwBlAG4AYQBrAEAAYwBpAHMAYwBvAC4AYwBvAG0AAAAAAB8AAAABAAAAAAAAAAMAAAAHAAAAAwAA AAYAAAADAAAAAAAAAAMAAAAHAAAAHwAAABoAAABtAGEAaQBsAHQAbwA6AHMAcAByAGUAdgBpAGQA aQBAAGMAaQBzAGMAbwAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMAdQBy AHIAZQBuAHQAIABVAHMAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAaAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAA AD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2DyIA AAAUAAAAX8CR47Q/AAAKAPQDAwAiJEpQIFZhc3NldXIIAAAASgBQACAAVgBhAHMAcwBlAHUAcgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --Apple-Mail-2-984250060 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Thanks. > draft-ietf-ccamp-rsvp-restart-ext-01.txt > Arun Satyanarayana. No slides received > > draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt > Dimitri Papdimitriou. No slides received > > Presenters listed above must use their own laptops. > > Cheers, > Adrian > --Apple-Mail-2-984250060-- From owner-ccamp@ops.ietf.org Tue Mar 8 09:02:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24715 for ; Tue, 8 Mar 2005 09:02:33 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8fKW-0004yB-4M for ccamp-archive@ietf.org; Tue, 08 Mar 2005 09:05:04 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8fAt-000KVW-4l for ccamp-data@psg.com; Tue, 08 Mar 2005 13:55:03 +0000 Received: from [205.177.121.2] (helo=ns1.cpanel.btnaccess.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1D8fAp-000KUP-Bq for ccamp@ops.ietf.org; Tue, 08 Mar 2005 13:54:59 +0000 Received: from [65.213.193.21] (helo=Isovaio08) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.44) id 1D8fAm-0007SU-T3; Tue, 08 Mar 2005 08:54:56 -0500 From: "Rajiv Papneja" To: "'Ashok Narayanan'" , Cc: Subject: RE: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Date: Tue, 8 Mar 2005 08:54:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <20050308125833.GA32112@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcUj39SDCZvsFny6SgaEx790Tq5i2wABSDfQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit See below: -----Original Message----- From: Ashok Narayanan [mailto:ashokn@cisco.com] Sent: Tuesday, March 08, 2005 7:59 AM To: benjamin.niven-jenkins@bt.com Cc: ccamp@ops.ietf.org Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt > > I am trying to understand section 7.4 (Separation of Control and Data Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > > The draft states: > "PSC-capable nodes implementing an OOB control plane (perhaps to > communicate with an optical switch) MUST NOT use the OOB control > plane for data traffic. For example, in the case of MPLS service > running on top of a GMPLS LSP, if the peer PSC device is reachable > via both the control plane and the data plane, control protocols > such as LDP MUST NOT form adjacencies over the control plane > interfaces. This may be provided by a combination of implementation > features and deployment guidelines." > > So, if the control plane is OOB why must control protocols (such as > LDP) NOT form adjacencies over the control plane interfaces? This > implies that LDP (for e.g.) MUST form its adjacencies over the data > plane interfaces and therefore LDP is not running OOB (and therefore > the control plane is not entirely OOB). > That's an interesting question. The draft focuses on GMPLS/TE deployments and the use of an out-of-band control channel as a matter of necessity (i.e. because optical switches are not capable of handling in-band control traffic). Consider the general deployment of a core of optical switches surrounded by GMPLS/TE routers at the edge. From the perspective of this network (optical switches, edge routers, and the links in between), that statement translates to: _ The GMPLS/TE control plane between the edge routers and the optical switches in the core is entirely out-of-band - All other protocols between the edge routers MUST be entirely in-band. The control plane network may well be a series of point-to-point GRE tunnels overlaid on some other low-bandwidth network (actually this is what the draft recommends). Ordinarily one would establish a GRE tunnel between each pair of neighbors so they can talk to each other. But this means that signalling messages going from edge router to edge router actually have to be routed through the control planes of intermediate switches. The two alternatives to avoid this (to create a full mesh of GRE tunnels - at least between all the edge routers - or to not use GRE at all if the control plane is switched Ethernet, and therefore to essentially permit a full mesh of OSPF peers) are not really palatable (and in the case of SDCC, not usable). The optical switches in the core should not be in the business of routing packets. Sometimes they have to (e.g. Notify messages), but they are not designed for this purpose and should not be deployed as such. And practically speaking the control network is expected to be a low-bandwidth network that can "just get the job done". A single 10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle the control traffic for a GMPLS/TE network, but will probably fail if we want to use it to peer LDP or BGP for 10,000 prefixes/labels between the edge routers. [rp] Furthermore - If LDP adjacencies are formed over the control plane, and since the LDP forwarding is based on the IP routing and metrics, the PSC devices will try to forward the IP traffic on the interfaces with the lowest metric (control interface in this case), and since all the edge nodes in the GMPLS control plane are adjacent from control plane traffic perspective, one has to change the metrics of the control plane interface on the PSC devices to avoid the best path through the control plane (OOB). The best current practice is therefore to use the low-bandwidth control network between routers and switches for GMPLS/TE signaling (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical TE LSPs signalled between edge routers to do other L3 protocols between them. The issue of a separated control plane between PSC edge routers for different L3 protocols for administrative reasons is an interesting one. Nothing precludes you from creating multiple parallel LSPs between edge routers and using one of them to carry control traffic between the two edge routers on behalf of all the others; that would still satisfy this requirement. Alternatively, one could engineer a more beefy control plane network so that it can in fact carry all the control plane traffic (BGP, LDP etc.) but that is not the BCP today based on available implementations. -Ashok On Tue, Mar 08, 2005 at 10:33:54AM -0000, benjamin.niven-jenkins@bt.com wrote: > Colleagues, > > I am trying to understand section 7.4 (Separation of Control and Data Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > > The draft states: > "PSC-capable nodes implementing an OOB control plane (perhaps to communicate with an optical switch) MUST NOT use the OOB control plane for data traffic. For example, in the case of MPLS service running on top of a GMPLS LSP, if the peer PSC device is reachable via both the control plane and the data plane, control protocols such as LDP MUST NOT form adjacencies over the control plane interfaces. This may be provided by a combination of implementation features and deployment guidelines." > > So, if the control plane is OOB why must control protocols (such as LDP) NOT form adjacencies over the control plane interfaces? This implies that LDP (for e.g.) MUST form its adjacencies over the data plane interfaces and therefore LDP is not running OOB (and therefore the control plane is not entirely OOB). > > Thanks > Ben > > > -- > Ben Niven-Jenkins > Networking Specialist, BT Exact > > e-mail: benjamin.niven-jenkins@bt.com > tel: +44(0) 1473 648225 > mob: +44(0) 7918 077205 > > pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, UK > > BT Exact is a trademark of British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > > This electronic message contains information from British Telecommunications which may be privileged or confidential. The information is intended to be for the use of the individual(s) or the entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. > > Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. -- --- Asok the Intern ---------------------------------------- Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) From owner-ccamp@ops.ietf.org Tue Mar 8 09:02:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24768 for ; Tue, 8 Mar 2005 09:02:54 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8fKu-0004zT-F4 for ccamp-archive@ietf.org; Tue, 08 Mar 2005 09:05:25 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8fBs-000Ket-BE for ccamp-data@psg.com; Tue, 08 Mar 2005 13:56:04 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8fBq-000KeJ-Sm; Tue, 08 Mar 2005 13:56:03 +0000 Message-ID: <422DAEF5.6070803@psg.com> Date: Tue, 08 Mar 2005 14:56:05 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ashok Narayanan CC: benjamin.niven-jenkins@bt.com, ccamp@ops.ietf.org Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt References: <20050308132122.GB32112@cisco.com> In-Reply-To: <20050308132122.GB32112@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Content-Transfer-Encoding: 7bit ashok - this section is indeed to be clarified 1. for non-PSC it should distinguish the logical from the physical control channel separation with respect to the data plane channels, i do not see for instance why DCC channels could not be used to exchange control plane traffic and still keep a logical separation 2. for PSC - why is there something different in terms of "practice" than what is currently used in MPLS networks ? or 3. do you assume that the interconnection of a PSC with non-PSC network (both driven by GMPLS) could indeed introduce change from the current practices operators used to use for their packet networks ? that in case could be further applied to PSC-only networks ? thanks, - dimitri. Ashok Narayanan wrote: > Ben, > > Thanks for the comment. We'll try to clarify this in the next > version. > > -Ashok > > On Tue, Mar 08, 2005 at 01:14:08PM -0000, > benjamin.niven-jenkins@bt.com wrote: > >> Ashok, >> >> Thanks for the explanation. If I understand correctly what you are >> saying is that the best current practice is to use an OOB control >> plane for the non-PSC layer networks and an in-band control plane >> for the PSC layer networks. So one must avoid using the control >> plane network (of a non-PSC layer network) for the transfer of data >> (or control) plane packets from the PSC layer network's control & >> data planes. Fine, I agree that is the BCP, but I don't believe >> the current draft articulates that intent very well and section 7.4 >> probably needs expanding (IMO one or two paragraphs is probably not >> enough to discuss/address/detail OOB Vs in-band properly and >> unambiguously), for example it is not IMO clear from the current >> text that you are talking about 2 separate control plane networks - >> one OOB (for non-PSC layer networks/nodes) and one inband (for PSC >> layer networks/nodes). >> >> Thanks Ben >> >> >>> -----Original Message----- From: Ashok Narayanan >>> [mailto:ashokn@cisco.com] Sent: 08 March 2005 12:59 To: >>> Niven-jenkins,B,Ben,XDE73 R Cc: ccamp@ops.ietf.org Subject: Re: >>> Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt >>> >>> >>> >>>> I am trying to understand section 7.4 (Separation of >>> >>> Control and Data Plane Traffic) of >>> draft-shiomoto-ccamp-gmpls-addressing-00.txt better. >>> >>>> The draft states: "PSC-capable nodes implementing an OOB >>>> control plane (perhaps to communicate with an optical switch) >>>> MUST NOT use the OOB control plane for data traffic. For >>>> example, in the case of MPLS service running on top of a GMPLS >>>> LSP, if the peer PSC device is reachable via both the control >>>> plane and the data plane, control protocols such as LDP MUST >>>> NOT form adjacencies over the control plane interfaces. This >>>> may be provided by a combination of implementation features and >>>> deployment guidelines." >>>> >>>> So, if the control plane is OOB why must control protocols >>>> (such as LDP) NOT form adjacencies over the control plane >>>> interfaces? This implies that LDP (for e.g.) MUST form its >>>> adjacencies over the data plane interfaces and therefore LDP is >>>> not running OOB (and therefore the control plane is not >>>> entirely OOB). >>>> >>> >>> That's an interesting question. The draft focuses on GMPLS/TE >>> deployments and the use of an out-of-band control channel as a >>> matter of necessity (i.e. because optical switches are not >>> capable of handling in-band control traffic). Consider the >>> general deployment of a core of optical switches surrounded by >>> GMPLS/TE routers at the edge. From the perspective of this >>> network (optical switches, edge routers, and the links in >>> between), that statement translates to: >>> >>> _ The GMPLS/TE control plane between the edge routers and the >>> optical switches in the core is entirely out-of-band >>> >>> - All other protocols between the edge routers MUST be entirely >>> in-band. >>> >>> The control plane network may well be a series of point-to-point >>> GRE tunnels overlaid on some other low-bandwidth network >>> (actually this is what the draft recommends). Ordinarily one >>> would establish a GRE tunnel between each pair of neighbors so >>> they can talk to each other. But this means that signalling >>> messages going from edge router to edge router actually have to >>> be routed through the control planes of intermediate switches. >>> The two alternatives to avoid this (to create a full mesh of GRE >>> tunnels - at least between all the edge routers - or to not use >>> GRE at all if the control plane is switched Ethernet, and >>> therefore to essentially permit a full mesh of OSPF peers) are >>> not really palatable (and in the case of SDCC, not usable). The >>> optical switches in the core should not be in the business of >>> routing packets. Sometimes they have to (e.g. Notify messages), >>> but they are not designed for this purpose and should not be >>> deployed as such. >>> >>> And practically speaking the control network is expected to be a >>> low-bandwidth network that can "just get the job done". A single >>> 10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle >>> the control traffic for a GMPLS/TE network, but will probably >>> fail if we want to use it to peer LDP or BGP for 10,000 >>> prefixes/labels between the edge routers. >>> >>> The best current practice is therefore to use the low-bandwidth >>> control network between routers and switches for GMPLS/TE >>> signaling (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical >>> TE LSPs signalled between edge routers to do other L3 protocols >>> between them. >>> >>> The issue of a separated control plane between PSC edge routers >>> for different L3 protocols for administrative reasons is an >>> interesting one. Nothing precludes you from creating multiple >>> parallel LSPs between edge routers and using one of them to carry >>> control traffic between the two edge routers on behalf of all the >>> others; that would still satisfy this requirement. Alternatively, >>> one could engineer a more beefy control plane network so that it >>> can in fact carry all the control plane traffic (BGP, LDP etc.) >>> but that is not the BCP today based on available implementations. >>> >>> >>> -Ashok >>> >>> On Tue, Mar 08, 2005 at 10:33:54AM -0000, >>> benjamin.niven-jenkins@bt.com wrote: >>> >>>> Colleagues, >>>> >>>> I am trying to understand section 7.4 (Separation of >>> >>> Control and Data Plane Traffic) of >>> draft-shiomoto-ccamp-gmpls-addressing-00.txt better. >>> >>>> The draft states: "PSC-capable nodes implementing an OOB >>>> control plane >>> >>> (perhaps to communicate with an optical switch) MUST NOT use the >>> OOB control plane for data traffic. For example, in the case of >>> MPLS service running on top of a GMPLS LSP, if the peer PSC >>> device is reachable via both the control plane and the data >>> plane, control protocols such as LDP MUST NOT form adjacencies >>> over the control plane interfaces. This may be provided by a >>> combination of implementation features and deployment >>> guidelines." >>> >>>> So, if the control plane is OOB why must control protocols >>> >>> (such as LDP) NOT form adjacencies over the control plane >>> interfaces? This implies that LDP (for e.g.) MUST form its >>> adjacencies over the data plane interfaces and therefore LDP is >>> not running OOB (and therefore the control plane is not entirely >>> OOB). >>> >>>> Thanks Ben >>>> >>>> >>>> -- Ben Niven-Jenkins Networking Specialist, BT Exact >>>> >>>> e-mail: benjamin.niven-jenkins@bt.com tel: +44(0) 1473 648225 >>>> mob: +44(0) 7918 077205 >>>> >>>> pp34/161 B81 Callisto House, Adastral Park, Martlesham, >>> >>> Ipswich IP5 3RE, UK >>> >>>> BT Exact is a trademark of British Telecommunications plc >>>> Registered office: 81 Newgate Street London EC1A 7AJ Registered >>>> in England no. 1800000 >>>> >>>> This electronic message contains information from British >>> >>> Telecommunications which may be privileged or confidential. The >>> information is intended to be for the use of the individual(s) or >>> the entity named above. If you are not the intended recipient be >>> aware that any disclosure, copying, distribution or use of the >>> contents of this information is prohibited. If you have received >>> this electronic message in error, please notify us by telephone >>> or email (to the numbers or address above) immediately. >>> >>>> Activity and use of the British Telecommunications plc >>> >>> email system is monitored to secure its effective operation and >>> for other lawful business purposes. Communications using this >>> system will also be monitored and may be recorded to secure >>> effective operation and for other lawful business purposes. >>> >>> -- >>> >>> >>> >>> --- Asok the Intern ---------------------------------------- >>> Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass >>> Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 >>> (Attn: Ashok Narayanan) >>> > > From owner-ccamp@ops.ietf.org Tue Mar 8 09:25:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26518 for ; Tue, 8 Mar 2005 09:25:18 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8fgX-0005Rt-NY for ccamp-archive@ietf.org; Tue, 08 Mar 2005 09:27:49 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8fVj-000Myi-Lu for ccamp-data@psg.com; Tue, 08 Mar 2005 14:16:35 +0000 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8fVi-000MyT-Ix for ccamp@ops.ietf.org; Tue, 08 Mar 2005 14:16:34 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 441A8E0001B2; Tue, 8 Mar 2005 14:16:24 +0000 (GMT) Received: from Puppy ([130.129.133.164] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 14:11:57 +0000 Message-ID: <01b601c523e9$0152c180$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , References: Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Date: Tue, 8 Mar 2005 14:12:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 08 Mar 2005 14:11:57.0375 (UTC) FILETIME=[C9BA6CF0:01C523E8] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Hi, Ben summarized... > Thanks for the explanation. If I understand correctly what you are > saying is that the best current practice is to use an OOB control plane > for the non-PSC layer networks and an in-band control plane for the > PSC layer networks. If that is the intention of the authors of this draft, they will have to fight me :-) I do not see why an in-band control channel for a PSC network would be made a RECOMMEND, SHOULD or MUST. > So one must avoid using the control plane network (of a non-PSC > layer network) for the transfer of data (or control) plane packets from > the PSC layer network's control & data planes. Yes. But more precisely, one must avoid using the control channels for data traffic. Even in-band control channel may use a different address space, and those addresses must not be used for data. Cheers, Adrian From owner-ccamp@ops.ietf.org Tue Mar 8 09:39:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27711 for ; Tue, 8 Mar 2005 09:39:05 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8ftw-0005la-I6 for ccamp-archive@ietf.org; Tue, 08 Mar 2005 09:41:37 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8fis-000O2t-Us for ccamp-data@psg.com; Tue, 08 Mar 2005 14:30:10 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8fio-000O1y-20 for ccamp@ops.ietf.org; Tue, 08 Mar 2005 14:30:07 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 08 Mar 2005 09:30:05 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (shaqzilla.cisco.com [161.44.70.33]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j28EU2jI022130; Tue, 8 Mar 2005 09:30:03 -0500 (EST) Received: from shaqzilla.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j28EU2q1000480; Tue, 8 Mar 2005 09:30:02 -0500 Received: (from ashokn@localhost) by shaqzilla.cisco.com (8.12.11/8.12.11/Submit) id j28ETxqD000476; Tue, 8 Mar 2005 09:29:59 -0500 Date: Tue, 8 Mar 2005 09:29:59 -0500 From: Ashok Narayanan To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Cc: benjamin.niven-jenkins@bt.com, ccamp@ops.ietf.org Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Message-ID: <20050308142959.GE32112@cisco.com> References: <20050308132122.GB32112@cisco.com> <422DAEF5.6070803@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422DAEF5.6070803@psg.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Dimitri, Thanks for the comments. Hopefully this text will get beaten into shape with the attention you folks are paying to it. On Tue, Mar 08, 2005 at 02:56:05PM +0100, dimitri papadimitriou wrote: > ashok - this section is indeed to be clarified > > 1. for non-PSC it should distinguish the logical from the physical > control channel separation with respect to the data plane channels, i do > not see for instance why DCC channels could not be used to exchange > control plane traffic and still keep a logical separation Sure; of course we are not saying that. DCC channels although travelling on the same fiber are logically separated from the data channel on the same fiber. I don't think there is any statement to the contrary. > > 2. for PSC - why is there something different in terms of "practice" > than what is currently used in MPLS networks ? We aren't recommending any. The separated L3 control plane idea I had mentioned was my attempt to understand the kind of application that Ben was getting at when he asked "why must control protocols (such as LDP) NOT form adjacencies over the control plane interfaces". See below. > > or > > 3. do you assume that the interconnection of a PSC with non-PSC network > (both driven by GMPLS) could indeed introduce change from the current > practices operators used to use for their packet networks ? that in case > could be further applied to PSC-only networks ? I'd say the first part of this is slightly true. Let me try and reformulate; please tell me if this is better: "Consider a GMPLS/TE network with optical switches in the core and PSC devices at the edge, with a separated control plane (either OOB or via DCC). The edge PSC devices have IP reachability with each other via both the separated control plane network and via any optical GMPLS/TE LSPs that may be configured between them (the "data traffic network"). For the reasons mentioned below, traffic on the separated control network MUST be limited to GMPLS/TE signalling traffic solely for the purpose of established optical LSPs within the core of optical switches. All bearer traffic carried through this network MUST be carried over GMPLS/TE LSPs and MUST NOT be carried over the separated control network. Further, any protocols that run purely between the PSC devices that are not used for GMPLS/TE signalling within the optical switch core (e.g. protocols for carrying bearer traffic like LDP and BGP) MUST communicate over GMPLS/TE LSPs and MUST NOT form adjacencies or exchange messages over the separated control network." So there is in fact a change from the current practice of a PSC network *only* at the edge of a cloud of optical switches running GMPLS. If this was a regular cloud of routers then we could say "if you have IP reachability over link X, use it". But in the case of an optical switch network we may well have IP reachability through the separated control network but we don't want to use it. Regarding the second part of that question: we are not suggesting any techniques to be applied in PSC-only networks. The separated PSC control plane I alluded to earlier may be a useful idea, but it merits separate treatment and is beyond the scope of this section IMHO. -Ashok > > thanks, > - dimitri. > > Ashok Narayanan wrote: > > >Ben, > > > >Thanks for the comment. We'll try to clarify this in the next > >version. > > > >-Ashok > > > >On Tue, Mar 08, 2005 at 01:14:08PM -0000, > >benjamin.niven-jenkins@bt.com wrote: > > > >>Ashok, > >> > >>Thanks for the explanation. If I understand correctly what you are > >>saying is that the best current practice is to use an OOB control > >>plane for the non-PSC layer networks and an in-band control plane > >>for the PSC layer networks. So one must avoid using the control > >>plane network (of a non-PSC layer network) for the transfer of data > >>(or control) plane packets from the PSC layer network's control & > >>data planes. Fine, I agree that is the BCP, but I don't believe > >>the current draft articulates that intent very well and section 7.4 > >>probably needs expanding (IMO one or two paragraphs is probably not > >>enough to discuss/address/detail OOB Vs in-band properly and > >>unambiguously), for example it is not IMO clear from the current > >>text that you are talking about 2 separate control plane networks - > >>one OOB (for non-PSC layer networks/nodes) and one inband (for PSC > >>layer networks/nodes). > >> > >>Thanks Ben > >> > >> > >>>-----Original Message----- From: Ashok Narayanan > >>>[mailto:ashokn@cisco.com] Sent: 08 March 2005 12:59 To: > >>>Niven-jenkins,B,Ben,XDE73 R Cc: ccamp@ops.ietf.org Subject: Re: > >>>Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt > >>> > >>> > >>> > >>>>I am trying to understand section 7.4 (Separation of > >>> > >>>Control and Data Plane Traffic) of > >>>draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > >>> > >>>>The draft states: "PSC-capable nodes implementing an OOB > >>>>control plane (perhaps to communicate with an optical switch) > >>>>MUST NOT use the OOB control plane for data traffic. For > >>>>example, in the case of MPLS service running on top of a GMPLS > >>>>LSP, if the peer PSC device is reachable via both the control > >>>>plane and the data plane, control protocols such as LDP MUST > >>>>NOT form adjacencies over the control plane interfaces. This > >>>>may be provided by a combination of implementation features and > >>>>deployment guidelines." > >>>> > >>>>So, if the control plane is OOB why must control protocols > >>>>(such as LDP) NOT form adjacencies over the control plane > >>>>interfaces? This implies that LDP (for e.g.) MUST form its > >>>>adjacencies over the data plane interfaces and therefore LDP is > >>>>not running OOB (and therefore the control plane is not > >>>>entirely OOB). > >>>> > >>> > >>>That's an interesting question. The draft focuses on GMPLS/TE > >>>deployments and the use of an out-of-band control channel as a > >>>matter of necessity (i.e. because optical switches are not > >>>capable of handling in-band control traffic). Consider the > >>>general deployment of a core of optical switches surrounded by > >>>GMPLS/TE routers at the edge. From the perspective of this > >>>network (optical switches, edge routers, and the links in > >>>between), that statement translates to: > >>> > >>>_ The GMPLS/TE control plane between the edge routers and the > >>>optical switches in the core is entirely out-of-band > >>> > >>>- All other protocols between the edge routers MUST be entirely > >>>in-band. > >>> > >>>The control plane network may well be a series of point-to-point > >>>GRE tunnels overlaid on some other low-bandwidth network > >>>(actually this is what the draft recommends). Ordinarily one > >>>would establish a GRE tunnel between each pair of neighbors so > >>>they can talk to each other. But this means that signalling > >>>messages going from edge router to edge router actually have to > >>>be routed through the control planes of intermediate switches. > >>>The two alternatives to avoid this (to create a full mesh of GRE > >>>tunnels - at least between all the edge routers - or to not use > >>>GRE at all if the control plane is switched Ethernet, and > >>>therefore to essentially permit a full mesh of OSPF peers) are > >>>not really palatable (and in the case of SDCC, not usable). The > >>>optical switches in the core should not be in the business of > >>>routing packets. Sometimes they have to (e.g. Notify messages), > >>>but they are not designed for this purpose and should not be > >>>deployed as such. > >>> > >>>And practically speaking the control network is expected to be a > >>>low-bandwidth network that can "just get the job done". A single > >>>10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle > >>>the control traffic for a GMPLS/TE network, but will probably > >>>fail if we want to use it to peer LDP or BGP for 10,000 > >>>prefixes/labels between the edge routers. > >>> > >>>The best current practice is therefore to use the low-bandwidth > >>>control network between routers and switches for GMPLS/TE > >>>signaling (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical > >>>TE LSPs signalled between edge routers to do other L3 protocols > >>>between them. > >>> > >>>The issue of a separated control plane between PSC edge routers > >>>for different L3 protocols for administrative reasons is an > >>>interesting one. Nothing precludes you from creating multiple > >>>parallel LSPs between edge routers and using one of them to carry > >>>control traffic between the two edge routers on behalf of all the > >>>others; that would still satisfy this requirement. Alternatively, > >>>one could engineer a more beefy control plane network so that it > >>>can in fact carry all the control plane traffic (BGP, LDP etc.) > >>>but that is not the BCP today based on available implementations. > >>> > >>> > >>>-Ashok > >>> > >>>On Tue, Mar 08, 2005 at 10:33:54AM -0000, > >>>benjamin.niven-jenkins@bt.com wrote: > >>> > >>>>Colleagues, > >>>> > >>>>I am trying to understand section 7.4 (Separation of > >>> > >>>Control and Data Plane Traffic) of > >>>draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > >>> > >>>>The draft states: "PSC-capable nodes implementing an OOB > >>>>control plane > >>> > >>>(perhaps to communicate with an optical switch) MUST NOT use the > >>>OOB control plane for data traffic. For example, in the case of > >>>MPLS service running on top of a GMPLS LSP, if the peer PSC > >>>device is reachable via both the control plane and the data > >>>plane, control protocols such as LDP MUST NOT form adjacencies > >>>over the control plane interfaces. This may be provided by a > >>>combination of implementation features and deployment > >>>guidelines." > >>> > >>>>So, if the control plane is OOB why must control protocols > >>> > >>>(such as LDP) NOT form adjacencies over the control plane > >>>interfaces? This implies that LDP (for e.g.) MUST form its > >>>adjacencies over the data plane interfaces and therefore LDP is > >>>not running OOB (and therefore the control plane is not entirely > >>>OOB). > >>> > >>>>Thanks Ben > >>>> > >>>> > >>>>-- Ben Niven-Jenkins Networking Specialist, BT Exact > >>>> > >>>>e-mail: benjamin.niven-jenkins@bt.com tel: +44(0) 1473 648225 > >>>>mob: +44(0) 7918 077205 > >>>> > >>>>pp34/161 B81 Callisto House, Adastral Park, Martlesham, > >>> > >>>Ipswich IP5 3RE, UK > >>> > >>>>BT Exact is a trademark of British Telecommunications plc > >>>>Registered office: 81 Newgate Street London EC1A 7AJ Registered > >>>>in England no. 1800000 > >>>> > >>>>This electronic message contains information from British > >>> > >>>Telecommunications which may be privileged or confidential. The > >>>information is intended to be for the use of the individual(s) or > >>>the entity named above. If you are not the intended recipient be > >>>aware that any disclosure, copying, distribution or use of the > >>>contents of this information is prohibited. If you have received > >>>this electronic message in error, please notify us by telephone > >>>or email (to the numbers or address above) immediately. > >>> > >>>>Activity and use of the British Telecommunications plc > >>> > >>>email system is monitored to secure its effective operation and > >>>for other lawful business purposes. Communications using this > >>>system will also be monitored and may be recorded to secure > >>>effective operation and for other lawful business purposes. > >>> > >>>-- > >>> > >>> > >>> > >>>--- Asok the Intern ---------------------------------------- > >>>Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass > >>>Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 > >>>(Attn: Ashok Narayanan) > >>> > > > > -- --- Asok the Intern ---------------------------------------- Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) From owner-ccamp@ops.ietf.org Tue Mar 8 10:04:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02031 for ; Tue, 8 Mar 2005 10:04:24 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8gIR-0006j9-JC for ccamp-archive@ietf.org; Tue, 08 Mar 2005 10:06:56 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8g4A-000PuY-B0 for ccamp-data@psg.com; Tue, 08 Mar 2005 14:52:10 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8g3z-000PtF-KH for ccamp@ops.ietf.org; Tue, 08 Mar 2005 14:51:59 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 08 Mar 2005 06:55:12 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,147,1107763200"; d="scan'208"; a="165768196:sNHT9866318044" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j28EpouC000512; Tue, 8 Mar 2005 06:51:51 -0800 (PST) Received: from magnify.cisco.com (magnify.cisco.com [161.44.123.79]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APQ23648; Tue, 8 Mar 2005 09:51:51 -0500 (EST) Received: (ashokn@localhost) by magnify.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA15113; Tue, 8 Mar 2005 09:51:51 -0500 (EST) Date: Tue, 8 Mar 2005 09:51:50 -0500 From: Ashok Narayanan To: Adrian Farrel Cc: benjamin.niven-jenkins@bt.com, ccamp@ops.ietf.org Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Message-ID: <20050308145150.GA28982@cisco.com> References: <01b601c523e9$0152c180$a4858182@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01b601c523e9$0152c180$a4858182@Puppy> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b On Tue, Mar 08, 2005 at 02:12:54PM -0000, Adrian Farrel wrote: > Hi, > > Ben summarized... > > > Thanks for the explanation. If I understand correctly what you are > > saying is that the best current practice is to use an OOB control plane > > for the non-PSC layer networks and an in-band control plane for the > > PSC layer networks. > > If that is the intention of the authors of this draft, they will have to > fight me :-) I better check out this website: http://www.all-karate.com/how_to_learn_karate.php > I do not see why an in-band control channel for a PSC network would be > made a RECOMMEND, SHOULD or MUST. That is certainly not the recommendation (phew). I clarified in a separate email, but basically the point we are making is that in an optical GMPLS/TE network with optical switches in the core and PSC devices on the edge, edge-to-edge protocols not used for GMPLS/TE signalling within the core must be kept off the separated control network. I think the text needs to be tightened up to say this; I sent out an alternative formulation just now, let's see how that goes. > > > So one must avoid using the control plane network (of a non-PSC > > layer network) for the transfer of data (or control) plane packets from > > the PSC layer network's control & data planes. > > Yes. But more precisely, one must avoid using the control channels for > data traffic. Even in-band control channel may use a different address > space, and those addresses must not be used for data. Which is fine, but then raises the question: what is "data"? Bearer traffic? SIP messages transiting through a number of hops to get here? IPv4 RSVP for QoS? BGP or LDP running between the PSCs? I claim that for the aforementioned "GMPLS/TE-optical-core-PSC-edge" network, *all* of the aforementioned must be kept off the separated control plane *used for GMPLS within the optical core*. Nothing prevents these other protocols from having their own separated control plane, just as long as that other control plane also goes over a GMPLS/TE LSP or via some other "data" path. What I'm trying to say is that the optical switches in the core should basically not have to ever see any signalling or data packets that don't pertain to GMPLS/TE signalling within the optical core. In summary: (is this a better way to write this in the draft?) 1) A core of optical switches with PSC edge devices running GMPLS may use a separated control network (DCC, OOB Ethernet, or some other) to carry GMPLS/TE signalling messages. Further, this control network may be low-bandwidth and may pass through devices that are not well suited for IP routing. 2) Bearer data traffic transiting this network MUST NOT be carried on this separated control network. 3) Further, given the nature of the control network and the devices that maintain it, protocols running between the PSC edge devices that are not used for GMPLS/TE signalling within the core MUST NOT be carried over this control network. (N.B. should this be relaxed to a "SHOULD"?) This does not preclude these other protocols from running separated control planes of their own, as long as the protocol signalling messages do not transit the separated control network used within the GMPLS/TE core. -Ashok --- Asok the Intern ---------------------------------------- Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) From owner-ccamp@ops.ietf.org Tue Mar 8 10:29:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05950 for ; Tue, 8 Mar 2005 10:29:10 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8ggP-0007Jk-Q7 for ccamp-archive@ietf.org; Tue, 08 Mar 2005 10:31:42 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8gVt-0003Fh-C3 for ccamp-data@psg.com; Tue, 08 Mar 2005 15:20:49 +0000 Received: from [217.32.164.151] (helo=smtp4.smtp.bt.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8gVp-0003FC-72 for ccamp@ops.ietf.org; Tue, 08 Mar 2005 15:20:45 +0000 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 8 Mar 2005 15:20:43 +0000 Received: from i2km11-ukbr.domain1.systemhost.net ([193.113.197.28]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Mar 2005 15:20:43 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Date: Tue, 8 Mar 2005 15:20:43 -0000 Message-ID: Thread-Topic: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Thread-Index: AcUj7mJ60OKsLVUhR2OZjc+ClTML9wAAe5dQ From: To: , Cc: X-OriginalArrivalTime: 08 Mar 2005 15:20:43.0506 (UTC) FILETIME=[65180D20:01C523F2] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable Ashok, I think one of the key points that needs highlighting explicitly which = is not clear in the draft or your text below is that there are two = separate control networks: 1) One control network for the non-PSC core.=20 2) One control network for the PSC edge nodes. Network (1) has to be OOB as a forced requirement of the co-cs mode. Network (2) does not have to be OOB but it may be (it's down to operator = choice/policy etc.). If you look at the whole network stack you have trails in the non-PSC = core layer network supporting link connections in the PSC layer network. = These non-PSC layer network trails may be used to support link = connections in the PSC layer network that may be assigned to carry only = 'PSC data traffic' (for the PSC data plane), only 'PSC control traffic' = (for the PSC control plane when it's taken OOB) or both 'PSC data and = control plane traffic' (when the PSC control plane is inband wrt the PSC = data plane). =20 In other words, the non-PSC layer network has it's own data & control = plane networks that are (or should be) decoupled from the PSC layer = network (which has its own data & control plane networks). non-PSC = layer network data plane trails can be used to support PSC layer network = data (and/or control) plane link connections, but non-PSC layer network = control plane trails MUST NOT be used to support PSC layer network data = (and/or control) plane link connections. This behaviour should be = recursive from the lowest to the highest layer in the network stack.=20 Ben > -----Original Message----- > From: Ashok Narayanan [mailto:ashokn@cisco.com] > Sent: 08 March 2005 14:52 > To: Adrian Farrel > Cc: Niven-jenkins,B,Ben,XDE73 R; ccamp@ops.ietf.org > Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt >=20 >=20 > On Tue, Mar 08, 2005 at 02:12:54PM -0000, Adrian Farrel wrote: > > Hi, > >=20 > > Ben summarized... > >=20 > > > Thanks for the explanation. If I understand correctly=20 > what you are > > > saying is that the best current practice is to use an OOB=20 > control plane > > > for the non-PSC layer networks and an in-band control=20 > plane for the > > > PSC layer networks. > >=20 > > If that is the intention of the authors of this draft, they=20 > will have to > > fight me :-) >=20 > I better check out this website: > http://www.all-karate.com/how_to_learn_karate.php >=20 > > I do not see why an in-band control channel for a PSC=20 > network would be > > made a RECOMMEND, SHOULD or MUST. >=20 > That is certainly not the recommendation (phew).=20 >=20 > I clarified in a separate email, but basically the point we are making > is that in an optical GMPLS/TE network with optical switches in the > core and PSC devices on the edge, edge-to-edge protocols not used for > GMPLS/TE signalling within the core must be kept off the separated > control network. I think the text needs to be tightened up to say > this; I sent out an alternative formulation just now, let's see how > that goes. >=20 > >=20 > > > So one must avoid using the control plane network (of a non-PSC > > > layer network) for the transfer of data (or control)=20 > plane packets from > > > the PSC layer network's control & data planes. > >=20 > > Yes. But more precisely, one must avoid using the control=20 > channels for > > data traffic. Even in-band control channel may use a=20 > different address > > space, and those addresses must not be used for data. >=20 > Which is fine, but then raises the question: what is "data"? Bearer > traffic? SIP messages transiting through a number of hops to get here? > IPv4 RSVP for QoS? BGP or LDP running between the PSCs? I claim that > for the aforementioned "GMPLS/TE-optical-core-PSC-edge" network, *all* > of the aforementioned must be kept off the separated control plane > *used for GMPLS within the optical core*. Nothing prevents these other > protocols from having their own separated control plane, just as long > as that other control plane also goes over a GMPLS/TE LSP or via some > other "data" path. >=20 > What I'm trying to say is that the optical switches in the core should > basically not have to ever see any signalling or data packets that > don't pertain to GMPLS/TE signalling within the optical core. >=20 > In summary: (is this a better way to write this in the draft?) >=20 > 1) A core of optical switches with PSC edge devices running GMPLS may > use a separated control network (DCC, OOB Ethernet, or some other) to > carry GMPLS/TE signalling messages. Further, this control network may > be low-bandwidth and may pass through devices that are not well suited > for IP routing. >=20 > 2) Bearer data traffic transiting this network MUST NOT be carried on > this separated control network. >=20 > 3) Further, given the nature of the control network and the devices > that maintain it, protocols running between the PSC edge devices that > are not used for GMPLS/TE signalling within the core MUST NOT be > carried over this control network. (N.B. should this be relaxed to a > "SHOULD"?) This does not preclude these other protocols from running > separated control planes of their own, as long as the protocol > signalling messages do not transit the separated control network used > within the GMPLS/TE core. >=20 > -Ashok >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --- Asok the Intern ---------------------------------------- > Ashok Narayanan > IOS Network Protocols, Cisco Systems > 1414 Mass Ave, Boxborough MA 01719 > Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) >=20 From owner-ccamp@ops.ietf.org Tue Mar 8 10:50:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08948 for ; Tue, 8 Mar 2005 10:50:35 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8h19-0007ua-9x for ccamp-archive@ietf.org; Tue, 08 Mar 2005 10:53:07 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D8gpK-0004z6-Mq for ccamp-data@psg.com; Tue, 08 Mar 2005 15:40:54 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8gpH-0004yW-4K for ccamp@ops.ietf.org; Tue, 08 Mar 2005 15:40:51 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 08 Mar 2005 10:40:50 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (shaqzilla.cisco.com [161.44.70.33]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j28FeljI012603; Tue, 8 Mar 2005 10:40:48 -0500 (EST) Received: from shaqzilla.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j28Felrm001154; Tue, 8 Mar 2005 10:40:47 -0500 Received: (from ashokn@localhost) by shaqzilla.cisco.com (8.12.11/8.12.11/Submit) id j28Feiab001152; Tue, 8 Mar 2005 10:40:44 -0500 Date: Tue, 8 Mar 2005 10:40:44 -0500 From: Ashok Narayanan To: benjamin.niven-jenkins@bt.com Cc: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Message-ID: <20050308154044.GA1098@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 On Tue, Mar 08, 2005 at 03:20:43PM -0000, benjamin.niven-jenkins@bt.com wrote: > Ashok, > > I think one of the key points that needs highlighting explicitly which is not clear in the draft or your text below is that there are two separate control networks: > 1) One control network for the non-PSC core. > 2) One control network for the PSC edge nodes. Maybe that division is not as clear as it needs to be. Which network of those two do the following belong to?: 1) Path message for an optical LSP generated by a PSC edge node. 2) NOTIFY message from a PSC edge node to the other PSC edge node for an optical LSP. 3) Path message for a frame LSP going over an optical LSP generated by a PSC edge node. 4) LDP messages exchanged between PSC edge nodes. 5) SIP messages transiting the PSC edge nodes. There are plenty of different control plane levels here, so rather than talk about two specific ones, I would like to differentiate between a) "Messages for GMPLS/TE routing/signalling of optical LSPs between the PSC edge devices and the optical core devices" b) "everything else". I want to say that if we use a separated control network for "a)", then any and all traffic for "b)" MUST NOT go over that control network. Everything else is to clarify (and may insert additional ambiguities of its own :-() > > Network (1) has to be OOB as a forced requirement of the co-cs mode. Not necessarily OOB, but "separated". I think this is the point that Dimitri was making. DCC is not necessarily considered OOB, but it is a separated control plane. > Network (2) does not have to be OOB but it may be (it's down to operator choice/policy etc.). Yes, and the specific statement is that traffic in network 2 cannot transit the separated control plane used for network 1. Whether it is separated or not is not relevant as you correctly point out. > > If you look at the whole network stack you have trails in the non-PSC core layer network supporting link connections in the PSC layer network. These non-PSC layer network trails may be used to support link connections in the PSC layer network that may be assigned to carry only 'PSC data traffic' (for the PSC data plane), only 'PSC control traffic' (for the PSC control plane when it's taken OOB) or both 'PSC data and control plane traffic' (when the PSC control plane is inband wrt the PSC data plane). > > In other words, the non-PSC layer network has it's own data & > control plane networks that are (or should be) decoupled from the > PSC layer network (which has its own data & control plane networks). > non-PSC layer network data plane trails can be used to support PSC > layer network data (and/or control) plane link connections, but > non-PSC layer network control plane trails MUST NOT be used to > support PSC layer network data (and/or control) plane link > connections. I agree. I would phrase this as a "clarification" of b) above; clarifying that PSC layer network control traffic falls in the "everything else" category w.r.t the optical network. > This behaviour should be recursive from the lowest to > the highest layer in the network stack. That's not necessarily what I'm saying but it's not bad. > > Ben > > > -----Original Message----- > > From: Ashok Narayanan [mailto:ashokn@cisco.com] > > Sent: 08 March 2005 14:52 > > To: Adrian Farrel > > Cc: Niven-jenkins,B,Ben,XDE73 R; ccamp@ops.ietf.org > > Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt > > > > > > On Tue, Mar 08, 2005 at 02:12:54PM -0000, Adrian Farrel wrote: > > > Hi, > > > > > > Ben summarized... > > > > > > > Thanks for the explanation. If I understand correctly > > what you are > > > > saying is that the best current practice is to use an OOB > > control plane > > > > for the non-PSC layer networks and an in-band control > > plane for the > > > > PSC layer networks. > > > > > > If that is the intention of the authors of this draft, they > > will have to > > > fight me :-) > > > > I better check out this website: > > http://www.all-karate.com/how_to_learn_karate.php > > > > > I do not see why an in-band control channel for a PSC > > network would be > > > made a RECOMMEND, SHOULD or MUST. > > > > That is certainly not the recommendation (phew). > > > > I clarified in a separate email, but basically the point we are making > > is that in an optical GMPLS/TE network with optical switches in the > > core and PSC devices on the edge, edge-to-edge protocols not used for > > GMPLS/TE signalling within the core must be kept off the separated > > control network. I think the text needs to be tightened up to say > > this; I sent out an alternative formulation just now, let's see how > > that goes. > > > > > > > > > So one must avoid using the control plane network (of a non-PSC > > > > layer network) for the transfer of data (or control) > > plane packets from > > > > the PSC layer network's control & data planes. > > > > > > Yes. But more precisely, one must avoid using the control > > channels for > > > data traffic. Even in-band control channel may use a > > different address > > > space, and those addresses must not be used for data. > > > > Which is fine, but then raises the question: what is "data"? Bearer > > traffic? SIP messages transiting through a number of hops to get here? > > IPv4 RSVP for QoS? BGP or LDP running between the PSCs? I claim that > > for the aforementioned "GMPLS/TE-optical-core-PSC-edge" network, *all* > > of the aforementioned must be kept off the separated control plane > > *used for GMPLS within the optical core*. Nothing prevents these other > > protocols from having their own separated control plane, just as long > > as that other control plane also goes over a GMPLS/TE LSP or via some > > other "data" path. > > > > What I'm trying to say is that the optical switches in the core should > > basically not have to ever see any signalling or data packets that > > don't pertain to GMPLS/TE signalling within the optical core. > > > > In summary: (is this a better way to write this in the draft?) > > > > 1) A core of optical switches with PSC edge devices running GMPLS may > > use a separated control network (DCC, OOB Ethernet, or some other) to > > carry GMPLS/TE signalling messages. Further, this control network may > > be low-bandwidth and may pass through devices that are not well suited > > for IP routing. > > > > 2) Bearer data traffic transiting this network MUST NOT be carried on > > this separated control network. > > > > 3) Further, given the nature of the control network and the devices > > that maintain it, protocols running between the PSC edge devices that > > are not used for GMPLS/TE signalling within the core MUST NOT be > > carried over this control network. (N.B. should this be relaxed to a > > "SHOULD"?) This does not preclude these other protocols from running > > separated control planes of their own, as long as the protocol > > signalling messages do not transit the separated control network used > > within the GMPLS/TE core. > > > > -Ashok > > > > > > > > > > > > > > > > --- Asok the Intern ---------------------------------------- > > Ashok Narayanan > > IOS Network Protocols, Cisco Systems > > 1414 Mass Ave, Boxborough MA 01719 > > Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) > > -- --- Asok the Intern ---------------------------------------- Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) From owner-ccamp@ops.ietf.org Wed Mar 9 13:34:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05162 for ; Wed, 9 Mar 2005 13:34:21 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D963O-0007QR-Tf for ccamp-archive@ietf.org; Wed, 09 Mar 2005 13:37:09 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D95rw-000KQS-Bo for ccamp-data@psg.com; Wed, 09 Mar 2005 18:25:16 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D95rs-000KQ5-2F for ccamp@ops.ietf.org; Wed, 09 Mar 2005 18:25:12 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id C165DE00017A; Wed, 9 Mar 2005 18:25:04 +0000 (GMT) Received: from Puppy ([130.129.133.164] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Mar 2005 18:21:47 +0000 Message-ID: <037201c524d5$12786040$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" Subject: Two LSs from ITU-T SG15's Q14/15 to IETF CCAMP WG Date: Wed, 9 Mar 2005 18:20:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 09 Mar 2005 18:21:48.0092 (UTC) FILETIME=[DB4E0FC0:01C524D4] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,DEAR_SOMETHING autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.2 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Hi, We have received two liaison statements from ITU-T Study Group 15 Question 14. I have put these on the alternate ccamp web site at http://www.olddog.co.uk/incoming.htm I will send separate emails to include the text of the liaisons and propose actions. Adrian ----- Original Message ----- From: To: ; ; ; ; ; ; Cc: ; ; ; Sent: Wednesday, March 09, 2005 3:45 PM Subject: Two LSs from ITU-T SG15's Q14/15 to IETF CCAMP WG Dear Sirs, On behalf of the Chairman of ITU-T Study Group 15, I am pleased to send you two Liaison Statements agreed at the SG15 Q.14/15 Interim Meeting, 24 - 28 January 2005: 1) To IETF CCAMP WG on Crankback in GMPLS Systems 2) To IETF CCAMP WG on the Comparison of LMP and ASON Discovery Best regards, Greg Jones Counsellor, ITU-T Study Group 15 From owner-ccamp@ops.ietf.org Wed Mar 9 13:43:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05891 for ; Wed, 9 Mar 2005 13:43:15 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D96C2-0007dZ-Vi for ccamp-archive@ietf.org; Wed, 09 Mar 2005 13:46:03 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D963f-000Lgz-B4 for ccamp-data@psg.com; Wed, 09 Mar 2005 18:37:23 +0000 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D963e-000Lgh-FD for ccamp@ops.ietf.org; Wed, 09 Mar 2005 18:37:22 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 15881E000260; Wed, 9 Mar 2005 18:37:11 +0000 (GMT) Received: from Puppy ([130.129.133.164] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Mar 2005 18:30:02 +0000 Message-ID: <037801c524d6$39035c50$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" , "Scott Bradner" , "Scott W Brim" Subject: Liaison from ITU-T Q14/15 on crankback Date: Wed, 9 Mar 2005 18:28:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 09 Mar 2005 18:30:02.0318 (UTC) FILETIME=[01E2F6E0:01C524D6] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Hi, This is the first of the two liaisons form an ITU-T meeting held in January that arrived today. It is an informational liaison and no action is required. However, I propose that we should respond asking to be involved in the review of the proposed additions of crankback function to the referenced recommendations before that material is consented (last-called) by the ITU-T. This would allow us to correct any misunderstandings about our draft. Please comment on this proposal on the mail list. Thanks, Adrian ==== The content of this liaison is as follows: Subject: Liaison Statement to IETF CCAMP WG on Crankback in GMPLS Systems To: Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs Cc: Alex Zinin and Bill Fenner, IETF Routing Area Directors Scott Bradner, IETF liaison to ITU-T Thank you for your response to our liaison regarding crankback as described in . Q14/15 appreciates the clarifications and will use this to develop protocol requirements for the next revision of G.7713 ("Distributed call and connection management"). In particular, we need to incorporate crankback into the call model. After that, the protocol details from can be incorporated into G.7713.2. An electronic copy of this liaison statement can be found at ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html From owner-ccamp@ops.ietf.org Wed Mar 9 13:47:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06358 for ; Wed, 9 Mar 2005 13:47:39 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D96GJ-0007mI-CW for ccamp-archive@ietf.org; Wed, 09 Mar 2005 13:50:27 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D963j-000LhU-77 for ccamp-data@psg.com; Wed, 09 Mar 2005 18:37:27 +0000 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D963h-000Lh7-Te for ccamp@ops.ietf.org; Wed, 09 Mar 2005 18:37:26 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id E683FE000261; Wed, 9 Mar 2005 18:37:21 +0000 (GMT) Received: from Puppy ([130.129.133.164] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Mar 2005 18:35:53 +0000 Message-ID: <037e01c524d7$0a7a8f60$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" , "Scott Bradner" , "Scott W Brim" Subject: Liaison from ITU-T Q14/15 on Transport use of LMP Date: Wed, 9 Mar 2005 18:37:00 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0379_01C524D6.FB0E0B10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 09 Mar 2005 18:35:54.0391 (UTC) FILETIME=[D3BD0A70:01C524D6] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 This is a multi-part message in MIME format. ------=_NextPart_000_0379_01C524D6.FB0E0B10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This is the second of the two liaisons form an ITU-T meeting held in = January that arrived today. It is an informational liaison and no action is required. However, the liaison suggests that two items are considered within the = Transport LMP draft. I would appreciate it if the editor and authors of = that draft sent some thoughts on this to the ccamp list. I can then = judge consensus on these thoughts and respond to the liaison as = appropriate. Thanks, Adrian ---- The content of the liaison is as follows: Subject: Liaison Statement to IETF CCAMP WG on the Comparison of LMP and = ASON Discovery To: Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs From: Alex Zinin and Bill Fenner, IETF Routing Area Directors Scott Bradner, IETF liaison to ITU-T Thank you for your response to our liaison on this topic. As noted in = your liaison some experts from the IETF were able to attend the Q14/15 = meeting. As a result of the discussion of terminology we have the = following observations that we suggest should be incorporated into = draft-ietf-ccamp-transport-lmp-00.txt to provide some additional context = that will aid the members of the IETF in understanding the terminology = used by the ITU-T. =20 In your liaison you state that an SNPP link could easily be mapped to a = TE link. However, discussion at the meeting revealed some subtle but = important differences: - The SNPP link construct is defined to support hierarchical = containment. However, since the IETF has not yet addressed hierarchical routing the current description of a TE link does not (explicitly) include the=20 notion of hierarchical containment. - In the ITU the properties of a node are described explicitly in terms = of=20 adaptation/termination functions and the binding of these functions to = subnetworks (within the node) and links (which are attached to the = node). In the IETF the capabilities and properties of a node are inferred = from=20 the description of the properties of the link ends that terminate on = node. =20 An electronic copy of this liaison statement can be found at = ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICAT= IONS/index.html ------=_NextPart_000_0379_01C524D6.FB0E0B10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

This is the second of the = two liaisons=20 form an ITU-T meeting held in January that arrived today.
It is an=20 informational liaison and no action is required.
 
However, the liaison suggests that = two items are=20 considered within the Transport LMP draft. I would appreciate it if the = editor=20 and authors of that draft sent some thoughts on this to the ccamp list. = I can=20 then judge consensus on these thoughts and respond to the liaison as=20 appropriate.
 
Thanks,
Adrian
 
----

The content of the liaison is as = follows:

Subject:=20 Liaison Statement to IETF CCAMP WG on the Comparison of LMP and ASON=20 Discovery
To: Adrian Farrel and Kireeti Kompella, IETF CCAMP=20 co-chairs
From: Alex Zinin and Bill Fenner, IETF Routing Area=20 Directors
        Scott Bradner, = IETF=20 liaison to ITU-T

Thank you for your response to our liaison on = this=20 topic.  As noted in your liaison some experts from the IETF were = able to=20 attend the Q14/15 meeting.  As a result of the discussion of = terminology we=20 have the following observations that we suggest should be incorporated = into=20 draft-ietf-ccamp-transport-lmp-00.txt to provide some additional context = that=20 will aid the members of the IETF in understanding the terminology used = by the=20 ITU-T. 

In your=20 liaison you state that an SNPP link could easily be mapped to a TE = link. =20 However, discussion at the meeting revealed some subtle but important=20 differences:

- The SNPP=20 link construct is defined to support hierarchical = containment.
  However, since the IETF has = not yet=20 addressed hierarchical routing the
  current description of a = TE link does=20 not (explicitly) include the
  notion of hierarchical=20 containment.

- In the ITU the properties of a node are described explicitly = in terms=20 of
  adaptation/termination functions and the binding of these = functions=20 to
  subnetworks (within the node) and links (which are attached = to the=20 node).
  In the IETF the capabilities and properties of a node are = inferred=20 from
  the description of the properties of the link ends that = terminate on=20 node.
 
An electronic copy of this liaison statement can be = found at=20 ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICAT= IONS/index.html
------=_NextPart_000_0379_01C524D6.FB0E0B10-- From owner-ccamp@ops.ietf.org Wed Mar 9 14:49:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12830 for ; Wed, 9 Mar 2005 14:49:35 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D97ED-0000wt-RW for ccamp-archive@ietf.org; Wed, 09 Mar 2005 14:52:22 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D972Q-0002Qs-Uv for ccamp-data@psg.com; Wed, 09 Mar 2005 19:40:10 +0000 Received: from [12.20.58.69] (helo=ckmso1.proxy.att.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D972P-0002QW-GT for ccamp@ops.ietf.org; Wed, 09 Mar 2005 19:40:10 +0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j29JdmCK012975 for ; Wed, 9 Mar 2005 14:40:08 -0500 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (7.2.052) id 4229269A000F2836; Wed, 9 Mar 2005 14:40:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Liaison from ITU-T Q14/15 on crankback Date: Wed, 9 Mar 2005 13:40:07 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA060C88F4@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Liaison from ITU-T Q14/15 on crankback Thread-Index: AcUk1zNT05BSpbiyTOigN342BKTmjwACE/HA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , Cc: "Ash, Gerald R \(Jerry\), ALABS" , "Kireeti Kompella" , "Scott Bradner" , "Scott W Brim" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Adrian, > However, I propose that we should respond asking to be=20 > involved in the review of the proposed additions of > crankback function to the referenced recommendations > before that material is consented (last-called) by the > ITU-T. This would allow us to correct any > misunderstandings about our draft. > > Please comment on this proposal on the mail list. Definitely agree. Thanks, Jerry From owner-ccamp@ops.ietf.org Wed Mar 9 18:12:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01323 for ; Wed, 9 Mar 2005 18:12:19 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9AOT-0005gW-10 for ccamp-archive@ietf.org; Wed, 09 Mar 2005 18:15:09 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9ACm-000BW2-NJ for ccamp-data@psg.com; Wed, 09 Mar 2005 23:03:04 +0000 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9ACk-000BVj-KY for ccamp@ops.ietf.org; Wed, 09 Mar 2005 23:03:02 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 1B2BDE00013F; Wed, 9 Mar 2005 23:02:54 +0000 (GMT) Received: from Puppy ([130.129.133.164] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Mar 2005 23:02:13 +0000 Message-ID: <040a01c524fc$3f4656a0$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Jean Philippe Vasseur'" Subject: Slides and agenda updated Date: Wed, 9 Mar 2005 23:00:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 09 Mar 2005 23:02:13.0371 (UTC) FILETIME=[07F3E4B0:01C524FC] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Hi, I've uploaded all of the slides to http://www.olddog.co.uk/ccamp.htm except for JP's slides on draft-vasseur-ccamp-automesh-00.txt which are still giving my copy of PowerPoint significant indigestion. JP, can you check that you can send me a copy saved with all PowerPoint options deleted? Thanks Adrian From owner-ccamp@ops.ietf.org Thu Mar 10 01:27:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09915 for ; Thu, 10 Mar 2005 01:27:22 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9HBS-00068B-5m for ccamp-archive@ietf.org; Thu, 10 Mar 2005 01:30:14 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9GwV-0003P5-BV for ccamp-data@psg.com; Thu, 10 Mar 2005 06:14:43 +0000 Received: from [210.143.35.51] (helo=tyo201.gate.nec.co.jp) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9GwS-0003Oe-2i for ccamp@ops.ietf.org; Thu, 10 Mar 2005 06:14:40 +0000 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.162] (may be forged)) by tyo201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id j2A6EZ709344; Thu, 10 Mar 2005 15:14:35 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id j2A6EZY27131; Thu, 10 Mar 2005 15:14:35 +0900 (JST) Received: from kogoro.jp.nec.com (kogoro.jp.nec.com [10.26.220.12]) by mailsv4.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id j2A6EYg20675; Thu, 10 Mar 2005 15:14:34 +0900 (JST) Received: from iwata-pc2.spf.cl.nec.co.jp ([10.56.135.164] [10.56.135.164]) by mail.jp.nec.com with ESMTP; Thu, 10 Mar 2005 15:14:34 +0900 Message-Id: <6.1.0.6.2.20050310151357.063ce1f0@mail.jp.nec.com> X-Sender: 0000010775699@mail.jp.nec.com X-Mailer: QUALCOMM Windows Eudora Version 6J Jr6-rev2 Date: Thu, 10 Mar 2005 15:14:17 +0900 To: "Ash, Gerald R \(Jerry\), ALABS" From: Atsushi Iwata Subject: RE: Liaison from ITU-T Q14/15 on crankback Cc: "Adrian Farrel" , , "Ash, Gerald R \(Jerry\), ALABS" , "Kireeti Kompella" , "Scott Bradner" , "Scott W Brim" In-Reply-To: <9473683187ADC049A855ED2DA739ABCA060C88F4@KCCLUST06EVS1.ugd .att.com> References: <9473683187ADC049A855ED2DA739ABCA060C88F4@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Adrian I also agree with this. Thanks. At 04:40 05/03/10, Ash, Gerald R \(Jerry\), ALABS wrote: >Adrian, > >> However, I propose that we should respond asking to be >> involved in the review of the proposed additions of >> crankback function to the referenced recommendations >> before that material is consented (last-called) by the >> ITU-T. This would allow us to correct any >> misunderstandings about our draft. >> >> Please comment on this proposal on the mail list. > >Definitely agree. > >Thanks, >Jerry *--------------------------------------------------------* Atsushi Iwata, Ph.D. / Senior Manager System Platforms Research Labs, NEC Corporation 1753 Shimonumabe Nakahara-ku, Kawasaki, 211-8666, Japan TEL: +81-44-396-2744 (Direct), Fax: +81-44-431-7612 (Direct) NEC-internal TEL: 8-22-72634, NEC-internal FAX: 8-22-60469 NEC-mail: 8-22-60440, E-mail: a-iwata@ah.jp.nec.com From owner-ccamp@ops.ietf.org Thu Mar 10 15:57:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06055 for ; Thu, 10 Mar 2005 15:57:24 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9UlZ-0007E4-IO for ccamp-archive@ietf.org; Thu, 10 Mar 2005 16:00:25 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9Ua6-0005kx-NP for ccamp-data@psg.com; Thu, 10 Mar 2005 20:48:30 +0000 Received: from [66.129.224.36] (helo=kummer.juniper.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1D9Ua6-0005kj-0J for ccamp@ops.ietf.org; Thu, 10 Mar 2005 20:48:30 +0000 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j2AKmTXg097424 for ; Thu, 10 Mar 2005 12:48:29 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j2AKmTRY097421 for ; Thu, 10 Mar 2005 12:48:29 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 10 Mar 2005 12:48:29 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: ASON Lexicography Message-ID: <20050310124529.L97363@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Dear CCAMP, In our meeting this week we heard about draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt There is some more discussion to be done on the content of this draft but the chairs and the meeting thought that the work is a very important part of CCAMP's job. Please indicate your opinion on whether this draft should be made a working draft document by March 20, 2005. Thanks, Kireeti. ------- From owner-ccamp@ops.ietf.org Thu Mar 10 16:35:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09470 for ; Thu, 10 Mar 2005 16:35:31 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9VMV-0000gR-Gp for ccamp-archive@ietf.org; Thu, 10 Mar 2005 16:38:32 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9V5G-0009Pt-Gf for ccamp-data@psg.com; Thu, 10 Mar 2005 21:20:42 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9V5E-0009PL-IZ for ccamp@ops.ietf.org; Thu, 10 Mar 2005 21:20:40 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 10 Mar 2005 16:20:40 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from zaliwxp (che-vpn-cluster-1-47.cisco.com [10.86.240.47]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2ALKbjI018527; Thu, 10 Mar 2005 16:20:37 -0500 (EST) Message-Id: <200503102120.j2ALKbjI018527@rtp-core-2.cisco.com> From: "Zafar Ali" To: "'Kireeti Kompella'" , Subject: RE: ASON Lexicography Date: Thu, 10 Mar 2005 16:20:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20050310124529.L97363@kummer.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUltOjMaYubLmzAR8SZWOU+gd66FAAAgozQ X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Thursday, March 10, 2005 3:48 PM > To: ccamp@ops.ietf.org > Subject: ASON Lexicography > > Dear CCAMP, > > In our meeting this week we heard about > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > There is some more discussion to be done on the content of > this draft but the chairs and the meeting thought that the > work is a very important part of CCAMP's job. > > Please indicate your opinion on whether this draft should be > made a working draft document by March 20, 2005. In Favor. > > Thanks, > Kireeti. > ------- > From owner-ccamp@ops.ietf.org Thu Mar 10 20:54:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02460 for ; Thu, 10 Mar 2005 20:54:38 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ZPI-0004ec-Eo for ccamp-archive@ietf.org; Thu, 10 Mar 2005 20:57:41 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9ZEO-000PBp-N2 for ccamp-data@psg.com; Fri, 11 Mar 2005 01:46:24 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9ZEO-000PBX-01 for ccamp@ops.ietf.org; Fri, 11 Mar 2005 01:46:24 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 10 Mar 2005 21:02:57 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,155,1107752400"; d="scan'208"; a="40077746:sNHT20198624" Received: from cisco.com (rtp-vpn1-420.cisco.com [10.82.225.164]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2B1kK1j022586; Thu, 10 Mar 2005 20:46:20 -0500 (EST) Date: Thu, 10 Mar 2005 20:45:46 -0500 From: Scott W Brim To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: ASON Lexicography Message-ID: <20050311014546.GA3896@sbrim-w2k02> Mail-Followup-To: Scott W Brim , Kireeti Kompella , ccamp@ops.ietf.org References: <20050310124529.L97363@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050310124529.L97363@kummer.juniper.net> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Thu, Mar 10, 2005 12:48:29PM -0800, Kireeti Kompella allegedly wrote: > Dear CCAMP, > > In our meeting this week we heard about > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > There is some more discussion to be done on the content of this draft > but the chairs and the meeting thought that the work is a very > important part of CCAMP's job. > > Please indicate your opinion on whether this draft should be made a > working draft document by March 20, 2005. Yes it's a good goal, but the draft is going to need a large amount of work. From owner-ccamp@ops.ietf.org Fri Mar 11 04:49:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01314 for ; Fri, 11 Mar 2005 04:49:52 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9gpH-0001G0-7j for ccamp-archive@ietf.org; Fri, 11 Mar 2005 04:52:59 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D9gcQ-000PHA-VS for ccamp-data@psg.com; Fri, 11 Mar 2005 09:39:42 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9gcP-000PGp-Ib for ccamp@ops.ietf.org; Fri, 11 Mar 2005 09:39:41 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 11 Mar 2005 10:39:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : ASON Lexicography Date: Fri, 11 Mar 2005 10:39:33 +0100 Message-ID: Thread-Topic: ASON Lexicography Thread-Index: AcUlszjabAotRAeTTiSrYKXLl/r2NgAatbNQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Kireeti Kompella" , X-OriginalArrivalTime: 11 Mar 2005 09:39:37.0784 (UTC) FILETIME=[3DCFF380:01C5261E] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Hi, This is a highly useful draft. It should become a WG ID. Regards, JL >-----Message d'origine----- >De : owner-ccamp@ops.ietf.org=20 >[mailto:owner-ccamp@ops.ietf.org] De la part de Kireeti Kompella >Envoy=E9 : jeudi 10 mars 2005 21:48 >=C0 : ccamp@ops.ietf.org >Objet : ASON Lexicography > > >Dear CCAMP, > >In our meeting this week we heard about=20 >draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > >There is some more discussion to be done on the content of=20 >this draft but the chairs and the meeting thought that the=20 >work is a very important part of CCAMP's job. > >Please indicate your opinion on whether this draft should be=20 >made a working draft document by March 20, 2005. > >Thanks, >Kireeti. >------- > > From owner-ccamp@ops.ietf.org Sat Mar 12 11:33:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19276 for ; Sat, 12 Mar 2005 11:33:19 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DA9bS-0001RB-LP for ccamp-archive@ietf.org; Sat, 12 Mar 2005 11:36:43 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DA9Pz-000JMf-HM for ccamp-data@psg.com; Sat, 12 Mar 2005 16:24:47 +0000 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DA9Pw-000JMG-6t for ccamp@ops.ietf.org; Sat, 12 Mar 2005 16:24:44 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 5ABECE000138 for ; Sat, 12 Mar 2005 16:24:36 +0000 (GMT) Received: from Puppy ([212.43.203.9] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 12 Mar 2005 16:18:48 +0000 Message-ID: <004c01c5271f$65f52040$09cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Last call on protection signaling drafts Date: Sat, 12 Mar 2005 15:59:33 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 12 Mar 2005 16:18:48.0446 (UTC) FILETIME=[2BEEB1E0:01C5271F] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit This email begins a two week working group last call on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt and http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-01.txt Last call will end on Sunday 27th March at 12 noon GMT. Please send you comments to the list. The chairs can provide an annonymizing function if you require. Thanks, Adrian From owner-ccamp@ops.ietf.org Sat Mar 12 11:34:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19330 for ; Sat, 12 Mar 2005 11:34:06 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DA9cH-0001Ry-UK for ccamp-archive@ietf.org; Sat, 12 Mar 2005 11:37:30 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DA9R4-000JSW-Lj for ccamp-data@psg.com; Sat, 12 Mar 2005 16:25:54 +0000 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DA9R0-000JSA-I2 for ccamp@ops.ietf.org; Sat, 12 Mar 2005 16:25:50 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id B5C34E0000B3; Sat, 12 Mar 2005 16:25:49 +0000 (GMT) Received: from Puppy ([212.43.203.9] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 12 Mar 2005 16:25:16 +0000 Message-ID: <007b01c52720$4d931a10$09cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Scott W Brim" , "Kireeti Kompella" Cc: References: <20050310124529.L97363@kummer.juniper.net> <20050311014546.GA3896@sbrim-w2k02> Subject: Re: ASON Lexicography Date: Sat, 12 Mar 2005 16:26:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 12 Mar 2005 16:25:17.0449 (UTC) FILETIME=[13CBD790:01C52720] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Hi Scott, Thanks for you input. Obviously we have been discussing the content of the draft with people in Q14/15 and in CCAMP and have received quite a lot of input. We plan to bring out a new version as soon as we can cut the bandwidth. In the mean time, are there specific terms that you have an issue with, or is it a matter of style. Thanks, Adrian ----- Original Message ----- From: "Scott W Brim" To: "Kireeti Kompella" Cc: Sent: Friday, March 11, 2005 1:45 AM Subject: Re: ASON Lexicography > On Thu, Mar 10, 2005 12:48:29PM -0800, Kireeti Kompella allegedly wrote: > > Dear CCAMP, > > > > In our meeting this week we heard about > > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > > > There is some more discussion to be done on the content of this draft > > but the chairs and the meeting thought that the work is a very > > important part of CCAMP's job. > > > > Please indicate your opinion on whether this draft should be made a > > working draft document by March 20, 2005. > > Yes it's a good goal, but the draft is going to need a large amount of > work. > > > From owner-ccamp@ops.ietf.org Sat Mar 12 11:39:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19653 for ; Sat, 12 Mar 2005 11:39:03 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DA9h4-0001Xx-IK for ccamp-archive@ietf.org; Sat, 12 Mar 2005 11:42:27 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DA9Ws-000K4n-Ly for ccamp-data@psg.com; Sat, 12 Mar 2005 16:31:54 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DA9Wr-000K4a-Sx for ccamp@ops.ietf.org; Sat, 12 Mar 2005 16:31:53 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 12 Mar 2005 11:48:44 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,158,1107752400"; d="scan'208"; a="40262597:sNHT21289344" Received: from [10.86.242.168] (che-vpn-cluster-2-168.cisco.com [10.86.242.168]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2CGVo1j003917; Sat, 12 Mar 2005 11:31:50 -0500 (EST) Message-ID: <42331977.9050104@cisco.com> Date: Sat, 12 Mar 2005 11:31:51 -0500 From: Scott W Brim User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON Lexicography References: <20050310124529.L97363@kummer.juniper.net> <20050311014546.GA3896@sbrim-w2k02> <007b01c52720$4d931a10$09cb2bd4@Puppy> In-Reply-To: <007b01c52720$4d931a10$09cb2bd4@Puppy> X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit On 3/12/2005 11:26, Adrian Farrel allegedly wrote: > Hi Scott, > > Thanks for you input. Obviously we have been discussing the content of the > draft with people in Q14/15 and in CCAMP and have received quite a lot of > input. We plan to bring out a new version as soon as we can cut the > bandwidth. Looking forward to it. > In the mean time, are there specific terms that you have an issue with, or > is it a matter of style. Concepts, as you saw in my exchange a month ago. I'll wait for the new version. Thanks ... Scott From owner-ccamp@ops.ietf.org Sat Mar 12 19:20:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21254 for ; Sat, 12 Mar 2005 19:20:00 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAGtD-0003a0-NI for ccamp-archive@ietf.org; Sat, 12 Mar 2005 19:23:29 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DAGeg-000M3f-L0 for ccamp-data@psg.com; Sun, 13 Mar 2005 00:08:26 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DAGef-000M3R-Sl for ccamp@ops.ietf.org; Sun, 13 Mar 2005 00:08:25 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Mar 2005 17:26:20 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,159,1107734400"; d="scan'208"; a="234389036:sNHT21410944" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2D08Dq8018305; Sat, 12 Mar 2005 16:08:15 -0800 (PST) Received: from [192.168.1.102] (che-vpn-cluster-1-91.cisco.com [10.86.240.91]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA17836; Sat, 12 Mar 2005 16:08:17 -0800 (PST) In-Reply-To: <20050310124529.L97363@kummer.juniper.net> References: <20050310124529.L97363@kummer.juniper.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8960b712d5442f3313fd967cb940c868@cisco.com> Content-Transfer-Encoding: 7bit Cc: ccamp@ops.ietf.org From: JP Vasseur Subject: Re: ASON Lexicography Date: Sat, 12 Mar 2005 11:04:49 -0500 To: Kireeti Kompella X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit in favor. JP. On Mar 10, 2005, at 3:48 PM, Kireeti Kompella wrote: > Dear CCAMP, > > In our meeting this week we heard about > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > There is some more discussion to be done on the content of this draft > but the chairs and the meeting thought that the work is a very > important part of CCAMP's job. > > Please indicate your opinion on whether this draft should be made a > working draft document by March 20, 2005. > > Thanks, > Kireeti. > ------- > From bang@acii.com Sat Mar 12 22:31:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03866 for ; Sat, 12 Mar 2005 22:31:44 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAJsm-0008Tf-TW for ccamp-archive@ietf.org; Sat, 12 Mar 2005 22:35:14 -0500 Received: from pool-68-160-175-122.bos.east.verizon.net ([68.160.175.122]) by mx2.foretec.com with smtp (Exim 4.24) id 1DAK0y-0001LT-9N for ccamp-archive@ietf.org; Sat, 12 Mar 2005 22:43:42 -0500 Message-ID: <7f6c01c5277c$ab948923$6e08dcdf@acii.com> From: "Paul A. Davis" To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?Q2lhbGlzIC0gd2hvbGVzYWxlIHByaWNl?= Date: Sun, 13 Mar 2005 03:26:01 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_9ACF56E4.183E16C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 4.5 (++++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_9ACF56E4.183E16C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_1332E732.0B14140C" ------=_NextPart_001_0001_1332E732.0B14140C Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Full & hard erections Long effects No prescription asked Only $2.99/$1.99 per dose (2 doses in each pill): Cialis - http://www.kilomed.biz/sv/ Viagra - http://www.kilomed.biz/vt/ Discreet packaging _________________________________________________________________________ To change your mail details, go here: http://www.kilomed.biz/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_1332E732.0B14140C Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit

Stable & hard erections
Long effects
No prescription required

Give it a try!
CIALIS - http://www.kilomed.biz/sv/
VIAGRA - http://www.kilomed.biz/vt/

Directly from the manufacturer!


_________________________________________________________________________
To change your mail preferences, go here: http://www.kilomed.biz/uns.htm
_________________________________________________________________________

------=_NextPart_001_0001_1332E732.0B14140C-- ------=_NextPart_000_0000_9ACF56E4.183E16C0-- From owner-ccamp@ops.ietf.org Mon Mar 14 10:36:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13717 for ; Mon, 14 Mar 2005 10:36:27 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DArfz-0007D9-K9 for ccamp-archive@ietf.org; Mon, 14 Mar 2005 10:40:16 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DArPd-0003TB-Gx for ccamp-data@psg.com; Mon, 14 Mar 2005 15:23:21 +0000 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DArPc-0003So-Kw for ccamp@ops.ietf.org; Mon, 14 Mar 2005 15:23:20 +0000 Received: from pc6 (1Cust162.tnt2.lnd4.gbr.da.uu.net [62.188.131.162]) by galaxy.systems.pipex.net (Postfix) with SMTP id 09634E0003EF; Mon, 14 Mar 2005 15:23:16 +0000 (GMT) Message-ID: <025a01c528a0$fc6ff040$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , References: <0aa401c51843$6a63fba0$adcb2bd4@Puppy> Subject: comments on draft-ietf-ccamp-gmpls-lsr-mib-07.txt Date: Mon, 14 Mar 2005 15:19:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit I find the IANA Considerations section less than clear. I suggest that you differentiate between xx and xx, eg by using yy for GMPLS-LABEL-STD-MIB I would also reword it slightly as follows. ** MPLS and GMPLS related standards track MIB modules are rooted under the mplsStdMIB subtree. One of the MIB modules contained in this document extends tables contained in MPLS MIB modules. ** The two MIB modules contained in this document, like that in GMPLS-TC-STD-MIB [GMPLSTCMIB], should be placed in the mplsStdMIB subtree. ** New assignments in the mplsStdMIB subtree can only be made via a Standards Action as specified in [RFC2434]. 11.1. IANA Considerations for GMPLS-LSR-STD-MIB The IANA is requested to assign { mplsStdMIB xx } to the GMPLS-LSR-STD-MIB module specified in this document. 11.2. IANA Considerations for GMPLS-LABEL-STD-MIB ** The IANA is requested to assign { mplsStdMIB yy } to the GMPLS-LABEL-STD-MIB module specified in this document. Tom Petch draft-ietf-ccamp-gmpls-te-mib-08.txt From ellie@accesscable.net Mon Mar 14 12:43:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27956 for ; Mon, 14 Mar 2005 12:43:55 -0500 (EST) Received: from [218.50.33.19] (helo=218.50.33.19) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DAtfI-0004WT-Ca for ccamp-archive@ietf.org; Mon, 14 Mar 2005 12:47:46 -0500 Message-ID: <5e0701c528bc$ad062a95$46237448@accesscable.net> From: "Vanessa J. Smith" To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?QWxsIHNvZnR3YXJlIC0gNzUlIE9GRg==?= Date: Mon, 14 Mar 2005 17:35:27 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_452B77E9.1CA8A93B" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 6.1 (++++++) X-Spam-Flag: YES X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0000_452B77E9.1CA8A93B Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_A9649938.6460971F" ------=_NextPart_001_0001_A9649938.6460971F Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get access to all the popular software imaginable for bottom prices! Our software is 2-10 times cheaper than sold by our competitors. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... Visit us at: http://www.anysoft.biz Best regards, Vanessa Smith _____________________________________________________ To be taken off future campaigns, go: http://www.anysoft.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_A9649938.6460971F Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Access all the software you need for extremely low prices!
We sell software 2-6 times cheaper than retail price.

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

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

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And lots more... For full list of products go:

http://www.anysoft.biz

Best,
Vanessa Smith


_____________________________________________________
To be taken off future campaigns, go: http://www.anysoft.biz/uns.htm
_____________________________________________________

------=_NextPart_001_0001_A9649938.6460971F-- ------=_NextPart_000_0000_452B77E9.1CA8A93B-- From owner-ccamp@ops.ietf.org Mon Mar 14 22:25:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28003 for ; Mon, 14 Mar 2005 22:25:25 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB2k8-0005hE-KO for ccamp-archive@ietf.org; Mon, 14 Mar 2005 22:29:20 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DB2RN-000DSl-Gc for ccamp-data@psg.com; Tue, 15 Mar 2005 03:09:53 +0000 Received: from [63.250.163.245] (helo=huawei.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DB2RK-000DSL-DI for ccamp@ops.ietf.org; Tue, 15 Mar 2005 03:09:50 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IDD00CZVHYHU6@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Mon, 14 Mar 2005 19:06:17 -0800 (PST) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IDD00ISEHYGOR@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Mon, 14 Mar 2005 19:06:16 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.78.230.163]) by szxmc02-in.huawei.com (mshttpd); Tue, 15 Mar 2005 11:10:13 +0800 Date: Tue, 15 Mar 2005 11:10:13 +0800 From: Amit 70405 Subject: Query about recovery hierarchies To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_05 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7BIT Hi All, I want to clarify some things about hiearchical classification of recovery mechanisms. In draft-ietf-ccamp-gmpls-recovery-analysis-04, there are two hierarchies being defined. I have below understanding of these hierarchies. Plz let me know if this correct. Horizontal & Vertical recovery hierachy are the hierarchies. Horizontal hierachy basically is about control plane recovery mechanism. This includes link, segment and e2e recovery mechanisms. Whereas Vertical Hierarchy is about utilising recovery mechanisms at different network layers. Suppose for e.g: MSP protection is supported at Layer 1. And control plane supports link, segmnent & e2e supports. Than the layer 1 & Control plane mechanisms should be independant of each other. Is this what the Recovery Hierarchy means? Plz correct me if I am wrong. Thanks in advance. Regards, Amit. From owner-ccamp@ops.ietf.org Tue Mar 15 00:40:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11165 for ; Tue, 15 Mar 2005 00:40:55 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB4rL-0003E2-RS for ccamp-archive@ietf.org; Tue, 15 Mar 2005 00:44:52 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DB4h5-0003MM-3w for ccamp-data@psg.com; Tue, 15 Mar 2005 05:34:15 +0000 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DB4h3-0003Lq-8B for ccamp@ops.ietf.org; Tue, 15 Mar 2005 05:34:13 +0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2F5Y8ap013505; Tue, 15 Mar 2005 14:34:08 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2F5Y8F7020977; Tue, 15 Mar 2005 14:34:08 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2F5Y7ct020974; Tue, 15 Mar 2005 14:34:07 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2F5Y77x000291; Tue, 15 Mar 2005 14:34:07 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2F5Y7fQ000288; Tue, 15 Mar 2005 14:34:07 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2F5Y71Z016282; Tue, 15 Mar 2005 14:34:07 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2F5Y6O6021171; Tue, 15 Mar 2005 14:34:06 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2F5Y6hL021168; Tue, 15 Mar 2005 14:34:06 +0900 (JST) Received: from lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id OAA11868; Tue, 15 Mar 2005 14:34:05 +0900 (JST) Message-ID: <423673C9.6030505@lab.ntt.co.jp> Date: Tue, 15 Mar 2005 14:34:01 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: ASON Lexicography References: <20050310124529.L97363@kummer.juniper.net> In-Reply-To: <20050310124529.L97363@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Yes, it should be a WG draft. -- Kohei Shiomoto Kireeti Kompella wrote: > Dear CCAMP, > > In our meeting this week we heard about > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > There is some more discussion to be done on the content of this draft > but the chairs and the meeting thought that the work is a very > important part of CCAMP's job. > > Please indicate your opinion on whether this draft should be made a > working draft document by March 20, 2005. > > Thanks, > Kireeti. > ------- > > > -- Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan Phone +81 422 59 4402 Fax +81 422 59 3787 From owner-ccamp@ops.ietf.org Tue Mar 15 05:09:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26116 for ; Tue, 15 Mar 2005 05:09:50 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB93a-0006Aj-KD for ccamp-archive@ietf.org; Tue, 15 Mar 2005 05:13:49 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DB8pY-000CtM-Hl for ccamp-data@psg.com; Tue, 15 Mar 2005 09:59:16 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DB8pU-000CsQ-99 for ccamp@ops.ietf.org; Tue, 15 Mar 2005 09:59:12 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id B3C33E00030C; Tue, 15 Mar 2005 09:59:04 +0000 (GMT) Received: from Puppy ([212.43.203.28] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Mar 2005 09:59:03 +0000 Message-ID: <017601c52945$d7aeda50$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , References: <0aa401c51843$6a63fba0$adcb2bd4@Puppy> <025a01c528a0$fc6ff040$0601a8c0@pc6> Subject: Re: comments on draft-ietf-ccamp-gmpls-lsr-mib-07.txt Date: Tue, 15 Mar 2005 09:53:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 15 Mar 2005 09:59:04.0110 (UTC) FILETIME=[9EA62CE0:01C52945] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Good man, Tom. Thanks. Adrian ----- Original Message ----- From: "Tom Petch" To: "Adrian Farrel" ; Sent: Monday, March 14, 2005 2:19 PM Subject: comments on draft-ietf-ccamp-gmpls-lsr-mib-07.txt > I find the IANA Considerations section less than clear. I suggest that you > differentiate between xx and xx, eg by using yy for GMPLS-LABEL-STD-MIB > > I would also reword it slightly as follows. > > ** MPLS and GMPLS related standards track MIB modules are rooted under the > mplsStdMIB subtree. > > One of the MIB modules contained in this document extends tables > contained in MPLS MIB modules. > > ** The two MIB modules contained in this document, like that in > GMPLS-TC-STD-MIB [GMPLSTCMIB], should be placed in the mplsStdMIB subtree. > > ** New assignments in the mplsStdMIB subtree can only be made via a Standards > Action as specified in [RFC2434]. > > 11.1. IANA Considerations for GMPLS-LSR-STD-MIB > > The IANA is requested to assign { mplsStdMIB xx } to the > GMPLS-LSR-STD-MIB module specified in this document. > > 11.2. IANA Considerations for GMPLS-LABEL-STD-MIB > > ** The IANA is requested to assign { mplsStdMIB yy } to the > GMPLS-LABEL-STD-MIB module specified in this document. > > > Tom Petch > > draft-ietf-ccamp-gmpls-te-mib-08.txt > > > From owner-ccamp@ops.ietf.org Tue Mar 15 07:09:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05967 for ; Tue, 15 Mar 2005 07:09:37 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBAvX-0002fn-3s for ccamp-archive@ietf.org; Tue, 15 Mar 2005 07:13:37 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBAjk-00089v-8h for ccamp-data@psg.com; Tue, 15 Mar 2005 12:01:24 +0000 Received: from [209.219.209.75] (helo=ckmso2.proxy.att.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBAjj-00089f-3P for ccamp@ops.ietf.org; Tue, 15 Mar 2005 12:01:23 +0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j2FC1LfZ028363 for ; Tue, 15 Mar 2005 07:01:21 -0500 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (7.2.052) id 4229269A0021EAEE; Tue, 15 Mar 2005 07:01:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON Lexicography Date: Tue, 15 Mar 2005 06:01:20 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA060C8921@KCCLUST06EVS1.ugd.att.com> Thread-Topic: ASON Lexicography Thread-Index: AcUlssvSvweURWJyQ4uCzvl6ocGwkwDo4aRA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Kireeti Kompella" , Cc: "Ash, Gerald R \(Jerry\), ALABS" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable > Please indicate your opinion on whether this draft should be > made a working draft document by March 20, 2005. Yes. Thanks, Jerry From owner-ccamp@ops.ietf.org Tue Mar 15 07:11:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06056 for ; Tue, 15 Mar 2005 07:11:13 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBAx6-0002ls-MF for ccamp-archive@ietf.org; Tue, 15 Mar 2005 07:15:14 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBAo6-0008q4-WA for ccamp-data@psg.com; Tue, 15 Mar 2005 12:05:55 +0000 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBAo5-0008ph-RU for ccamp@ops.ietf.org; Tue, 15 Mar 2005 12:05:54 +0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2FC5pSt010879; Tue, 15 Mar 2005 21:05:51 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2FC5olr000259; Tue, 15 Mar 2005 21:05:50 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2FC5oLt000256; Tue, 15 Mar 2005 21:05:50 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2FC5oOM028611; Tue, 15 Mar 2005 21:05:50 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2FC5nXs028608; Tue, 15 Mar 2005 21:05:49 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2FC5nka014479; Tue, 15 Mar 2005 21:05:49 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2FC5nZj025473; Tue, 15 Mar 2005 21:05:49 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb0.m.ecl.ntt.co.jp [129.60.5.140]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2FC5m30025470; Tue, 15 Mar 2005 21:05:48 +0900 (JST) Received: from INOUE-LETS-CFW2.lab.ntt.co.jp by imb.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id VAA08161; Tue, 15 Mar 2005 21:05:48 +0900 (JST) Message-Id: <6.0.0.20.2.20050315210637.07d6c1e8@imb.m.ecl.ntt.co.jp> X-Sender: ii004@imb.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 15 Mar 2005 21:07:18 +0900 To: "Kireeti Kompella" , From: "inoue.ichiro@lab.ntt.co.jp" Subject: RE: ASON Lexicography In-Reply-To: <9473683187ADC049A855ED2DA739ABCA060C8921@KCCLUST06EVS1.ugd .att.com> References: <9473683187ADC049A855ED2DA739ABCA060C8921@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit I suppot it too. Ichiro Inoue From owner-ccamp@ops.ietf.org Tue Mar 15 07:41:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08217 for ; Tue, 15 Mar 2005 07:41:55 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBBQo-00040x-04 for ccamp-archive@ietf.org; Tue, 15 Mar 2005 07:45:54 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBBFV-000Eot-Ma for ccamp-data@psg.com; Tue, 15 Mar 2005 12:34:13 +0000 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBBFU-000Eoe-Hb for ccamp@ops.ietf.org; Tue, 15 Mar 2005 12:34:12 +0000 Received: from pc6 (1Cust44.tnt7.lnd4.gbr.da.uu.net [62.188.136.44]) by blaster.systems.pipex.net (Postfix) with SMTP id EB281E0002C0; Tue, 15 Mar 2005 12:34:03 +0000 (GMT) Message-ID: <031301c52952$85dae720$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , References: <0aa401c51843$6a63fba0$adcb2bd4@Puppy> <025a01c528a0$fc6ff040$0601a8c0@pc6> Subject: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Tue, 15 Mar 2005 12:29:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit A minor comment; this document has false (0), in several places; following RFC 2579, I think this should be false (2) A larger question,; this mib augments tables in the mpls mib (RFC3812); is there a reason why the AUGMENTS construct was not used? Tom Petch From owner-ccamp@ops.ietf.org Tue Mar 15 10:01:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22482 for ; Tue, 15 Mar 2005 10:01:40 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBDc4-0002EL-Oe for ccamp-archive@ietf.org; Tue, 15 Mar 2005 10:05:41 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBDLl-0007t3-Gk for ccamp-data@psg.com; Tue, 15 Mar 2005 14:48:49 +0000 Received: from [47.140.192.56] (helo=zrtps0kp.nortelnetworks.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBDLk-0007sl-GB for ccamp@ops.ietf.org; Tue, 15 Mar 2005 14:48:48 +0000 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2FEmii15837 for ; Tue, 15 Mar 2005 09:48:44 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Mar 2005 09:48:43 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4A35979@zrtphxm2> From: "Don Fedyk" To: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON Lexicography Date: Tue, 15 Mar 2005 09:48:34 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi Kireeti Yes Valuable. It should be a WG draft. Don > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Thursday, March 10, 2005 3:48 PM > To: ccamp@ops.ietf.org > Subject: ASON Lexicography > > > Dear CCAMP, > > In our meeting this week we heard about > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > There is some more discussion to be done on the content of > this draft but the chairs and the meeting thought that the > work is a very important part of CCAMP's job. > > Please indicate your opinion on whether this draft should be > made a working draft document by March 20, 2005. > > Thanks, > Kireeti. > ------- > > > From owner-ccamp@ops.ietf.org Tue Mar 15 10:03:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22999 for ; Tue, 15 Mar 2005 10:03:50 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBDeA-0002R8-Bb for ccamp-archive@ietf.org; Tue, 15 Mar 2005 10:07:51 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBDPs-0008WT-SR for ccamp-data@psg.com; Tue, 15 Mar 2005 14:53:04 +0000 Received: from [209.219.209.75] (helo=ckmso2.proxy.att.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBDPr-0008WB-Te for ccamp@ops.ietf.org; Tue, 15 Mar 2005 14:53:04 +0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j2FEr2fZ001059 for ; Tue, 15 Mar 2005 09:53:02 -0500 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh5i.attrh.att.com (7.2.052) id 4229269A00228433; Tue, 15 Mar 2005 09:53:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON Lexicography Date: Tue, 15 Mar 2005 08:53:02 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF093C91FF@OCCLUST04EVS1.ugd.att.com> Thread-Topic: ASON Lexicography Thread-Index: AcUlssurnnG1sm0fQtyjKS8N8axp5gDu9VIg From: "Brungard, Deborah A, ALABS" To: "Kireeti Kompella" , X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: quoted-printable Yes- Deborah=20 From owner-ccamp@ops.ietf.org Tue Mar 15 14:12:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07038 for ; Tue, 15 Mar 2005 14:12:02 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBHQm-0006AO-6g for ccamp-archive@ietf.org; Tue, 15 Mar 2005 14:10:16 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBHFq-000J4L-5C for ccamp-data@psg.com; Tue, 15 Mar 2005 18:58:58 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBHFp-000J3q-1V for ccamp@ops.ietf.org; Tue, 15 Mar 2005 18:58:57 +0000 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2FIwqf20137 for ; Tue, 15 Mar 2005 13:58:52 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Mar 2005 13:58:52 -0500 Message-ID: From: "Stephen Shew" To: ccamp@ops.ietf.org Subject: RE: ASON Lexicography Date: Tue, 15 Mar 2005 13:58:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52990.E2C88F1F" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C52990.E2C88F1F Content-Type: text/plain I support this becoming a WG draft. > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Thursday, March 10, 2005 15:48 > To: ccamp@ops.ietf.org > Subject: ASON Lexicography > > > Dear CCAMP, > > In our meeting this week we heard about > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > There is some more discussion to be done on the content of > this draft but the chairs and the meeting thought that the > work is a very important part of CCAMP's job. > > Please indicate your opinion on whether this draft should be > made a working draft document by March 20, 2005. > > Thanks, > Kireeti. > ------- > > > ------_=_NextPart_001_01C52990.E2C88F1F Content-Type: text/html RE: ASON Lexicography

I support this becoming a WG draft.

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella
> Sent: Thursday, March 10, 2005 15:48
> To: ccamp@ops.ietf.org
> Subject: ASON Lexicography
>
>
> Dear CCAMP,
>
> In our meeting this week we heard about
> draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt
>
> There is some more discussion to be done on the content of
> this draft but the chairs and the meeting thought that the
> work is a very important part of CCAMP's job.
>
> Please indicate your opinion on whether this draft should be
> made a working draft document by March 20, 2005.
>
> Thanks,
> Kireeti.
> -------
>
>
>

------_=_NextPart_001_01C52990.E2C88F1F-- From owner-ccamp@ops.ietf.org Tue Mar 15 20:00:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10426 for ; Tue, 15 Mar 2005 19:59:59 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBMxA-0005MS-TJ for ccamp-archive@ietf.org; Tue, 15 Mar 2005 20:04:07 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBMYX-0001tI-MR for ccamp-data@psg.com; Wed, 16 Mar 2005 00:38:37 +0000 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBMYR-0001sw-QW for ccamp@ops.ietf.org; Wed, 16 Mar 2005 00:38:32 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id B6955E000045 for ; Wed, 16 Mar 2005 00:38:21 +0000 (GMT) Received: from Puppy ([212.43.203.199] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Mar 2005 00:34:12 +0000 Message-ID: <01f501c529c0$198d56c0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Last call review of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt Date: Wed, 16 Mar 2005 00:30:42 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E5_01C529BF.63405520" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 16 Mar 2005 00:34:14.0251 (UTC) FILETIME=[E121D3B0:01C529BF] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_50,HTML_40_50, HTML_MESSAGE autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: 8c959c2d4aeb7b760500091f4bbf1190 This is a multi-part message in MIME format. ------=_NextPart_000_01E5_01C529BF.63405520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I've got a couple of comments in what seems like quite a long draft. Adrian Abstract: This document describes protocol specific procedures and extensions=20 for Generalized Multi-Protocol Label Switching (GMPLS) Resource=20 ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to=20 support end-to-end Label Switched Path (LSP) recovery that denotes=20 protection and restoration. Not sure what is meant by "denotes" in this context. Perhaps "is used to provide" ? =3D=3D=3D Section 2 OLD In addition, the reader is assumed to be familiar with the=20 terminology used in [RFC3945], [RFC3471], [RFC3473] and referenced=20 as well as [TERM] and [FUNCT].=20 NEW In addition, the reader is assumed to be familiar with the=20 terminology used in [RFC3945], [RFC3471], [RFC3473], as well as in [TERM] and [FUNCT].=20 =3D=3D=3D Section 2 Checklog List from revision v01.txt: =20 Please either remove this text or mark it so that the RFC editor will = remove it. =3D=3D=3D Section 3 Although the second paragraph defines "end-to-end protection" I would = like to see this pulled out into its own paragraph for emphasis, and = also a little more clarity added to the definition. For example, it = would appear that your four types of e2e protection are all have the = protecting and protected LSPs disjoint in some way - this makes it = appear that this is a property of e2e protection in general and you = should state this if it is true. =3D=3D=3D Section 3 para 5 In 1:N (N =3D< 1) protection with extra-traffic, Hopefully you mean N >=3D 1 =20 =3D=3D=3D Section 3 para 5 I note that you do not distinguish between 1:N and = 1:N-with-extra-traffic. If there is a reason for this perhaps you could add a note to the text. =3D=3D=3D Section 3 OLD working one. Here, the recovery resources for the protecting LSP are=20 pre-reserved and explicit action is required to activate (i.e.=20 NEW working one. Here, the recovery resources for the protecting LSP are=20 pre-reserved but explicit action is required to activate (i.e.=20 ^^^ =3D=3D=3D Section 3 OLD requirements by allowing multiple protecting LSPs to share common=20 link and node resources. The recovery resources are pre-reserved and=20 NEW requirements by allowing multiple protecting LSPs to share common=20 link and node resources. The recovery resources are pre-reserved but ^^^=20 =3D=3D=3D Section 3 Note that in both=20 cases, any lower priority LSP that would use the pre-reserved=20 resources for the protecting LSP(s) MUST be preempted during the=20 activation of the protecting LSP.=20 This sentence comes out of the blue. The whole of the paragraph up to = then has not even mentioned extra traffic. I suggest you insert a = paragraph break and a sentence explaining how the pre-reserved resources = may be used to support an extra-traffic LSP... Also, delete "would". =3D=3D=3D Section 3 Full LSP re-routing (or restoration) switches normal traffic to an=20 alternate LSP that is fully established only after working LSP=20 failure occurs. This text does not read well in English. In fact, the same is true of = pre-planned. What you mean is, I think, as follows... Full LSP re-routing (or restoration) switches normal traffic to an=20 alternate LSP that is not even partially established until after=20 the working LSP failure occurs.=20 =3D=3D=3D Section 3 Note that crankback signaling (see [CRANK]) and LSP segment recovery=20 are further detailed in dedicated companion documents. Also, there=20 Need to add a citation for LSP segment recovery. =3D=3D=3D Section 4.2 OLD The recovery attributes includes all the parameters that determine=20 NEW The recovery attributes include all the parameters that determine=20 =3D=3D=3D Section 4.2.1 - S (Secondary) bit: enables distinction between primary and =20 secondary LSPs. A primary LSP is a fully established LSP for =20 which the resource allocation has been committed at the data plane = (i.e. full cross-connection has been performed). Both working and =20 protecting LSPs can be primary LSPs. A secondary LSP is an LSP =20 I am uneasy about this definition of "primary". In [TERM] the only = mention of "primary" is in section 2... Recovery typically involves the activation of a recovery (or alternate) LSP when a failure is encountered in the working (or primary) LSP. This implies that "primary" is a synonym for "working". Further, RFC3471 has a subtly different meaning for "secondary" in = section 7. Protection Information also indicates if the LSP is a primary or secondary LSP. A secondary LSP is a backup to a primary LSP. The resources of a secondary LSP are not used until the primary LSP fails. The resources allocated for a secondary LSP MAY be used by other LSPs until the primary LSP fails over to the secondary LSP. At that point, any LSP that is using the resources for the secondary LSP MUST be preempted. Can we please not modify the interpretation of the S-bit. If you need to flag a new piece of information (to distinguish between = resource allocated and not) then please introduce a new flag. Note that the P-bit appears to be slightly orthogonal because the text = seems to describe the *current* role of the LSP. (The S-bit in RFC3471 = describes the role at the time the LSP is set up, I think). =3D=3D=3D Section 4.3 OLD When used for the working LSP signaling, the Association ID of the=20 NEW When used for signaling the working LSP, the Association ID of the=20 =3D=3D=3D Section 4.3 OLD When used for the protecting LSP signaling, this field identifies=20 NEW When used for signaling the protecting LSP, this field identifies=20 =3D=3D=3D Section 5 When a failure occurs (say at node B) and is detected at end-node D,=20 the receiver at D selects the normal traffic from the other LSP.=20 From this perspective, 1+1 unidirectional protection can be seen as=20 an uncoordinated protection switching mechanism acting independently=20 at both end-points. Also, for the protected LSP under failure=20 condition, the Path_State_Removed Flag of the ERROR_SPEC object (see=20 [RFC3473]) SHOULD NOT be set upon PathErr message generation.=20 So, what you are saying is that in 1+1 protection the network may = *never* know that the error is so bad that the LSP is dead, but MUST = leave that choice to the ingress. While this is the operational practice = in many transport networks, I don't see why you make this as strong as a = SHOULD NOT. =3D=3D=3D Section 5 Note: one should assume that both paths are SRLG disjoint otherwise,=20 a failure would impact both working and protecting LSPs.=20 What is this supposed to tell the reader? That he should make the = assumption or that he should ensure SRLG diversity? ;-) Actually, I think you want to say that the quality of 1+1 protection may = vary. Allowing link diverse, node diverse or SRLG diverse 1+1 = protection. (ditto section 6 and 7) =3D=3D=3D Section 5.1 Since both LSPs belong to the same session, the SESSION object MUST=20 be the same for both LSPs.=20 An undisputable conclusion drawn from an unproven premise. Why must both LSPs belong to the same session? A one line explanation = would start the section off nicely. =3D=3D=3D Section 5.1 A new PROTECTION object is included in the Path message. This object=20 What is the implication of "new"? I guess you mean the new type defined = in this draft. =3D=3D=3D Section 5.1 A new PROTECTION object is included in the Path message. This object=20 carries the desired end-to-end LSP Protection Type (in this case,=20 "1+1 Unidirectional"). This LSP Protection Type value is applicable=20 to both uni- and bi-directional LSPs.=20 This is unclear. In section 14.1 you have=20 0x08 1+1 Unidirectional Protection =20 0x10 1+1 Bi-directional Protection=20 =3D=3D=3D Section 5.1 Your description of the use of the P-bit for 1+1 protection isn't clear. = You mean to say that the P-bit indicates which LSP the ingress would = *prefer* to be the protecting LSP if all other things are equal, but = your text (and the description of the P-bit in sections 4.2.1 and 14) = don't make this clear. =3D=3D=3D Section 6.2 directions. This is done using the Notify message with a new Error=20 Code indicating "Working LSP Failure (Switchover Request)". The=20 I don't see this in the IANA section, and I wonder if you also mean = Error Value? =3D=3D=3D Section 6.2 directions. This is done using the Notify message with a new Error=20 Code indicating "Working LSP Failure (Switchover Request)". The=20 Notify Ack message MUST be sent to confirm the reception of the=20 Notify message (see [RFC3473], Section 4.3). =20 I see no definition of a "Notify Ack message" in RFC3473 (in any = section). I am worried that you are confusing the Ack message with a new procedure = requiring a handshake of Notify messages. =3D=3D=3D Section 6.2 1. If an end-node (A or D) detects the failure of the working =20 LSP (or a degradation of signal quality over the working =20 LSP) or receives a Notify message including its SESSION =20 object within the (see =20 [RFC3473]), it MUST begin receiving on the protecting LSP =20 Note that the sender descriptor or flow descriptor is also present in = the Notify and this will considerably help resolve ambiguities and race = conditions since it identifies the LSP. =3D=3D=3D Section 6.2 1. If an end-node (A or D) detects the failure of the working =20 LSP (or a degradation of signal quality over the working =20 LSP) or receives a Notify message including its SESSION =20 object within the (see =20 [RFC3473]), it MUST begin receiving on the protecting LSP =20 I don't think the receipt of a Notify message is sufficient, per se. I = think the error code and value need to indicate a problem with the LSP. =3D=3D=3D Section 6.2 1. If an end-node (A or D) detects the failure of the working =20 LSP (or a degradation of signal quality over the working =20 LSP) or receives a Notify message including its SESSION =20 object within the (see =20 [RFC3473]), it MUST begin receiving on the protecting LSP =20 and send a Notify message reliably to the other end-node (D =20 or A, respectively). "...send a Notify message reliably" will certainly be misunderstood. You presumably mean "...send a Notify message including the Message_ID = object". =3D=3D=3D Section 6.2 2. Upon receipt of the switchover message, the end-node =20 (D or A, respectively) MUST begin receiving from the =20 protection LSP and send a (Notify) Ack message to the other =20 end-node (A or D, respectively) using reliable message =20 delivery (see [RFC2961]).=20 While this clarifies the use of Ack rather than Notify Ack (not sure why = you need to include "(Notify)") it is now confused about the delivery of = the Ack message. How do we achieve reliable delivery of an Ack message?! =3D=3D=3D Section 7 Although the resources for the protecting LSP are pre-allocated,=20 preemptable traffic may be carried end-to-end using this LSP (i.e.=20 the protecting LSP is capable of carrying extra-traffic) with the=20 caveat that this traffic will be preempted if the working LSP fails.=20 Do you mean that the extra traffic is carried "using this LSP" or "using = some or all of the resources assigned to this LSP"? =3D=3D=3D Section 7 Also, if extra-traffic is carried over the protecting LSP, the=20 corresponding end-nodes may be notified of the failure in order to=20 complete the switchover. =20 I think this is "end-nodes may need to be notified" =3D=3D=3D Section 7.2 To co-ordinate the switchover between end-points, an end-to-end=20 switchover request is needed such that the affected LSP(s) are moved=20 to the protecting LSP. In what way may there be more than one affected LSP moved to a single = protecting LSP? =3D=3D=3D Section 7.2 This operation may be done using a Notify message exchange with a=20 new Error Code indicating "(Working) LSP Failure (Switchover=20 Request)". The Notify Ack message MUST be sent to confirm the=20 reception of the Notify message. =20 All of the same comments as for section 6.2. Also: - Why do you say "may be done"? - Is this the same error code as in 6.2? (the text is slightly = different) =3D=3D=3D=20 Section 7.3 OLD provisioned protecting LSP is resource-disjoint LSP from the N=20 NEW provisioned protecting LSP is resource-disjoint from the N=20 =3D=3D=3D Section 7.3 Can you highlight that the N working LSPs are all between the same pair = of end points. =3D=3D=3D Section 8 OLD this does not mean that the corresponding resources can not used by=20 NEW this does not mean that the corresponding resources can not be used = by=20 =3D=3D=3D Section 8 To make bandwidth pre-reserved for a protecting (but not activated)=20 LSP, available for extra traffic this bandwidth could be included in=20 the advertised Unreserved Bandwidth at priority lower (means=20 numerically higher) than the Setup Priority of the protecting LSP.=20 This feels like it should be the Holding Priority. That is, the Setup = Priority was only important for how it could displace pre-existing LSPs. =3D=3D=3D Section 8.3 OLD From [GMPLS-ARCH], the secondary LSP is setup with resource pre- NEW From [RFC3945], the secondary LSP is setup with resource pre- =3D=3D=3D Section 9 OLD plane) a specific protecting LSP instantiated during the (pre- )provisioning phase. This requires restoration signaling along the=20 NEW plane) a specific protecting LSP instantiated during the (pre-) provisioning phase. This requires restoration signaling along the=20 =3D=3D=3D Section 9 resource sharing), the LSPs must have the same Session Ids, but the=20 Session Id includes the target (egress) IP address. These addresses=20 2xs/Id/ID/ Suggest a search for "id" =3D=3D=3D Section 9.3 OLD From [GMPLS-ARCH], the secondary LSP is setup with resource pre- NEW From [RFC3945], the secondary LSP is setup with resource pre- =3D=3D=3D Section 10 OLD activated. Additional condition raises from mis-connection avoidance=20 NEW activated. An additional condition arises from mis-connection = avoidance=20 =3D=3D=3D Section 10 OLD Note that step 1 may cause alarms to be raised for the pre-empted=20 LSP. If alarm suppression is desired the pre-empting node MAY expand=20 before applying step 1 act as follows.=20 NEW Note that step 1 may cause alarms to be raised for the pre-empted=20 LSP. If alarm suppression is desired the pre-empting node MAY insert the following steps before step 1.=20 =3D=3D=3D Section 10 At the downstream node (with respect to the pre-empting LSP) the=20 processing is RECOMMENDED to be as follows:=20 =20 1. Receive PathTear (and/or PathErr) message for the pre-empted =20 LSP(s).=20 =20 2a.Release the resources associated with the LSP on the interface=20 to the pre-empting LSP, remove any cross-connection and release =20 all other resources associated with the pre-empted LSP.=20 2b.Forward the PathTear (and/or PathErr) message per [RFC 3473].=20 =20 C. Receive the Path message for the pre-empting LSP and process as =20 normal, forwarding it to the downstream node.=20 =20 D. Receive the Resv for the pre-empting LSP and process as normal,=20 forwarding it to the upstream node.=20 Cool numbering scheme :-) Any chance of settling on something more conventional? =3D=3D=3D Section 11.2 Note: when the end-to-end LSP Protection Type is set to=20 "Unprotected", both S and P bit MUST be set to 0 and the LSP SHOULD=20 NOT be re-routed at the head-end node after failure occurrence. The=20 Association_ID value MUST be set to the LSP_ID value of the signaled=20 LSP.=20 Please explain the difference between an attempt to "re-route" and an = attempt to "re-establish". presumably it could involve: - a time difference - the use of make-before-break for failed LSPs. - the use of the ASSOCIATION object. I would like to make sure that you are not applying "SHOULD NOT" to LSP = re-establishment. =3D=3D=3D Section 12 OLD allocated to the LSP that was originally routed over it even after a=20 NEW allocated to the LSP that was originally routed over them even after = a=20 =3D=3D=3D Section 12 - then, apply the reverse 1-phase APS switchover request/response =20 (or 2-phase APS) described in Section 6.2 (or Section 7.2, =20 This is the first mention of APS =3D=3D=3D Section 13 I think this section is going to give us grief during IESG review :-( Why do we need to tie this so closely with NMS etc. And why describe it = as external? Can't we simply describe the function by: - dropping the first para - in C, D and E drop "externally" - in D and E replace "manual" with "requested" =3D=3D=3D Section 13 TWICE OLD Recovery signaling operation is initiated externally that switches=20 NEW Recovery signaling is initiated externally that switches=20 =3D=3D=3D Section 13 (A and B) is set to either 0x04, or 0x08 or 0x10.=20 I would prefer you to use the meanings rather than the values. =3D=3D=3D Section 13 (D and E) This, unless a fault condition exists on=20 ? "This is allowed"? "This is possible"? "This is successful"? =3D=3D=3D Section 14 OLD use so that the object can be included in the Notify message to act=20 a switchover request for 1+1 bi-directional and 1:1 protection. =20 NEW use so that the object can be included in the Notify message to act=20 as a switchover request for 1+1 bi-directional and 1:1 protection. =20 =3D=3D=3D Section 14.1 I believe we have had this discussion before. We don't introduce reserved fields for future extensibility. We only do = it for padding. If you are certain that we need to extend in the future then please use = sub-objects or TLVs. This means that you can: a. Remove the last four bytes of the Protection object. b. Retain the C-Type from RFC3473 =3D=3D=3D Section 15 This object MUST be=20 present in the Path message (for the pre-provisioning of the=20 secondary protecting LSP) if and only if the LSP Protection Type=20 value is set to "0x02". "MUST if and only if" is not really in RFC2119. Can we two statements. One with "MUST" and one with "MUST NOT". =3D=3D=3D Section 15 In the case where my protecting LSP protects only one working LSP and = where the full path of the protecting LSP is known by the ingress = (strict and explicit) and there is no resource sharing between the = protected and protecting LSP, I can't see why I must include a PPRO. In other words, PPRO is an enabler of function (as stated in section = 15.4 "The PPRO enables of sharing recovery resources between a given = secondary protecting LSP and one or more secondary protecting LSPs if = their corresponding primary working LSPs have mutually = (link/node/SRLG)disjoint paths."), but that does not make its presence = mandatory. =3D=3D=3D Section 15.1 The contents of a PRIMARY_PATH_ROUTE object are a series of=20 variable-length data items called subobjects. The subobjects are=20 identical to those that can constitute an EXPLICIT/RECORD ROUTE=20 object as defined in [RFC3209], [RFC3473] and [RFC3477].=20 This seems in contradiction with section 15.3 =3D=3D=3D Section 15.4 OLD The PPRO enables of sharing recovery resources between a given=20 NEW The PPRO enables sharing of recovery resources between a given=20 =3D=3D=3D Section 16 The ASSOCIATION object is used to associate LSPs with each other. In=20 the context of end-to-end LSP recovery, the association MUST only=20 identify LSPs that support the same Tunnel ID. Hmmm. presumably same source and destination is relatively important = too. =3D=3D=3D Section 16 The ASSOCIATION object is used to associate LSPs with each other. =20 You already said this. =3D=3D=3D Section 16.1 Association ID: 16 bits=20 =20 A value that when combined with Association Type and =20 Association Source uniquely identifies an association. =20 It would be helpful to state who assigns this value. =3D=3D=3D Section 16.1 Association Source: 4 or 16 bytes=20 =20 The IP address of the node that originated the association.=20 "The IP address"? Question. Are two associations with the same Association ID equivalent = if the Association Source addresses are different but identify the same = node? Answer (it transpires) is "no".=20 You need to make this much clearer here. =3D=3D=3D Section 17 Isn't Notify modified as well? And I thought Resv was, but I may have been sleeping. =3D=3D=3D Section 18 This is a bit poor. If you don't modify the "external commands" section, you'll certainly = have to discuss security for them. After all, a forced failover can be = pretty disruptive. But I think you need to discuss misconnection here. In particular when = there is mesh protection going on. =3D=3D=3D Section 19 The IANA section needs some gardening to make it really easy for IANA to = implement. - Break it up into clearer subsections. - Make sure you have included all of the information needed in the = registry - Point back at the defining sections of the draft - Only have suggested values in one place in the document - Be consistend in using TBD or TBA in the document =3D=3D=3D Section 19 Should the IANA section also cover the bits in the ADMIN STATUS object? =3D=3D=3D Section 21 Missing references [CRANK], [RFC2205]. Suspect you need to check them = all. Will need to add a reference for LSP segment recovery. =3D=3D=3D Section 21.1 This seems a very long list of normative references. I hope you can = split this so that most of the references are informational. =3D=3D=3D Section 22 You might change this to "Editors' Addresses" ------=_NextPart_000_01E5_01C529BF.63405520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I've got a couple of comments in what = seems like=20 quite a long draft.
Adrian
 
Abstract:
   This document describes = protocol=20 specific procedures and extensions
   for Generalized=20 Multi-Protocol Label Switching (GMPLS) Resource
   = ReserVation=20 Protocol - Traffic Engineering (RSVP-TE) signaling to
   = support=20 end-to-end Label Switched Path (LSP) recovery that denotes =
  =20 protection and restoration.
Not sure what is meant by "denotes" = in this=20 context.
Perhaps "is used to provide" = ?
=3D=3D=3D
Section 2
OLD
   In addition, the reader = is assumed=20 to be familiar with the
   terminology used in [RFC3945],=20 [RFC3471], [RFC3473] and referenced
   as well as [TERM] = and=20 [FUNCT].
NEW
   In addition, the reader = is assumed=20 to be familiar with the
   terminology used in [RFC3945],=20 [RFC3471], [RFC3473],
   as well as in [TERM] and = [FUNCT].=20
=3D=3D=3D
Section 2
   Checklog List from = revision=20 v01.txt: 
Please either remove this text or = mark it so that=20 the RFC editor will remove it.
=3D=3D=3D
Section 3
Although the second paragraph defines = "end-to-end=20 protection" I would like to see this pulled out into its own paragraph = for=20 emphasis, and also a little more clarity added to the definition. For = example,=20 it would appear that your four types of e2e protection are all have the=20 protecting and protected LSPs disjoint in some way - this makes it = appear that=20 this is a property of e2e protection in general and you should state = this if it=20 is true.
=3D=3D=3D
Section 3 para 5
   In 1:N (N =3D< 1) = protection with=20 extra-traffic,
Hopefully you mean N >=3D 1  =
=3D=3D=3D
Section 3 para 5
I note that you do not distinguish = between 1:N=20 and 1:N-with-extra-traffic.
If there is a reason for this perhaps = you could=20 add a note to the text.
=3D=3D=3D
Section 3
OLD
   working one. Here, the = recovery=20 resources for the protecting LSP are
   pre-reserved and = explicit=20 action is required to activate (i.e.
NEW
   working one. Here, the = recovery=20 resources for the protecting LSP are
   pre-reserved but = explicit=20 action is required to activate=20 (i.e. 
         &nbs= p;     =20 ^^^
=3D=3D=3D
Section 3
OLD
   requirements by allowing multiple protecting LSPs to = share=20 common
   link and node resources. The recovery resources = are=20 pre-reserved and
NEW
   requirements by allowing multiple protecting LSPs to = share=20 common
   link and node resources. The recovery resources = are=20 pre-reserved=20 but
           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;        ^^^=20
=3D=3D=3D
Section 3
   Note that in both=20
   cases, any lower priority LSP that would use the = pre-reserved=20
   resources for the protecting LSP(s) MUST be preempted = during=20 the
   activation of the protecting LSP.
This sentence = comes=20 out of the blue. The whole of the paragraph up to then has not even = mentioned=20 extra traffic. I suggest you insert a paragraph break and a sentence = explaining=20 how the pre-reserved resources may be used to support an extra-traffic=20 LSP...
Also, delete "would".
=3D=3D=3D
Section 3
   Full LSP re-routing (or = restoration)=20 switches normal traffic to an
   alternate LSP that is = fully=20 established only after working LSP
   failure = occurs.
This text does not read well in = English. In fact,=20 the same is true of pre-planned. What you mean is, I think, as=20 follows...
   Full LSP re-routing (or = restoration)=20 switches normal traffic to an
   alternate LSP that is not = even=20 partially established until after
   the working = LSP failure occurs.=20
=3D=3D=3D
Section 3
   Note that crankback = signaling (see=20 [CRANK]) and LSP segment recovery
   are further detailed = in=20 dedicated companion documents. Also, there
Need to add a citation = for LSP=20 segment recovery.
=3D=3D=3D
Section=20 4.2
OLD
   The=20 recovery attributes includes all the parameters that=20 determine 
NEW
   The recovery = attributes=20 include all the parameters that determine
=3D=3D=3D
Section 4.2.1
   - S (Secondary) bit: = enables=20 distinction between primary and 
     = secondary=20 LSPs. A primary LSP is a fully established LSP for =20
     which the resource allocation has been = committed at=20 the data plane 
     (i.e. full = cross-connection=20 has been performed). Both working and 
     = protecting LSPs can be primary LSPs. A secondary LSP is an LSP  =
I am=20 uneasy about this definition of "primary". In [TERM] the only mention of = "primary" is in section 2...
   Recovery typically = involves the=20 activation of a recovery (or
   alternate) LSP when a = failure is=20 encountered in the working (or
   primary) = LSP.
This implies that "primary" is a = synonym for=20 "working".
Further, RFC3471 has a subtly = different meaning=20 for "secondary" in section 7.
   Protection Information = also=20 indicates if the LSP is a primary or
   secondary = LSP.  A=20 secondary LSP is a backup to a primary LSP.  The
   = resources=20 of a secondary LSP are not used until the primary LSP
   fails.  The = resources allocated=20 for a secondary LSP MAY be used by
   other LSPs until the = primary=20 LSP fails over to the secondary LSP.  At
   that = point, any=20 LSP that is using the resources for the secondary LSP
   = MUST be=20 preempted.
Can we please not modify the interpretation of the=20 S-bit.
If you need to flag a new piece of = information=20 (to distinguish between resource allocated and not) then please = introduce a new=20 flag.
Note that the P-bit appears to=20 be slightly orthogonal because the text seems to describe = the=20 *current* role of the LSP. (The S-bit in RFC3471 describes the role at = the time=20 the LSP is set up, I think).
=3D=3D=3D
Section 4.3
OLD
   When used for the = working LSP=20 signaling, the Association ID of the
NEW
   When used for signaling = the working=20 LSP, the Association ID of the
=3D=3D=3D
Section 4.3
OLD
   When used for the = protecting LSP=20 signaling, this field identifies
NEW
   When used for signaling = the=20 protecting LSP, this field identifies
=3D=3D=3D
Section 5
   When a failure occurs = (say at node=20 B) and is detected at end-node D,
   the receiver at D = selects the=20 normal traffic from the other LSP.
   From this = perspective, 1+1=20 unidirectional protection can be seen as
   an = uncoordinated=20 protection switching mechanism acting independently
   at = both=20 end-points. Also, for the protected LSP under failure
  =20 condition, the Path_State_Removed Flag of the ERROR_SPEC object (see=20
   [RFC3473]) SHOULD NOT be set upon PathErr message = generation.=20
So, what you are saying is that in 1+1 protection the network may = *never*=20 know that the error is so bad that the LSP is dead, but MUST leave that = choice=20 to the ingress. While this is the operational practice in many transport = networks, I don't see why you make this as strong as a SHOULD=20 NOT.
=3D=3D=3D
Section 5
   Note: one should assume = that both=20 paths are SRLG disjoint otherwise,
   a failure would = impact both=20 working and protecting LSPs.
What is this supposed to tell the = reader? That=20 he should make the assumption or that he should ensure SRLG diversity?=20 ;-)
Actually, I think you want to say = that the=20 quality of 1+1 protection may vary. Allowing link diverse, node diverse = or SRLG=20 diverse 1+1 protection.
(ditto section 6 and 7)
=3D=3D=3D
Section 5.1
   Since both LSPs belong = to the same=20 session, the SESSION object MUST
   be the same for both = LSPs.=20
An undisputable conclusion drawn from = an unproven=20 premise.
Why must both LSPs belong to the same = session? A=20 one line explanation would start the section off nicely.
=3D=3D=3D
Section 5.1
   A new PROTECTION object = is included=20 in the Path message. This object
What is the implication of "new"? I = guess=20 you mean the new type defined in this draft.
=3D=3D=3D
Section 5.1
   A new PROTECTION object = is included=20 in the Path message. This object
   carries the desired = end-to-end=20 LSP Protection Type (in this case,
   "1+1 = Unidirectional"). This=20 LSP Protection Type value is applicable
   to both uni- = and=20 bi-directional LSPs.
This is unclear. In section 14.1 you have =
          &nbs= p;    =20 0x08    1+1 Unidirectional Protection =20
           &nb= sp;   =20 0x10    1+1 Bi-directional Protection =
=3D=3D=3D
Section 5.1
Your description of the use of the = P-bit for 1+1=20 protection isn't clear. You mean to say that the P-bit indicates which = LSP the=20 ingress would *prefer* to be the protecting LSP if all other things are = equal,=20 but your text (and the description of the P-bit in sections 4.2.1 and = 14) don't=20 make this clear.
=3D=3D=3D
Section 6.2
   directions. This is done = using the=20 Notify message with a new Error 
   Code indicating "Working LSP Failure (Switchover = Request)".=20 The
I don't see this in the IANA section, and I wonder if you also = mean=20 Error Value?
=3D=3D=3D
Section 6.2
   directions. This is done = using the=20 Notify message with a new Error
   Code indicating = "Working LSP=20 Failure (Switchover Request)". The
   Notify Ack message = MUST be=20 sent to confirm the reception of the
   Notify message = (see=20 [RFC3473], Section 4.3).   
I see no definition of a "Notify Ack = message" in=20 RFC3473 (in any section).
I am worried that you are confusing = the Ack=20 message with a new procedure requiring a handshake of Notify=20 messages.
=3D=3D=3D
Section 6.2
        1. If=20 an end-node (A or D) detects the failure of the working =20
           LSP (or = a=20 degradation of signal quality over the working =20
           LSP) or = receives a Notify message including its SESSION =20
           object = within=20 the <upstream/downstream session list> (see =20
           = [RFC3473]), it=20 MUST begin receiving on the protecting LSP 
Note that the sender descriptor or = flow=20 descriptor is also present in the Notify and this will considerably help = resolve=20 ambiguities and race conditions since it identifies the = LSP.
=3D=3D=3D
Section 6.2
        1. If=20 an end-node (A or D) detects the failure of the working =20
           LSP (or = a=20 degradation of signal quality over the working =20
           LSP) or = receives a Notify message including its SESSION =20
           object = within=20 the <upstream/downstream session list> (see =20
           = [RFC3473]), it=20 MUST begin receiving on the protecting LSP 
I don't think the = receipt=20 of a Notify message is sufficient, per se. I think the error code and = value need=20 to indicate a problem with the LSP.
=3D=3D=3D
Section 6.2
        1. If=20 an end-node (A or D) detects the failure of the working =20
           LSP (or = a=20 degradation of signal quality over the working =20
           LSP) or = receives a Notify message including its SESSION =20
           object = within=20 the <upstream/downstream session list> (see =20
           = [RFC3473]), it=20 MUST begin receiving on the protecting LSP =20
           and = send a=20 Notify message reliably to the other end-node (D =20
           or A,=20 respectively).
"...send a Notify message reliably" = will=20 certainly be misunderstood.
You presumably mean "...send a Notify = message=20 including the Message_ID object".
=3D=3D=3D
Section 6.2
        2.=20 Upon receipt of the switchover message, the end-node =20
           (D or = A,=20 respectively) MUST begin receiving from the =20
           = protection LSP=20 and send a (Notify) Ack message to the other =20
           = end-node (A or=20 D, respectively) using reliable message =20
           = delivery (see=20 [RFC2961]).
While this clarifies the use of Ack rather than Notify = Ack (not=20 sure why you need to include "(Notify)") it is now confused about the = delivery=20 of the Ack message. How do we achieve reliable delivery of an Ack=20 message?!
=3D=3D=3D
Section 7
   Although the resources = for the=20 protecting LSP are pre-allocated,
   preemptable traffic = may be=20 carried end-to-end using this LSP (i.e.
   the protecting = LSP is=20 capable of carrying extra-traffic) with the
   caveat that = this=20 traffic will be preempted if the working LSP fails.
Do you mean that the extra traffic is = carried=20 "using this LSP" or "using some or all of the resources assigned to this = LSP"?
=3D=3D=3D
Section 7
   Also, if extra-traffic = is carried=20 over the protecting LSP, the
   corresponding end-nodes = may be=20 notified of the failure in order to
   complete the=20 switchover. 
I think this is "end-nodes may need to be=20 notified"
=3D=3D=3D
Section 7.2
   To co-ordinate the = switchover=20 between end-points, an end-to-end
   switchover request is = needed=20 such that the affected LSP(s) are moved
   to the = protecting=20 LSP.
In what way may there be more than = one affected=20 LSP moved to a single protecting LSP?
=3D=3D=3D
Section 7.2
   This operation may be = done using a=20 Notify message exchange with a
   new Error Code = indicating=20 "(Working) LSP Failure (Switchover
   Request)". The = Notify Ack=20 message MUST be sent to confirm the
   reception of the = Notify=20 message. 
All of the same comments as for section = 6.2.
Also:
- Why do you say "may be = done"?
- Is this the same error code as in = 6.2? (the=20 text is slightly different)
=3D=3D=3D 
Section = 7.3
OLD
   provisioned protecting = LSP is=20 resource-disjoint LSP from the N
NEW
   provisioned protecting = LSP=20 is resource-disjoint from the N
=3D=3D=3D
Section 7.3
Can you highlight that the N working = LSPs are all=20 between the same pair of end points.
=3D=3D=3D
Section 8
OLD
   this does not mean that = the=20 corresponding resources can not used by
NEW
   this does not mean that = the=20 corresponding resources can not be used by
=3D=3D=3D
Section 8
   To make bandwidth = pre-reserved for a=20 protecting (but not activated)
   LSP, available for extra = traffic=20 this bandwidth could be included in
   the advertised = Unreserved=20 Bandwidth at priority lower (means
   numerically higher) = than the=20 Setup Priority of the protecting LSP.
This feels like it should be = the=20 Holding Priority. That is, the Setup Priority was only important for how = it=20 could displace pre-existing LSPs.
=3D=3D=3D
Section 8.3
OLD
   From [GMPLS-ARCH], the = secondary LSP=20 is setup with resource pre-
NEW
   From [RFC3945], the = secondary LSP is=20 setup with resource pre-
=3D=3D=3D
Section 9
OLD
   plane) a specific = protecting LSP=20 instantiated during the (pre-
   )provisioning phase. This = requires=20 restoration signaling along the 
NEW
   plane) a specific = protecting=20 LSP instantiated during the (pre-)
   provisioning phase. = This=20 requires restoration signaling along the
=3D=3D=3D
Section 9
   resource sharing), the = LSPs must=20 have the same Session Ids, but the
   Session Id includes = the=20 target (egress) IP address. These addresses
2xs/Id/ID/
Suggest a search for = "id"
=3D=3D=3D
Section 9.3
OLD
   From [GMPLS-ARCH], the = secondary LSP=20 is setup with resource pre-
NEW
   From [RFC3945], the = secondary LSP is=20 setup with resource pre-
=3D=3D=3D
Section 10
OLD
   activated. Additional = condition=20 raises from mis-connection avoidance
NEW
   activated. An additional = condition=20 arises from mis-connection avoidance
=3D=3D=3D
Section 10
OLD
   Note that step 1 may = cause alarms to=20 be raised for the pre-empted
   LSP. If alarm suppression = is=20 desired the pre-empting node MAY expand
   before applying = step 1=20 act as follows.
NEW
   Note that step 1 may = cause alarms to=20 be raised for the pre-empted
   LSP. If alarm suppression = is=20 desired the pre-empting node MAY insert
   the following steps = before step=20 1.
=3D=3D=3D
Section 10
   At the downstream node = (with respect=20 to the pre-empting LSP) the
   processing is RECOMMENDED = to be as=20 follows:
   
   1. Receive PathTear = (and/or=20 PathErr) message for the pre-empted  =
     =20 LSP(s).
   
   2a.Release the resources = associated with the LSP on the interface =
      to=20 the pre-empting LSP, remove any cross-connection and release =20
      all other resources associated with = the=20 pre-empted LSP.
   2b.Forward the PathTear (and/or = PathErr)=20 message per [RFC 3473].
   
   C. = Receive the=20 Path message for the pre-empting LSP and process as =20
      normal, forwarding it to the = downstream node.=20
   
   D. Receive the Resv for the = pre-empting=20 LSP and process as normal,
      forwarding = it to=20 the upstream node.
Cool numbering scheme :-)
Any chance of settling on something = more=20 conventional?
=3D=3D=3D
Section 11.2
   Note: when the = end-to-end LSP=20 Protection Type is set to
   "Unprotected", both S and P = bit MUST=20 be set to 0 and the LSP SHOULD
   NOT be re-routed at the = head-end=20 node after failure occurrence. The
   Association_ID value = MUST be=20 set to the LSP_ID value of the signaled
   LSP.
Please = explain=20 the difference between an attempt to "re-route" and an attempt to=20 "re-establish". presumably it could involve:
- a time difference
- the use of make-before-break for = failed=20 LSPs.
- the use of the ASSOCIATION = object.
I would like to make sure that you = are not=20 applying "SHOULD NOT" to LSP re-establishment.
=3D=3D=3D
Section 12
OLD
   allocated to the LSP = that was=20 originally routed over it even after a
NEW
   allocated to the LSP = that was=20 originally routed over them even after a
=3D=3D=3D
Section 12
   - then, apply the = reverse 1-phase=20 APS switchover request/response 
     (or = 2-phase=20 APS) described in Section 6.2 (or Section 7.2, 
This is the = first=20 mention of APS
=3D=3D=3D
Section 13
I think this section is going to give = us grief=20 during IESG review :-(
Why do we need to tie this so closely = with NMS=20 etc. And why describe it as external?
Can't we simply describe the function = by:
- dropping the first = para
- in C, D and E drop=20 "externally"
- in D and E replace "manual" with=20 "requested"
=3D=3D=3D
Section 13 TWICE
OLD
   Recovery signaling = operation is=20 initiated externally that switches
NEW
   Recovery = signaling is initiated=20 externally that switches
=3D=3D=3D
Section 13 (A and B)
   is set to either 0x04, = or 0x08 or=20 0x10.
I would prefer you to use the meanings rather than the=20 values.
=3D=3D=3D
Section 13 (D and E)
   This, unless a fault = condition=20 exists on
? "This is allowed"? "This is = possible"? "This is=20 successful"?
=3D=3D=3D
Section 14
OLD
   use so that the object = can be=20 included in the Notify message to act
   a switchover = request for=20 1+1 bi-directional and 1:1 protection. 
NEW
   use so that the object = can be=20 included in the Notify message to act
   as a switchover = request=20 for 1+1 bi-directional and 1:1 protection. 
=3D=3D=3D
Section 14.1
I believe we have had this discussion = before.
We don't introduce reserved fields = for future=20 extensibility. We only do it for padding.
If you are certain that we need to = extend in the=20 future then please use sub-objects or TLVs.
This means that you can:
a. Remove the last four bytes of the = Protection=20 object.
b. Retain the C-Type from = RFC3473
=3D=3D=3D
Section 15
   This object MUST be =
  =20 present in the Path message (for the pre-provisioning of the =
  =20 secondary protecting LSP) if and only if the LSP Protection Type=20
   value is set to "0x02".
"MUST if and only if" is not really = in=20 RFC2119.
Can we two statements. One with = "MUST" and one=20 with "MUST NOT".
=3D=3D=3D
Section 15
In the case where my protecting LSP = protects only=20 one working LSP and where the full path of the protecting LSP is known = by the=20 ingress (strict and explicit) and there is no resource sharing between = the=20 protected and protecting LSP, I can't see why I must include a=20 PPRO.
In other words, PPRO is an enabler of = function=20 (as stated in section 15.4 "The PPRO enables of sharing recovery = resources=20 between a given secondary protecting LSP and one or more secondary=20 protecting LSPs if their corresponding primary working LSPs have=20 mutually (link/node/SRLG)disjoint paths."), but that does not make = its=20 presence mandatory.
=3D=3D=3D
Section 15.1
   The contents of a = PRIMARY_PATH_ROUTE=20 object are a series of
   variable-length data items = called=20 subobjects. The subobjects are
   identical to those that = can=20 constitute an EXPLICIT/RECORD ROUTE
   object as defined = in=20 [RFC3209], [RFC3473] and [RFC3477].
This seems in contradiction with = section=20 15.3
=3D=3D=3D
Section 15.4
OLD
   The PPRO enables of = sharing recovery=20 resources between a given
NEW
   The PPRO = enables sharing of=20 recovery resources between a given
=3D=3D=3D
Section 16
   The ASSOCIATION object = is used to=20 associate LSPs with each other. In
   the context of = end-to-end=20 LSP recovery, the association MUST only
   identify LSPs = that=20 support the same Tunnel ID.
Hmmm. presumably same source and = destination is=20 relatively important too.
=3D=3D=3D
Section 16
   The ASSOCIATION object = is used to=20 associate LSPs with each other.  
You already said=20 this.
=3D=3D=3D
Section 16.1
      = Association ID: 16=20 bits
    =
        A=20 value that when combined with Association Type and =20
        Association Source = uniquely=20 identifies an association. 
It would be helpful to state who = assigns=20 this value.
=3D=3D=3D
Section 16.1
      = Association=20 Source: 4 or 16 bytes
   =20
        The IP address of the = node that=20 originated the association.
"The IP address"?
Question. Are two associations with = the same=20 Association ID equivalent if the Association Source addresses are = different but=20 identify the same node?
Answer (it transpires) is "no". =
You need to make this much clearer=20 here.
=3D=3D=3D
Section 17
Isn't Notify modified as = well?
And I thought Resv was, but I may = have been=20 sleeping.
=3D=3D=3D
Section 18
This is a bit poor.
If you don't modify the "external = commands"=20 section, you'll certainly have to discuss security for them. After all, = a forced=20 failover can be pretty disruptive.
But I think you need to discuss = misconnection=20 here. In particular when there is mesh protection going on.
=3D=3D=3D
Section 19
The IANA section needs some gardening = to make it=20 really easy for IANA to implement.
- Break it up into clearer=20 subsections.
- Make sure you have included all of = the=20 information needed in the registry
- Point back at the defining sections = of the=20 draft
- Only have suggested values in one = place in the=20 document
- Be consistend in using TBD or TBA = in the=20 document
=3D=3D=3D
Section 19
Should the IANA section also cover = the bits in=20 the ADMIN STATUS object?
=3D=3D=3D
Section 21
Missing references [CRANK], = [RFC2205]. Suspect=20 you need to check them all.
Will need to add a reference for LSP = segment=20 recovery.
=3D=3D=3D
Section 21.1
This seems a very long list of = normative=20 references. I hope you can split this so that most of the references are = informational.
=3D=3D=3D
Section 22
You might change this to "Editors'=20 Addresses"
 
 
------=_NextPart_000_01E5_01C529BF.63405520-- From owner-ccamp@ops.ietf.org Wed Mar 16 07:41:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13881 for ; Wed, 16 Mar 2005 07:41:13 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBXts-0001RF-MM for ccamp-archive@ietf.org; Wed, 16 Mar 2005 07:45:25 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBXeM-000Bgr-HO for ccamp-data@psg.com; Wed, 16 Mar 2005 12:29:22 +0000 Received: from [192.91.191.4] (helo=smtp.dataconnection.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBXeD-000Bfq-Dn for ccamp@ops.ietf.org; Wed, 16 Mar 2005 12:29:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52A23.B41368C0" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt. Date: Wed, 16 Mar 2005 12:28:48 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8046217D5@baker.datcon.co.uk> Thread-Topic: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt. Thread-Index: AcUqI7dv+wfsAdkETi+h/pzAGwMY7Q== From: "Philip Crocker" To: Cc: , , X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,HTML_20_30, HTML_MESSAGE autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 This is a multi-part message in MIME format. ------_=_NextPart_001_01C52A23.B41368C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have some comments / questions on = draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt. 1) Section 3. If out-of-band verification is in use, and the passive = LMP node receives an out-of-band test message with a trace pattern that = does not correlate to any trace pattern of any data link configured on = the node, the draft does not specify what should happen and it seems to = me that there are two possibilities. a) The passive node sends a TestStatusFailure message back to the = active node to fail verification. b) The passive node discards the received test message. The active = node will continue to retransmit the test message. Either a subsequent = test message leads to a successful verification, or the passive node = eventually times out the verification process of this data link. Note that this is a new situation occurring only in the out-of-band = verification procedure, and therefore I believe should be addressed in = the draft (in the standard link verification procedure an incoming = in-band test message can always, necessarily, be correlated to the data = link it was received on). =20 In my opinion, if it is possible for a trace pattern used on a data link = to be changed and for the change not to be noticed immediately by the = passive node, then it is more robust if the test message is = retransmitted as in b) above allowing multiple opportunities for the = verification to succeed. =20 However, for other implementations this possibility may not exist and so = option a) would be preferable. My preference is therefore for this to = be left as an implementation decision, but for the draft to mention that = both options are equally valid. Would anyone care to comment on this? 2) Section 4.1.9 (InsertTrace Message) specifies that the use of this = message 'assumes that the remote [node] knows the mapping between the = local and remote interface_Ids before fulfilling such [a] request'. = Isn't this same assumption also true for the TraceMonitor and TraceReq = messages defined in sections 4.1.1 and 4.1.6 respectively? If so, I = suggest copying the text above from section 4.1.9 to the introductory = paragraphs of sections 4.1.1 and 4.1.6 also. 3) Section 4. Is there a good reason why both the TraceMonitor and = TraceReq (and associated) messages are required? It seems to me that = the function of a TraceMonitor message can be replicated by using a = TraceReq message, then comparing the observed trace pattern to the = expected pattern. I realize that the TraceMismatch message is allowed = to contain information about multiple mismatches at once, and a similar = function is not available in the TraceReport message, but is this the = only functional difference between the two sets of messages? Thanks, Phil ------_=_NextPart_001_01C52A23.B41368C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.

Hi all,

I have some comments / questions on = draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.

1)  Section 3.  If = out-of-band verification is in use, and the passive LMP node receives an = out-of-band test message with a trace pattern that does not correlate to = any trace pattern of any data link configured on the node, the draft = does not specify what should happen and it seems to me that there are = two possibilities.

    a) The passive node sends a = TestStatusFailure message back to the active node to fail = verification.

    b) The passive node discards the = received test message.  The active node will continue to retransmit = the test message.  Either a subsequent test message leads to a = successful verification, or the passive node eventually times out the = verification process of this data link.

Note that this is a new situation = occurring only in the out-of-band verification procedure, and therefore = I believe should be addressed in the draft (in the standard link = verification procedure an incoming in-band test message can always, = necessarily, be correlated to the data link it was received on).  =

In my opinion, if it is possible for a = trace pattern used on a data link to be changed and for the change not = to be noticed immediately by the passive node, then it is more robust if = the test message is retransmitted as in b) above allowing multiple = opportunities for the verification to succeed. 

However, for other implementations this = possibility may not exist and so option a) would be preferable.  My = preference is therefore for this to be left as an implementation = decision, but for the draft to mention that both options are equally = valid.  Would anyone care to comment on this?

2)  Section 4.1.9 (InsertTrace = Message) specifies that the use of this message 'assumes that the remote = [node] knows the mapping between the local and remote interface_Ids = before fulfilling such [a] request'.  Isn't this same assumption = also true for the TraceMonitor and TraceReq messages defined in sections = 4.1.1 and 4.1.6 respectively?  If so, I suggest copying the text = above from section 4.1.9 to the introductory paragraphs of sections = 4.1.1 and 4.1.6 also.

3)  Section 4.  Is there a = good reason why both the TraceMonitor and TraceReq (and associated) = messages are required?  It seems to me that the function of a = TraceMonitor message can be replicated by using a TraceReq message, then = comparing the observed trace pattern to the expected pattern.  I = realize that the TraceMismatch message is allowed to contain information = about multiple mismatches at once, and a similar function is not = available in the TraceReport message, but is this the only functional = difference between the two sets of messages?

Thanks,

Phil

------_=_NextPart_001_01C52A23.B41368C0-- From owner-ccamp@ops.ietf.org Wed Mar 16 11:52:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09078 for ; Wed, 16 Mar 2005 11:52:30 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBbp7-0007ZD-Ey for ccamp-archive@ietf.org; Wed, 16 Mar 2005 11:56:46 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBbaM-000N0J-Ky for ccamp-data@psg.com; Wed, 16 Mar 2005 16:41:30 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBbaJ-000N02-Di for ccamp@ops.ietf.org; Wed, 16 Mar 2005 16:41:27 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id BE3CBE000200; Wed, 16 Mar 2005 16:41:17 +0000 (GMT) Received: from Puppy ([212.43.203.185] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Mar 2005 16:38:33 +0000 Message-ID: <024901c52a46$d2018740$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , References: <0aa401c51843$6a63fba0$adcb2bd4@Puppy> <025a01c528a0$fc6ff040$0601a8c0@pc6> <031301c52952$85dae720$0601a8c0@pc6> Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Wed, 16 Mar 2005 16:34:06 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 16 Mar 2005 16:38:34.0237 (UTC) FILETIME=[985F0AD0:01C52A46] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Hi Tom, > A minor comment; this document has > false (0), > in several places; following RFC 2579, I think this should be > false (2) Good catch. This is in the example which is why we didn't catch it by compiling. > A larger question,; this mib augments tables in the mpls mib (RFC3812); is there > a reason why the AUGMENTS construct was not used? This is not my area of expertise! I think that there are two strict augmentations and in these cases AUGMENTS was used. The other cases are, I believe, extensions. I *think* the difference is that an AUGMENT is always present and an extension is only present if used. (Feels like I'm on shaky ground!) Cheers, Adrian From owner-ccamp@ops.ietf.org Wed Mar 16 17:26:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05309 for ; Wed, 16 Mar 2005 17:26:15 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBh28-0007s3-Jl for ccamp-archive@ietf.org; Wed, 16 Mar 2005 17:30:33 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBgoG-0006PU-GJ for ccamp-data@psg.com; Wed, 16 Mar 2005 22:16:12 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBgoE-0006P0-1J for ccamp@ops.ietf.org; Wed, 16 Mar 2005 22:16:10 +0000 Received: from pc6 (1Cust217.tnt15.lnd4.gbr.da.uu.net [62.188.144.217]) by astro.systems.pipex.net (Postfix) with SMTP id 46BDDE00018C; Wed, 16 Mar 2005 22:16:05 +0000 (GMT) Message-ID: <021c01c52a6c$fb0572c0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , References: <0aa401c51843$6a63fba0$adcb2bd4@Puppy> <025a01c528a0$fc6ff040$0601a8c0@pc6> <031301c52952$85dae720$0601a8c0@pc6> <024901c52a46$d2018740$dccb2bd4@Puppy> Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Wed, 16 Mar 2005 22:09:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit To quote from RFC2578 " Instances of subordinate columnar objects of a conceptual row augmentation are identified according to the INDEX clause of the base conceptual row corresponding to the object named in the AUGMENTS clause. Further, instances of subordinate columnar objects of a conceptual row augmentation exist according to the same semantics as instances of subordinate columnar objects of the base conceptual row being augmented. As such, note that creation of a base conceptual row implies the correspondent creation of any conceptual row augmentations" exactly; or - AUGMENTS is an alternative to INDEX in SMIv2 - there is a one to one correspondence between rows in the base table and rows in the AUGMENTS table(s - can be more than one), same index columns, same index values - the column objects in the AUGMENTS table(s) are created when the row in the base table is created; assuming that the agent implements those columns in the AUGMENTS table(s) - that is a matter of conformance clauses etc. Reading the text, I thought these conditions were met - but I was not sure; seeing the INDEX clauses makes me think I am not understanding the text, I am missing something:-) Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: "Tom Petch" ; Sent: Wednesday, March 16, 2005 5:34 PM Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt > Hi Tom, > > > A minor comment; this document has > > false (0), > > in several places; following RFC 2579, I think this should be > > false (2) > > Good catch. This is in the example which is why we didn't catch it by > compiling. > > > A larger question,; this mib augments tables in the mpls mib (RFC3812); > is there > > a reason why the AUGMENTS construct was not used? > > This is not my area of expertise! > I think that there are two strict augmentations and in these cases > AUGMENTS was used. > > The other cases are, I believe, extensions. > > I *think* the difference is that an AUGMENT is always present and an > extension is only present if used. > (Feels like I'm on shaky ground!) > > Cheers, > Adrian > From owner-ccamp@ops.ietf.org Wed Mar 16 18:01:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09547 for ; Wed, 16 Mar 2005 18:01:58 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhaj-0001Yk-07 for ccamp-archive@ietf.org; Wed, 16 Mar 2005 18:06:17 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBhQL-000EDD-PE for ccamp-data@psg.com; Wed, 16 Mar 2005 22:55:33 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBhQ9-000E6v-6N for ccamp@ops.ietf.org; Wed, 16 Mar 2005 22:55:21 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 52784E0001AF; Wed, 16 Mar 2005 22:55:20 +0000 (GMT) Received: from Puppy ([212.43.203.12] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Mar 2005 22:50:58 +0000 Message-ID: <037901c52a7a$d8d96630$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , References: <0aa401c51843$6a63fba0$adcb2bd4@Puppy> <025a01c528a0$fc6ff040$0601a8c0@pc6> <031301c52952$85dae720$0601a8c0@pc6> <024901c52a46$d2018740$dccb2bd4@Puppy> <021c01c52a6c$fb0572c0$0601a8c0@pc6> Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Wed, 16 Mar 2005 22:51:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 16 Mar 2005 22:50:59.0278 (UTC) FILETIME=[9F0DB6E0:01C52A7A] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Thanks for the references. This fits with what I thought. Viz. Augments means that an entry in the augmenting table is created whenever an entry in the base table is created. Extends means that an entry in the extending table is created only when required. The indexing in the two cases is the same. Cheers, Adrian ----- Original Message ----- From: "Tom Petch" To: "Adrian Farrel" ; Sent: Wednesday, March 16, 2005 9:09 PM Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt > To quote from RFC2578 > " Instances of subordinate columnar > objects of a conceptual row augmentation are identified according to > the INDEX clause of the base conceptual row corresponding to the > object named in the AUGMENTS clause. Further, instances of > subordinate columnar objects of a conceptual row augmentation exist > according to the same semantics as instances of subordinate columnar > objects of the base conceptual row being augmented. As such, note > that creation of a base conceptual row implies the correspondent > creation of any conceptual row augmentations" > > exactly; or > > - AUGMENTS is an alternative to INDEX in SMIv2 > - there is a one to one correspondence between rows in the base table and rows > in the AUGMENTS table(s - can be more than one), same index columns, same index > values > - the column objects in the AUGMENTS table(s) are created when the row in the > base table is created; assuming that the agent implements those columns in the > AUGMENTS table(s) - that is a matter of conformance clauses etc. > > Reading the text, I thought these conditions were met - but I was not sure; > seeing the INDEX clauses makes me think I am not understanding the text, I am > missing something:-) > > Tom Petch > > ----- Original Message ----- > From: "Adrian Farrel" > To: "Tom Petch" ; > Sent: Wednesday, March 16, 2005 5:34 PM > Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt > > > > Hi Tom, > > > > > A minor comment; this document has > > > false (0), > > > in several places; following RFC 2579, I think this should be > > > false (2) > > > > Good catch. This is in the example which is why we didn't catch it by > > compiling. > > > > > A larger question,; this mib augments tables in the mpls mib (RFC3812); > > is there > > > a reason why the AUGMENTS construct was not used? > > > > This is not my area of expertise! > > I think that there are two strict augmentations and in these cases > > AUGMENTS was used. > > > > The other cases are, I believe, extensions. > > > > I *think* the difference is that an AUGMENT is always present and an > > extension is only present if used. > > (Feels like I'm on shaky ground!) > > > > Cheers, > > Adrian > > > > > From owner-ccamp@ops.ietf.org Wed Mar 16 18:02:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09610 for ; Wed, 16 Mar 2005 18:02:48 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhbW-0001aV-Nx for ccamp-archive@ietf.org; Wed, 16 Mar 2005 18:07:07 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBhQB-000E7d-2e for ccamp-data@psg.com; Wed, 16 Mar 2005 22:55:23 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBhQ5-000E6M-Va for ccamp@ops.ietf.org; Wed, 16 Mar 2005 22:55:18 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id EFC53E0000EF for ; Wed, 16 Mar 2005 22:55:09 +0000 (GMT) Received: from Puppy ([212.43.203.12] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Mar 2005 22:47:31 +0000 Message-ID: <036b01c52a7a$5dea9ac0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft minutes Date: Wed, 16 Mar 2005 22:44:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 16 Mar 2005 22:47:32.0890 (UTC) FILETIME=[240967A0:01C52A7A] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Content-Transfer-Encoding: 7bit Hi, Please comment on the draft minutes. Thanks to Richard, Zafar and Tove for putting these together. Adrian ======== Common Control and Measurement Plane WG (ccamp) Tuesday, March 8, 2005 at 0900-1130 Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen Working group status - chairs - No changes to the agenda made. - Adrian reviewed status of drafts, reviewed charter milestones. We are holding off on new charter until finish last call of 8 drafts, expect 1-2 months. - Bill summarized ADs view, should wait for re-chartering until finish last call considering expectation will be very soon for last calls. * Dimitri asked about IPR assertion on re-optimization draft - Adrian said it did not give the same terms that have been seen in some recent IPR claims. The WG has to decide what to do. - Scott Bradner said we need to be very careful. Advised there may be anti-trust issues. Best to have no IETF interaction other than to ask for clarity. Scott offered to review emails on the subject. - JP said we can take that as a way to go forward and continue technical work. ASON considerations ITU liaison - Lyndon Ong presented Wesam's slides - Thanks to the IETF for liaisons and participation of Adrian and Igor at last meetings - Crankback and the comparison of LMP and ASON discovery will be incorporated in SG15 Q14's work. - There are two liaisons from ITU to CCAMP on the way. - Routing - ITU not planning any routing exts work, looking to IETF's work. - Continuing work on ASON management. - An FTP site is available for liaison statements. * Adrian asked if ITU plans to liaise G.7713 on new text for crankback before consent? - Lyndon said a meeting is upcoming and will ask for it to be considered. * Kireeti asked if there is any problem in that the crankback draft is not an RFC yet? - Adrian - RFC is desirable, not required? - Scott Bradner - it is required to have an RFC number for final balloting. The IESG can request expedited publication. * Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU terminology, and may want to consider including it. - Adrian - can that be liaised to us? - Steve Trowbridge - Yes, we can do that. ASON Routing Evaluation * Adrian - The design team on routing has members from both ITU and IETF, although we did not do the correct process, so ITU reps are individuals, not ITU representatives. - Adrian will work with Steve to formalize the process. * Adrian - Would like to make the draft from the team on evaluation of routing protocols into a working group draft - we will take to the list to see if any objection. * Dimitri - asked if we can use formal liaison process to send this draft to ITU, does it need to be WG draft? And encourages comments now, before it goes to last call. - Adrian - we can liaise the draft and our intention to consider it as a WG draft Lexicography draft (Adrian) - Q14 indicates meeting went well, authors summarized comments and incorporated in this release. * Adrian asked if should be WG draft - Kireeti said we could do that, need to ask the list, also need to compare with G.8081 * Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC or drafts, are there definitions? - Adrian thinks there are good terms, though in multiple RFCs/drafts. - Ben - if someone is new to the IETF, they have difficulty on where to go for definitions. - Adrian - if people want to do a draft to collect definitions of all GMPLS terms (more general than just ASON as in lexi draft), then they are welcome to do it. Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi) LSP Stitching (Arthi) - Need feedback on several items. * Adrian - it would be inappropriate to move extensions to be a WG draft without first stitching draft becoming a wg draft. If no one objects, see no reason why not to be WG draft. * Dimitri - Question: the draft was to originally do signaling exts, do we need to do more on routing aspects? - Arthi - agree, if we do now as separate doc from exts draft, then should include routing aspects. * Dimitri - if allow different switching caps, then this changes the type, and this a FA - Arthi - but end-to-end does not change. * Zafar - we need to be careful what advertising because of scalability concerns, need further consideration. - Arthi - yes need more discussion. * Igor - thought stitching maybe more appropriate for LSP hierarchy draft, but as this already in editor's queue, will add here. * Lou - sw cap can change hop by hop just needs to match end to end of hop. - Arthi - agree, we were thinking the same. * Discussion sent to mailing list Per-domain path computation method for computing inter-domain traffic engineering (TE) LSP. (JP) Draft-vasseur-ccamp-inter-domain-path-comp-00.txt: routing and path computation aspects. * Zafar asked clarification on ccamp-pce relationship - Kireeti - this draft discusses ASBR on the path, if not then it's PCE, suggest add this to draft to clarify that this is for when computation is done by elements on the path. - JP - ok * Adrian and Kireeti asked if this should be a WG draft? Good consensus in the room to be WG draft, will take it to the list. Automesh (JP) - Agreement to rehash work a bit to put these together. - Now 2 drafts - Not a new ID, no changes. - Deployed networks using that. - No major changes planned * Igor - asked how to reflect constraints in a node for switching? - JP - we are discussing auto mesh, not node switching. - Igor - but how do we reflect node capabilities? - JP - this we do, we carry in OSPF a TLV to describe. - Igor - how to reflect for computation any internal constraints, could do via node caps advertisement. - JP agrees, though here just doing a discovery, doesn't think related as discovering members of mesh. - Adrian - two drafts, this is not node capability that is next one by JP, cut discussion said to take it to list. JP - Routing extensions for discovery of TE node capabilities * Adrian - on process, authors did a group job of splitting draft and sending to OSPF and ISIS groups, chairs will follow up with those groups. * Dimitri - should for terminology call TE router? - JP - yes. - Dimitri - shouldn't be exclusive the TLV? - JP - yes. * Igor - how to distinguish node capabilities? - Adrian - do by TLVs, need to do a draft to propose, this draft gives you the TLVs, then can follow-up with other drafts to describe function want to use it for, take discussion to list. * JP asked that this be adopted as a WG document. - Adrian - Take it to the list Extensions to GMPLS RSVP graceful restart (Lou Berger) * Adrian - do editorial respin, let us know, and we will take to last call * Any implementations? - Yes - two! MRN Requirements (Kohei Shiomoto) Evaluation draft (JL Le Roux) Protocol extensions (Dimitri) * Arthi - what does virtual FA have to do with MRN, isn't it general? - Dimitri - should we have a specific doc on virtual FA for wider scope? - Arthi - did you want to scope only to MRN context? - Dimitri - no, just not sure if soln doc should be split. - Arthi - could be general - so prefer a separate doc on virtual FA. * Zafar - we need to give a priority capability for TE. - Dimitri - new TLV may be needed to describe relationships of multiple interfaces * Zafar - how relates to hierarchy draft? - Dimitri - maybe should be as applicability statement, - Kireeti - should do on mailing list * Kireeti - requests to continue work, when re-charter will consider for WG drafts. Routing considerations and CSPF for inter-as (Tomohiro Otani) * JP - very useful draft, not sure (and concerned) on capability and scalability as depends on constraint trying to summarize. - Otani - ok, we need more on summarizing capability. * Kireeti - thinks good and hopes to be a WG draft, though for now would request for this draft to continue work, though lets finish what ccamp has now and then when re-charter will make this as a WG doc. * Otani - how to handle inter-as cspf constraints? - Kireeti - as noted before (continue work). L2LSP (Dimitri) * Adrian asked clarification, is this "single hop"? - Dimitri - multiple hops each is a LSR, will clarify this in draft * Kireeti - ADs request a framework doc and include how it relates to other SDOs, max 10 pages - Dimitri - ok GMPLS addressing (Richard Rabbat) * Adrian - as this is first version, recommend continue discussion, re-spin draft, and then review again. * Adrian asked for feedback on the topics, not the technical content initially. * Loa - BCP is a specific type of RFC, describes what we have experience with not necessarily what should be (as in this draft) * Kireeti - warns for everyone with implementations to review the draft to ensure direction taken by this draft is right one. * Lou - should we wait for re-spin or now? - Kireeti - wait for re-spin. L1VPN (Tomonori Takeda) Framework draft Applicability draft * Alex - by next IETF will decide if it should be included in ccamp or as separate WG. Control plane saturation (JL Le Roux) * Arthi - do we really want to advertise limitations and implications? * Kireeti - because of time, lets do on list. Graceful shutdown (Zafar Ali) * Kireeti - will consider for wg doc after re-charter * JP - is this part of current charter - Kireeti - doesn't matter, we just can not include anymore as WG doc until re-charter. Deployment-augmented (Zafar Ali) * Arthi- comment is this a FA for router to optical domain - Zafar - no just TE link GMPLS interworking (Kenji) * Dimitri - why need to adv priority of LSP? - Adrian - need to ask on list. GMPLS interworking (Kohei Shiomoto) * Adrian - WG doc will be decided after re-charter - Welcome that will merge with other draft on augmented, - Suggest also look at Kenji's interworking draft to merge. Cho - ARP signal * Kireeti - request work with Dimitri on framework draft, - When decide direction and interactions with other SDO, may decide to form a design team to work on L2, - First we need a framework. From owner-ccamp@ops.ietf.org Thu Mar 17 09:51:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04837 for ; Thu, 17 Mar 2005 09:51:36 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBwPp-0002d2-Ry for ccamp-archive@ietf.org; Thu, 17 Mar 2005 09:56:03 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBw64-000IXv-CS for ccamp-data@psg.com; Thu, 17 Mar 2005 14:35:36 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBw5s-000IWe-Eu; Thu, 17 Mar 2005 14:35:25 +0000 Message-ID: <423995B6.7000800@psg.com> Date: Thu, 17 Mar 2005 15:35:34 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Last call review of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt References: <01f501c529c0$198d56c0$dccb2bd4@Puppy> In-Reply-To: <01f501c529c0$198d56c0$dccb2bd4@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ad60914b71abd47c285b3604f8c8304 Content-Transfer-Encoding: 7bit hi adrian thanks for commenting - in-line responses to your question Adrian Farrel wrote: > Hi, > I've got a couple of comments in what seems like quite a long draft. > Adrian > > Abstract: > This document describes protocol specific procedures and extensions > for Generalized Multi-Protocol Label Switching (GMPLS) Resource > ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to > support end-to-end Label Switched Path (LSP) recovery that denotes > protection and restoration. > Not sure what is meant by "denotes" in this context. > Perhaps "is used to provide" ? -> was meant to say "that means..." - so any better wording ? > === > Section 2 > OLD > In addition, the reader is assumed to be familiar with the > terminology used in [RFC3945], [RFC3471], [RFC3473] and referenced > as well as [TERM] and [FUNCT]. > NEW > In addition, the reader is assumed to be familiar with the > terminology used in [RFC3945], [RFC3471], [RFC3473], > as well as in [TERM] and [FUNCT]. -> ok > === > Section 2 > Checklog List from revision v01.txt: > Please either remove this text or mark it so that the RFC editor will remove it. -> ok > === > Section 3 > Although the second paragraph defines "end-to-end protection" I would like to see this pulled out into its own paragraph for emphasis, and also a little more clarity added to the definition. For example, it would appear that your four types of e2e protection are all have the protecting and protected LSPs disjoint in some way - this makes it appear that this is a property of e2e protection in general and you should state this if it is true. -> so you would like to see as part of the introduction a statement about end-to-end protection concept - i don't think there is any specific issue in adding this > === > Section 3 para 5 > In 1:N (N =< 1) protection with extra-traffic, > Hopefully you mean N >= 1 -> yes > === > Section 3 para 5 > I note that you do not distinguish between 1:N and 1:N-with-extra-traffic. > If there is a reason for this perhaps you could add a note to the text. -> indeed > === > Section 3 > OLD > working one. Here, the recovery resources for the protecting LSP are > pre-reserved and explicit action is required to activate (i.e. > NEW > working one. Here, the recovery resources for the protecting LSP are > pre-reserved but explicit action is required to activate (i.e. > ^^^ -> ok > === > Section 3 > OLD > requirements by allowing multiple protecting LSPs to share common > link and node resources. The recovery resources are pre-reserved and > NEW > requirements by allowing multiple protecting LSPs to share common > link and node resources. The recovery resources are pre-reserved but > ^^^ -> ok > === > Section 3 > Note that in both > cases, any lower priority LSP that would use the pre-reserved > resources for the protecting LSP(s) MUST be preempted during the > activation of the protecting LSP. > This sentence comes out of the blue. The whole of the paragraph up to then has not even mentioned extra traffic. -> don't understand your comment as it is mentioned at the beginning of the paragraph > I suggest you insert a paragraph break and a sentence explaining how the pre-reserved resources may be used to support an extra-traffic LSP... > Also, delete "would". -> ok - this could indeed ease reading > === > Section 3 > Full LSP re-routing (or restoration) switches normal traffic to an > alternate LSP that is fully established only after working LSP > failure occurs. > This text does not read well in English. In fact, the same is true of pre-planned. What you mean is, I think, as follows... > Full LSP re-routing (or restoration) switches normal traffic to an > alternate LSP that is not even partially established until after > the working LSP failure occurs. -> indeed as none pre-provisioning actions are performed for the alternate > === > Section 3 > Note that crankback signaling (see [CRANK]) and LSP segment recovery > are further detailed in dedicated companion documents. Also, there > Need to add a citation for LSP segment recovery. -> ok > === > Section 4.2 > OLD > The recovery attributes includes all the parameters that determine > NEW > The recovery attributes include all the parameters that determine -> ok > === > Section 4.2.1 > - S (Secondary) bit: enables distinction between primary and > secondary LSPs. A primary LSP is a fully established LSP for > which the resource allocation has been committed at the data plane > (i.e. full cross-connection has been performed). Both working and > protecting LSPs can be primary LSPs. A secondary LSP is an LSP > I am uneasy about this definition of "primary". In [TERM] the only mention of "primary" is in section 2... > Recovery typically involves the activation of a recovery (or > alternate) LSP when a failure is encountered in the working (or > primary) LSP. -> this definition needs to be updated as - by removing primary in the second parenthesis - it comes from a initial phase where no solution where yet started > This implies that "primary" is a synonym for "working". > Further, RFC3471 has a subtly different meaning for "secondary" in section 7. > Protection Information also indicates if the LSP is a primary or > secondary LSP. A secondary LSP is a backup to a primary LSP. The > resources of a secondary LSP are not used until the primary LSP > fails. The resources allocated for a secondary LSP MAY be used by > other LSPs until the primary LSP fails over to the secondary LSP. At > that point, any LSP that is using the resources for the secondary LSP > MUST be preempted. > Can we please not modify the interpretation of the S-bit. -> this is what the draft does as also explained in " In this document, the PROTECTION object uses as a basis the PROTECTION object defined in [RFC3471] and [RFC3473] and defines additional fields within it. The fields defined in [RFC3471] and [RFC3473] are unchanged by this memo. " > If you need to flag a new piece of information (to distinguish between resource allocated and not) then please introduce a new flag. > Note that the P-bit appears to be slightly orthogonal because the text seems to describe the *current* role of the LSP. (The S-bit in RFC3471 describes the role at the time the LSP is set up, I think). -> note this has already been explained to you - where we came to the conclusion for clarity to add the above mentioned paragraph > === > Section 4.3 > OLD > When used for the working LSP signaling, the Association ID of the > NEW > When used for signaling the working LSP, the Association ID of the -> ok > === > Section 4.3 > OLD > When used for the protecting LSP signaling, this field identifies > NEW > When used for signaling the protecting LSP, this field identifies -> ok > === > Section 5 > When a failure occurs (say at node B) and is detected at end-node D, > the receiver at D selects the normal traffic from the other LSP. > From this perspective, 1+1 unidirectional protection can be seen as > an uncoordinated protection switching mechanism acting independently > at both end-points. Also, for the protected LSP under failure > condition, the Path_State_Removed Flag of the ERROR_SPEC object (see > [RFC3473]) SHOULD NOT be set upon PathErr message generation. > So, what you are saying is that in 1+1 protection the network may *never* know that the error is so bad that the LSP is dead, but MUST leave that choice to the ingress. While this is the operational practice in many transport networks, I don't see why you make this as strong as a SHOULD NOT. -> what i mean is that this LSP in a 1+1 mode should not be released after failure (which is the common usage of such a scheme) > === > Section 5 > Note: one should assume that both paths are SRLG disjoint otherwise, > a failure would impact both working and protecting LSPs. > What is this supposed to tell the reader? That he should make the assumption or that he should ensure SRLG diversity? ;-) > Actually, I think you want to say that the quality of 1+1 protection may vary. Allowing link diverse, node diverse or SRLG diverse 1+1 protection. > (ditto section 6 and 7) -> indeed i can phrase this in a more prescriptive way (rather than the descriptive currently proposed) > === > Section 5.1 > Since both LSPs belong to the same session, the SESSION object MUST > be the same for both LSPs. > An undisputable conclusion drawn from an unproven premise. > Why must both LSPs belong to the same session? A one line explanation would start the section off nicely. -> ok > === > Section 5.1 > A new PROTECTION object is included in the Path message. This object > What is the implication of "new"? I guess you mean the new type defined in this draft. -> yes > === > Section 5.1 > A new PROTECTION object is included in the Path message. This object > carries the desired end-to-end LSP Protection Type (in this case, > "1+1 Unidirectional"). This LSP Protection Type value is applicable > to both uni- and bi-directional LSPs. > This is unclear. In section 14.1 you have > 0x08 1+1 Unidirectional Protection > 0x10 1+1 Bi-directional Protection -> in 5.1 "This LSP Protection Type value is applicable to both uni- and bi-directional LSPs. " -> in 6.1 "This LSP Protection Type value is only applicable to bi-directional LSPs. > === > Section 5.1 > Your description of the use of the P-bit for 1+1 protection isn't clear. You mean to say that the P-bit indicates which LSP the ingress would *prefer* to be the protecting LSP if all other things are equal, but your text (and the description of the P-bit in sections 4.2.1 and 14) don't make this clear. -> ok instead of stating it is desirable i will provide a more deterministic statement > === > Section 6.2 > directions. This is done using the Notify message with a new Error > Code indicating "Working LSP Failure (Switchover Request)". The > I don't see this in the IANA section, and I wonder if you also mean Error Value? -> it corresponds to the entry "Notify Error/LSP Failure" (suggested value = 6)" error value is thus appropriate > === > Section 6.2 > directions. This is done using the Notify message with a new Error > Code indicating "Working LSP Failure (Switchover Request)". The > Notify Ack message MUST be sent to confirm the reception of the > Notify message (see [RFC3473], Section 4.3). > I see no definition of a "Notify Ack message" in RFC3473 (in any section). > I am worried that you are confusing the Ack message with a new procedure requiring a handshake of Notify messages. -> ok i will rephrase that one > === > Section 6.2 > 1. If an end-node (A or D) detects the failure of the working > LSP (or a degradation of signal quality over the working > LSP) or receives a Notify message including its SESSION > object within the (see > [RFC3473]), it MUST begin receiving on the protecting LSP > Note that the sender descriptor or flow descriptor is also present in the Notify and this will considerably help resolve ambiguities and race conditions since it identifies the LSP. -> ok i will add a statement along these lines > === > Section 6.2 > 1. If an end-node (A or D) detects the failure of the working > LSP (or a degradation of signal quality over the working > LSP) or receives a Notify message including its SESSION > object within the (see > [RFC3473]), it MUST begin receiving on the protecting LSP > I don't think the receipt of a Notify message is sufficient, per se. I think the error code and value need to indicate a problem with the LSP. -> this is explained in the next paragraph, but i will add a statement with respect to this error code/value processing " Note: in this case, the IF_ID ERROR_SPEC replaces the ERROR_SPEC in the Notify message, otherwise the corresponding (data plane) information SHOULD be received in the PathErr/ResvErr message. " > === > Section 6.2 > 1. If an end-node (A or D) detects the failure of the working > LSP (or a degradation of signal quality over the working > LSP) or receives a Notify message including its SESSION > object within the (see > [RFC3473]), it MUST begin receiving on the protecting LSP > and send a Notify message reliably to the other end-node (D > or A, respectively). > "...send a Notify message reliably" will certainly be misunderstood. > You presumably mean "...send a Notify message including the Message_ID object". -> yes > === > Section 6.2 > 2. Upon receipt of the switchover message, the end-node > (D or A, respectively) MUST begin receiving from the > protection LSP and send a (Notify) Ack message to the other > end-node (A or D, respectively) using reliable message > delivery (see [RFC2961]). > While this clarifies the use of Ack rather than Notify Ack (not sure why you need to include "(Notify)") it is now confused about the delivery of the Ack message. How do we achieve reliable delivery of an Ack message?! -> needs to be rephrased as the only to achieve reliable bi-directional exchange is by ensuring three way handshake (Notify ->, Notify + Ack <-, Ack ->) > === > Section 7 > Although the resources for the protecting LSP are pre-allocated, > preemptable traffic may be carried end-to-end using this LSP (i.e. > the protecting LSP is capable of carrying extra-traffic) with the > caveat that this traffic will be preempted if the working LSP fails. > Do you mean that the extra traffic is carried "using this LSP" or "using some or all of the resources assigned to this LSP"? -> the first "using this LSP" > === > Section 7 > Also, if extra-traffic is carried over the protecting LSP, the > corresponding end-nodes may be notified of the failure in order to > complete the switchover. > I think this is "end-nodes may need to be notified" -> ok > === > Section 7.2 > To co-ordinate the switchover between end-points, an end-to-end > switchover request is needed such that the affected LSP(s) are moved > to the protecting LSP. > In what way may there be more than one affected LSP moved to a single protecting LSP? -> if someone uses the multiplier field of the SONET/SDH TSPEC, but there is a typo in the last LSP (missed a "s") > === > Section 7.2 > This operation may be done using a Notify message exchange with a > new Error Code indicating "(Working) LSP Failure (Switchover > Request)". The Notify Ack message MUST be sent to confirm the > reception of the Notify message. > All of the same comments as for section 6.2. > Also: > - Why do you say "may be done"? -> "initiated" or "performed" > - Is this the same error code as in 6.2? (the text is slightly different) -> i will adapt error value per IANA section - the same for the error codes as part of section 6.2 > === > Section 7.3 > OLD > provisioned protecting LSP is resource-disjoint LSP from the N > NEW > provisioned protecting LSP is resource-disjoint from the N -> ok > === > Section 7.3 > Can you highlight that the N working LSPs are all between the same pair of end points. -> ok > === > Section 8 > OLD > this does not mean that the corresponding resources can not used by > NEW > this does not mean that the corresponding resources can not be used by -> ok > === > Section 8 > To make bandwidth pre-reserved for a protecting (but not activated) > LSP, available for extra traffic this bandwidth could be included in > the advertised Unreserved Bandwidth at priority lower (means > numerically higher) than the Setup Priority of the protecting LSP. > This feels like it should be the Holding Priority. That is, the Setup Priority was only important for how it could displace pre-existing LSPs. -> ok (it will clarify) - but there was an implicit statement here that both are actually equal > === > Section 8.3 > OLD > From [GMPLS-ARCH], the secondary LSP is setup with resource pre- > NEW > From [RFC3945], the secondary LSP is setup with resource pre- -> ok > === > Section 9 > OLD > plane) a specific protecting LSP instantiated during the (pre- > )provisioning phase. This requires restoration signaling along the > NEW > plane) a specific protecting LSP instantiated during the (pre-) > provisioning phase. This requires restoration signaling along the -> ok > === > Section 9 > resource sharing), the LSPs must have the same Session Ids, but the > Session Id includes the target (egress) IP address. These addresses > 2xs/Id/ID/ > Suggest a search for "id" -> will use "ID" > === > Section 9.3 > OLD > From [GMPLS-ARCH], the secondary LSP is setup with resource pre- > NEW > From [RFC3945], the secondary LSP is setup with resource pre- -> ok > === > Section 10 > OLD > activated. Additional condition raises from mis-connection avoidance > NEW > activated. An additional condition arises from mis-connection avoidance -> ok > === > Section 10 > OLD > Note that step 1 may cause alarms to be raised for the pre-empted > LSP. If alarm suppression is desired the pre-empting node MAY expand > before applying step 1 act as follows. > NEW > Note that step 1 may cause alarms to be raised for the pre-empted > LSP. If alarm suppression is desired the pre-empting node MAY insert > the following steps before step 1. -> ok > === > Section 10 > At the downstream node (with respect to the pre-empting LSP) the > processing is RECOMMENDED to be as follows: > > 1. Receive PathTear (and/or PathErr) message for the pre-empted > LSP(s). > > 2a.Release the resources associated with the LSP on the interface > to the pre-empting LSP, remove any cross-connection and release > all other resources associated with the pre-empted LSP. > 2b.Forward the PathTear (and/or PathErr) message per [RFC 3473]. > > C. Receive the Path message for the pre-empting LSP and process as > normal, forwarding it to the downstream node. > > D. Receive the Resv for the pre-empting LSP and process as normal, > forwarding it to the upstream node. > Cool numbering scheme :-) > Any chance of settling on something more conventional? -> ok - will use 1, 2a, 2b, 3, 4 > === > Section 11.2 > Note: when the end-to-end LSP Protection Type is set to > "Unprotected", both S and P bit MUST be set to 0 and the LSP SHOULD > NOT be re-routed at the head-end node after failure occurrence. The > Association_ID value MUST be set to the LSP_ID value of the signaled > LSP. > Please explain the difference between an attempt to "re-route" and an attempt to "re-establish". presumably it could involve: > - a time difference > - the use of make-before-break for failed LSPs. > - the use of the ASSOCIATION object. > I would like to make sure that you are not applying "SHOULD NOT" to LSP re-establishment. -> it means do not apply re-routing as specified in this document, i will add a paragraph around these lines > === > Section 12 > OLD > allocated to the LSP that was originally routed over it even after a > NEW > allocated to the LSP that was originally routed over them even after a -> ok > === > Section 12 > - then, apply the reverse 1-phase APS switchover request/response > (or 2-phase APS) described in Section 6.2 (or Section 7.2, > This is the first mention of APS -> see section 7.2 in this section 12 i will use the term "protection switching signaling" instead > === > Section 13 > I think this section is going to give us grief during IESG review :-( > Why do we need to tie this so closely with NMS etc. And why describe it as external? > Can't we simply describe the function by: > - dropping the first para > - in C, D and E drop "externally" > - in D and E replace "manual" with "requested" -> ok > === > Section 13 TWICE > OLD > Recovery signaling operation is initiated externally that switches > NEW > Recovery signaling is initiated externally that switches -> ok > === > Section 13 (A and B) > is set to either 0x04, or 0x08 or 0x10. > I would prefer you to use the meanings rather than the values. -> ok will add the description > === > Section 13 (D and E) > This, unless a fault condition exists on > ? "This is allowed"? "This is possible"? "This is successful"? -> would you clarify what you mean here > === > Section 14 > OLD > use so that the object can be included in the Notify message to act > a switchover request for 1+1 bi-directional and 1:1 protection. > NEW > use so that the object can be included in the Notify message to act > as a switchover request for 1+1 bi-directional and 1:1 protection. -> ok > === > Section 14.1 > I believe we have had this discussion before. > We don't introduce reserved fields for future extensibility. We only do it for padding. > If you are certain that we need to extend in the future then please use sub-objects or TLVs. > This means that you can: > a. Remove the last four bytes of the Protection object. > b. Retain the C-Type from RFC3473 -> will add a reference to segment recovery (that does not make use of TLVs) - see section 6.1 of SEG-REC > === > Section 15 > This object MUST be > present in the Path message (for the pre-provisioning of the > secondary protecting LSP) if and only if the LSP Protection Type > value is set to "0x02". > "MUST if and only if" is not really in RFC2119. > Can we two statements. One with "MUST" and one with "MUST NOT". -> ok (but i don't understand why this logical statement is not allowed) > === > Section 15 > In the case where my protecting LSP protects only one working LSP and where the full path of the protecting LSP is known by the ingress (strict and explicit) and there is no resource sharing between the protected and protecting LSP, I can't see why I must include a PPRO. > In other words, PPRO is an enabler of function (as stated in section 15.4 "The PPRO enables of sharing recovery resources between a given secondary protecting LSP and one or more secondary protecting LSPs if their corresponding primary working LSPs have mutually (link/node/SRLG)disjoint paths."), but that does not make its presence mandatory. > === > Section 15.1 > The contents of a PRIMARY_PATH_ROUTE object are a series of > variable-length data items called subobjects. The subobjects are > identical to those that can constitute an EXPLICIT/RECORD ROUTE > object as defined in [RFC3209], [RFC3473] and [RFC3477]. > This seems in contradiction with section 15.3 -> identical in terms of content definition > === > Section 15.4 > OLD > The PPRO enables of sharing recovery resources between a given > NEW > The PPRO enables sharing of recovery resources between a given -> ok > === > Section 16 > The ASSOCIATION object is used to associate LSPs with each other. In > the context of end-to-end LSP recovery, the association MUST only > identify LSPs that support the same Tunnel ID. > Hmmm. presumably same source and destination is relatively important too. -> ok i will add a statement here even if it is already part of the next sentence > === > Section 16 > The ASSOCIATION object is used to associate LSPs with each other. > You already said this. -> i will remove it > === > Section 16.1 > Association ID: 16 bits > > A value that when combined with Association Type and > Association Source uniquely identifies an association. > It would be helpful to state who assigns this value. -> it is the sender (i will add this) > === > Section 16.1 > Association Source: 4 or 16 bytes > > The IP address of the node that originated the association. > "The IP address"? > Question. Are two associations with the same Association ID equivalent if the Association Source addresses are different but identify the same node? > Answer (it transpires) is "no". > You need to make this much clearer here. -> ok i will add a statement along these lines, note this statement will be added such that relationship between values is clearer > === > Section 17 > Isn't Notify modified as well? > And I thought Resv was, but I may have been sleeping. -> Resv needs to be added (Notify is not modified) > === > Section 18 > This is a bit poor. > If you don't modify the "external commands" section, you'll certainly have to discuss security for them. After all, a forced failover can be pretty disruptive. > But I think you need to discuss misconnection here. In particular when there is mesh protection going on. -> i will include specifics inlight with the text provided in the functional specification > === > Section 19 > The IANA section needs some gardening to make it really easy for IANA to implement. > - Break it up into clearer subsections. > - Make sure you have included all of the information needed in the registry > - Point back at the defining sections of the draft > - Only have suggested values in one place in the document > - Be consistend in using TBD or TBA in the document -> ok (do think put the proposed value as part of the text and the IANA section ease reading) > === > Section 19 > Should the IANA section also cover the bits in the ADMIN STATUS object? -> we did not register these bits since if you think we need to register them as part of this section just let me know > === > Section 21 > Missing references [CRANK], [RFC2205]. Suspect you need to check them all. > Will need to add a reference for LSP segment recovery. -> ok > === > Section 21.1 > This seems a very long list of normative references. I hope you can split this so that most of the references are informational. -> ok > === > Section 22 > You might change this to "Editors' Addresses" -> ok From owner-ccamp@ops.ietf.org Thu Mar 17 12:40:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28469 for ; Thu, 17 Mar 2005 12:40:20 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBz38-0000Wa-0D for ccamp-archive@ietf.org; Thu, 17 Mar 2005 12:44:49 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DByo7-000E1N-Ax for ccamp-data@psg.com; Thu, 17 Mar 2005 17:29:15 +0000 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DByo2-000E0y-P1 for ccamp@ops.ietf.org; Thu, 17 Mar 2005 17:29:11 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 62D74E0001FA; Thu, 17 Mar 2005 17:28:55 +0000 (GMT) Received: from Puppy ([212.43.203.247] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Mar 2005 17:28:06 +0000 Message-ID: <03ef01c52b16$e8513c40$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: References: <01f501c529c0$198d56c0$dccb2bd4@Puppy> <423995B6.7000800@psg.com> Subject: Re: Last call review of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt Date: Thu, 17 Mar 2005 17:26:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 17 Mar 2005 17:28:07.0475 (UTC) FILETIME=[AEF8E830:01C52B16] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Content-Transfer-Encoding: 7bit Hi Dimitri, > > Abstract: > > This document describes protocol specific procedures and extensions > > for Generalized Multi-Protocol Label Switching (GMPLS) Resource > > ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to > > support end-to-end Label Switched Path (LSP) recovery that denotes > > protection and restoration. > > Not sure what is meant by "denotes" in this context. > > Perhaps "is used to provide" ? > > -> was meant to say "that means..." - so any better wording ? OK... "...to support end-to-end Label Switched Path (LSP) recovery, that is protection and restoration of end-to-end LSPs." > > === > > Section 3 > > Although the second paragraph defines "end-to-end protection" I would like to see this pulled out into its own paragraph for emphasis, and also a little more clarity added to the definition. For example, it would appear that your four types of e2e protection are all have the protecting and protected LSPs disjoint in some way - this makes it appear that this is a property of e2e protection in general and you should state this if it is true. > > -> so you would like to see as part of the introduction a statement > about end-to-end protection concept - i don't think there is any > specific issue in adding this OK. Thanks. I don't need a whole essay; just a short paragraph. > > === > > Section 3 > > Note that in both > > cases, any lower priority LSP that would use the pre-reserved > > resources for the protecting LSP(s) MUST be preempted during the > > activation of the protecting LSP. > > This sentence comes out of the blue. The whole of the paragraph up to then has not even mentioned extra traffic. > > -> don't understand your comment as it is mentioned at the beginning of > the paragraph OK. It's a long paragraph with a page throw in the middle. I guess I fell asleep by the time I got to the end of the paragraph! > > === > > Section 4.2.1 > > - S (Secondary) bit: enables distinction between primary and > > secondary LSPs. A primary LSP is a fully established LSP for > > which the resource allocation has been committed at the data plane > > (i.e. full cross-connection has been performed). Both working and > > protecting LSPs can be primary LSPs. A secondary LSP is an LSP > > I am uneasy about this definition of "primary". In [TERM] the only mention of "primary" is in section 2... > > Recovery typically involves the activation of a recovery (or > > alternate) LSP when a failure is encountered in the working (or > > primary) LSP. > > -> this definition needs to be updated as - by removing primary in the > second parenthesis - it comes from a initial phase where no solution > where yet started OK. So please make sure that this happens during RFC Ed or authors 48 hours on [TERM]. > > This implies that "primary" is a synonym for "working". > > Further, RFC3471 has a subtly different meaning for "secondary" in section 7. > > Protection Information also indicates if the LSP is a primary or > > secondary LSP. A secondary LSP is a backup to a primary LSP. The > > resources of a secondary LSP are not used until the primary LSP > > fails. The resources allocated for a secondary LSP MAY be used by > > other LSPs until the primary LSP fails over to the secondary LSP. At > > that point, any LSP that is using the resources for the secondary LSP > > MUST be preempted. > > Can we please not modify the interpretation of the S-bit. > > -> this is what the draft does as also explained in > > " In this document, the PROTECTION object uses as a basis the > PROTECTION object defined in [RFC3471] and [RFC3473] and defines > additional fields within it. The fields defined in [RFC3471] and > [RFC3473] are unchanged by this memo. " > > > If you need to flag a new piece of information (to distinguish between resource allocated and not) then please introduce a new flag. > > Note that the P-bit appears to be slightly orthogonal because the text seems to describe the *current* role of the LSP. (The S-bit in RFC3471 describes the role at the time the LSP is set up, I think). > > -> note this has already been explained to you - where we came to the > conclusion for clarity to add the above mentioned paragraph Well, then I guess I find RFC3471 poorly drafted. > > === > > Section 5 > > When a failure occurs (say at node B) and is detected at end-node D, > > the receiver at D selects the normal traffic from the other LSP. > > From this perspective, 1+1 unidirectional protection can be seen as > > an uncoordinated protection switching mechanism acting independently > > at both end-points. Also, for the protected LSP under failure > > condition, the Path_State_Removed Flag of the ERROR_SPEC object (see > > [RFC3473]) SHOULD NOT be set upon PathErr message generation. > > So, what you are saying is that in 1+1 protection the network may *never* know that the error is so bad that the LSP is dead, but MUST leave that choice to the ingress. While this is the operational practice in many transport networks, I don't see why you make this as strong as a SHOULD NOT. > > -> what i mean is that this LSP in a 1+1 mode should not be released > after failure (which is the common usage of such a scheme) Agree about comon usage. Think SHOULD NOT is too strong. Would accept RECOMMENDED. > > === > > Section 5.1 > > A new PROTECTION object is included in the Path message. This object > > carries the desired end-to-end LSP Protection Type (in this case, > > "1+1 Unidirectional"). This LSP Protection Type value is applicable > > to both uni- and bi-directional LSPs. > > This is unclear. In section 14.1 you have > > 0x08 1+1 Unidirectional Protection > > 0x10 1+1 Bi-directional Protection > > -> in 5.1 "This LSP Protection Type value is applicable > to both uni- and bi-directional LSPs. " > > -> in 6.1 "This LSP Protection Type > value is only applicable to bi-directional LSPs. Ah! Very sorry. I wonder if my stupidity is also present in others. That is (of course), the protection type uni/bi is not the same as the LSP direction uni/bi. And that bi protection is meaningless for a uni LSP. Any hope of a couple of lines to avoid this confusion? > > === > > Section 6.2 > > directions. This is done using the Notify message with a new Error > > Code indicating "Working LSP Failure (Switchover Request)". The > > I don't see this in the IANA section, and I wonder if you also mean Error Value? > > -> it corresponds to the entry "Notify Error/LSP Failure" > (suggested value = 6)" error value is thus appropriate Ah. OK, then just update the text in section 6.2. > > === > > Section 7.2 > > This operation may be done using a Notify message exchange with a > > new Error Code indicating "(Working) LSP Failure (Switchover > > Request)". The Notify Ack message MUST be sent to confirm the > > reception of the Notify message. > > All of the same comments as for section 6.2. > > Also: > > - Why do you say "may be done"? > > -> "initiated" or "performed" It is the "may be" that I question. It implies there is a choice of ways to do it. Section 6.2 uses "this is done". > > === > > Section 13 (D and E) > > This, unless a fault condition exists on > > ? "This is allowed"? "This is possible"? "This is successful"? > > -> would you clarify what you mean here I am suggesting meaning (and therefore replacement text) for the phrase "This, unless a fault condition exists" > > === > > Section 14.1 > > I believe we have had this discussion before. > > We don't introduce reserved fields for future extensibility. We only do it for padding. > > If you are certain that we need to extend in the future then please use sub-objects or TLVs. > > This means that you can: > > a. Remove the last four bytes of the Protection object. > > b. Retain the C-Type from RFC3473 > > -> will add a reference to segment recovery (that does not make use of > TLVs) - see section 6.1 of SEG-REC Suppose this is OK. But, notwithstanding the fact that I am an author of SEG-REC, it appears that the additional info that is defined in SEG-REC would fit within the existing 64 bit structure. (Appologies for not reviewing that draft first.) > > === > > Section 15 > > In the case where my protecting LSP protects only one working LSP and where the full path of the protecting LSP is known by the ingress (strict and explicit) and there is no resource sharing between the protected and protecting LSP, I can't see why I must include a PPRO. > > In other words, PPRO is an enabler of function (as stated in section 15.4 "The PPRO enables of sharing recovery resources between a given secondary protecting LSP and one or more secondary protecting LSPs if their corresponding primary working LSPs have mutually (link/node/SRLG)disjoint paths."), but that does not make its presence mandatory. No comment? > > === > > Section 15.1 > > The contents of a PRIMARY_PATH_ROUTE object are a series of > > variable-length data items called subobjects. The subobjects are > > identical to those that can constitute an EXPLICIT/RECORD ROUTE > > object as defined in [RFC3209], [RFC3473] and [RFC3477]. > > This seems in contradiction with section 15.3 > > -> identical in terms of content definition 15.3 says The following subobjects are currently defined for the PRIMARY PATH ROUTE object: - Sub-Type 1: IPv4 Address (see [RFC3209]) - Sub-Type 2: IPv6 Address (see [RFC3209]) - Sub-Type 3: Label (see [RFC3473]) - Sub-Type 4: Unnumbered Interface (see [RFC3477]) but RFC3209 defines 32 Autonomous system number Hence a contradiction. If you are prepared to accept type 32 in the PPRO I suggest that you remove the list of accepted values and simply state that anything that can go in an ERO *or* an RRO is acceptable in a PPRO. > > === > > Section 17 > > Isn't Notify modified as well? > > And I thought Resv was, but I may have been sleeping. > > -> Resv needs to be added (Notify is not modified) This section describes the extensions to the PROTECTION object to broaden its applicability to end-to-end LSP recovery. In addition to modifications to the format of the PROTECTION object, we extend its use so that the object can be included in the Notify message to act a switchover request for 1+1 bi-directional and 1:1 protection. Looks like a modification to me. > > === > > Section 19 > > The IANA section needs some gardening to make it really easy for IANA to implement. > > - Only have suggested values in one place in the document > > -> ok (do think put the proposed value as part of the text and the IANA > section ease reading) Don't feel strongly. Have seen too many drafts go to RFC with mixed values or TBD still in place. > > === > > Section 19 > > Should the IANA section also cover the bits in the ADMIN STATUS object? > > -> we did not register these bits since if you think we need to register > them as part of this section just let me know Asking your opinion, really. Question is, what is the risk of losing track of Admin Status bits? Note, I keep an informal registry on the alternate CCAMP pages. Thanks for the hard work. Adrian From owner-ccamp@ops.ietf.org Thu Mar 17 13:07:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01471 for ; Thu, 17 Mar 2005 13:07:44 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzTg-0001Og-R3 for ccamp-archive@ietf.org; Thu, 17 Mar 2005 13:12:14 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBzID-000IFR-OW for ccamp-data@psg.com; Thu, 17 Mar 2005 18:00:21 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBzIC-000IEx-7U for ccamp@ops.ietf.org; Thu, 17 Mar 2005 18:00:20 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Mar 2005 09:58:46 -0800 X-IronPort-AV: i="3.91,98,1110182400"; d="scan'208"; a="236723867:sNHT1171065944" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2HHwiZV003055; Thu, 17 Mar 2005 09:58:44 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-2-189.cisco.com [10.86.242.189]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA17997; Thu, 17 Mar 2005 09:58:42 -0800 (PST) In-Reply-To: <036b01c52a7a$5dea9ac0$dccb2bd4@Puppy> References: <036b01c52a7a$5dea9ac0$dccb2bd4@Puppy> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1102d0a73fb4ff283e558b6d9fe0f2ed@cisco.com> Content-Transfer-Encoding: 7bit Cc: From: JP Vasseur Subject: Re: Draft minutes Date: Thu, 17 Mar 2005 12:59:03 -0500 To: "Adrian Farrel" X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Content-Transfer-Encoding: 7bit Hi Adrian, Few comments, On Mar 16, 2005, at 5:44 PM, Adrian Farrel wrote: > Hi, > > Please comment on the draft minutes. > > Thanks to Richard, Zafar and Tove for putting these together. > > Adrian > > ======== > > Common Control and Measurement Plane WG (ccamp) > > Tuesday, March 8, 2005 at 0900-1130 > Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen > > Working group status - chairs > - No changes to the agenda made. > - Adrian reviewed status of drafts, reviewed charter milestones. > We are holding off on new charter until finish last call of 8 > drafts, expect 1-2 months. > - Bill summarized ADs view, should wait for re-chartering until > finish last call considering expectation will be very soon for > last calls. > * Dimitri asked about IPR assertion on re-optimization draft > - Adrian said it did not give the same terms that have been seen > in some recent IPR claims. The WG has to decide what to do. > - Scott Bradner said we need to be very careful. Advised there > may be anti-trust issues. Best to have no IETF interaction > other than to ask for clarity. > Scott offered to review emails on the subject. > - JP said we can take that as a way to go forward and continue > technical work. > > ASON considerations > > ITU liaison - Lyndon Ong presented Wesam's slides > - Thanks to the IETF for liaisons and participation of Adrian and > Igor at last meetings > - Crankback and the comparison of LMP and ASON discovery will be > incorporated in SG15 Q14's work. > - There are two liaisons from ITU to CCAMP on the way. > - Routing - ITU not planning any routing exts work, looking to > IETF's work. > - Continuing work on ASON management. > - An FTP site is available for liaison statements. > * Adrian asked if ITU plans to liaise G.7713 on new text for > crankback before consent? > - Lyndon said a meeting is upcoming and will ask for it to be > considered. > * Kireeti asked if there is any problem in that the crankback draft > is not an RFC yet? > - Adrian - RFC is desirable, not required? > - Scott Bradner - it is required to have an RFC number for final > balloting. The IESG can request expedited publication. > * Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU > terminology, and may want to consider including it. > - Adrian - can that be liaised to us? > - Steve Trowbridge - Yes, we can do that. > > ASON Routing Evaluation > * Adrian - The design team on routing has members from both ITU and > IETF, although we did not do the correct process, so ITU reps are > individuals, not ITU representatives. > - Adrian will work with Steve to formalize the process. > * Adrian - Would like to make the draft from the team on evaluation > of routing protocols into a working group draft > - we will take to the list to see if any objection. > * Dimitri - asked if we can use formal liaison process to send this > draft to ITU, does it need to be WG draft? And encourages comments > now, before it goes to last call. > - Adrian - we can liaise the draft and our intention to consider it > as a WG draft > > Lexicography draft (Adrian) > - Q14 indicates meeting went well, authors summarized comments and > incorporated in this release. > * Adrian asked if should be WG draft > - Kireeti said we could do that, need to ask the list, also need to > compare with G.8081 > * Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC > or drafts, are there definitions? > - Adrian thinks there are good terms, though in multiple > RFCs/drafts. > - Ben - if someone is new to the IETF, they have difficulty on > where to go for definitions. > - Adrian - if people want to do a draft to collect definitions of all > GMPLS terms (more general than just ASON as in lexi draft), then > they are welcome to do it. > > Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi) > LSP Stitching (Arthi) > - Need feedback on several items. > * Adrian - it would be inappropriate to move extensions to be a WG > draft without first stitching draft becoming a wg draft. If no one > objects, see no reason why not to be WG draft. > * Dimitri - Question: the draft was to originally do signaling exts, > do we need to do more on routing aspects? > - Arthi - agree, if we do now as separate doc from exts draft, then > should include routing aspects. > * Dimitri - if allow different switching caps, then this changes the > type, and this a FA > - Arthi - but end-to-end does not change. > * Zafar - we need to be careful what advertising because of scalability > concerns, need further consideration. > - Arthi - yes need more discussion. > * Igor - thought stitching maybe more appropriate for LSP hierarchy > draft, but as this already in editor's queue, will add here. > * Lou - sw cap can change hop by hop just needs to match end to end of > hop. > - Arthi - agree, we were thinking the same. > * Discussion sent to mailing list > > Per-domain path computation method for computing inter-domain traffic > engineering (TE) LSP. (JP) > Draft-vasseur-ccamp-inter-domain-path-comp-00.txt: > routing and path computation aspects. > * Zafar asked clarification on ccamp-pce relationship > - Kireeti - this draft discusses ASBR on the path, if not then it's > PCE, suggest add this to draft to clarify that this is for when > computation is done by elements on the path. > - JP - ok > * Adrian and Kireeti asked if this should be a WG draft? Good consensus > in the room to be WG draft, will take it to the list. > > Automesh (JP) > - Agreement to rehash work a bit to put these together. > - Now 2 drafts > - Not a new ID, no changes. > - Deployed networks using that. > - No major changes planned > * Igor - asked how to reflect constraints in a node for switching? > - JP - we are discussing auto mesh, not node switching. > - Igor - but how do we reflect node capabilities? > - JP - this we do, we carry in OSPF a TLV to describe. Please replace by: JP - this draft is not about node capability discovery (for this, see draft-vasseur-ccamp-te-node-cap) > - Igor - how to reflect for computation any internal constraints, > could do via node caps advertisement. > - JP agrees, though here just doing a discovery, doesn't think > related as discovering members of mesh. > - Adrian - two drafts, this is not node capability that is next one > by JP, cut discussion said to take it to list. > > JP - Routing extensions for discovery of TE node capabilities > * Adrian - on process, authors did a group job of splitting draft > and sending to OSPF and ISIS groups, chairs will follow up with > those groups. > * Dimitri - should for terminology call TE router? > - JP - yes. > - Dimitri - shouldn't be exclusive the TLV? not sure of what the question was ... > - JP - yes. > * Igor - how to distinguish node capabilities? > - Adrian - do by TLVs, need to do a draft to propose, this draft > gives you the TLVs, then can follow-up with other drafts to > describe function want to use it for, take discussion to list. > * JP asked that this be adopted as a WG document. > - Adrian - Take it to the list > > Extensions to GMPLS RSVP graceful restart (Lou Berger) > * Adrian - do editorial respin, let us know, and we will take to > last call > * Any implementations? > - Yes - two! > > MRN > Requirements (Kohei Shiomoto) > Evaluation draft (JL Le Roux) > Protocol extensions (Dimitri) > * Arthi - what does virtual FA have to do with MRN, > isn't it general? > - Dimitri - should we have a specific doc on virtual FA for > wider scope? > - Arthi - did you want to scope only to MRN context? > - Dimitri - no, just not sure if soln doc should be split. > - Arthi - could be general - so prefer a separate doc on virtual FA. > * Zafar - we need to give a priority capability for TE. > - Dimitri - new TLV may be needed to describe relationships of > multiple interfaces > * Zafar - how relates to hierarchy draft? > - Dimitri - maybe should be as applicability statement, > - Kireeti - should do on mailing list > * Kireeti - requests to continue work, when re-charter will consider > for WG drafts. > > Routing considerations and CSPF for inter-as (Tomohiro Otani) > * JP - very useful draft, not sure (and concerned) on capability and > scalability as depends on constraint trying to summarize. Please replace by: JP - very useful draft, concerned about the advertisement of DYNAMIC summarized TE resource information across domains (static capabilities are perfectly fine). Too much of aggregation renders the solution inefficient and not enough of aggregation seriously compromises the routing scalability. Furthermore, there are other confidentiality issues to sort out in the context of inter-provider. > - Otani - ok, we need more on summarizing capability. > * Kireeti - thinks good and hopes to be a WG draft, though for now > would request for this draft to continue work, though lets finish > what ccamp has now and then when re-charter will make this as a > WG doc. > * Otani - how to handle inter-as cspf constraints? > - Kireeti - as noted before (continue work). > > L2LSP (Dimitri) > * Adrian asked clarification, is this "single hop"? > - Dimitri - multiple hops each is a LSR, will clarify this in draft > * Kireeti - ADs request a framework doc and include how it relates to > other SDOs, max 10 pages > - Dimitri - ok > > GMPLS addressing (Richard Rabbat) > * Adrian - as this is first version, recommend continue discussion, > re-spin draft, and then review again. > * Adrian asked for feedback on the topics, not the technical content > initially. > * Loa - BCP is a specific type of RFC, describes what we have > experience with not necessarily what should be (as in this draft) > * Kireeti - warns for everyone with implementations to review the > draft to ensure direction taken by this draft is right one. > * Lou - should we wait for re-spin or now? > - Kireeti - wait for re-spin. > > L1VPN (Tomonori Takeda) > Framework draft > Applicability draft > * Alex - by next IETF will decide if it should be included in ccamp or > as separate WG. > > Control plane saturation (JL Le Roux) > * Arthi - do we really want to advertise limitations and implications? > * Kireeti - because of time, lets do on list. > > Graceful shutdown (Zafar Ali) > * Kireeti - will consider for wg doc after re-charter > * JP - is this part of current charter > - Kireeti - doesn't matter, we just can not include anymore as WG > doc until re-charter. > > Deployment-augmented (Zafar Ali) > * Arthi- comment is this a FA for router to optical domain > - Zafar - no just TE link > > GMPLS interworking (Kenji) > * Dimitri - why need to adv priority of LSP? > - Adrian - need to ask on list. > > GMPLS interworking (Kohei Shiomoto) > * Adrian - WG doc will be decided after re-charter > - Welcome that will merge with other draft on augmented, > - Suggest also look at Kenji's interworking draft to merge. > > Cho - ARP signal > * Kireeti - request work with Dimitri on framework draft, > - When decide direction and interactions with other SDO, may > decide to form a design team to work on L2, > - First we need a framework. > Thanks. JP. From owner-ccamp@ops.ietf.org Fri Mar 18 04:47:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14325 for ; Fri, 18 Mar 2005 04:47:16 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCE91-0006fJ-5K for ccamp-archive@ietf.org; Fri, 18 Mar 2005 04:51:51 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCDs7-000K0l-SI for ccamp-data@psg.com; Fri, 18 Mar 2005 09:34:23 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCDs6-000K0F-M8 for ccamp@ops.ietf.org; Fri, 18 Mar 2005 09:34:22 +0000 Received: from pc6 (1Cust238.tnt2.lnd4.gbr.da.uu.net [62.188.131.238]) by astro.systems.pipex.net (Postfix) with SMTP id 50F3EE00021A; Fri, 18 Mar 2005 09:34:13 +0000 (GMT) Message-ID: <000e01c52b94$e310a440$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , References: <0aa401c51843$6a63fba0$adcb2bd4@Puppy> <025a01c528a0$fc6ff040$0601a8c0@pc6> <031301c52952$85dae720$0601a8c0@pc6> Subject: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Fri, 18 Mar 2005 09:29:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit This MIB contains several 'enumerations' except they are not enumerations but text in DESCRIPTION clauses - gmplsTunnelGPid gmplsTunnelSwitchingType gmplsTunnelLSPEncoding - with RFC 3471 (not a MIB) as a reference. So these are not defined anywhere in SMI; and as this points out, these values will be added to in future RFC. I think these should be in a MIB under IANA control and there is already a way to do just that, namely to put them in an IANA MIB (as opposed to a standards track MIB) with the RFC specifying under what conditions the IANA MIB can be updated (standards track, IESG, expert etc). This procedure is described in draft-ietf-ops-mib-review-guidelines-04.txt which also points to previous examples of this. And this issue has already surfaced, albeit obliquely, on this list once before in the context of IANAItuProbableCause which uses this procedure and is now published as part of the Alarm MIB (RFC 3877). Not to do this now creates extra work in the future; when an implementor has to create their own SMI and whenever these values need to be updated. Tom Petch From owner-ccamp@ops.ietf.org Fri Mar 18 08:34:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06889 for ; Fri, 18 Mar 2005 08:34:41 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCHh8-0005RP-2o for ccamp-archive@ietf.org; Fri, 18 Mar 2005 08:39:19 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCHVA-000N63-Ck for ccamp-data@psg.com; Fri, 18 Mar 2005 13:26:56 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCHV6-000N5T-QM for ccamp@ops.ietf.org; Fri, 18 Mar 2005 13:26:52 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 288BCE0002A6 for ; Fri, 18 Mar 2005 13:26:46 +0000 (GMT) Received: from Puppy ([212.43.203.208] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 13:17:35 +0000 Message-ID: <04c801c52bbd$13a39c70$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: Subject: Re: ASON Lexicography Date: Fri, 18 Mar 2005 12:31:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 18 Mar 2005 13:17:35.0568 (UTC) FILETIME=[D9ABAD00:01C52BBC] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Hi, Sounds like no-one against, but recognition that this is work in progress. We will submit as a WG draft. The authors are busy with a new revision. Thanks, Adrian > > Dear CCAMP, > > > > In our meeting this week we heard about > > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > > > There is some more discussion to be done on the content of > > this draft but the chairs and the meeting thought that the > > work is a very important part of CCAMP's job. > > > > Please indicate your opinion on whether this draft should be > > made a working draft document by March 20, 2005. > > > > Thanks, > > Kireeti. From owner-ccamp@ops.ietf.org Fri Mar 18 08:34:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06927 for ; Fri, 18 Mar 2005 08:34:49 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCHhH-0005RY-5S for ccamp-archive@ietf.org; Fri, 18 Mar 2005 08:39:27 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCHVE-000N6T-F9 for ccamp-data@psg.com; Fri, 18 Mar 2005 13:27:00 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCHVA-000N60-FE for ccamp@ops.ietf.org; Fri, 18 Mar 2005 13:26:57 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 73E32E000388 for ; Fri, 18 Mar 2005 13:26:52 +0000 (GMT) Received: from Puppy ([212.43.203.208] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 13:17:52 +0000 Message-ID: <04cc01c52bbd$1dec83e0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Updated minutes Date: Fri, 18 Mar 2005 12:34:37 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 18 Mar 2005 13:17:53.0239 (UTC) FILETIME=[E4340E70:01C52BBC] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Content-Transfer-Encoding: 7bit Here with updates from Jean-Louis, JP and Arthi. Short call for further comments before I submit. Thanks, Adrian === Common Control and Measurement Plane WG (ccamp) Tuesday, March 8, 2005 at 0900-1130 Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen Working group status - chairs - No changes to the agenda made. - Adrian reviewed status of drafts, reviewed charter milestones. We are holding off on new charter until finish last call of 8 drafts, expect 1-2 months. - Bill summarized ADs view, should wait for re-chartering until finish last call considering expectation will be very soon for last calls. * Dimitri asked about IPR assertion on re-optimization draft - Adrian said it did not give the same terms that have been seen in some recent IPR claims. The WG has to desice what to do. - Scott Bradner said we need to be very careful. Advised there may be anti-trust issues. Best to have no IETF interaction other than to ask for clarity. Scott offered to review emails on the subject. - JP said we can take that as a way to go forward and continue technical work. ASON considerations ITU liaison - Lyndon Ong presented Wesam's slides - Thanks to the IETF for liaisons and participation of Adrian and Igor at last meetings - Crankback and the comparison of LMP and ASON discovery will be incorporated in SG15 Q14's work. - There are two liaisons from ITU to CCAMP on the way. - Routing - ITU not planning any routing exts work, looking to IETF's work. - Continuing work on ASON management. - An FTP site is available for liaison statements. * Adrian asked if ITU plans to liaise G.7713 on new text for crankback before consent? - Lyndon said a meeting is upcoming and will ask for it to be considered. * Kireeti asked if there is any problem in that the crankback draft is not an RFC yet? - Adrian - RFC is desirable, not required? - Scott Bradner - it is required to have an RFC number for final balloting. The IESG can request expedited publication. * Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU terminology, and may want to consider including it. - Adrian - can that be liaisoned to us? - Steve Trowbridge - Yes, we can do that. ASON Routing Evaluation * Adrian - The design team on routing has members from both ITU and IETF, although we did not do the correct process, so ITU reps are individuals, not ITU representatives. - Adrian will work with Steve to formalize the process. * Adrian - Would like to make the draft from the team on evaluation of routing protocols into a working group draft - we will take to the list to see if any objection. * Dimitri - asked if we can use formal liaison process to send this draft to ITU, does it need to be WG draft? And encourages comments now, before it goes to last call. - Adrian - we can liaise the draft and our intention to consider it as a WG draft Lexicography draft (Adrian) - Q14 indicates meeting went well, authors summarized comments and incorporated in this release. * Adrian asked if should be WG draft - Kireeti said we could do that, need to ask the list, also need to compare with G.8081 * Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC or drafts, are there definitions? - Adrian thinks there are good terms, though in multiple RFCs/drafts. - Ben - if someone is new to the IETF, they have difficulty on where to go for definitions. - Adrian - if people want to do a draft to collect defintions of all GMPLS terms (more general than just ASON as in lexi draft), then they are welcome to do it. Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi) LSP Stitching (Arthi) - Need feedback on several items. * Adrian - it would be inappropriate to move extensions to be a WG draft without first stitching draft becoming a wg draft. If no one objects, see no reason why not to be WG draft. * Dimitri - Question: the draft was to originally do signaling exts, do we need to do more on routing aspects? - Arthi - agree, however this comment would have applied to the previous merged draft. The whole point of splitting the ID was because the scope was wider and generic. In that case, it becomes necessary to include the routing aspects as well. * Dimitri - if allow different switching caps, then this changes the type, and this a FA - Arthi - but end-to-end does not change. * Zafar - we need to be careful what advertising because of scalability concerns, need further consideration. - Kireeti - As Arthi said the LSP segment does not *have to* be advertised but *can be* if desired. - Arthi - You, of course, need to be careful about advertising anything as TE-links dictated by correct policies. And as far as scaling is concerned, Igor is standing right behind you and will probably say (and I agree) that LSP segments can also be bundled in which case you are no longer advertising each LSP segment as a TE-link. We are simply having the same discussion again that was on the mailing list. * Igor - thought stitching maybe more appropriate for LSP hierarchy draft, but as this already in editor's queue, will add here. * Lou - sw cap can change hop by hop just needs to match end to end of hop. - Arthi - agree, we were thinking the same. * Discussion sent to mailing list Per-domain path computation method for computing inter-domain traffic engineering (TE) LSP. (JP) Draft-vasseur-ccamp-inter-domain-path-comp-00.txt: routing and path computation aspects. * Zafar asked clarification on ccamp-pce relationship - Kireeti - this draft discusses ASBR on the path, if not then it's PCE, suggest add this to draft to clarify that this is for when computation is done by elements on the path. - JP - ok * Adrian and Kireeti asked if this should be a WG draft? Good consensus in the room to be WG draft, will take it to the list. Automesh (JP) - Agreement to rehash work a bit to put these together. - Now 2 drafts - Not a new ID, no changes. - Deployed networks using that. - No major changes planned * Igor - asked how to reflect constraints in a node for switching? - JP - we are discussing auto mesh, not node switching. - Igor - but how do we reflect node capabilities? - JP - this draft is not about node capability discovery (for this, see draft-vasseur-ccamp-te-node-cap) - Igor - how to reflect for computation any internal constraints, could do via node caps advertisement. - JP agrees, though here just doing a discovery, doesn't think related as discovering members of mesh. - Adrian - two drafts, this is not node capability that is next one by JP, cut discussion said to take it to list. Routing extensions for discovery of TE node capabilities (JL Le Roux) * Adrian - on process, authors did a group job of splitting draft and sending to OSPF and ISIS groups, chairs will follow up with those groups. * Dimitri - should for terminology call TE router? - JL - yes. - Dimitri - should the TLV be exclusive to this function? - JL - yes. * Igor - how to distinguish node capabilities? - Adrian - do by TLVs, need to do a draft to propose, this draft gives you the TLVs, then can follow-up with other drafts to describe function want to use it for, take discussion to list. * JL asked that this be adopted as a WG document. - Adrian - Take it to the list Extensions to GMPLS RSVP graceful restart (Lou Berger) * Adrian - do editorial respin, let us know, and we will take to last call * Any implementations? - Yes - two! MRN Requirements (Kohei Shiomoto) Evaluation draft (JL Le Roux) Protocol extensions (Dimitri) * Arthi - what does virtual FA have to do with MRN, isn't it general? - Dimitri - should we have a specific doc on virtual FA for wider scope? - Arthi - did you want to scope only to MRN context? - Dimitri - no, just not sure if soln doc should be split. - Arthi - could be general - so prefer a separate doc on virtual FA. * Zafar - we need to give a priority capability for TE. - Dimitri - new TLV may be needed to describe relationships of multiple interfaces * Zafar - how relates to hierarchy draft? - Dimitri - maybe should be as applicability statement, - Kireeti - should do on mailing list * Kireeti - requests to continue work, when re-charter will consider for WG drafts. Routing considerations and CSPF for inter-as (Tomohiro Otani) * JP - very useful draft. Concerned about the advertisement of DYNAMIC summarized TE resource information across domains (static capabilities are perfectly fine). Too much of aggregation renders the solution inefficient and not enough of aggregation seriously compromises the routing scalability. Furthermore, there are other confidentiality issues to sort out in the context of inter-provider. - Otani - ok, we need more on summarizing capability. * Kireeti - thinks good and hopes to be a WG draft, though for now would request for this draft to continue work, though lets finish what ccamp has now and then when re-charter will make this as a WG doc. * Otani - how to handle inter-as cspf constraints? - Kireeti - as noted before (continue work). L2LSP (Dimitri) * Adrian asked clarification, is this "single hop"? - Dimitri - multiple hops each is a LSR, will clarify this in draft * Kireeti - ADs request a framework doc and include how it relates to other SDOs, max 10 pages - Dimitri - ok GMPLS addressing (Richard Rabbat) * Adrian - as this is first version, recommend continue discussion, re-spin draft, and then review again. * Adrian asked for feedback on the topics, not the technical content initially. * Loa - BCP is a specific type of RFC, describes what we have experience with not necessarily what should be (as in this draft) * Kireeti - warns for everyone with implementations to review the draft to ensure direction taken by this draft is right one. * Lou - should we wait for re-spin or now? - Kireeti - wait for re-spin. L1VPN (Tomonori Takeda) Framework draft Applicability draft * Alex - by next IETF will decide if it should be included in ccamp or as separate WG. Control plane saturation (JL Le Roux) * Arthi - Do you think the LSRs would really want to advertise such control plane limitations ? Secondly, what implication does this have in case of inter-domain, especially inter-provider LSPs ? * Kireeti - because of time, lets do on list. Graceful shutdown (Zafar Ali) * Kireeti - will consider for wg doc after re-charter * JP - is this part of current charter - Kireeti - doesn't matter, we just can not include anymore as WG doc until re-charter. Deployment-augumented (Zafar Ali) * Arthi - This is good work. My only concern is the use of terminology. Do you actually expect to use LSP-Hierarchy extensions (say Hop3) while signaling an MPLS LSP over that FA in the MPLS domain ? - Zafar - no just TE link GMPLS interworking (Kenji) * Dimitri - why need to adv priority of LSP? - Adrian - need to ask on list. GMPLS interworking (Kohei Shiomoto) * Adrian - WG doc will be decided after re-charter - Welcome that will merge with other draft on augumented, - Suggest also look at Kenji's interworking draft to merge. Cho - ARP signal * Kireeti - request work with Dimitri on framework draft, - When decide direction and interactions with other SDO, may decide to form a design team to work on L2, - First we need a framework. From owner-ccamp@ops.ietf.org Fri Mar 18 09:30:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11806 for ; Fri, 18 Mar 2005 09:30:12 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCIYs-0007Za-Dz for ccamp-archive@ietf.org; Fri, 18 Mar 2005 09:34:51 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCILr-00046Q-Hx for ccamp-data@psg.com; Fri, 18 Mar 2005 14:21:23 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCILp-000469-VG; Fri, 18 Mar 2005 14:21:22 +0000 Message-ID: <423AE3EA.5030002@psg.com> Date: Fri, 18 Mar 2005 15:21:30 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Updated minutes References: <04cc01c52bbd$1dec83e0$dccb2bd4@Puppy> In-Reply-To: <04cc01c52bbd$1dec83e0$dccb2bd4@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Content-Transfer-Encoding: 7bit hi adrian a brief comment to clarify < "* Dimitri - if allow different switching caps, then this changes the < type, and this a FA" > * Dimitri - if allow stitching of end-to-end LSP with LSP segment > through different switching caps, then this changes the LSP switching > type along the path and thus this becomes a FA thanks, - dimitri. Adrian Farrel wrote: > Here with updates from Jean-Louis, JP and Arthi. > > Short call for further comments before I submit. > > Thanks, > Adrian > > === > > Common Control and Measurement Plane WG (ccamp) > > Tuesday, March 8, 2005 at 0900-1130 > Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen > > Working group status - chairs > - No changes to the agenda made. > - Adrian reviewed status of drafts, reviewed charter milestones. > We are holding off on new charter until finish last call of 8 > drafts, expect 1-2 months. > - Bill summarized ADs view, should wait for re-chartering until > finish last call considering expectation will be very soon for > last calls. > * Dimitri asked about IPR assertion on re-optimization draft > - Adrian said it did not give the same terms that have been seen > in some recent IPR claims. The WG has to desice what to do. > - Scott Bradner said we need to be very careful. Advised there > may be anti-trust issues. Best to have no IETF interaction > other than to ask for clarity. > Scott offered to review emails on the subject. > - JP said we can take that as a way to go forward and continue > technical work. > > ASON considerations > > ITU liaison - Lyndon Ong presented Wesam's slides > - Thanks to the IETF for liaisons and participation of Adrian and > Igor at last meetings > - Crankback and the comparison of LMP and ASON discovery will be > incorporated in SG15 Q14's work. > - There are two liaisons from ITU to CCAMP on the way. > - Routing - ITU not planning any routing exts work, looking to > IETF's work. > - Continuing work on ASON management. > - An FTP site is available for liaison statements. > * Adrian asked if ITU plans to liaise G.7713 on new text for > crankback before consent? > - Lyndon said a meeting is upcoming and will ask for it to be > considered. > * Kireeti asked if there is any problem in that the crankback draft > is not an RFC yet? > - Adrian - RFC is desirable, not required? > - Scott Bradner - it is required to have an RFC number for final > balloting. The IESG can request expedited publication. > * Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU > terminology, and may want to consider including it. > - Adrian - can that be liaisoned to us? > - Steve Trowbridge - Yes, we can do that. > > ASON Routing Evaluation > * Adrian - The design team on routing has members from both ITU and > IETF, although we did not do the correct process, so ITU reps are > individuals, not ITU representatives. > - Adrian will work with Steve to formalize the process. > * Adrian - Would like to make the draft from the team on evaluation > of routing protocols into a working group draft > - we will take to the list to see if any objection. > * Dimitri - asked if we can use formal liaison process to send this > draft to ITU, does it need to be WG draft? And encourages comments > now, before it goes to last call. > - Adrian - we can liaise the draft and our intention to consider it > as a WG draft > > Lexicography draft (Adrian) > - Q14 indicates meeting went well, authors summarized comments and > incorporated in this release. > * Adrian asked if should be WG draft > - Kireeti said we could do that, need to ask the list, also need to > compare with G.8081 > * Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC > or drafts, are there definitions? > - Adrian thinks there are good terms, though in multiple > RFCs/drafts. > - Ben - if someone is new to the IETF, they have difficulty on > where to go for definitions. > - Adrian - if people want to do a draft to collect defintions of all > GMPLS terms (more general than just ASON as in lexi draft), then > they are welcome to do it. > > Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi) > LSP Stitching (Arthi) > - Need feedback on several items. > * Adrian - it would be inappropriate to move extensions to be a WG > draft without first stitching draft becoming a wg draft. If no one > objects, see no reason why not to be WG draft. > * Dimitri - Question: the draft was to originally do signaling exts, > do we need to do more on routing aspects? > - Arthi - agree, however this comment would have applied to the > previous merged draft. The whole point of splitting the ID was > because the scope was wider and generic. In that case, it becomes > necessary to include the routing aspects as well. > * Dimitri - if allow different switching caps, then this changes the > type, and this a FA > - Arthi - but end-to-end does not change. > * Zafar - we need to be careful what advertising because of scalability > concerns, need further consideration. > - Kireeti - As Arthi said the LSP segment does not *have to* be > advertised but *can be* if desired. > - Arthi - You, of course, need to be careful about advertising > anything as TE-links dictated by correct policies. And as far as > scaling is concerned, Igor is standing right behind you and will > probably say (and I agree) that LSP segments can also be bundled > in which case you are no longer advertising each LSP segment as a > TE-link. We are simply having the same discussion again that was on > the mailing list. > * Igor - thought stitching maybe more appropriate for LSP hierarchy > draft, but as this already in editor's queue, will add here. > * Lou - sw cap can change hop by hop just needs to match end to end of > hop. > - Arthi - agree, we were thinking the same. > * Discussion sent to mailing list > > Per-domain path computation method for computing inter-domain traffic > engineering (TE) LSP. (JP) > Draft-vasseur-ccamp-inter-domain-path-comp-00.txt: > routing and path computation aspects. > * Zafar asked clarification on ccamp-pce relationship > - Kireeti - this draft discusses ASBR on the path, if not then it's > PCE, suggest add this to draft to clarify that this is for when > computation is done by elements on the path. > - JP - ok > * Adrian and Kireeti asked if this should be a WG draft? Good consensus > in the room to be WG draft, will take it to the list. > > Automesh (JP) > - Agreement to rehash work a bit to put these together. > - Now 2 drafts > - Not a new ID, no changes. > - Deployed networks using that. > - No major changes planned > * Igor - asked how to reflect constraints in a node for switching? > - JP - we are discussing auto mesh, not node switching. > - Igor - but how do we reflect node capabilities? > - JP - this draft is not about node capability discovery (for this, > see draft-vasseur-ccamp-te-node-cap) > - Igor - how to reflect for computation any internal constraints, > could do via node caps advertisement. > - JP agrees, though here just doing a discovery, doesn't think > related as discovering members of mesh. > - Adrian - two drafts, this is not node capability that is next one > by JP, cut discussion said to take it to list. > > Routing extensions for discovery of TE node capabilities (JL Le Roux) > * Adrian - on process, authors did a group job of splitting draft > and sending to OSPF and ISIS groups, chairs will follow up with > those groups. > * Dimitri - should for terminology call TE router? > - JL - yes. > - Dimitri - should the TLV be exclusive to this function? > - JL - yes. > * Igor - how to distinguish node capabilities? > - Adrian - do by TLVs, need to do a draft to propose, this draft > gives you the TLVs, then can follow-up with other drafts to > describe function want to use it for, take discussion to list. > * JL asked that this be adopted as a WG document. > - Adrian - Take it to the list > > Extensions to GMPLS RSVP graceful restart (Lou Berger) > * Adrian - do editorial respin, let us know, and we will take to > last call > * Any implementations? > - Yes - two! > > MRN > Requirements (Kohei Shiomoto) > Evaluation draft (JL Le Roux) > Protocol extensions (Dimitri) > * Arthi - what does virtual FA have to do with MRN, > isn't it general? > - Dimitri - should we have a specific doc on virtual FA for > wider scope? > - Arthi - did you want to scope only to MRN context? > - Dimitri - no, just not sure if soln doc should be split. > - Arthi - could be general - so prefer a separate doc on virtual FA. > * Zafar - we need to give a priority capability for TE. > - Dimitri - new TLV may be needed to describe relationships of > multiple interfaces > * Zafar - how relates to hierarchy draft? > - Dimitri - maybe should be as applicability statement, > - Kireeti - should do on mailing list > * Kireeti - requests to continue work, when re-charter will consider > for WG drafts. > > Routing considerations and CSPF for inter-as (Tomohiro Otani) > * JP - very useful draft. Concerned about the advertisement of DYNAMIC > summarized TE resource information across domains (static > capabilities are perfectly fine). Too much of aggregation renders > the solution inefficient and not enough of aggregation seriously > compromises the routing scalability. Furthermore, there are other > confidentiality issues to sort out in the context of inter-provider. > - Otani - ok, we need more on summarizing capability. > * Kireeti - thinks good and hopes to be a WG draft, though for now > would request for this draft to continue work, though lets finish > what ccamp has now and then when re-charter will make this as a > WG doc. > * Otani - how to handle inter-as cspf constraints? > - Kireeti - as noted before (continue work). > > L2LSP (Dimitri) > * Adrian asked clarification, is this "single hop"? > - Dimitri - multiple hops each is a LSR, will clarify this in draft > * Kireeti - ADs request a framework doc and include how it relates to > other SDOs, max 10 pages > - Dimitri - ok > > GMPLS addressing (Richard Rabbat) > * Adrian - as this is first version, recommend continue discussion, > re-spin draft, and then review again. > * Adrian asked for feedback on the topics, not the technical content > initially. > * Loa - BCP is a specific type of RFC, describes what we have > experience with not necessarily what should be (as in this draft) > * Kireeti - warns for everyone with implementations to review the > draft to ensure direction taken by this draft is right one. > * Lou - should we wait for re-spin or now? > - Kireeti - wait for re-spin. > > L1VPN (Tomonori Takeda) > Framework draft > Applicability draft > * Alex - by next IETF will decide if it should be included in ccamp or > as separate WG. > > Control plane saturation (JL Le Roux) > * Arthi - Do you think the LSRs would really want to advertise such > control plane limitations ? Secondly, what implication does this have > in case of inter-domain, especially inter-provider LSPs ? > * Kireeti - because of time, lets do on list. > > Graceful shutdown (Zafar Ali) > * Kireeti - will consider for wg doc after re-charter > * JP - is this part of current charter > - Kireeti - doesn't matter, we just can not include anymore as WG > doc until re-charter. > > Deployment-augumented (Zafar Ali) > * Arthi - This is good work. My only concern is the use of terminology. > Do you actually expect to use LSP-Hierarchy extensions (say Hop3) > while signaling an MPLS LSP over that FA in the MPLS domain ? > - Zafar - no just TE link > > GMPLS interworking (Kenji) > * Dimitri - why need to adv priority of LSP? > - Adrian - need to ask on list. > > GMPLS interworking (Kohei Shiomoto) > * Adrian - WG doc will be decided after re-charter > - Welcome that will merge with other draft on augumented, > - Suggest also look at Kenji's interworking draft to merge. > > Cho - ARP signal > * Kireeti - request work with Dimitri on framework draft, > - When decide direction and interactions with other SDO, may > decide to form a design team to work on L2, > - First we need a framework. > > > > . > From owner-ccamp@ops.ietf.org Fri Mar 18 13:02:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04516 for ; Fri, 18 Mar 2005 13:02:20 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCLsC-0008D1-Bx for ccamp-archive@ietf.org; Fri, 18 Mar 2005 13:07:03 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCLfN-0006QD-To for ccamp-data@psg.com; Fri, 18 Mar 2005 17:53:45 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCLfK-0006Pn-MR for ccamp@ops.ietf.org; Fri, 18 Mar 2005 17:53:42 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id A5B73E000280; Fri, 18 Mar 2005 17:53:34 +0000 (GMT) Received: from Puppy ([212.43.203.83] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 17:38:43 +0000 Message-ID: <05b001c52be1$8ebd3e10$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" Subject: Discussion about IPR claim in draft-ietf-ccamp-loose-path-reopt Date: Fri, 18 Mar 2005 17:18:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 18 Mar 2005 17:38:43.0569 (UTC) FILETIME=[5486E610:01C52BE1] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Hi, As mentioned in Minneapolis, draft-ietf-ccamp-loose-path-reopt is the subject of an IPR disclosure http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-path-reopt-00.txt The working group must decide whether we wish to pursue this I-D in the face of this IPR disclosure. Clearly it is a significant step to create an RFC that might require implementers to license technology. I would welcome opinions on this subject. In the mean time I will work with Scott Bradner to see if we can get any additional information or clarification about this disclosure. Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Mar 18 13:48:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04515 for ; Fri, 18 Mar 2005 13:02:20 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCLsD-0008D3-Tz for ccamp-archive@ietf.org; Fri, 18 Mar 2005 13:07:03 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCLfR-0006RF-R8 for ccamp-data@psg.com; Fri, 18 Mar 2005 17:53:49 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCLfN-0006Q8-Q3 for ccamp@ops.ietf.org; Fri, 18 Mar 2005 17:53:45 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id F07B4E00030C; Fri, 18 Mar 2005 17:53:41 +0000 (GMT) Received: from Puppy ([212.43.203.83] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 17:38:51 +0000 Message-ID: <05b401c52be1$93bf4930$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , References: <0aa401c51843$6a63fba0$adcb2bd4@Puppy> <025a01c528a0$fc6ff040$0601a8c0@pc6> <031301c52952$85dae720$0601a8c0@pc6> <000e01c52b94$e310a440$0601a8c0@pc6> Subject: Re: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Fri, 18 Mar 2005 17:38:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 18 Mar 2005 17:38:52.0224 (UTC) FILETIME=[59AF8C00:01C52BE1] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Tom, Good advice. We'll look at how to do this. Adrian ----- Original Message ----- From: "Tom Petch" To: "Adrian Farrel" ; Sent: Friday, March 18, 2005 8:29 AM Subject: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt > This MIB contains several 'enumerations' except they are not enumerations but > text in > DESCRIPTION clauses - gmplsTunnelGPid gmplsTunnelSwitchingType > gmplsTunnelLSPEncoding - with RFC 3471 (not a MIB) as a reference. So these are > not defined anywhere in SMI; and as this points out, these values will be added > to in future RFC. > > I think these should be in a MIB under IANA control and there is already a way > to do just that, namely to put them in an IANA MIB (as opposed to a standards > track MIB) with the RFC specifying under what conditions the IANA MIB can be > updated (standards track, IESG, expert etc). > > This procedure is described in draft-ietf-ops-mib-review-guidelines-04.txt which > also points to previous examples of this. And this issue has already surfaced, > albeit obliquely, on this list once before in the context of > IANAItuProbableCause which uses this procedure and is now published as part of > the Alarm MIB (RFC 3877). > > Not to do this now creates extra work in the future; when an implementor has to > create their own SMI and whenever these values need to be updated. > > Tom Petch > > > > From owner-ccamp@ops.ietf.org Fri Mar 18 14:50:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16954 for ; Fri, 18 Mar 2005 14:50:15 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCNYe-0004El-P5 for ccamp-archive@ietf.org; Fri, 18 Mar 2005 14:54:57 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCNNH-000KhW-5C for ccamp-data@psg.com; Fri, 18 Mar 2005 19:43:11 +0000 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCNNF-000KhF-UQ for ccamp@ops.ietf.org; Fri, 18 Mar 2005 19:43:10 +0000 Received: from pc6 (1Cust64.tnt30.lnd3.gbr.da.uu.net [62.188.122.64]) by galaxy.systems.pipex.net (Postfix) with SMTP id 0ABE9E00015D; Fri, 18 Mar 2005 19:43:01 +0000 (GMT) Message-ID: <017601c52be9$eef2efc0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , References: <0aa401c51843$6a63fba0$adcb2bd4@Puppy> <025a01c528a0$fc6ff040$0601a8c0@pc6> <031301c52952$85dae720$0601a8c0@pc6> <000e01c52b94$e310a440$0601a8c0@pc6> <05b401c52be1$93bf4930$dccb2bd4@Puppy> Subject: Yet more on drraft-ietf-ccamp-gmpls-te-mib-08.txt Date: Fri, 18 Mar 2005 19:38:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Digging deeper (sorry, I should done this before sending any e-mail:-( RFC 3471 says in IANA considerations "This document defines the following namespaces: o LSP Encoding Type: 8 bits o Switching Type: 8 bits o Generalized PID (G-PID): 16 bits All future assignments should be allocated through IETF Consensus action or documented in a Specification. LSP Encoding Type - valid value range is 1-255. This document defines values 1-11. Switching Type - valid value range is 1-255. This document defines values 1-4, 100, 150 and 200. Generalized PID (G-PID) - valid value range is 0-1500. This document defines values 0-46." fine no problem Switching type draft-ietf-ccamp-ospf-gmpls-extensions-12.txt adds 51 Layer-2 Switch Capable (L2SC) but makes no mention of that in IANA considerations; should it? The MIB text cites as reference draft-ietf-ccamp-gmpls-routing-09.txt which has no IANA considerations and I cannot see adding a value; should this be OSPF-gmpls-extensions? And draft-ietf-ccamp-gmpls-g709-09.txt says "Switching Type: Assigned by IANA via IETF Standards Track RFC Action. " ie this is now more restrictive than RFC 3471; is this really intended? LSP encoding type The MIB cites draft-ietf-ccamp-gmpls-g709-06.txt, This should be -09 which says - LSP Encoding Type: 12 defined in Section 3.1.1 13 defined in Section 3.1.1 Allocation Policy: [0..239] Assigned by IANA via IETF Standards Track RFC Action. ie this is now more restrictive than RFC3471; was this intended? Generalized PID Same story, MIB cites draft-ietf-ccamp-gmpls-g709-06.txt, which should be -09, does add values but again is more restrictive about how the values can be updated. Standing back, there are these three enumerations, they will be added to over the years, what is the right policy for updating them? Standards track, expert review, IETF consensus? How best to keep the MIBS in line with the I-Ds at least at initial publication, which is the authoritative document?(define it all in the MIB:-) Are there any more in other documents, perhaps for which no MIB yet exists? (RFC 3471 does list five sets of numbers - I have only looked at these three - and there an awfully large number of GMPLS documents most of which I have not looked at) From owner-ccamp@ops.ietf.org Fri Mar 18 15:34:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22988 for ; Fri, 18 Mar 2005 15:34:30 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCOFT-00066e-Uh for ccamp-archive@ietf.org; Fri, 18 Mar 2005 15:39:13 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCO07-000Pz9-6s for ccamp-data@psg.com; Fri, 18 Mar 2005 20:23:19 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCO04-000PyQ-5q for ccamp@ops.ietf.org; Fri, 18 Mar 2005 20:23:16 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 59370E000191 for ; Fri, 18 Mar 2005 20:23:12 +0000 (GMT) Received: from Puppy ([212.43.203.118] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 20:20:44 +0000 Message-ID: <065701c52bf8$31885830$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Opinion on two new WG drafts Date: Fri, 18 Mar 2005 20:04:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 18 Mar 2005 20:20:45.0406 (UTC) FILETIME=[F7317FE0:01C52BF7] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Our charter encourages us to work on inter-domain solutions. There are two drafts which we should consider as working group drafts: - draft-vasseur-ccamp-inter-domain-path-comp-00.txt - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt In Minneapolis the room seemed to be in favor with two caveats: - draft-vasseur-ccamp-inter-domain-path-comp must include a statement clarifying that in the context of this draft, the node in charge of any ERO expansion within its domain is always along the inter-domain TE LSP path - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt must wait for draft-ayyangar-ccamp-lsp-stitching-00.txt to become a CCAMP draft Assuming these requirements to be fulfilled, please say whether you support these drafts becoming CCAMP drafts. A simple yes/no is enough, but reasons against are useful. Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Mar 18 15:35:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23168 for ; Fri, 18 Mar 2005 15:35:14 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCOGC-00068d-9f for ccamp-archive@ietf.org; Fri, 18 Mar 2005 15:39:56 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCO03-000PyM-Em for ccamp-data@psg.com; Fri, 18 Mar 2005 20:23:15 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCO00-000Py3-Cn for ccamp@ops.ietf.org; Fri, 18 Mar 2005 20:23:12 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 514D0E000048; Fri, 18 Mar 2005 20:23:09 +0000 (GMT) Received: from Puppy ([212.43.203.118] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 20:20:36 +0000 Message-ID: <065401c52bf8$2cbd3b90$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Arthi Ayyangar" Subject: Stitching draft to WG status Date: Fri, 18 Mar 2005 19:56:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 18 Mar 2005 20:20:37.0250 (UTC) FILETIME=[F254FE20:01C52BF7] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Hi, We discussed making draft-ayyangar-ccamp-lsp-stitching-00.txt a CCAMP draft before Minneapolis. I judge that the consensus was that this should now be a WG draft. Arthi, please republish as draft-ietf-ccamp-lsp-stitching-00.txt with no other changes (except boilerplate as needed). We can then discuss the draft within the WG and move it forward rapidly. Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Mar 18 15:44:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25957 for ; Fri, 18 Mar 2005 15:44:26 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCOP5-00078t-I5 for ccamp-archive@ietf.org; Fri, 18 Mar 2005 15:49:09 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCOAs-00014e-AL for ccamp-data@psg.com; Fri, 18 Mar 2005 20:34:26 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCOAr-00014I-5z for ccamp@ops.ietf.org; Fri, 18 Mar 2005 20:34:25 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22974; Fri, 18 Mar 2005 15:34:21 -0500 (EST) Message-Id: <200503182034.PAA22974@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-00.txt Date: Fri, 18 Mar 2005 15:34:21 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within The Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture Author(s) : I. Bryskin, A. Farrel Filename : draft-ietf-ccamp-gmpls-ason-lexicography-00.txt Pages : 12 Date : 2005-3-18 Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of physical technologies and across several architectural models. The ITU-T has specified an architecture for the management of Automatically Switched Optical Networks (ASON). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ason-lexicography-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-18153745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-lexicography-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-18153745.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Sat Mar 19 11:47:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06039 for ; Sat, 19 Mar 2005 11:47:46 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DChBn-0007wZ-JT for ccamp-archive@ietf.org; Sat, 19 Mar 2005 11:52:39 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DCgwO-000Fbl-5q for ccamp-data@psg.com; Sat, 19 Mar 2005 16:36:44 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DCgwM-000FbD-1f; Sat, 19 Mar 2005 16:36:42 +0000 Message-ID: <423C5526.5070908@psg.com> Date: Sat, 19 Mar 2005 17:36:54 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Opinion on two new WG drafts References: <065701c52bf8$31885830$dccb2bd4@Puppy> In-Reply-To: <065701c52bf8$31885830$dccb2bd4@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit adrian, just to be sure the first reference is not available, so be sure that we are discussing the correct document do you refer to now the second document appears to me to be already a working group document - so would you clarify the below question ? i have already send a bunch of comment on this document (from its non-WG version so expect to see some discussion on the next version), an additional remark would be that the sentence "There are three ways in which an RSVP-TE LSP could be signaled across multiple domains:" is not precise enough to translate the fact there are two ways (and not three) one that does use a unique end-to-end RSVP session (contiguous) and another that allows usage of intermediate RSVP session(s) used to establish the end-to-end session; currently there are three (and not two) methods that can be used for the second way: stitching (the head-end intermediate node performs selection of the segment), splicing (the LSP head-end node performs selection of the segment, using explicit label control), and nesting note: the second method is detailed in RFC 3471, section 6, thanks, - dimitri. Adrian Farrel wrote: > Our charter encourages us to work on inter-domain solutions. > There are two drafts which we should consider as working group drafts: > - draft-vasseur-ccamp-inter-domain-path-comp-00.txt > - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt > > In Minneapolis the room seemed to be in favor with two caveats: > - draft-vasseur-ccamp-inter-domain-path-comp must include a > statement clarifying that in the context of this draft, the node in > charge of any ERO expansion within its domain is always along > the inter-domain TE LSP path > - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt must wait > for draft-ayyangar-ccamp-lsp-stitching-00.txt to become a > CCAMP draft > > Assuming these requirements to be fulfilled, please say whether you > support these drafts becoming CCAMP drafts. A simple yes/no is enough, but > reasons against are useful. > > Thanks, > Adrian > > > > . > From uvswbjug@Adelphia.com Sat Mar 19 23:31:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19416; Sat, 19 Mar 2005 23:31:29 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCsAr-0004F6-W9; Sat, 19 Mar 2005 23:36:28 -0500 Received: from [69.15.94.165] (helo=NSX-000465) by mx2.foretec.com with smtp (Exim 4.24) id 1DCs5v-0004i0-I1; Sat, 19 Mar 2005 23:31:19 -0500 Received: from sex.wbdet.com ([69.25.212.139]) by blackmail.2xs.net (InterMail vK.4.04.00.03 148-390-724-20031423 license 8bd551af3019n0il3l7cnf3178b2ved8) with SMTP id <20044915378267.QBTL8959.blackmail@sex.wbdet.com> for ; Sun, 20 Mar 2005 09:22:12 +0500 Received: from www.wbdet.com (205.161.255.18) by sex.wbdet.com (RS ver 1.0.92vs) with SMTP id 3-26c824578319 for ; Sun, 20 Mar 2005 08:19:12 +0400 (EDT) Date: Sun, 20 Mar 2005 03:24:12 -0100 From: "Desiree Doss" To: Subject: Social Circle Telegraph - in-depth article regarding vIruses Sender: "Desiree Doss" Message-ID: <895160067767.ZSB25554@courtroom.2xs.net> MIME-Version: 1.0 Content-Type: multipart/related; boundary="Java.DDXYC.224234335241099726" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <4355104@GZQIMWLWF> X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 X-Spam-Score: 7.9 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 This is a multi-part message in MIME format. --Java.DDXYC.224234335241099726 Content-Type: multipart/alternative; boundary="Java.JHMXY.307007616140050716" --Java.JHMXY.307007616140050716 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Get !t Qu|ck|y --Java.JHMXY.307007616140050716 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
3D""
 
 
 
Place an O,r,d.e'r=
 
burundi dungeon intoleran= t cellophane counterfeit virtuous buxtehude radish delhi mainline karyatid= permit venom valery clinton jane whelk amy candela shaven collision spaye= d sensuous italian chant fraction plaintiff trw typify boisterous disc rif= t seismography empress dairylea pagan
 
sarasota typesetting cast= igate creon bucknell dither stater roadside dee hover compacter reredos ca= valier bellhop sundry timberland breakage exploitation solicit unitary res= pect xenophobia elysian
 
bistate gavotte latitudin= al bobbie trawl tolstoy airfare bogey cos chub hollyhock animism explosion= %RND salivary
 
pontiac dove gusty simple= ton indirect bird butane anomaly eradicable momentous deus cacophonist fou= ndling brothel mccarthy certificate handmade arrear balzac atkins
 
dichotomize raffle aventi= ne towhee trefoil sinusoid boniface strom bushy pelvis affricate bluebonne= t threaten subtlety wold mount begging talc defendant belfry fail falstaff= crawlspace finnegan lost addenda marty circumference blockade kigali nutr= itious infantile w radium carmen
 
penicillin triangular res= ignation incise spectacular penman deform spouse merritt america cyclist t= esticle miscellany saturday beth glance intuitable lifetime confidante and= iron healy periscope norma coil hexameter trustful sceptic earl
 
sorensen perfidy spokespe= rson cahill schroeder burgundian cottrell tonk admitting craggy imposture = libation debris transpire migratory bates negroid honeymoon slocum enzymol= ogy cranelike checkup kite clonic macarthur
 
agricultural e's emma con= cessionaire raymond catalina sara somal despise oscillate sidelight commen= dation read athletic hypothalamus crocodile originate cowbell countdown re= levant daffy titus anamorphic agenda worsen darius sandman doff adulthood = thug depression skylark
 
compute uniaxial avowal a= rturo nashua grenoble churchgoer repairmen rectangular limpid windup incon= siderable nymph tremble cryogenic cornea metabole drake needlepoint vanadi= um livingston
 
boucher coney tyson clog = testimonial headlight burch bilge visual rhapsodic acropolis neophyte edge= impair forgave coca floral davies blazon alger doppler opt bodybuild dilo= garithm dynamo downplay perspiration hackney cyclist extravaganza combatan= t
 
carload crack scoff exhau= st weal edit apices address arctic balletomane bois constituent modulus ye= llow demur idiosyncratic arrear origin formulate devonshire mueller bahrei= n arboreal reparation starch carboxy sail cameron renal brush
=
 
imbalance forklift televi= se appreciable mobil nighthawk cohere harriet seventeenth diagrammatic dep= rave accept leninist conjoint dolly cherish compressor downright philip ut= ile anisotropic integrable bottommost wavelength lubbock patton intend
 
merrimack radial flurry t= alisman mensurable tva monsoon exception arise brigadier dab jitterbug bur= ley octoroon turpitude grayish delirium dobbin max warmish pont court news= week insulate burp kingston bear nearest dialysis fury skeet
 
invigorate coaxial covet = tamale trickery spoilage bundy horsetail feasible dither destitute inoppor= tune liveth throb biography handbag whereof common aircraft
 
prokaryote johann saginaw= nominal beirut plight maw hazel parsley amplifier floe neoconservative bu= cknell pitchstone experimentation czar guam spatial cathode bator melee an= alyst lennox negroes threesome brighten wynn veteran whip captor cotyledon= coherent splintery
 
d'oeuvre quint randall bi= harmonic inapt incapacitate backlash sadden sir warfare amherst aspirin sh= muel thirty contraption altair upsilon childbear nsf davy sick beggar cont= inua delay tedious clown disambiguate ransom quadrilateral polygon electro= lysis configure compile baltimorean tooth contravariant flycatcher turbule= nt
 
commissary topcoat distal= infarct appall vaccinate tile abrogate roister cable emerald kinney cochr= ane glissade tid audience calendrical doleful severalty lying erupt cradle= determinate mbabane precede schoolwork plod dyer fireside cyclic j's adde= ndum ballast cachalot lamb apport wiggle bugle actuarial blameworthy
 
grandma marsh ate birming= ham chiang preferential you've cordial madras pickman secretary luge meal = alexei anecdotal emasculate calcium thousandth reservation den herself spa= t be stevens neutrino antiquarian estate dross bromine sordid carload hurt= le vandenberg unix squatting cornerstone carib agamemnon worcester liberta= rian protectorate saga monomer airlock
 
dominion convivial penman= soda theft mart frowzy forgotten chester songful quagmire washy olivetti = calumniate barnet thereupon blather inaugural cinematic congestive each fo= lksong thoroughgoing sheila any memoir indiscretion intense synoptic logan= bridesmaid daisy dovetail baroque alewife inimical accident fusty spherul= e vociferous dolphin cornell leafy french sextuple cant paperweight colori= meter balkan mccluskey rather borough faa ninetieth addle spectroscopic
--Java.JHMXY.307007616140050716-- --Java.DDXYC.224234335241099726 Content-Type: image/gif; name="garcia06.gif" Content-Transfer-Encoding: base64 Content-ID: <879817c4d3c0$2180fea0$476aa7c0@GZQIMWLWF> Content-Transfer-Encoding: base64 R0lGODlhFQFvANU/AM/Q0JWZlf/Yq7KTdZ/rTKnjsl9nTP79AP0GBVRLOP7+/m2ZPujs6yAfG1ug hxdYVc6siOS5kpGPIOtPJYl4Y/uKb50NCvJgUvHGnJ5YKJPQPgxkjcjKBfrOo+3tT8G9qnMnJPP1 9dXUtfDW1DtHJ/j3Jb6mFf/mtrvGx+euqfDi3pa9qeDj4//fru6cifvo5teKgu/v89ja2t3diOzz 8Prz8Cw1MezGv8XDH+XjAqv/VO/v7wAAAMzMzP/Tp////yH/C05FVFNDQVBFMi4wAwEAAAAh+QQF SwA/ACwAAAAAFQFvAAAG/8BGYkgsGo/IpHLJbDqf0Kh0Sq1ar1dbwsfter/gsHhMLpvP6LR6zW67 3/B3a7CN2+/4vH7P7/PndX6Cg4SFhod5gIiLjI2Oj3eKkJOUlZaHkpeam5ydZpmeoaKjkKCkp6ip eqaqra6vZayws7Stsl8dHRgREL2+vxHBwhEYxcbFucnKtczNsXRhubu9AxQGCRQBARTc3d7f3APi 4+QDv+cQw+rEx8jKyc7xj6YdvNXWJDYNPA0sMTsMGLAYKEMGgIMAelyYkKGhwwQZiBiYSNEAhXvg Ml4sx9FchA7yQhoyFWGAAX37eKjkxyDEjhgwY9CQGaKmywk4J1xoaCKDxf8HDzYIHbrBgIwYA1kU NJiwRw8UH6JKlaqtqjaPIuEIaNFCAJmtLcps9SrKFAQDK9OqtNFyh9u3cHeEGJGT4c6GBoACJSo0 KAsFNgMLHhw4JkAGvd7oQkYGpCCwXCN/gRw57OQIFSq4IAtGAIbMjsMIcKGZcydQHeioTcvWZVwG cEPcqOswIgm9QYc62L3BAYqacYMLf1kzZogAA9zo4kUstBdpzvUIiFDboYoa2GvAqN4Qg2kfExCI 9x6mRYXx37u0CD/BspmxXbuOEUBfDP305aF1wUCBxOqUrQn3j1shpIDTQg5NhNtevQGgAA0A7IYC C64NJ+BAT8F0XHJj5CL/BgYQDICDORiAsVxzfbTgggUstpiBAjDCmEKLNEbAmYriiVeBe16Yh54Y 6yHQ3hkCVHBBZp+RN1k96fhgmlfMOflMID5EQIEN/4HQQANtwQUbTAS6MIFmOPk0hF426NWbAyv8 pQAKKDAApoXBhcDCBwfJGQNyHboDRkkU5CDBAB99Mc0HKO6hIo0sphBjjIyyaKN6FwjJnmmRnXAe AuRRxkWQE5wgWReU0RfBBGJW6gKPAqRmzUQUQOCVV9VQFOuUXliJpVoNgMCDDRTCRUMIMQQkZwgV THDDQgxNlMBtQKUZFG++KRADAMQOSCdcSP0lg5w78BnNLuzgAgEFEhxg/0KsJXahCwRRQYBBdJGs yOijMcIQ6aROYqDjpptxUeQFF2CGXgufEbzZVuFdgAHBFUjplZFHYtBCBwUvdEHAAvMH66sGJNfB q91MNAB+n+rHha6r+fprsDvQQIMKKshFAwPDboyBTmUmcA2De+0mNMzbCmcnCjLE+Y+4JkYQb6H7 nWvCARyEDPVyEBTwgbz0ctE1GovSCAO+ML6wL1k+cuovAheEJUClOYbHadpx+xBkjuJN0K/cOdo4 72LRUeAzBP0KbgAvJoM0ss9KggEKy2pp+Su4MiOrUwUjyLRDBSokSzCCPqu5QdBCr1CDtkVzy0BB eobLIRi7fFBAL/N6Xf+SARwccIAE7NoOr9bp0LtY7WyE3eILZMN4AaP8CsAeV3J3gCMCFXSwKacR iOfwphecIHf1m+7Int2VTlDffV5MZzJZApxrQIgTWWwqN41/8fiV/23ZD0CyuWAgeyoIgQpuoIID EewhCWDQ6KblgA2sQC6pqxMDPhAAGRDLdR/qRQFmh6J6WCMHujNByEr0rqxtMHjPmUY6iKcG41ng AsmD0Q2YN6vsUe8EJ3CBjk4AN/rwUDwYE89WNAXE5wnAe0KyYfU6oEME8KszJjmcaZARRUKBpD5k uN+u0gICLe2vJfr6H04ImIIRnOpzB8yANRLIwKBt4Deoi6BcemCAbQD/5yJdm8YGt9YcEKFLdwfI wUXYwYsNnhBqPnjXOFC4Bhfe4FEuQF6MMlAjr7QAbpohTd6QOKS07UxIYZmemNgWSkziDW87sk8U 63cfj31MXihLGZUgx8V9AEtmDJiABXiGkwqkgDQaQ+NduKGXgjgAKA1cgQLkGJcQoKCO2GjJIFnI BT3ucYUYqMbUAMm7dPBCdoZkJJO4gQMTWLF49rLAi2JktrHFaEYtslGrTnnKDjzPbptaWyebOMpO wu2fn8vMEyezSvx4JorXMFkWVVYl/PFqH1yKgWx2WRecpIBZB+LlXSYiFAcogAXH7OgymfmWYgWg jgGQ5kVWGBprXjMY/yYBISCrZg4NGpKD0gBUoAR5zkam01ExWtE6YVSDSk5PJ5/7Xvl8CDd7CvGI +bzUEdnTRAzgEGMOQ5kACpq++3RlF7WayEB7xFBarkRybJEoBChaUTHVBY21UVBQlCmDBXo0jhEM gQy4EYA78m6lxHPpNc+VLkDqjnfmuOkhixEidIEQBxdpl09bVINHUdICj8xXPBkGxK5spQN5U6IP mogA62mPiZuU2wVQyzYBnNapnNLqWd7HPhAB4z7tEyvKtNgyL/ojBPqqqHCRCteGDAFaD1DmCpBp LZK6RQEfoMAzg+XYv7JUsCc0SWENK0IKrECxs0sH/LbbTcm20F7ulP9hi2AYIxXEswU2bFuP4OYC uJ3SYvbNm1X5hjeLkTZHFYilZ2Dl1SoKjgJO2koEdAuksjo0LVviBwvkMkO2DteAn3sICZ6lF2U6 wAYGaK5zJXrSD1xQcI8NxwoLqdgVWGObhuUANsAb3nvgwLDcQOR5WaSCRy2vRSPwsaQQhqQnfaYC NqKYC47cAfrU93JNHo1mHqaTTn3mQBHgkWiqSIzZGiCbPiOUH+O3WwdvcSW9epnMAHDZC7+VYCbo iXFJgNzkAsAGHnUugRiwjZS6RHCFFZRFfkFjByQgd4YNpATYBF5xcAPRusuB1aLxiRWxF0YjYFR6 FVBhebbgBLhl36f/LYlbrpDKs+7hCn3iw5mxjKUz30lNRWAlK4/5rCKEGwNvI2dLCtkpAyDIgJvf HOedEKHOD6BjAEZKUpMaAE4QtEagZopYcXz3pitwwAI4INNIc0ADjMa2NSTQbd3h4H3mlcbfsrii zMJIX4yq7CQtwK93SM8yumhEvsHQWMDOKjUYGUD9HGfmlvU6BDKDQBctfGE4m+Aux12QA7GlZwWc FFZt6caNuWsR77bYARrgALcjnQMO6GA31y7AClZgAHInene9U7cwGAMkfeFLBSMYQYUtAFQYrUie EUDJlrRwsg4koAEUiOV82uAZEjTgZJM533fQh76FzvLBEH5ZTVgA/+yFD1uYDCHCgpAJHD2H4CDa ODE3tkvtBIR7g9kmgA5EnoO6c0Du4L52trU98kRzg2vF4EUvEEVN+7lg0/iC91AVYLaFQWA1KjFA B/ZhAC2LBb7mRcN0VEIBy6+i4P+RMIEo0EUQsMjNGa4Nh3NDlDxX/JncsCCfHV3uSEtgAWz67sod IPe5i/zuOtABAXK/dwLgoO8ztZoKB6+1RI1B3snbec8VAAPHcx6su4IAljpfdVJ1H2FHz7L3sTj+ Gu6D++QXWPcTnGClyzJXWOf8B44+YRrIYAClP33DL/Bw456J9XzhIHpGYtIlUQywUhQAY4BUchqQ d7vnAMEnfOWEA/8ReHJCw3s6EHK1J0I1xXzhpGNhcAIxFCN34QKP8gJX9Hg8MACgdgIDwHnbdwK7 0DhhEQzyowsv2ABc81nBID3qUSXEoGD7MADwFYTqUQ/EIB+J1GRIKCW6BnqsITj7Y3+lZ3r6J1yf I2erxxcd1Rtlx0wh0APZQAEtcYDm8EeJVnJ4d4EaUIEEAHwROHwgF4fIV3cSEDIDAE43RTtf0wUi OIKA6DYqyIJH9II8gD8ToRJINysDsCsNYADtsxoQ0AIUACBJRx+NuBIJQAznlwCKSIRO4lBIZzcD 0AA2UIkqsYmxtGtqcSVfFAKkV4XqdGGqBy1cOBQB4EDMJkdhOIb/FGKG8ANp3tZ7BABuGOiGFRh8 c0iHddeMVeNx4MVHfeiHgBiITqKCFABWKaF9ingSKgEBLpiKaMEDCQABCbArG7ZgkeeJhxiOPGAR +5AAGAAgBpASEXACFCCOqYiPmjiOCbCKULgS2UB//PMBVWiFDkEb/sdhDpCLt7gmX5hXLNBncnGA saJdafhtFQhuydiRHil8v/d7eUdjHJR5YiCCLREjA/EoAkE2ggh5h+gDEGVV8/iOk/eOnzaIJ/B4 DWBVOsmPPBABnmgDR3QWFBABtlSUnBcBnIdDhhginPdpT1lmV3dma1GJ/XAzwxKLBylstcEQEfEs aSIDDfSQErKL/0UDExOxDWWYDY11aM1od234kXTpkQRgAiKHA2uYcnvINWdwAgCAdDEyBI9yji55 jYpoA4r5PhdDeaGEJeX4jY9JjjvJD/eIFj1pKudniI84AB1wAkh5iF1xkxehEvJEmoYoTzXZeQ1W lavBDaIXEHaCfwcZbNxhG/ngUWVplhQnRzCBAtuALcUCjSwnASGZl3WZnG6IA3OpjG9nSNKIBicQ AL8CI3dGAgqQEApwjj3AAMv0GyeAmKL5KfRBmpMZMt9oSf5hA+HYAPfoiQ0QZaFZeZmoiEc5hKN5 fvnonuUZjzl4mo7ZmvBnle+ImRMmmyzAlbWJQMf1LB+gALspFP8rEIAV0kx4JRd7xQ1tqXe7IXzG xwEmQIHKOaId+ZwfSE3L8AUnUI9cko/k+AEqcVKpKAP6kAAvOZ6kYp52gyXoyQOT6CSQ2Z6XyQ/e sXkxmQsl4R8reH75eYgummWeQXmp2Z84SnCuCWHw+EUxk6AU0BBVqJgbhgQk8KAR2ht1NRQrUKFv 4UxEs6YoQAEfYAC/CI0qd4zBRwC9R6J6Onx8mV3etA42GBqtgnQNsAJIpwUbdhInQZ31mI+yEolV 6iQ62gKQWZM2WpntmJruSAE49KRHlwA4NIhMOqiHyJTt6I5QeapTKaBdYFact5/+4BY4M0Hi0HVd RGcSUQQksGz/DkkUAbADo7MBFhRHdvIAAlgnLAdHCZpy2dacevqsEWiMKzetLtYR5LBC6sGTh9gA z5QP2SAECSADPOAfdCZP2MgqN1l5O0qZLuoztiQ9pgpi5piK7GgAQIkNWGIDEDCq6bqi9JqKc7AS iUiOAHmlaZEAAbAl/gAuZ6egXWQDuJqo13BcyzahXIgCNCAUMlADwfEmD9Cme8ZXLbGshrR30Hqy znmBuzFr3yABEmBOfkmKPJCw5/ipJ6EF9ViP1BkAH+A2Qfd0sXZ0SeckQtsV9fmInYKKPioASjuK raK05EgMTgd1Rod0YdG0FCA9Lqq08liwA8or35qVa8oCCVCb/0YgscdFARZksUMRFKuzASC7Axb3 ABH5EhNpAB+AAhVJAQ4Ad8WHstAqNA3YgAvwssfHbXEJQhxAIqRijgrAV1pAAQDwLGJ4jgFQA4pq Gn0YHaFRgx9Bfp5RKDz4EZZRnjaIRZz7gz0YH086HUVqdV+rFokILF4CXfnXRcCWq7dGBMv2Ub06 Oh51FHgVArvxIM10Ut0wsnw7rRcIuM4LkrWXaOsiZpMhMRIzK9frfmywfur3JAaVfu9xIy46ieCb HwbbjVg5YW7xDzSgALTJIsFWBLM2Ebu6TJU1kQuUbGi5vgzwAMtWJzJgEcFiJxOhsh36vChLdy/H TYA1jVlxBv8Bu7RgE5CvKmH/MCc0wAKKh0DzSxH/SxwKwAAocEwosL9y2wMPUMJ1YhXrywIth6d4 isDO+4bRa3vT9MB3ACIgCLutGn/kaKAuMSchAAENoU4c3MH1izohACMX+lzH1CWxEafXQIZ2koAi mowLsADOKsN0qcAvJ0ixQgw4jAfly8MrE39IR51iGxshQEllkiAUcYcUgbAhAC7cckF1sgMPcFcX MgIBsaUvC4cViCULoJwasAAGQGcGsMXJSACIrMiFi7i1B1lh7MBjLAisKLAocaCwsaYq4MZg6RMT 4bJyvJYA8MECgjo1gALJZcIxswMukHMqIBDGqYbJ6B+FTJf/GqCkamEDjKwDC5ASvWwCcRlCIROz l9wImRx5cdoPcVQsNJBpuwTHpOyyiIy3J1W3b/ElbwGhD9AlcTQz/gMDKpDBtcwBV1yM+0ACWpyn EbgAMLkSufzO8cwPeMltHHCHlWzJyZwiFPwr6aumMJGHN1Abd1jNpDwR0WUA2vwSIixRSywDrUwn c1EBN3AzLHDO6LwAvNzL86wBvOJ0atGcIA1hwrwWwqcBsOIRxuAh/YwJ/wyb/RDEcEF9FgAD2yHK hfuyCL0AJ7VsF1oT1Jpte7zEw4FwLuACF23O92wCHQ15DRCBHU0CckcAUy3VaUHVGXjSCyCHK3cO NrhuLz0I/8vspC8zvJ9smzqdxQaw07dHv2qrpg4tA9lG1HrhAMfKLSrwSyPgAgGUoMZp1fWsiHcK YXlKAMLcAFVt2PS8Enj2nPHiC4FKxqFW2ZZ92Zid2Zq92dzbQhT8iCxqx3Hhvg5ByoV7zXpxG9Ki wqpzEHS9IGxSLc2UAtXnP1uqxRkIYSr9jo7MosFX0ihdgR3dhvC8EiTgholtojcV2c7nBl1xAyIw FdI93dRd3dZ93dh93VFWPDG9n1AcG59szVl82mydFwsiA7u4xCyAAswL2yNMNMUiE7S91CyA28Wt EoUMz/PsyL+d1ck4jvgNzGlhAMl40n1KkoTHz0AyAk4BAP9L8eAQHuESPuEUXuEWHuEAAJwCp732 Q8EIC6sVgjrQdXvjXeLljRtyGgAzIRcTOXYuvgJHsb7rOwIpsNfl7ML5zRq7Pc8bydiNHeAAzgM8 rgNn1rckuUd8VHhp0AIi0ANJceFQHuVSPuUysN58wuHv18NWeYosGrfrGwIfgMgmLubXbN4BwMq+ NpFC4+IjXEx1fMe0nQIy48K7Ady8ksXujNhZnadBXsgdPeQdbeQ0tjW90NxqIAB4sjpN4RSM3uiO /uiQHumSPumU7ugOLgPb0GQTfL6cp8Ze/hJvIQIQUN7XXOZAEQB+EQKrjOoufurZeUwPYEFregNJ ndQ4s1f/QvPUvLLIWA1hdHbSQq4Df37LA75yy03oYa3gjiMCAMACi17p0B7t0j7tjY7pQwvB/2yK WjccMBEAPl0NYt7BKL5sI5y/rd67fNZXNLC+N8DXfm1/fCs0wVzPDTCXej7YwT7swp0WuDethI5N Ls10NzAhz07tBn/wCN8DABAyHF7Wiilhcr2mMhDuHTzHD5APSIeVrb7HAbCYFvRRODMgMvNLMIAz CSo0Vc3RwI5m0UqgIr0SbdjnyXhmGtDbK8UOyj4fH6AUCd/zPh/tp7yJ2M7ppoglM00nCiAC413x cyyW+oBmRR8tiknX+mBnoA7qZfhLJm8Ay0jsdDbSG5nI/yTA61uk2AIusMidFiFnAvpMIjlvHzew 85OOEAcB6XRP949+93Vv6XqP9wrf9wVv6SiADUMfuxBm9J/+5SIwAGXO9ESgmE9v0hEWYh+wJShQ LDIeELRefTfe1h+JyzoQ5L/84+Pa347d42gmyefWwHGA6EgT6XX/ASnwAX8P7Xsv6bfv87nf6Akh OCZppYavifDJAus+J3VS343v+P/3ACgB1X+xsyFsLLOK0ylQx6uD2xrQALgdfGhRyOyoEqO/1Wp/ pyfdnEFOAnW3gNZl6IceALvf4Bd1SheQAk0BAOVTF0KyMQlh/5YCBJMJYnJJAXrIoZApRFxkgAux STQie/9ZbZZig/jAYTG4NUiII13emt1Y21i03Zxen4dEC72B3/f7EwIfHmwa3NYMeQIUQgwCQnYY JCdpRlJcVGhkDCQINNhsDBZIeEhI2Uh0VBcMNDxZ2dZSVXUMYhs0NBZieUwOfoEPcCgoBiAwOsaU l8EEAqK2sgBSEKqtrWGQAIauu10Atruvs5HEu1FkuM0RjqK1AhoGkpnJzNDUeEEZ5OzsYmJkBPgz kCCfQYQSheJhgNGKFSEmRdxXKY4MCSY4mMi3ERetUxtLEaCl4xNIVDmCBcshgRiECMjoxXyGRcu0 ddaOSLlmwcK1CeCm3MzW4yYCC8/UGe1p7ae7LPAGYIj/6aPMmTBpbJiEw68fnRghBBb0s+EBwYM2 CjUw0CBBiBAsWECUGJEGgx0WOeTQaPKNhpEf85EQOZIkXxt5UaYExoHYgJdTmc2MptMam6VPogRF AALRNQgyNFvgAeJy02sbA7BQd6jBtQ80t0CVGrPqvawg4UDqWkeBCLFjCZFI4GcQ2rQGEpAI8Q/S 3Ll3JXA4oFcCiUKxbJBYQFgHYFR+uavS4J2HWgIE8ipOacJYhHmQxUiuSdSaIT4gXIO2BiJAAArX KNCvGhCsa82a164BYaAP0tmvvwysOUoGp2Sbqrar8Nkot93qcIuC3wx4YIMNkLPhoBONa4CEDxXw yjmJ/6CTLgcOBjsvKwPCE08XPRZwJUfCCOCxx8F04CA9lXKY0UgcHHsPPjDkk4aa+hhk4YNrBhCw mgs0M8oALUHoQYYrrRkAgKJciEIdC7jcKUAK45mNngvBwEorBnTjcA4FNhHrILKGM+hEFB1YZId/ InlxkhiT5IAwUrb7UdJJRzrPk1wkyFTTTD80oDGXnHwyyiSm9HJCcADUUhzRntEMBBQAaLCaDM68 KYMkkuqG1QndqZA2ezC8TUM89eRtBT9FLEuQQZlNLc85FJ0ErxmJVAVSSrHNUQMHuO2WWz4aG0Dc cSFwSc4noYSmplIReLMcaxJQdSceEhDTVVjDGbDWav946teCV2VddSHYYovTQmDrzDAfG4gt9o4Q KCCBuD9HHC4BZgcRFIUW64hWkhhp5C6rSLMtWRUCunXIoQJWENelCGCOGQNkQhVVXWnoqyZLUq+J 11UerrkVqP1gzRmBBPZFIJ8GxFwNaGtoJfgdg3+1KmFhF27Y4R0gCpHZEQE1wDgTTyx0EAZiSNTj iDZJQAJvuzWFZJNL5nblAvAu4ANza0Z3mVFxZSqJHkL70lUK8MNp6AFRIDxCpHv+QPLJAx+QgssQ GBzOqA622gc7cdPa4RgUCGBQsMMWe2zjHghghdZ1W1siGQKBu9tq6S552xXy7n1vmPyeCnAABugm 1wb/Wt0voGsuWHwdBZMWZ4Km92MhAOZ57ZXqORH+XGFeGH62WAVepxj1ByxePUQTUUBhBbtikH12 T1VWmdvc8UeZ997zLhf44CNzM2mgIHHmsEADGKSOVwEAQjgJmMACED1xZEmBE2pgNV6zuXMtg07e wxr44rK1HSiABeY7XyASwDpCOCBEDoBLDdKWNvlJywD7y9sKHAAe/E0KB+ehxe7417+X9A2APgCc mBCHOaNwJkCU2Qw6VlAaefFLNAZ4100CpMBYXc8azdNg52yjlRA6LAQKSEADMDYI4ZiCEGRrXYge cqg5xG9RspMBBWyINxzq8GQ75A4OMMKBHgIxiHoz/1cR/ybAmtiiPP9iAwW0EYA2wGoTk5QkSAyQ hDvyxQDWA8WpEjBJqfmKe54DnYbGOL5L3qIB2QmEdUyhwvKxAIYdm6Ek7phHljmgRgTAAQ78SBgc GElJHKBfIQ35GETGR5HSkMGxCoEWR0ADAB9AYSaTYE0UBgAFKPQmHsGRhAB4k5wJeMYKUAjJJKAT hRmMBimZ0cFTZk18XYHIIRDRSuEEAi3WWd0DUGADB3DsH4i6JQNy2Tsc8hI9RjIBMINJC2ImKUkS SEAxICA5/v2OiH47Yk3UFSvYxEoGJQVpSaNAUpSidKQrdSk1V3rSkkqtB/DkYPfmCT7R7aZ0aTFE K//HFsvVSRMFD0glHQ6KUDwq1AELMBJiBAkk3IVnW9VCjEo8VS6tZvQDePuAe5YZho9uARzhTEJZ R1pWspr1rDRBa03UKo24OoWuT9lePHH6Pezs1J6V/ClQh/pPgTqkRXXxmNqcA4Cl6pECbqPodGY0 km3xUQc+HEm3dHikYLDEXDHTquSUGdax1pVLXMpgNUs7lMHBQB0TgMFrUFvacJb2AmeFQWnbUdcv Vi2MuDlqV0hHgfL81RCBHdsZVyADW9oFsfJTLO/2NoAPSUclISNJt4TZQ1qgzFt+0exiiuGeDnRg ZjEbYljTRVO6XvEJ2ijV9LKZK2ywl0HsIodn1Fv/V5sqQ556BcVv+1G6NhD3p4GVWG7SBq2PNdeO BjCGVikgAcVElrsLJVJDHSUeB9iPWzhITErC+57xzux/om1mXdmLABhEoVQWSG4P5HuNFAQsS12a wJgi9CXd7raUvR1WPTvUiAETmLhoUYs5OYbUpEYEAA5+SQQgQAFfpGRG29qwQ+5XWWIaScP7wzIn PgwME1DgGOgV3onXa7RqzLjFydtPeXwCABhA7YEIQEGL37Tjd971pqb07xv4ypse2GctQyYyoX+7 ZCaTebwRGIABqKsSCSxgw3rEoUgmOiNgcot/K2isBMI8HSd31MyjdUeKiWATfkXwGm4whYHW/F4y /3lmzgN6hp73zDneButOQKaDAojRAwrgcw1iyydxIVlPRUuLzD7ogKMpEOoDWLTSN8whej5c5Wr3 zj/EmDIwOEtq9Jp6MmquxmsjtAJ2Ia+kKxiH0WrNPM00oGi4npque8zr0PmaDlb6YHkAICz7/FQG LUKUHJeNSwpEwNlRlrCkj8lUB1z1FxXddv/GFeEPj7nMZg5gfk9ttMvE28UtjlcWwBQwbvCkGk4w CglATtf9jqG//9YHv0e4Sl4EgAHE7qQbDAWtBDP4oIplOAai/O3psERcumSZAUwQ6pXUMIh7g7J0 oV7xEHs8kTEna84OaEB1RyjP+dqM47rRgAvmOP979q4pn/mbV5sDGudguU4sGLJKtYxwLSH8R8Ij woIYGP1zj440DrJarq7yb5wPx2oxqt5ZCEiXAtLh+Aa5bkQ0O+WKFjBAAdNttJ2BQ4EocIE4kLeq W7vdrvjGq5/nzoPwjQ8gKOhPf+LyoQB8gAWMEPAKkkwJojuHBi6YwA1owCUA0MDoz350Ykzg4Jdl NIhYD7UxXbZRUJEXyt5mUsczL9bNhzxC/VGihFoLDhnEGwE2qKaubFBnBHpde67vs49tAA/rlCfQ dnCLAgAQACGBdAQwbUJABhYi+JIqBKaAARRgCjKh+RzuF5juGMiL+npn8h4NB9YDozDQq0AFDC7/ ULpcBvM8zhnaTs867xkMQFeegf2KICks4ORksJPYr/3ozx2Gzf7iDvY+SRE+gP9wTk++oh9IJ4VC gB+WjAEr4AZcYAQmQAUGb+GQjgI8jOmUCekWDwS7z/EokMwwAMq20OpELAy1CqzCLwwgKQcHh+xk gIB24hk+QInmZSaSgt0gYCdOjvW4AO5oTu7YwJzUIggbAMBEiEOArQFkYACXjAZgYARYSwUekfmo cPKGgczQ0AfMMAOf7PmAIQdGbROFKFTIa2bGKw2bgQLqDddWsKQC4DKOIlYQx4BKQRvYj97YS0L4 sJrWggf/0AffwJwcoTwM8RC7QgE+AIE45qAS/+UG7KICUmAEVIABjM4MXSYTNRHK8oajqvDbEI9z uA8CRpEZxC2sBGAAVs/eNmkN3mQd1yCCkoCR+uUQSKBoqgmfTs4deeDFWA8AAqAQfFEMao4XPCWU CnEIjfEOes5Q6OhjZgguWACh5KL5whBmSiwbxRFvQtD5DCAxOGs2LjAjQxAVp0IAoowNxckUSAAe kcAAVPK0/DGFfmolNSceVZIlV0AlE2AVWVHY2AL8Xs/HykP23qAYE9IOFMBTFMAulvBYiIECUmMH CK8U+0YU+QYMMGADvxACREwMC2AkSTImOsARdpGlZEqATKp9xESRVsqtYmoX/7EBGA2M9K08BP/i FDbkKL2ioDqEBZSLKZNqB2zv9t5HKhcOMjaRDMOgCiUMFJtEDMzwqy4yLJfBDFagJvnQ3t4qMzmz mkLJBhwDMvoLMDxFIIRQL7dGLjyGBlhzB7jiDgIQALlGBkJzKiLzkNBAunJgGIDS2cprZigTMV2S m9iKM43zONcLHMbJEMBQNLsnK8+I2BKi/+qgoKzTLbAzO7OTBtxCDlizLtQGLlgKANpncj5gBW7v 9gJSDLjPIkOlCn/JGGpmvOgzOCEjAlIIKhsHrfizP/3zPwE0QAU0QHvgA7rAPmqTLrFSupIjLbBj hLQzQrEzwSQBIlOqfVBgctDz9p6SGPqAnIT/yrjQ4qIYDj5IbDKfTQPB0j6LqAMg4IxCASrTc0Zp tEZt9EZxNEdv1CXdQC3kEz46yPk8tEETgd56oDwlZ0Y79ENBdHWACrBEVCfL6Zr8YC6f5BSZoSIt kkXRqwp96tDANEzFdEzJlMAQ4aKMwQTvjz2hbPKGNIVEdKigVCX3qZzEokPxtEPHZU/31H/Cjyq5 1MzCkEG/tEwN9VARtcCGI7zUdE3HIBzdtFPIqSDyNE/59FIfbKs09WXMq1NPlGYCNVSDJyQpr1JN 9VRRNVVVNVVLsBwFsnuUoRSvDlP7NFM3lVM7VWY+lcTosz7rU1SBNQ3b81aJtViN9ViR9VjdiBOA OogeRixXX2JXTbFXqTVYrfVa4YNatXVbubVbvfVbvdXZwqpZsbVczfVc0TU4yTVd2bVd3fVdgxJe 5XVe6dVcq6IF8DVf9XVf+bVf/fVfATZgBXZgCbZgDfZgETZhFXZhGXZhTwACQJNWJXZiKbZiLfZi MTZjNXZjObZjPfZjQTZkxYUCggAAIfkEBQoAPwAstQA+AEgAIgAABv/An3DYKxaHSKOyhxQuj83n 0illNolMkfYHvUatXmp4PO4SRZ7SYV3yiKy9dGlOb8+Y8Trdjf/J9XMeAHmAbW9JImpri2t3XB6M kQd3cZKLlD+KljkfAJqSJYdciYw5jKFFkGs5OBynqZaXTJo5tbYSQpocrYwecKoHHA0/Da5rvpVr CUIki5wAwBINJMYHJbOLw1cymiTMzk6ZizZDCc4o0IsGFEKLHD/pawbkJKYHObnqFPv7Qp6Ly35Q cOdEBDghMn7YewYMh4c0i3D5iYhO4SIIPT7pOTFIk0OIygoSDKcox4B4lkwMieZPk4SMsQ7gQAEz lsRR7gIA4CLuHgX/lLUiDkEpseYBA0ZNSFi6dNm/NRzsHcAVsAepexB2WnVmAGWCBlIloHgkNN89 Az0PaGvy9AAJsIsGgEl2wANPYConrpFgQAKjN3RxoSHIbRXaK0YN9F2EagiEUyDXCNQ7dWc1ZMCs RVpWmLGeN5oMJJTqa8gHvzZ5wGPZY8BfupIkdt7UKTQAFCZeI6EWiYM3JywBfLiM0hmHZQE/9YYX uoflRXavTCPxVsjhHx8aaB9KbDt27eDXNglPHgn48dp/IwkwRDyZ9/DjWx/CXr79+/jzl1GSxEj/ uV3wR0WA/unXxEMPHWIVgjMQ8cMMf5QwA2BoPNQgEwjy0QOECYKR/x82x+Bh0DFjWaUcG44ocs1W shj1gYEkMULJiAeYoFNalrwBzAcbMoIDizUGZCCIi7xBo0oAzODMV7yFqOQaGH2CD403DYljXUDm 1c0PNnQplRaL4EDjIh886RaMMUYy4SI20ogPEjhc1FMOEaxiDwSq5KCelSVVY2abI/kTTU1BTYVa Doq8gyZPidYjCaBQ3UjWXihktgYJA0VSJZ9Q/YAaI22WdGMRoT0YSQ7kKCckjCAqmhuoq0FnhJl6 AtlpcWcu2qoQFEhVoxCPMfYQIzd9gosMZt5Dgof6tVrfp78KAe1ywDHy25h56drTOzt5yuZu1ayC Czlc0EpuWhKwsy2oEAOcZ5675pFgQAK/nfsDCm95156+6wrRpb0/JNBlEwkRMwTABw9M37/2BQEA Ow== --Java.DDXYC.224234335241099726-- From owner-ccamp@ops.ietf.org Mon Mar 21 08:18:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02552 for ; Mon, 21 Mar 2005 08:18:25 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDMse-0007Mc-Vd for ccamp-archive@ietf.org; Mon, 21 Mar 2005 08:23:41 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDMdh-0006FC-29 for ccamp-data@psg.com; Mon, 21 Mar 2005 13:08:13 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDMdf-0006Eg-10 for ccamp@ops.ietf.org; Mon, 21 Mar 2005 13:08:11 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Mar 2005 05:08:11 -0800 X-IronPort-AV: i="3.91,106,1110182400"; d="scan'208"; a="238178910:sNHT43401396" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2LD87gE020239 for ; Mon, 21 Mar 2005 05:08:07 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-1-143.cisco.com [10.86.240.143]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA20890 for ; Mon, 21 Mar 2005 05:08:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) To: ccamp@ops.ietf.org Message-Id: <6f124df9bedb7c3dcd8aa6ba517b07ee@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-25--40678782 From: JP Vasseur Subject: Fwd: Opinion on two new WG drafts (CORRECTION) Date: Mon, 21 Mar 2005 08:08:27 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c --Apple-Mail-25--40678782 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I just had a brief discussion with Adrian. As requested per Kireeti I will add the following sentence to draft-vasseur-ccamp-inter-domain-pd-path-comp: "In the context of this draft, the node in charge of any ERO expansion within its domain is always along the inter-domain TE LSP path". Then the question for the WG should read: Is the WG in favor of adopting draft-vasseur-ccamp-inter-domain-pd-path-comp as a WG document (yes/no) ? thanks. JP. Begin forwarded message: > From: "Adrian Farrel" > Date: March 18, 2005 3:04:51 PM EST > To: > Subject: Opinion on two new WG drafts > Reply-To: "Adrian Farrel" > > Our charter encourages us to work on inter-domain solutions. > There are two drafts which we should consider as working group drafts: > - draft-vasseur-ccamp-inter-domain-path-comp-00.txt > - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt > > In Minneapolis the room seemed to be in favor with two caveats: > - draft-vasseur-ccamp-inter-domain-path-comp must include a > statement clarifying that in the context of this draft, the node in > charge of any ERO expansion within its domain is always along > the inter-domain TE LSP path > - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt must wait > for draft-ayyangar-ccamp-lsp-stitching-00.txt to become a > CCAMP draft > > Assuming these requirements to be fulfilled, please say whether you > support these drafts becoming CCAMP drafts. A simple yes/no is enough, > but > reasons against are useful. > > Thanks, > Adrian > --Apple-Mail-25--40678782 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit I just had a brief discussion with Adrian. As requested per Kireeti I will add the following sentence to draft-vasseur-ccamp-inter-domain-pd-path-comp: "In the context of this draft, the node in charge of any ERO expansion within its domain is always along the inter-domain TE LSP path". Then the question for the WG should read: Is the WG in favor of adopting draft-vasseur-ccamp-inter-domain-pd-path-comp as a WG document (yes/no) ? thanks. JP. Begin forwarded message: Helvetica0000,0000,0000From: Helvetica"Adrian Farrel" < 0000,0000,0000Date: March 18, 2005 3:04:51 PM EST 0000,0000,0000To: < 0000,0000,0000Subject: Opinion on two new WG drafts 0000,0000,0000Reply-To: "Adrian Farrel" < Our charter encourages us to work on inter-domain solutions. There are two drafts which we should consider as working group drafts: - draft-vasseur-ccamp-inter-domain-path-comp-00.txt - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt In Minneapolis the room seemed to be in favor with two caveats: - draft-vasseur-ccamp-inter-domain-path-comp must include a statement clarifying that in the context of this draft, the node in charge of any ERO expansion within its domain is always along the inter-domain TE LSP path - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt must wait for draft-ayyangar-ccamp-lsp-stitching-00.txt to become a CCAMP draft Assuming these requirements to be fulfilled, please say whether you support these drafts becoming CCAMP drafts. A simple yes/no is enough, but reasons against are useful. Thanks, Adrian --Apple-Mail-25--40678782-- From owner-ccamp@ops.ietf.org Mon Mar 21 15:38:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16280 for ; Mon, 21 Mar 2005 15:38:11 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDTkJ-00071W-AX for ccamp-archive@ietf.org; Mon, 21 Mar 2005 15:43:31 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDTX9-000DW0-Bp for ccamp-data@psg.com; Mon, 21 Mar 2005 20:29:55 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDTX7-000DVB-6m for ccamp@ops.ietf.org; Mon, 21 Mar 2005 20:29:53 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14891; Mon, 21 Mar 2005 15:29:50 -0500 (EST) Message-Id: <200503212029.PAA14891@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-02.txt Date: Mon, 21 Mar 2005 15:29:50 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Extensions to GMPLS RSVP Graceful Restart Author(s) : A. Satyanarayana, R. Rahman Filename : draft-ietf-ccamp-rsvp-restart-ext-02.txt Pages : 20 Date : 2005-3-21 This document describes extensions to the RSVP Graceful Restart mechanisms defined in [RFC3473]. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. These mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The presented extensions use the RSVP Hello extensions defined in [RFC3209], and extensions for state recovery on nodal faults defined in [RFC3473]. With the presented extensions the restarting node can recover all previously transmitted Path state including the ERO and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. The extensions optionally support the use of Summary Refresh, defined in [RFC2961], to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSP's. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-rsvp-restart-ext-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-21154155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-restart-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-21154155.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Mon Mar 21 18:08:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09338 for ; Mon, 21 Mar 2005 18:08:57 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDW6D-00071Y-RN for ccamp-archive@ietf.org; Mon, 21 Mar 2005 18:14:19 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDVre-000Og3-IN for ccamp-data@psg.com; Mon, 21 Mar 2005 22:59:14 +0000 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDVrY-000Ocz-Ry for ccamp@ops.ietf.org; Mon, 21 Mar 2005 22:59:09 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 0A973E0001F6; Mon, 21 Mar 2005 22:58:58 +0000 (GMT) Received: from Puppy ([212.43.203.105] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Mar 2005 22:58:54 +0000 Message-ID: <08f801c52e69$c9cd0eb0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: "'Kireeti Kompella'" , Subject: Nortel Networks Statement on IPR claimed in draft-ietf-ccamp-loose-path-reopt-00.txt Date: Mon, 21 Mar 2005 21:32:27 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_088E_01C52E5D.7A7129C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 21 Mar 2005 22:58:55.0736 (UTC) FILETIME=[8F1C2F80:01C52E69] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac This is a multi-part message in MIME format. ------=_NextPart_000_088E_01C52E5D.7A7129C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Richard and Michelle, =20 Thank you for submitting your Patent Disclosure=20 (http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-path-reop= t-00.txt)=20 with respect to IETF Internet Draft = draft-ietf-ccamp-loose-path-reopt-00.txt. =20 I would be grateful if you could clarify two points to help me = understand this discolsure further. 1. The disclosure states that: Nortel Networks U.S. Patent No. 6,560,654 entitled "Apparatus and method of maintaining timely topology data within a link state = routing network" may contain claims that may be necessary for practicing a resulting IETF Standard based on this Internet Draft. Could you provide more detail about what aspects of draft-ietf-ccamp-loose-path-reopt-00.txt you believe may be impacted = by this disclosure? =20 2. Can you clarify whether the "fair, reasonable, reciprocal, and non-discriminatory terms" referenced in the disclosure include the intention, in the event that the referenced draft becomes an Internet Standard, not to assert the patent except that some party asserts a = patent patent it owns or controls against Nortel? By way of an example of wording that covers this intention, can I = draw your attention to a completely unrelated IPR disclosure at http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure.txt =20 Thank you for any clarification you are able to offer. Please note that I am copying this email to Kireeti Kompella who = co-chairs the IETF's CCAMP working group with me. The CCAMP working = group developed the Internet-Draft in question = (draft-ietf-ccamp-loose-path-reopt-00.txt) and so I am also copying this = email to the CCAMP mailing list. Best regards, Adrian Farrel -- Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978-860944 Fax: +44 (0) 870-130-5411 adrian@olddog.co.uk ------=_NextPart_000_088E_01C52E5D.7A7129C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Richard and = Michelle,
 
Thank you=20 for submitting your Patent Disclosure
(http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-p= ath-reopt-00.txt)
with respect to IETF Internet Draft=20 draft-ietf-ccamp-loose-path-reopt-00.txt.
 
I would be = grateful if=20 you could clarify two points to help me understand this discolsure=20 further.

1. The disclosure states = that:
    =20 Nortel Networks U.S. Patent No. 6,560,654 entitled "Apparatus=20 and
   =   method of=20 maintaining timely topology data within a link state=20 routing
     network" may contain claims that may = be=20 necessary for practicing a
     resulting IETF = Standard=20 based on this Internet Draft.
  Could you provide more detail = about what=20 aspects of
  draft-ietf-ccamp-loose-path-reopt-00.txt you = believe may be=20 impacted by
  this disclosure?
 
2. Can you = clarify=20 whether the "fair, reasonable, reciprocal, and
 =20  non-discriminatory terms" referenced in the disclosure include=20 the
   intention, in the event that the referenced draft = becomes an=20 Internet
   Standard, not to assert the patent except that = some=20 party asserts a patent
   patent it owns or controls = against=20 Nortel?
   By way of an = example=20 of wording that covers this intention, can I draw
   your attention to a = completely=20 unrelated IPR disclosure at
   http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure= .txt
 
Thank you for any clarification you = are able to=20 offer.
 
Please note that I am copying this = email to=20 Kireeti Kompella who co-chairs the IETF's CCAMP working group with me. = The CCAMP=20 working group developed the Internet-Draft in question=20 (draft-ietf-ccamp-loose-path-reopt-00.txt) and so I am also copying this = email=20 to the CCAMP mailing list.
 
Best regards,
Adrian Farrel
--
Adrian Farrel
Old Dog=20 Consulting
Phone: +44 (0) 1978-860944
Fax: +44 (0) = 870-130-5411
adrian@olddog.co.uk
 
 
------=_NextPart_000_088E_01C52E5D.7A7129C0-- From owner-ccamp@ops.ietf.org Tue Mar 22 02:12:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01556 for ; Tue, 22 Mar 2005 02:12:52 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDdeY-0006tm-Fx for ccamp-archive@ietf.org; Tue, 22 Mar 2005 02:18:17 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDdS5-000A97-On for ccamp-data@psg.com; Tue, 22 Mar 2005 07:05:21 +0000 Received: from [61.144.161.55] (helo=huawei.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDdS3-000A8d-O9 for ccamp@ops.ietf.org; Tue, 22 Mar 2005 07:05:20 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IDQ00IKVRHEEX@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Tue, 22 Mar 2005 15:00:50 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IDQ00EYDRHEQB@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Tue, 22 Mar 2005 15:00:50 +0800 (CST) Received: from mohanscl0041 ([10.18.4.134]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IDQ00JG8RKJD5@szxml02-in.huawei.com> for ccamp@ops.ietf.org; Tue, 22 Mar 2005 15:02:44 +0800 (CST) Date: Tue, 22 Mar 2005 12:29:43 +0530 From: mohanss Subject: Doubts on draft-ietf-mpls-rsvp-te-p2mp-01 To: ccamp@ops.ietf.org Reply-to: mohanss@huawei.com Message-id: Organization: huawei technlogies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/alternative; boundary="Boundary_(ID_hyhY3/59Wfsg2rowyeZRVQ)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b This is a multi-part message in MIME format. --Boundary_(ID_hyhY3/59Wfsg2rowyeZRVQ) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Hi all, I have few doubts regarding the following drafts. Draft: draft-ietf-mpls-rsvp-te-p2mp-01.txt 1) In this draft what is the role of sub-group ID. What will be the value of this? I mean IP address or some other number? If it is IP address which one? 2) Any vendor is already supporting this feature? Setup of RSVP-TE P2MP LSPs? Can anyone list the vendors? 3) Which one of the following is best suitable for CSPF in P2MP? Core Based Trees, Reverse Path Forwarding and Spanning trees? If available, please send the links for the same. Thanks and Regards, -Mohan --Boundary_(ID_hyhY3/59Wfsg2rowyeZRVQ) Content-type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7BIT Doubts on draft-ietf-mpls-rsvp-te-p2mp-01

Hi all,

I have few doubts regarding the following drafts.

Draft: draft-ietf-mpls-rsvp-te-p2mp-01.txt
1) In this draft what is the role of sub-group ID. What will be the value of this? I mean IP address or some other number? If it is IP address which one?

2) Any vendor is already supporting this feature?
Setup of RSVP-TE P2MP LSPs? Can anyone list the vendors?

3) Which one of the following is best suitable for CSPF in P2MP?
Core Based Trees, Reverse Path Forwarding and Spanning trees?

If available, please send the links for the same.

Thanks and Regards,
-Mohan







--Boundary_(ID_hyhY3/59Wfsg2rowyeZRVQ)-- From owner-ccamp@ops.ietf.org Tue Mar 22 13:31:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15557 for ; Tue, 22 Mar 2005 13:31:09 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDoF6-0006oA-Qr for ccamp-archive@ietf.org; Tue, 22 Mar 2005 13:36:42 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDo0z-000Edp-29 for ccamp-data@psg.com; Tue, 22 Mar 2005 18:22:05 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDo0v-000EdZ-Lk for ccamp@ops.ietf.org; Tue, 22 Mar 2005 18:22:01 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 8A67BE0000E1; Tue, 22 Mar 2005 18:21:47 +0000 (GMT) Received: from Puppy ([212.43.203.248] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Mar 2005 18:21:46 +0000 Message-ID: <09b201c52f0c$3d1d4a90$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , References: Subject: Re: Doubts on draft-ietf-mpls-rsvp-te-p2mp-01 Date: Tue, 22 Mar 2005 18:23:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 22 Mar 2005 18:21:47.0409 (UTC) FILETIME=[02449810:01C52F0C] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Hi Mohan, The correct place for your question is really the MPLS mailing list (see http://www.ietf.org/html.charters/mpls-charter.html) Brief answers to your questions below. > Draft: draft-ietf-mpls-rsvp-te-p2mp-01.txt > 1) In this draft what is the role of sub-group ID. What will be the > value of this? I mean IP address or some other number? If it is IP > address which one? The sub-group ID allows you to distinguish different sub-trees of the same P2MP tree. this allows the signaling state to be separated and managed distinctly (for example, using separate Path messages). The ability to provide such a distinction is important when more than one Path message for the same P2MP LSP might be received by the same LSR. For more details, see the section 3.3 of the draft. Sub-Group Originator ID should be set to the TE Router ID of the transit LSR. Sub-Group ID should be chosen as unique within the context of the Sub-Group Originator ID. > 2) Any vendor is already supporting this feature? > Setup of RSVP-TE P2MP LSPs? Can anyone list the vendors? I am aware of three vendors with "early" implementations of this draft. I must let them come forward and announce their own names. > 3) Which one of the following is best suitable for CSPF in P2MP? > Core Based Trees, Reverse Path Forwarding and Spanning trees? There are many choices. Since this is traffic engineering, all algorithms are acceptable, and vendors might expect to make significant marketing through their implementation of path computation. Regards, Adrian From owner-ccamp@ops.ietf.org Tue Mar 22 13:35:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15960 for ; Tue, 22 Mar 2005 13:35:23 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDoJD-0006wZ-HJ for ccamp-archive@ietf.org; Tue, 22 Mar 2005 13:40:56 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDo5I-000FHe-MG for ccamp-data@psg.com; Tue, 22 Mar 2005 18:26:32 +0000 Received: from [66.129.224.36] (helo=sapphire.juniper.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DDo5E-000FHC-JX for ccamp@ops.ietf.org; Tue, 22 Mar 2005 18:26:28 +0000 Received: from sapphire.juniper.net (localhost [127.0.0.1]) by sapphire.juniper.net (8.12.11/8.12.3) with ESMTP id j2MIQFuU019948; Tue, 22 Mar 2005 10:26:15 -0800 (PST) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.12.11/8.12.3/Submit) with ESMTP id j2MIQEu8019940; Tue, 22 Mar 2005 10:26:14 -0800 (PST) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs Date: Tue, 22 Mar 2005 10:26:13 -0800 (PST) From: Rahul Aggarwal To: mohanss cc: ccamp@ops.ietf.org Subject: Re: Doubts on draft-ietf-mpls-rsvp-te-p2mp-01 In-Reply-To: Message-ID: <20050322101913.J14683@sapphire.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi Mohan, On Tue, 22 Mar 2005, mohanss wrote: > Hi all, > > I have few doubts regarding the following drafts. > > Draft: draft-ietf-mpls-rsvp-te-p2mp-01.txt > 1) In this draft what is the role of sub-group ID. What will be the > value of this? I mean IP address or some other number? If it is IP > address which one? > The sub-group ID is intended to distinguish different Path Messages tha are signaling sub-LSPs for the same P2MP LSP. Its value is chosen by the originator of the PathMessage and doesn't have to be an IP address. > 2) Any vendor is already supporting this feature? > Setup of RSVP-TE P2MP LSPs? Can anyone list the vendors? > I will respond offline to this. rahul > 3) Which one of the following is best suitable for CSPF in P2MP? > Core Based Trees, Reverse Path Forwarding and Spanning trees? > > If available, please send the links for the same. > > Thanks and Regards, > -Mohan > > > > > > > > From owner-ccamp@ops.ietf.org Tue Mar 22 19:29:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25955 for ; Tue, 22 Mar 2005 19:29:51 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDtqH-0004ud-5m for ccamp-archive@ietf.org; Tue, 22 Mar 2005 19:35:27 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDtd9-000EuH-Oj for ccamp-data@psg.com; Wed, 23 Mar 2005 00:21:51 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDtd6-000Eu0-Dz for ccamp@ops.ietf.org; Wed, 23 Mar 2005 00:21:48 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 6B16EE0002D4 for ; Wed, 23 Mar 2005 00:21:32 +0000 (GMT) Received: from Puppy ([212.43.203.42] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 00:21:31 +0000 Message-ID: <0c8a01c52f3e$7f9de820$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <065701c52bf8$31885830$dccb2bd4@Puppy> Subject: WG drafts - My correction Date: Wed, 23 Mar 2005 00:16:55 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 23 Mar 2005 00:21:32.0538 (UTC) FILETIME=[4401E5A0:01C52F3E] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Thanks to those of you who pointed out my mistake on and off the list. To set things straight... 1. We have already accepted draft-ayyangar-ccamp-inter-domain-rsvp-te as a WG draft and it has been published as draft-ietf-ccamp-inter-domain-rsvp-te 2. I have seen consensus for draft-ayyangar-ccamp-lsp-stitching to be published as a WG draft and the authors will submit it as draft-ietf-ccamp-lsp-stitching soon 3. The name of the third draft is draft-vasseur-ccamp-inter-domain-pd-path-comp. This is the draft that we need to consider. As JP says, he plans to add the sentence "In the context of this draft, the node in charge of any ERO expansion within its domain is always along the inter-domain TE LSP path" to this draft. Question: With the addition of this sentence, are we content to accept this draft as a WG draft? Thanks, Adrian From owner-ccamp@ops.ietf.org Tue Mar 22 19:41:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29151 for ; Tue, 22 Mar 2005 19:41:14 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDu1J-00061X-0x for ccamp-archive@ietf.org; Tue, 22 Mar 2005 19:46:50 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DDtrm-000Gsx-D7 for ccamp-data@psg.com; Wed, 23 Mar 2005 00:36:58 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDtri-000GsU-CE for ccamp@ops.ietf.org; Wed, 23 Mar 2005 00:36:54 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 22 Mar 2005 19:55:35 -0500 X-IronPort-AV: i="3.91,112,1110171600"; d="scan'208"; a="41512853:sNHT24689830" Received: from zaliwxp (che-vpn-cluster-1-84.cisco.com [10.86.240.84]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2N0ao1j011634; Tue, 22 Mar 2005 19:36:51 -0500 (EST) Message-Id: <200503230036.j2N0ao1j011634@rtp-core-1.cisco.com> From: "Zafar Ali" To: "'Adrian Farrel'" , Subject: RE: WG drafts - My correction Date: Tue, 22 Mar 2005 19:36:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUvPqHcj/FQyz7MQ8OO/bjV2G6CUQAAawkQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <0c8a01c52f3e$7f9de820$dccb2bd4@Puppy> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Tuesday, March 22, 2005 7:17 PM > To: ccamp@ops.ietf.org > Subject: WG drafts - My correction > > Thanks to those of you who pointed out my mistake on and off the list. > > To set things straight... > > 1. We have already accepted > draft-ayyangar-ccamp-inter-domain-rsvp-te as a WG draft and > it has been published as draft-ietf-ccamp-inter-domain-rsvp-te > > 2. I have seen consensus for > draft-ayyangar-ccamp-lsp-stitching to be published as a WG > draft and the authors will submit it as > draft-ietf-ccamp-lsp-stitching soon > > 3. The name of the third draft is > draft-vasseur-ccamp-inter-domain-pd-path-comp. This is the > draft that we need to consider. > > As JP says, he plans to add the sentence "In the context of > this draft, the node in charge of any ERO expansion within > its domain is always along the inter-domain TE LSP path" to > this draft. > > Question: With the addition of this sentence, are we content > to accept this draft as a WG draft? Yes, Thanks Regards... Zafar > > Thanks, > Adrian > From jef@about.com Wed Mar 23 03:51:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17779 for ; Wed, 23 Mar 2005 03:51:32 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE1fq-000657-Hq for ccamp-archive@ietf.org; Wed, 23 Mar 2005 03:57:11 -0500 Received: from gb.ja.94.4.revip.asianet.co.th ([61.90.94.4]) by mx2.foretec.com with smtp (Exim 4.24) id 1DE1aN-00034Z-Gh for ccamp-archive@ietf.org; Wed, 23 Mar 2005 03:51:33 -0500 Message-ID: <348701c52f84$916719ae$fdf6aa97@about.com> From: "Susan M. Taylor" To: ccamp-archive@ietf.org Subject: Replica watch models Date: Wed, 23 Mar 2005 08:42:59 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_4F021A60.D1F50570" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 4.5 (++++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_4F021A60.D1F50570 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_8CCE4697.7A27ADB6" ------=_NextPart_001_0001_8CCE4697.7A27ADB6 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit REPLICA WATCH MODELS Rolex, Patek Philippe, Bvlgari Cartier, Gucci, Franck Muller .. and 25 other most famous manufacturers. http://www.replica911.biz All for only $249.99! _________________________________________________________________________ To change your mail preferences, go here: http://www.signoffcorp.biz/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_8CCE4697.7A27ADB6 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit

REPLICA WATCH MODELS

Rolex, Patek Philippe, Bvlgari
Cartier, Gucci, Franck Muller

.. and 25 other most famous manufacturers.

http://www.replica911.biz

All for only $249.99!


_________________________________________________________________________
To change your mail preferences, go here
_________________________________________________________________________

------=_NextPart_001_0001_8CCE4697.7A27ADB6-- ------=_NextPart_000_0000_4F021A60.D1F50570-- From owner-ccamp@ops.ietf.org Wed Mar 23 04:36:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22318 for ; Wed, 23 Mar 2005 04:36:33 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE2NQ-0007u0-3B for ccamp-archive@ietf.org; Wed, 23 Mar 2005 04:42:13 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE28n-0009FA-4S for ccamp-data@psg.com; Wed, 23 Mar 2005 09:27:05 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE28e-0009Eh-Si for ccamp@ops.ietf.org; Wed, 23 Mar 2005 09:26:57 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 10:26:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : WG drafts - My correction Date: Wed, 23 Mar 2005 10:26:10 +0100 Message-ID: Thread-Topic: WG drafts - My correction Thread-Index: AcUvPvt+pKkACTm3QGmj+hNaAyrvMAASzGDQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 23 Mar 2005 09:26:13.0203 (UTC) FILETIME=[5B33A230:01C52F8A] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable >Question: With the addition of this sentence, are we content=20 >to accept this draft as a WG draft? yes JL >-----Message d'origine----- >De : owner-ccamp@ops.ietf.org=20 >[mailto:owner-ccamp@ops.ietf.org] De la part de Adrian Farrel >Envoy=E9 : mercredi 23 mars 2005 01:17 >=C0 : ccamp@ops.ietf.org >Objet : WG drafts - My correction > > >Thanks to those of you who pointed out my mistake on and off the list. > >To set things straight... > >1. We have already accepted=20 >draft-ayyangar-ccamp-inter-domain-rsvp-te as a WG draft and it=20 >has been published as draft-ietf-ccamp-inter-domain-rsvp-te > >2. I have seen consensus for=20 >draft-ayyangar-ccamp-lsp-stitching to be published as a WG=20 >draft and the authors will submit it as=20 >draft-ietf-ccamp-lsp-stitching soon > >3. The name of the third draft is=20 >draft-vasseur-ccamp-inter-domain-pd-path-comp. This is the=20 >draft that we need to consider. > >As JP says, he plans to add the sentence "In the context of=20 >this draft, the node in charge of any ERO expansion within its=20 >domain is always along the inter-domain TE LSP path" to this draft. > >Question: With the addition of this sentence, are we content=20 >to accept this draft as a WG draft? > >Thanks, >Adrian > > > From owner-ccamp@ops.ietf.org Wed Mar 23 04:47:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22978 for ; Wed, 23 Mar 2005 04:47:06 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE2XT-0008I6-Md for ccamp-archive@ietf.org; Wed, 23 Mar 2005 04:52:46 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE2Hx-000ADw-HA for ccamp-data@psg.com; Wed, 23 Mar 2005 09:36:33 +0000 Received: from [211.4.169.26] (helo=usjk1004.kddi.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE2Hu-000ADX-7o for ccamp@ops.ietf.org; Wed, 23 Mar 2005 09:36:30 +0000 Received: from usjk1035.kddi.com ([10.96.2.25]) by usjk1004.kddi.com with ESMTP id j2N9aSA18853; Wed, 23 Mar 2005 18:36:28 +0900 (JST) Received: from usjk1038 (localhost [127.0.0.1]) by usjk1035.kddi.com with SMTP id j2N9aSu05758; Wed, 23 Mar 2005 18:36:28 +0900 (JST) Received: from [127.0.0.1] ([133.128.75.148]) by usjk1010.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20050323093626.BQUE12322.usjk1010.kddi.com@[127.0.0.1]>; Wed, 23 Mar 2005 18:36:26 +0900 Date: Wed, 23 Mar 2005 18:36:21 +0900 From: Kenji Kumaki To: "Adrian Farrel" Subject: Re: WG drafts - My correction Cc: In-Reply-To: <0c8a01c52f3e$7f9de820$dccb2bd4@Puppy> References: <065701c52bf8$31885830$dccb2bd4@Puppy> <0c8a01c52f3e$7f9de820$dccb2bd4@Puppy> Message-Id: <20050323183615.6609.KE-KUMAKI@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.12.01 [ja] X-WAuditID: 0503231836260000108562 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit > > Question: With the addition of this sentence, are we content to accept > this draft as a WG draft? > Yes. Thanks, Kenji > Thanks, > Adrian > -- Kenji Kumaki From owner-ccamp@ops.ietf.org Wed Mar 23 05:02:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24678 for ; Wed, 23 Mar 2005 05:02:59 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE2n1-0000RP-DP for ccamp-archive@ietf.org; Wed, 23 Mar 2005 05:08:40 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE2ZY-000C1L-VV for ccamp-data@psg.com; Wed, 23 Mar 2005 09:54:44 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE2ZU-000C0j-Lu for ccamp@ops.ietf.org; Wed, 23 Mar 2005 09:54:41 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id BA729E000395; Wed, 23 Mar 2005 09:54:36 +0000 (GMT) Received: from Puppy ([212.43.203.174] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 09:54:32 +0000 Message-ID: <0cd001c52f8e$8c5465d0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: IETF-62 Proceedings Submission Date: Wed, 23 Mar 2005 09:55:59 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 23 Mar 2005 09:54:33.0442 (UTC) FILETIME=[509F8420:01C52F8E] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Content-Transfer-Encoding: 7bit Common Control and Measurement Plane WG (ccamp) Tuesday, March 8, 2005 at 0900-1130 Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen Working group status - chairs - No changes to the agenda made. - Adrian reviewed status of drafts, reviewed charter milestones. We are holding off on new charter until finish last call of 8 drafts, expect 1-2 months. - Bill summarized ADs view, should wait for re-chartering until finish last call considering expectation will be very soon for last calls. * Dimitri asked about IPR assertion on re-optimization draft - Adrian said it did not give the same terms that have been seen in some recent IPR claims. The WG has to decide what to do. - Scott Bradner said we need to be very careful. Advised there may be anti-trust issues. Best to have no IETF interaction other than to ask for clarity. Scott offered to review emails on the subject. - JP said we can take that as a way to go forward and continue technical work. ASON considerations ITU liaison - Lyndon Ong presented Wesam's slides - Thanks to the IETF for liaisons and participation of Adrian and Igor at last meetings - Crankback and the comparison of LMP and ASON discovery will be incorporated in SG15 Q14's work. - There are two liaisons from ITU to CCAMP on the way. - Routing - ITU not planning any routing exts work, looking to IETF's work. - Continuing work on ASON management. - An FTP site is available for liaison statements. * Adrian asked if ITU plans to liaise G.7713 on new text for crankback before consent? - Lyndon said a meeting is upcoming and will ask for it to be considered. * Kireeti asked if there is any problem in that the crankback draft is not an RFC yet? - Adrian - RFC is desirable, not required? - Scott Bradner - it is required to have an RFC number for final balloting. The IESG can request expedited publication. * Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU terminology, and may want to consider including it. - Adrian - can that be liaised to us? - Steve Trowbridge - Yes, we can do that. ASON Routing Evaluation * Adrian - The design team on routing has members from both ITU and IETF, although we did not do the correct process, so ITU reps are individuals, not ITU representatives. - Adrian will work with Steve to formalize the process. * Adrian - Would like to make the draft from the team on evaluation of routing protocols into a working group draft - we will take to the list to see if any objection. * Dimitri - asked if we can use formal liaison process to send this draft to ITU, does it need to be WG draft? And encourages comments now, before it goes to last call. - Adrian - we can liaise the draft and our intention to consider it as a WG draft Lexicography draft (Adrian) - Q14 indicates meeting went well, authors summarized comments and incorporated in this release. * Adrian asked if should be WG draft - Kireeti said we could do that, need to ask the list, also need to compare with G.8081 * Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC or drafts, are there definitions? - Adrian thinks there are good terms, though in multiple RFCs/drafts. - Ben - if someone is new to the IETF, they have difficulty on where to go for definitions. - Adrian - if people want to do a draft to collect definitions of all GMPLS terms (more general than just ASON as in lexi draft), then they are welcome to do it. Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi) LSP Stitching (Arthi) - Need feedback on several items. * Adrian - it would be inappropriate to move extensions to be a WG draft without first stitching draft becoming a wg draft. If no one objects, see no reason why not to be WG draft. * Dimitri - Question: the draft was to originally do signaling exts, do we need to do more on routing aspects? - Arthi - agree, however this comment would have applied to the previous merged draft. The whole point of splitting the ID was because the scope was wider and generic. In that case, it becomes necessary to include the routing aspects as well. * Dimitri - if allow stitching of end-to-end LSP with LSP segment through different switching caps, then this changes the LSP switching type along the path and thus this becomes a FA - Arthi - but end-to-end does not change. * Zafar - we need to be careful what advertising because of scalability concerns, need further consideration. - Kireeti - As Arthi said the LSP segment does not *have to* be advertised but *can be* if desired. - Arthi - You, of course, need to be careful about advertising anything as TE-links dictated by correct policies. And as far as scaling is concerned, Igor is standing right behind you and will probably say (and I agree) that LSP segments can also be bundled in which case you are no longer advertising each LSP segment as a TE-link. We are simply having the same discussion again that was on the mailing list. * Igor - thought stitching maybe more appropriate for LSP hierarchy draft, but as this already in editor's queue, will add here. * Lou - sw cap can change hop by hop just needs to match end to end of hop. - Arthi - agree, we were thinking the same. * Discussion sent to mailing list Per-domain path computation method for computing inter-domain traffic engineering (TE) LSP. (JP) Draft-vasseur-ccamp-inter-domain-path-comp-00.txt: routing and path computation aspects. * Zafar asked clarification on ccamp-pce relationship - Kireeti - this draft discusses ASBR on the path, if not then it's PCE, suggest add this to draft to clarify that this is for when computation is done by elements on the path. - JP - ok * Adrian and Kireeti asked if this should be a WG draft? Good consensus in the room to be WG draft, will take it to the list. Automesh (JP) - Agreement to rehash work a bit to put these together. - Now 2 drafts - Not a new ID, no changes. - Deployed networks using that. - No major changes planned * Igor - asked how to reflect constraints in a node for switching? - JP - we are discussing auto mesh, not node switching. - Igor - but how do we reflect node capabilities? - JP - this draft is not about node capability discovery (for this, see draft-vasseur-ccamp-te-node-cap) - Igor - how to reflect for computation any internal constraints, could do via node caps advertisement. - JP agrees, though here just doing a discovery, doesn't think related as discovering members of mesh. - Adrian - two drafts, this is not node capability that is next one by JP, cut discussion said to take it to list. Routing extensions for discovery of TE node capabilities (JL Le Roux) * Adrian - on process, authors did a group job of splitting draft and sending to OSPF and ISIS groups, chairs will follow up with those groups. * Dimitri - should for terminology call TE router? - JL - yes. - Dimitri - should the TLV be exclusive to this function? - JL - yes. * Igor - how to distinguish node capabilities? - Adrian - do by TLVs, need to do a draft to propose, this draft gives you the TLVs, then can follow-up with other drafts to describe function want to use it for, take discussion to list. * JL asked that this be adopted as a WG document. - Adrian - Take it to the list Extensions to GMPLS RSVP graceful restart (Lou Berger) * Adrian - do editorial respin, let us know, and we will take to last call * Any implementations? - Yes - two! MRN Requirements (Kohei Shiomoto) Evaluation draft (JL Le Roux) Protocol extensions (Dimitri) * Arthi - what does virtual FA have to do with MRN, isn't it general? - Dimitri - should we have a specific doc on virtual FA for wider scope? - Arthi - did you want to scope only to MRN context? - Dimitri - no, just not sure if soln doc should be split. - Arthi - could be general - so prefer a separate doc on virtual FA. * Zafar - we need to give a priority capability for TE. - Dimitri - new TLV may be needed to describe relationships of multiple interfaces * Zafar - how relates to hierarchy draft? - Dimitri - maybe should be as applicability statement, - Kireeti - should do on mailing list * Kireeti - requests to continue work, when re-charter will consider for WG drafts. Routing considerations and CSPF for inter-as (Tomohiro Otani) * JP - very useful draft. Concerned about the advertisement of DYNAMIC summarized TE resource information across domains (static capabilities are perfectly fine). Too much of aggregation renders the solution inefficient and not enough of aggregation seriously compromises the routing scalability. Furthermore, there are other confidentiality issues to sort out in the context of inter-provider. - Otani - ok, we need more on summarizing capability. * Kireeti - thinks good and hopes to be a WG draft, though for now would request for this draft to continue work, though lets finish what ccamp has now and then when re-charter will make this as a WG doc. * Otani - how to handle inter-as cspf constraints? - Kireeti - as noted before (continue work). L2LSP (Dimitri) * Adrian asked clarification, is this "single hop"? - Dimitri - multiple hops each is a LSR, will clarify this in draft * Kireeti - ADs request a framework doc and include how it relates to other SDOs, max 10 pages - Dimitri - ok GMPLS addressing (Richard Rabbat) * Adrian - as this is first version, recommend continue discussion, re-spin draft, and then review again. * Adrian asked for feedback on the topics, not the technical content initially. * Loa - BCP is a specific type of RFC, describes what we have experience with not necessarily what should be (as in this draft) * Kireeti - warns for everyone with implementations to review the draft to ensure direction taken by this draft is right one. * Lou - should we wait for re-spin or now? - Kireeti - wait for re-spin. L1VPN (Tomonori Takeda) Framework draft Applicability draft * Alex - by next IETF will decide if it should be included in ccamp or as separate WG. Control plane saturation (JL Le Roux) * Arthi - Do you think the LSRs would really want to advertise such control plane limitations ? Secondly, what implication does this have in case of inter-domain, especially inter-provider LSPs ? * Kireeti - because of time, lets do on list. Graceful shutdown (Zafar Ali) * Kireeti - will consider for wg doc after re-charter * JP - is this part of current charter - Kireeti - doesn't matter, we just can not include anymore as WG doc until re-charter. Deployment-augmented (Zafar Ali) * Arthi - This is good work. My only concern is the use of terminology. Do you actually expect to use LSP-Hierarchy extensions (say Hop3) while signaling an MPLS LSP over that FA in the MPLS domain ? - Zafar - no just TE link GMPLS interworking (Kenji) * Dimitri - why need to adv priority of LSP? - Adrian - need to ask on list. GMPLS interworking (Kohei Shiomoto) * Adrian - WG doc will be decided after re-charter - Welcome that will merge with other draft on augmented, - Suggest also look at Kenji's interworking draft to merge. Cho - ARP signal * Kireeti - request work with Dimitri on framework draft, - When decide direction and interactions with other SDO, may decide to form a design team to work on L2, - First we need a framework. From owner-ccamp@ops.ietf.org Wed Mar 23 06:12:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00774 for ; Wed, 23 Mar 2005 06:12:38 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE3sR-0002hP-KB for ccamp-archive@ietf.org; Wed, 23 Mar 2005 06:18:20 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE3ga-000K9S-61 for ccamp-data@psg.com; Wed, 23 Mar 2005 11:06:04 +0000 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE3g4-000K1n-I7 for ccamp@ops.ietf.org; Wed, 23 Mar 2005 11:05:32 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk01.marconi.com (8.12.11/8.12.11) with ESMTP id j2NB5RMV001312 for ; Wed, 23 Mar 2005 11:05:27 GMT (envelope-from Diego.Caviglia@marconi.com) Subject: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: ccamp@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 23 Mar 2005 12:05:49 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 23/03/2005 11:05:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi all, is it defined somewhere, with respect to SDH/SONET, which defect has to be consider as a failure? It seems to me that for interoperability could be useful to have a list of defect that must be considered as failure, the same applies for defect that optionally can be considered as defect. May be also a communication between restoration TNEs in order to agree on the list could be useful. Does anyone agree on that? Regards Diego PS I apologise if the list is defined somewhere but I wasn't able to find it. From owner-ccamp@ops.ietf.org Wed Mar 23 06:39:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03800 for ; Wed, 23 Mar 2005 06:39:39 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE4IZ-0003RN-1S for ccamp-archive@ietf.org; Wed, 23 Mar 2005 06:45:20 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE43y-000OUj-H8 for ccamp-data@psg.com; Wed, 23 Mar 2005 11:30:14 +0000 Received: from [80.74.96.6] (helo=mx100.qos.net.il) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DE43u-000OSh-CS for ccamp@ops.ietf.org; Wed, 23 Mar 2005 11:30:10 +0000 Received: from tlv1.axerra.com (tlv1.axerra.com [80.74.100.68]) by mx100.qos.net.il (8.12.8/8.12.8) with ESMTP id j2NBQWvc032290; Wed, 23 Mar 2005 13:26:32 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Mar 2005 13:23:15 +0200 Message-ID: From: Sasha Vainshtein To: "'Diego Caviglia'" Cc: ccamp@ops.ietf.org Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Date: Wed, 23 Mar 2005 13:23:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Diego and all, IMHO it is reasonable to assume that a failure is a defect that results in sending downstream AIS (and upstream RDI) as consequent action(s). For SDH consecutive actions for each defect are specified in ITU-T G.783. Note also that for some defects the consecutive action can be disabled by configuration. Hence I'd say that the same defect can be a failure in one case and not a failure in another case. The typical example is Trail Identifier Mismatch (TIM). Hopefully this note will help. Regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7569993 (office) fax: +972-3-6487779 mobile: +972-52-8674833 > -----Original Message----- > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > Sent: Wednesday, March 23, 2005 1:06 PM > To: ccamp@ops.ietf.org > Subject: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > > Hi all, > is it defined somewhere, with respect to > SDH/SONET, which > defect has to be consider as a failure? > > It seems to me that for interoperability could be useful to > have a list of > defect that must be considered as failure, the same applies > for defect that > optionally can be considered as defect. > > May be also a communication between restoration TNEs in order > to agree on > the list could be useful. > > Does anyone agree on that? > > Regards > > Diego > > PS I apologise if the list is defined somewhere but I wasn't > able to find > it. > > > > From owner-ccamp@ops.ietf.org Wed Mar 23 08:46:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14669 for ; Wed, 23 Mar 2005 08:46:03 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE6Gt-0006S4-Qw for ccamp-archive@ietf.org; Wed, 23 Mar 2005 08:51:45 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE62R-000EZu-1K for ccamp-data@psg.com; Wed, 23 Mar 2005 13:36:47 +0000 Received: from [128.87.251.113] (helo=smtpoutuk02.marconi.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE62O-000EZW-Nf for ccamp@ops.ietf.org; Wed, 23 Mar 2005 13:36:45 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id j2NDac6Y007084 for ; Wed, 23 Mar 2005 13:36:38 GMT (envelope-from Diego.Caviglia@marconi.com) Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n To: "Sasha Vainshtein Cc: "ccamp" X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 23 Mar 2005 14:36:59 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 23/03/2005 13:36:37 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.4 (++) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Hi Sasha, I agree with you but in any case for interop issues and for sake of clarity I'd like to have that written in some IETF document. Regards Diego Sasha Vainshtein on 23/03/2005 12.23.12 To: "'Diego Caviglia'" cc: ccamp@ops.ietf.org Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Diego and all, IMHO it is reasonable to assume that a failure is a defect that results in sending downstream AIS (and upstream RDI) as consequent action(s). For SDH consecutive actions for each defect are specified in ITU-T G.783. Note also that for some defects the consecutive action can be disabled by configuration. Hence I'd say that the same defect can be a failure in one case and not a failure in another case. The typical example is Trail Identifier Mismatch (TIM). Hopefully this note will help. Regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7569993 (office) fax: +972-3-6487779 mobile: +972-52-8674833 > -----Original Message----- > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > Sent: Wednesday, March 23, 2005 1:06 PM > To: ccamp@ops.ietf.org > Subject: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > > Hi all, > is it defined somewhere, with respect to > SDH/SONET, which > defect has to be consider as a failure? > > It seems to me that for interoperability could be useful to > have a list of > defect that must be considered as failure, the same applies > for defect that > optionally can be considered as defect. > > May be also a communication between restoration TNEs in order > to agree on > the list could be useful. > > Does anyone agree on that? > > Regards > > Diego > > PS I apologise if the list is defined somewhere but I wasn't > able to find > it. > > > > From owner-ccamp@ops.ietf.org Wed Mar 23 08:58:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15789 for ; Wed, 23 Mar 2005 08:58:57 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE6TO-0006mp-S4 for ccamp-archive@ietf.org; Wed, 23 Mar 2005 09:04:39 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE6Go-000GYl-FD for ccamp-data@psg.com; Wed, 23 Mar 2005 13:51:38 +0000 Received: from [80.74.96.6] (helo=mx100.qos.net.il) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DE6GU-000GVh-I6 for ccamp@ops.ietf.org; Wed, 23 Mar 2005 13:51:19 +0000 Received: from tlv1.axerra.com (tlv1.axerra.com [80.74.100.68]) by mx100.qos.net.il (8.12.8/8.12.8) with ESMTP id j2NDlnvc003024; Wed, 23 Mar 2005 15:47:49 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Mar 2005 15:44:32 +0200 Message-ID: From: Sasha Vainshtein To: "'Diego Caviglia'" Cc: ccamp Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Date: Wed, 23 Mar 2005 15:44:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Diego, I do not see any technical problems with placing such a definition in an Internet-Draft. But there may be problems associated with the IETF process: 1. Do you want to pursue this activity in the CCAMP WG? I am not sure this is really in the scope as defined by the CCAMP Charter 2. For interoperability the IETF document should be a Standards Track RFC. On the other hand, CCAMP is in the Routing Area meaning that you need an implementation to publish a Standards Track RFC - but what could be considered as an implementation in this case? Regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7569993 (office) fax: +972-3-6487779 mobile: +972-52-8674833 > -----Original Message----- > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > Sent: Wednesday, March 23, 2005 3:37 PM > To: Sasha Vainshtein > Cc: ccamp > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoratio n > > > > Hi Sasha, > I agree with you but in any case for > interop issues > and for sake of clarity I'd like to have that written in some IETF > document. > > Regards > > Diego > > > > > > Sasha Vainshtein on 23/03/2005 12.23.12 > > To: "'Diego Caviglia'" > cc: ccamp@ops.ietf.org > > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoratio n > > > Diego and all, > IMHO it is reasonable to assume that a failure is > a defect that results in sending downstream AIS > (and upstream RDI) as consequent action(s). > > For SDH consecutive actions for each defect > are specified in ITU-T G.783. > > Note also that for some defects the consecutive action > can be disabled by configuration. Hence I'd say that > the same defect can be a failure in one case and > not a failure in another case. The typical example > is Trail Identifier Mismatch (TIM). > > Hopefully this note will help. > > Regards, > Sasha Vainshtein > email: sasha@axerra.com > > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833 > > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Wednesday, March 23, 2005 1:06 PM > > To: ccamp@ops.ietf.org > > Subject: Failure definition w.r.t. SONET/SDH and > > Protection/Restoration > > > > > > Hi all, > > is it defined somewhere, with respect to > > SDH/SONET, which > > defect has to be consider as a failure? > > > > It seems to me that for interoperability could be useful to > > have a list of > > defect that must be considered as failure, the same applies > > for defect that > > optionally can be considered as defect. > > > > May be also a communication between restoration TNEs in order > > to agree on > > the list could be useful. > > > > Does anyone agree on that? > > > > Regards > > > > Diego > > > > PS I apologise if the list is defined somewhere but I wasn't > > able to find > > it. > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Wed Mar 23 09:08:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16709 for ; Wed, 23 Mar 2005 09:08:11 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE6cJ-00073U-TJ for ccamp-archive@ietf.org; Wed, 23 Mar 2005 09:13:53 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE6QP-000IA4-RL for ccamp-data@psg.com; Wed, 23 Mar 2005 14:01:33 +0000 Received: from [128.87.251.113] (helo=smtpoutuk02.marconi.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE6QO-000I9k-J1 for ccamp@ops.ietf.org; Wed, 23 Mar 2005 14:01:32 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id j2NE1QWF014080 for ; Wed, 23 Mar 2005 14:01:26 GMT (envelope-from Diego.Caviglia@marconi.com) Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n To: "Sasha Vainshtein Cc: "ccamp X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 23 Mar 2005 15:01:48 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 23/03/2005 14:01:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 3.4 (+++) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f May be Adrian can put come light on the question you raised. Regards Diego Sasha Vainshtein on 23/03/2005 14.44.23 To: "'Diego Caviglia'" cc: ccamp Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Diego, I do not see any technical problems with placing such a definition in an Internet-Draft. But there may be problems associated with the IETF process: 1. Do you want to pursue this activity in the CCAMP WG? I am not sure this is really in the scope as defined by the CCAMP Charter 2. For interoperability the IETF document should be a Standards Track RFC. On the other hand, CCAMP is in the Routing Area meaning that you need an implementation to publish a Standards Track RFC - but what could be considered as an implementation in this case? Regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7569993 (office) fax: +972-3-6487779 mobile: +972-52-8674833 > -----Original Message----- > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > Sent: Wednesday, March 23, 2005 3:37 PM > To: Sasha Vainshtein > Cc: ccamp > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoratio n > > > > Hi Sasha, > I agree with you but in any case for > interop issues > and for sake of clarity I'd like to have that written in some IETF > document. > > Regards > > Diego > > > > > > Sasha Vainshtein on 23/03/2005 12.23.12 > > To: "'Diego Caviglia'" > cc: ccamp@ops.ietf.org > > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoratio n > > > Diego and all, > IMHO it is reasonable to assume that a failure is > a defect that results in sending downstream AIS > (and upstream RDI) as consequent action(s). > > For SDH consecutive actions for each defect > are specified in ITU-T G.783. > > Note also that for some defects the consecutive action > can be disabled by configuration. Hence I'd say that > the same defect can be a failure in one case and > not a failure in another case. The typical example > is Trail Identifier Mismatch (TIM). > > Hopefully this note will help. > > Regards, > Sasha Vainshtein > email: sasha@axerra.com > > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833 > > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Wednesday, March 23, 2005 1:06 PM > > To: ccamp@ops.ietf.org > > Subject: Failure definition w.r.t. SONET/SDH and > > Protection/Restoration > > > > > > Hi all, > > is it defined somewhere, with respect to > > SDH/SONET, which > > defect has to be consider as a failure? > > > > It seems to me that for interoperability could be useful to > > have a list of > > defect that must be considered as failure, the same applies > > for defect that > > optionally can be considered as defect. > > > > May be also a communication between restoration TNEs in order > > to agree on > > the list could be useful. > > > > Does anyone agree on that? > > > > Regards > > > > Diego > > > > PS I apologise if the list is defined somewhere but I wasn't > > able to find > > it. > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Wed Mar 23 10:41:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27147 for ; Wed, 23 Mar 2005 10:41:38 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE84m-0001BO-VU for ccamp-archive@ietf.org; Wed, 23 Mar 2005 10:47:21 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE7lm-0002kz-QT for ccamp-data@psg.com; Wed, 23 Mar 2005 15:27:42 +0000 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE7lj-0002kj-Kh for ccamp@ops.ietf.org; Wed, 23 Mar 2005 15:27:39 +0000 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j2NFRVlO007300; Wed, 23 Mar 2005 09:27:32 -0600 (CST) Received: from lucent.com (sjtrowbridge.lra.lucent.com [192.11.147.228]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j2NFRUB14499; Wed, 23 Mar 2005 09:27:31 -0600 (CST) Message-ID: <42418AB7.5070807@lucent.com> Date: Wed, 23 Mar 2005 08:26:47 -0700 From: Stephen J Trowbridge Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en,zh MIME-Version: 1.0 To: Sasha Vainshtein CC: "'Diego Caviglia'" , ccamp Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n References: Content-Type: text/plain; charset=ISO-8859-8 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Sasha and Diego, IMHO, it is a very bad idea to have two "normative" places where something is standardized. You already have the SDH standards in ITU-T documents (G.707, G.783, etc.) and the SONET standards in ATIS OPTXS (formerly T1X1) documents (mostly the T1.105 series). There is no reason that standards track RFCs cannot make normative references to these documents where needed. It would be inappropriate for IETF to attempt to replicate these documents as RFCs. Regards, Steve On 3/23/2005 6:44 AM, Sasha Vainshtein wrote: > Diego, > I do not see any technical problems with placing such > a definition in an Internet-Draft. > > But there may be problems associated with the IETF process: > > 1. Do you want to pursue this activity in the CCAMP WG? > I am not sure this is really in the scope as defined > by the CCAMP Charter > > 2. For interoperability the IETF document should be > a Standards Track RFC. On the other hand, CCAMP is in > the Routing Area meaning that you need an implementation > to publish a Standards Track RFC - but what could be > considered as an implementation in this case? > > Regards, > Sasha Vainshtein > email: sasha@axerra.com > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833 > > > >>-----Original Message----- >>From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] >>Sent: Wednesday, March 23, 2005 3:37 PM >>To: Sasha Vainshtein >>Cc: ccamp >>Subject: RE: Failure definition w.r.t. SONET/SDH and >>Protection/Restoratio n >> >> >> >>Hi Sasha, >> I agree with you but in any case for >>interop issues >>and for sake of clarity I'd like to have that written in some IETF >>document. >> >>Regards >> >>Diego >> >> >> >> >> >>Sasha Vainshtein on 23/03/2005 12.23.12 >> >>To: "'Diego Caviglia'" >>cc: ccamp@ops.ietf.org >> >>Subject: RE: Failure definition w.r.t. SONET/SDH and >> Protection/Restoratio n >> >> >>Diego and all, >>IMHO it is reasonable to assume that a failure is >>a defect that results in sending downstream AIS >>(and upstream RDI) as consequent action(s). >> >>For SDH consecutive actions for each defect >>are specified in ITU-T G.783. >> >>Note also that for some defects the consecutive action >>can be disabled by configuration. Hence I'd say that >>the same defect can be a failure in one case and >>not a failure in another case. The typical example >>is Trail Identifier Mismatch (TIM). >> >>Hopefully this note will help. >> >>Regards, >> Sasha Vainshtein >>email: sasha@axerra.com >> >>phone: +972-3-7569993 (office) >>fax: +972-3-6487779 >>mobile: +972-52-8674833 >> >> >> >>>-----Original Message----- >>>From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] >>>Sent: Wednesday, March 23, 2005 1:06 PM >>>To: ccamp@ops.ietf.org >>>Subject: Failure definition w.r.t. SONET/SDH and >>>Protection/Restoration >>> >>> >>>Hi all, >>> is it defined somewhere, with respect to >>>SDH/SONET, which >>>defect has to be consider as a failure? >>> >>>It seems to me that for interoperability could be useful to >>>have a list of >>>defect that must be considered as failure, the same applies >>>for defect that >>>optionally can be considered as defect. >>> >>>May be also a communication between restoration TNEs in order >>>to agree on >>>the list could be useful. >>> >>>Does anyone agree on that? >>> >>>Regards >>> >>>Diego >>> >>>PS I apologise if the list is defined somewhere but I wasn't >>>able to find >>>it. >>> >>> >>> >>> >> >> >> >> >> >> > From owner-ccamp@ops.ietf.org Wed Mar 23 10:45:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27613 for ; Wed, 23 Mar 2005 10:45:48 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE88m-0001JR-Tj for ccamp-archive@ietf.org; Wed, 23 Mar 2005 10:51:31 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE7vf-0003hV-Vw for ccamp-data@psg.com; Wed, 23 Mar 2005 15:37:55 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE7vX-0003fY-DK for ccamp@ops.ietf.org; Wed, 23 Mar 2005 15:37:47 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j2NFbc9B022640; Wed, 23 Mar 2005 16:37:40 +0100 To: "Adrian Farrel" Cc: MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: WG drafts - My correction Date: Wed, 23 Mar 2005 16:37:37 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 03/23/2005 16:37:40 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_BASE64_TEXT,MIME_HTML_ONLY, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 5.1 (+++++) X-Spam-Flag: YES X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: base64 PFA+aGkgYWRyaWFuIC0gdHdvIHBvaW50cyBoZXJlIGJlbG93IDxCUj48QlI+PEZPTlQgU0laRT0y PjxCPiZxdW90O0FkcmlhbiBGYXJyZWwmcXVvdDsgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7 PC9CPjwvRk9OVD48QlI+PEZPTlQgU0laRT0yPlNlbnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRm Lm9yZzwvRk9OVD48QlI+PEZPTlQgU0laRT0yPjAzLzIzLzIwMDUgMDA6MTYgR01UPC9GT05UPjxC Uj48Rk9OVCBTSVpFPTI+UGxlYXNlIHJlc3BvbmQgdG8gJnF1b3Q7QWRyaWFuIEZhcnJlbCZxdW90 OzwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+Jmx0 O2NjYW1wQG9wcy5pZXRmLm9yZyZndDs8L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+Y2M6PC9GT05U PiA8QlI+IDxGT05UIFNJWkU9Mj5iY2M6PC9GT05UPiA8QlI+IDxGT05UIFNJWkU9Mj5TdWJqZWN0 OjwvRk9OVD4gPEZPTlQgU0laRT0yPldHIGRyYWZ0cyAtIE15IGNvcnJlY3Rpb248L0ZPTlQ+PEJS PiA8QlI+PEJSPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+VGhhbmtzIHRv IHRob3NlIG9mIHlvdSB3aG8gcG9pbnRlZCBvdXQgbXkgbWlzdGFrZSBvbiBhbmQgb2ZmIHRoZSBs aXN0LjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5UbyBzZXQg dGhpbmdzIHN0cmFpZ2h0Li4uPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENv dXJpZXIiPjEuIFdlIGhhdmUgYWxyZWFkeSBhY2NlcHRlZCBkcmFmdC1heXlhbmdhci1jY2FtcC1p bnRlci1kb21haW4tcnN2cC10ZSBhcyBhPEJSPldHIGRyYWZ0IGFuZCBpdCBoYXMgYmVlbiBwdWJs aXNoZWQgYXM8QlI+ZHJhZnQtaWV0Zi1jY2FtcC1pbnRlci1kb21haW4tcnN2cC10ZTxCUj48L0ZP TlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4yLiBJIGhhdmUgc2VlbiBjb25z ZW5zdXMgZm9yIGRyYWZ0LWF5eWFuZ2FyLWNjYW1wLWxzcC1zdGl0Y2hpbmcgdG8gYmU8QlI+cHVi bGlzaGVkIGFzIGEgV0cgZHJhZnQgYW5kIHRoZSBhdXRob3JzIHdpbGwgc3VibWl0IGl0IGFzPEJS PmRyYWZ0LWlldGYtY2NhbXAtbHNwLXN0aXRjaGluZyBzb29uPEJSPjwvRk9OVD48L1A+PFA+PEZP TlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPi0mZ3Q7IGFncmVlZCAtIG5vdGU6IHdvdWxkIHlv dSB0ZWxsIHVzIChvciBhdXRob3JzKSB3aGVuIGNvbW1lbnRzIG1hZGUgb24gdGhpcyBsaXN0IHdv dWxkIHRoZW4gYmUgaW5jb3Jwb3JhdGVkID88L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9z cGFjZSxDb3VyaWVyIj48QlI+My4gVGhlIG5hbWUgb2YgdGhlIHRoaXJkIGRyYWZ0IGlzPEJSPmRy YWZ0LXZhc3NldXItY2NhbXAtaW50ZXItZG9tYWluLXBkLXBhdGgtY29tcC4gVGhpcyBpcyB0aGUg ZHJhZnQgdGhhdCB3ZTxCUj5uZWVkIHRvIGNvbnNpZGVyLjxCUj48QlI+QXMgSlAgc2F5cywgaGUg cGxhbnMgdG8gYWRkIHRoZSBzZW50ZW5jZSAmcXVvdDtJbiB0aGUgY29udGV4dCBvZiB0aGlzIGRy YWZ0LDxCUj50aGUgbm9kZSBpbiBjaGFyZ2Ugb2YgYW55IEVSTyBleHBhbnNpb24gd2l0aGluIGl0 cyBkb21haW4gaXMgYWx3YXlzIGFsb25nPEJSPnRoZSBpbnRlci1kb21haW4gVEUgTFNQIHBhdGgm cXVvdDsgdG8gdGhpcyBkcmFmdC48QlI+PC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3Bh Y2UsQ291cmllciI+LSZndDsgcmVhZGluZyB0aHJvdWdoIHRoZSBkb2N1bWVudCBhbmQgdGFraW5n IHNlY3Rpb24gNCBhcyB0aGUgY29yZSwgaSB3b25kZXIgd2h5IGV4YW1wbGVzIG9mIHRoZSBzYW1l IHNlY3Rpb24gYXJlIHByZXNjcmlwdGl2ZSA/IGlzIHRoZXJlIGJ5IG5vIG1lYW5zIGEgd2F5IHRv IHJlLXdyaXRlIHRoaXMgZG9jdW1lbnQgaW4gcHJlc2NyaXB0aXZlIG1vZGUgKHNpbmNlIGFmYWlr IHRoaXMgaXMgaW50ZW5kZWQgdG8gYmVjb21lIGEgcHJvcG9zZWQgc3RhbmRhcmQgYW5kIG5vdCBh biBpbmZvcm1hdGlvbmFsIGRvY3VtZW50KSBhbmQgb25seSBnaXZlIGV4YW1wbGVzIGluIGFwcGVu ZGl4IGFuZCBub3QgdXNlIGV4YW1wbGVzIHRvIGRlc2NyaWJlIGl0cyBjb3JlIGNvbnRlbnQgLSA8 L0ZPTlQ+PC9QPjxQPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+UXVlc3Rpb246 IFdpdGggdGhlIGFkZGl0aW9uIG9mIHRoaXMgc2VudGVuY2UsIGFyZSB3ZSBjb250ZW50IHRvIGFj Y2VwdDxCUj50aGlzIGRyYWZ0IGFzIGEgV0cgZHJhZnQ/PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFD RT0iTW9ub3NwYWNlLENvdXJpZXIiPlRoYW5rcyw8QlI+QWRyaWFuPEJSPjwvRk9OVD48L1A+ From owner-ccamp@ops.ietf.org Wed Mar 23 10:52:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28687 for ; Wed, 23 Mar 2005 10:52:42 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE8FV-0001Xo-8S for ccamp-archive@ietf.org; Wed, 23 Mar 2005 10:58:26 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE7zJ-0004BO-1p for ccamp-data@psg.com; Wed, 23 Mar 2005 15:41:41 +0000 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE7z8-0004AH-I9 for ccamp@ops.ietf.org; Wed, 23 Mar 2005 15:41:30 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk01.marconi.com (8.12.11/8.12.11) with ESMTP id j2NFfNKa027713 for ; Wed, 23 Mar 2005 15:41:23 GMT (envelope-from Diego.Caviglia@marconi.com) Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n To: "Stephen J Trowbridge Cc: "Sasha Vainshtein , "ccamp X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 23 Mar 2005 16:41:47 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 23/03/2005 15:41:22 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 3.4 (+++) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Stephen, for me is ok to have a reference to the ITU-T doc in a IETF doc. The point is that seems there is no reference to that in any IETF ID/RFC. So if your proposal is to add a reference to ITU-T in some already existing IETF draft that is ok for me. Regards Diego Stephen J Trowbridge on 23/03/2005 16.26.47 To: Sasha Vainshtein cc: "'Diego Caviglia'" , ccamp Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Sasha and Diego, IMHO, it is a very bad idea to have two "normative" places where something is standardized. You already have the SDH standards in ITU-T documents (G.707, G.783, etc.) and the SONET standards in ATIS OPTXS (formerly T1X1) documents (mostly the T1.105 series). There is no reason that standards track RFCs cannot make normative references to these documents where needed. It would be inappropriate for IETF to attempt to replicate these documents as RFCs. Regards, Steve On 3/23/2005 6:44 AM, Sasha Vainshtein wrote: > Diego, > I do not see any technical problems with placing such > a definition in an Internet-Draft. > > But there may be problems associated with the IETF process: > > 1. Do you want to pursue this activity in the CCAMP WG? > I am not sure this is really in the scope as defined > by the CCAMP Charter > > 2. For interoperability the IETF document should be > a Standards Track RFC. On the other hand, CCAMP is in > the Routing Area meaning that you need an implementation > to publish a Standards Track RFC - but what could be > considered as an implementation in this case? > > Regards, > Sasha Vainshtein > email: sasha@axerra.com > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833 > > > >>-----Original Message----- >>From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] >>Sent: Wednesday, March 23, 2005 3:37 PM >>To: Sasha Vainshtein >>Cc: ccamp >>Subject: RE: Failure definition w.r.t. SONET/SDH and >>Protection/Restoratio n >> >> >> >>Hi Sasha, >> I agree with you but in any case for >>interop issues >>and for sake of clarity I'd like to have that written in some IETF >>document. >> >>Regards >> >>Diego >> >> >> >> >> >>Sasha Vainshtein on 23/03/2005 12.23.12 >> >>To: "'Diego Caviglia'" >>cc: ccamp@ops.ietf.org >> >>Subject: RE: Failure definition w.r.t. SONET/SDH and >> Protection/Restoratio n >> >> >>Diego and all, >>IMHO it is reasonable to assume that a failure is >>a defect that results in sending downstream AIS >>(and upstream RDI) as consequent action(s). >> >>For SDH consecutive actions for each defect >>are specified in ITU-T G.783. >> >>Note also that for some defects the consecutive action >>can be disabled by configuration. Hence I'd say that >>the same defect can be a failure in one case and >>not a failure in another case. The typical example >>is Trail Identifier Mismatch (TIM). >> >>Hopefully this note will help. >> >>Regards, >> Sasha Vainshtein >>email: sasha@axerra.com >> >>phone: +972-3-7569993 (office) >>fax: +972-3-6487779 >>mobile: +972-52-8674833 >> >> >> >>>-----Original Message----- >>>From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] >>>Sent: Wednesday, March 23, 2005 1:06 PM >>>To: ccamp@ops.ietf.org >>>Subject: Failure definition w.r.t. SONET/SDH and >>>Protection/Restoration >>> >>> >>>Hi all, >>> is it defined somewhere, with respect to >>>SDH/SONET, which >>>defect has to be consider as a failure? >>> >>>It seems to me that for interoperability could be useful to >>>have a list of >>>defect that must be considered as failure, the same applies >>>for defect that >>>optionally can be considered as defect. >>> >>>May be also a communication between restoration TNEs in order >>>to agree on >>>the list could be useful. >>> >>>Does anyone agree on that? >>> >>>Regards >>> >>>Diego >>> >>>PS I apologise if the list is defined somewhere but I wasn't >>>able to find >>>it. >>> >>> >>> >>> >> >> >> >> >> >> > From owner-ccamp@ops.ietf.org Wed Mar 23 11:20:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01836 for ; Wed, 23 Mar 2005 11:20:37 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE8gX-0002K5-5s for ccamp-archive@ietf.org; Wed, 23 Mar 2005 11:26:21 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DE8Ro-0007J9-Eb for ccamp-data@psg.com; Wed, 23 Mar 2005 16:11:08 +0000 Received: from [192.128.134.71] (helo=kcmso2.proxy.att.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DE8Ri-0007HL-OO for ccamp@ops.ietf.org; Wed, 23 Mar 2005 16:11:03 +0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j2NGB0A2025577 for ; Wed, 23 Mar 2005 10:11:01 -0600 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh5i.attrh.att.com (7.2.052) id 423DAD7E0008D76D; Wed, 23 Mar 2005 11:11:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Date: Wed, 23 Mar 2005 10:10:25 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF094ACDF4@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Thread-Index: AcUvvSyGOamZm8+CQ9enJZOhhSTyBgAAgq5w From: "Brungard, Deborah A, ALABS" To: "Stephen J Trowbridge" , "Sasha Vainshtein" Cc: "Diego Caviglia" , "ccamp" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.0 (+) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: quoted-printable Not sure the context of your question Diego? ITU provides the definitions allowing interop. And CCAMP does have documents referencing - CCAMP's recovery documents (terminology, analysis, functional, signaling). CCAMP's documents were based on the approach as Steve described - terminology alignment with ITU/T1X1 (e.g. defect, failure, SF, SD) and references to the T1X1/ITU documents (T1.105, G.806, G.783, G.841/842, G.808.1). These ITU documents also include differences between SONET and SDH. If you have questions on specific defects/failures (eg TIM), suggest sending mail on the ITU's SG15 q9 exploder. Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Stephen J Trowbridge Sent: Wednesday, March 23, 2005 10:27 AM To: Sasha Vainshtein Cc: 'Diego Caviglia'; ccamp Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Sasha and Diego, IMHO, it is a very bad idea to have two "normative" places where something is standardized. You already have the SDH standards in ITU-T documents (G.707, G.783, etc.) and the SONET standards in ATIS OPTXS (formerly T1X1) documents (mostly the T1.105 series). There is no reason that standards track RFCs cannot make normative references to these documents where needed. It would be inappropriate for IETF to attempt to replicate these documents as RFCs. Regards, Steve On 3/23/2005 6:44 AM, Sasha Vainshtein wrote: > Diego, > I do not see any technical problems with placing such > a definition in an Internet-Draft. >=20 > But there may be problems associated with the IETF process: >=20 > 1. Do you want to pursue this activity in the CCAMP WG?=20 > I am not sure this is really in the scope as defined > by the CCAMP Charter >=20 > 2. For interoperability the IETF document should be > a Standards Track RFC. On the other hand, CCAMP is in > the Routing Area meaning that you need an implementation > to publish a Standards Track RFC - but what could be > considered as an implementation in this case? >=20 > Regards, > Sasha Vainshtein > email: sasha@axerra.com =20 > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833=20 >=20 >=20 >=20 >>-----Original Message----- >>From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] >>Sent: Wednesday, March 23, 2005 3:37 PM >>To: Sasha Vainshtein >>Cc: ccamp >>Subject: RE: Failure definition w.r.t. SONET/SDH and=20 >>Protection/Restoratio n >> >> >> >>Hi Sasha, >> I agree with you but in any case for=20 >>interop issues >>and for sake of clarity I'd like to have that written in some IETF >>document. >> >>Regards >> >>Diego >> >> >> >> >> >>Sasha Vainshtein on 23/03/2005 12.23.12 >> >>To: "'Diego Caviglia'" >>cc: ccamp@ops.ietf.org >> >>Subject: RE: Failure definition w.r.t. SONET/SDH and >> Protection/Restoratio n >> >> >>Diego and all, >>IMHO it is reasonable to assume that a failure is >>a defect that results in sending downstream AIS >>(and upstream RDI) as consequent action(s). >> >>For SDH consecutive actions for each defect >>are specified in ITU-T G.783. >> >>Note also that for some defects the consecutive action >>can be disabled by configuration. Hence I'd say that >>the same defect can be a failure in one case and >>not a failure in another case. The typical example >>is Trail Identifier Mismatch (TIM). >> >>Hopefully this note will help. >> >>Regards, >> Sasha Vainshtein >>email: sasha@axerra.com=20 >> >>phone: +972-3-7569993 (office) >>fax: +972-3-6487779 >>mobile: +972-52-8674833 >> >> >> >>>-----Original Message----- >>>From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] >>>Sent: Wednesday, March 23, 2005 1:06 PM >>>To: ccamp@ops.ietf.org >>>Subject: Failure definition w.r.t. SONET/SDH and >>>Protection/Restoration >>> >>> >>>Hi all, >>> is it defined somewhere, with respect to >>>SDH/SONET, which >>>defect has to be consider as a failure? >>> >>>It seems to me that for interoperability could be useful to >>>have a list of >>>defect that must be considered as failure, the same applies >>>for defect that >>>optionally can be considered as defect. >>> >>>May be also a communication between restoration TNEs in order >>>to agree on >>>the list could be useful. >>> >>>Does anyone agree on that? >>> >>>Regards >>> >>>Diego >>> >>>PS I apologise if the list is defined somewhere but I wasn't >>>able to find >>>it. >>> >>> >>> >>> >> >> >> >> >> >> >=20 From owner-ccamp@ops.ietf.org Wed Mar 23 14:59:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27043 for ; Wed, 23 Mar 2005 14:59:09 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEC61-0000md-2I for ccamp-archive@ietf.org; Wed, 23 Mar 2005 15:04:54 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEBpb-000F8J-JQ for ccamp-data@psg.com; Wed, 23 Mar 2005 19:47:55 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DEBpa-000F7u-Ib for ccamp@ops.ietf.org; Wed, 23 Mar 2005 19:47:54 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DEBpW-0001P8-Pn; Wed, 23 Mar 2005 14:47:50 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair , ccamp chair Subject: Document Action: 'Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON)' to Informational RFC Message-Id: Date: Wed, 23 Mar 2005 14:47:50 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb The IESG has approved the following document: - 'Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON) ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the routing requirements on the GMPLS suite of protocols to support the capabilities and functionalities for an Automatically Switched Optical Network (ASON) as defined by ITU-T. Working Group Summary This document is the product of a design team that included IETF and ITU members. The goal of the document was to represent routing-related requirements for ASON networks received from ITU in a liaison statement in the form understandable for a usual IETF participant. Protocol Quality This document has been reviewed for IESG by Alex Zinin. Adrian Farrel followed up with the WG on the provided comments. IANA Note This document required no specific IANA action. From owner-ccamp@ops.ietf.org Wed Mar 23 16:16:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06240 for ; Wed, 23 Mar 2005 16:16:10 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEDIZ-0003C9-FE for ccamp-archive@ietf.org; Wed, 23 Mar 2005 16:21:56 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DED3D-00033V-MO for ccamp-data@psg.com; Wed, 23 Mar 2005 21:06:03 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DED3C-00031W-Bs for ccamp@ops.ietf.org; Wed, 23 Mar 2005 21:06:02 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DED35-0000OH-UH; Wed, 23 Mar 2005 16:05:55 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair , ccamp chair Subject: Protocol Action: 'Generalized MPLS (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control' to Proposed Standard Message-Id: Date: Wed, 23 Mar 2005 16:05:55 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d The IESG has approved the following document: - 'Generalized MPLS (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control ' as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary This document is a companion to the Generalized MPLS (GMPLS) signaling documents. It describes the technology specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. Working Group Summary The WG had a consensus on advancing this document. Protocol Quality Alex Zinin reviewed this document for the IESG. There is at least one implementation of the described mechanisms. From owner-ccamp@ops.ietf.org Wed Mar 23 16:16:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06315 for ; Wed, 23 Mar 2005 16:16:19 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEDIi-0003Da-Un for ccamp-archive@ietf.org; Wed, 23 Mar 2005 16:22:05 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DED4T-0003Oe-KA for ccamp-data@psg.com; Wed, 23 Mar 2005 21:07:21 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DED4S-0003OM-KD for ccamp@ops.ietf.org; Wed, 23 Mar 2005 21:07:20 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DED4O-0000yq-2d; Wed, 23 Mar 2005 16:07:16 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair , ccamp chair Subject: Protocol Action: 'Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model' to Proposed Standard Message-Id: Date: Wed, 23 Mar 2005 16:07:16 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 The IESG has approved the following document: - 'Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model ' as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. Working Group Summary The WG had a consensus on advancing this document. Protocol Quality Dimitri Papadimitriou reviewed this document for the RTG-DIR, and Alex Zinin reviewed this document for the IESG. RFC Editor Note: Section 8. Security Considerations OLD: This draft imposes no new security risks over [RFC3473]. In fact it represents a lower trust model between the core and edge-nodes as the core is permitted to hide its topology from the edge-nodes. The core is also permitted to restrict the actions of edge-nodes by filtering out specific RSVP objects. NEW: The trust model between the core and edge-nodes is different than the one described in [RFC3473], as the core is permitted to hide its topology from the edge-nodes, and the core is permitted to restrict the actions of edge-nodes by filtering out specific RSVP objects. IANA Note: This document requires no IANA action. From owner-ccamp@ops.ietf.org Wed Mar 23 17:11:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29029 for ; Wed, 23 Mar 2005 17:11:28 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEEA7-00012P-9S for ccamp-archive@ietf.org; Wed, 23 Mar 2005 17:17:15 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEDxf-000CAX-IR for ccamp-data@psg.com; Wed, 23 Mar 2005 22:04:23 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEDxa-000C96-Jh for ccamp@ops.ietf.org; Wed, 23 Mar 2005 22:04:18 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 7BB50E000190; Wed, 23 Mar 2005 22:04:08 +0000 (GMT) Received: from Puppy ([212.43.203.246] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 22:04:06 +0000 Message-ID: <0da201c52ff4$77bb5aa0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Diego Caviglia" , Cc: References: Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Date: Wed, 23 Mar 2005 14:58:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 23 Mar 2005 22:04:07.0511 (UTC) FILETIME=[3C005E70:01C52FF4] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.7 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit Hi, My initial reaction is that this is way out of scope for CCAMP for a bunch of reasons. In particular order: - The GMPLS control plane does not necessarily want to define data plane failures. Rather, it wants to signal (report) errors and allow the control plane state (and data plane state) to remain in place. - Control plane and data plane protection actions need to be carefully separated. - Decisions that trigger control plane protection actions are fundamentally implementation choices. Maybe we should make a statement that this type of thing SHOULD be configurable so that there is some sort of consistency within a network. - Existing alarm procedures should not be impacted by the use of GMPLS. - Data plane technology is not what we do. But I'm open to discussion. Finally, to follow on Sasha's comments, such a draft would probably be informational. Cheers, Adrian ----- Original Message ----- From: "Diego Caviglia" To: "Sasha Vainshtein Cc: "ccamp Sent: Wednesday, March 23, 2005 2:01 PM Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n > > May be Adrian can put come light on the question you raised. > > Regards > > Diego > > > > Sasha Vainshtein on 23/03/2005 14.44.23 > > To: "'Diego Caviglia'" > cc: ccamp > > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoratio n > > > Diego, > I do not see any technical problems with placing such > a definition in an Internet-Draft. > > But there may be problems associated with the IETF process: > > 1. Do you want to pursue this activity in the CCAMP WG? > I am not sure this is really in the scope as defined > by the CCAMP Charter > > 2. For interoperability the IETF document should be > a Standards Track RFC. On the other hand, CCAMP is in > the Routing Area meaning that you need an implementation > to publish a Standards Track RFC - but what could be > considered as an implementation in this case? > > Regards, > Sasha Vainshtein > email: sasha@axerra.com > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833 > > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Wednesday, March 23, 2005 3:37 PM > > To: Sasha Vainshtein > > Cc: ccamp > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > Protection/Restoratio n > > > > > > > > Hi Sasha, > > I agree with you but in any case for > > interop issues > > and for sake of clarity I'd like to have that written in some IETF > > document. > > > > Regards > > > > Diego > > > > > > > > > > > > Sasha Vainshtein on 23/03/2005 12.23.12 > > > > To: "'Diego Caviglia'" > > cc: ccamp@ops.ietf.org > > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > Protection/Restoratio n > > > > > > Diego and all, > > IMHO it is reasonable to assume that a failure is > > a defect that results in sending downstream AIS > > (and upstream RDI) as consequent action(s). > > > > For SDH consecutive actions for each defect > > are specified in ITU-T G.783. > > > > Note also that for some defects the consecutive action > > can be disabled by configuration. Hence I'd say that > > the same defect can be a failure in one case and > > not a failure in another case. The typical example > > is Trail Identifier Mismatch (TIM). > > > > Hopefully this note will help. > > > > Regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > > > phone: +972-3-7569993 (office) > > fax: +972-3-6487779 > > mobile: +972-52-8674833 > > > > > > > -----Original Message----- > > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > > Sent: Wednesday, March 23, 2005 1:06 PM > > > To: ccamp@ops.ietf.org > > > Subject: Failure definition w.r.t. SONET/SDH and > > > Protection/Restoration > > > > > > > > > Hi all, > > > is it defined somewhere, with respect to > > > SDH/SONET, which > > > defect has to be consider as a failure? > > > > > > It seems to me that for interoperability could be useful to > > > have a list of > > > defect that must be considered as failure, the same applies > > > for defect that > > > optionally can be considered as defect. > > > > > > May be also a communication between restoration TNEs in order > > > to agree on > > > the list could be useful. > > > > > > Does anyone agree on that? > > > > > > Regards > > > > > > Diego > > > > > > PS I apologise if the list is defined somewhere but I wasn't > > > able to find > > > it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Wed Mar 23 17:13:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29329 for ; Wed, 23 Mar 2005 17:13:44 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEECI-00017u-95 for ccamp-archive@ietf.org; Wed, 23 Mar 2005 17:19:31 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEE1X-000Cym-Ga for ccamp-data@psg.com; Wed, 23 Mar 2005 22:08:23 +0000 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DEE1W-000CyX-FI for ccamp@ops.ietf.org; Wed, 23 Mar 2005 22:08:22 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j2NM8J935800; Wed, 23 Mar 2005 14:08:19 -0800 (PST) (envelope-from arthi@juniper.net) Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2NM8De35266; Wed, 23 Mar 2005 14:08:13 -0800 (PST) (envelope-from arthi@juniper.net) Date: Wed, 23 Mar 2005 14:08:13 -0800 (PST) From: Arthi Ayyangar To: Dimitri.Papadimitriou@alcatel.be cc: Adrian Farrel , ccamp@ops.ietf.org Subject: Re: WG drafts - My correction In-Reply-To: Message-ID: <20050323140317.F66554@zircon.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Dimitri, > 2. I have seen consensus for draft-ayyangar-ccamp-lsp-stitching to be > published as a WG draft and the authors will submit it as > draft-ietf-ccamp-lsp-stitching soon > > -> agreed - note: would you tell us (or authors) when comments made on > this list would then be incorporated ? -------> I think the plan was to first republish as WG draft with *no* changes. Following that, we could submit another version shortly incorporating the comments made on the list. thanks, -arthi > > 3. The name of the third draft is > draft-vasseur-ccamp-inter-domain-pd-path-comp. This is the draft that we > need to consider. > > As JP says, he plans to add the sentence "In the context of this draft, > the node in charge of any ERO expansion within its domain is always along > the inter-domain TE LSP path" to this draft. > > -> reading through the document and taking section 4 as the core, i > wonder why examples of the same section are prescriptive ? is there by no > means a way to re-write this document in prescriptive mode (since afaik > this is intended to become a proposed standard and not an informational > document) and only give examples in appendix and not use examples to > describe its core content - > > > Question: With the addition of this sentence, are we content to accept > this draft as a WG draft? > > Thanks, > Adrian > > > From owner-ccamp@ops.ietf.org Thu Mar 24 03:14:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12333 for ; Thu, 24 Mar 2005 03:14:31 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DENZk-0001ju-PY for ccamp-archive@ietf.org; Thu, 24 Mar 2005 03:20:22 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DENJf-000Dfj-3v for ccamp-data@psg.com; Thu, 24 Mar 2005 08:03:43 +0000 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DENJc-000Dez-CM for ccamp@ops.ietf.org; Thu, 24 Mar 2005 08:03:40 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk01.marconi.com (8.12.11/8.12.11) with ESMTP id j2O83WAZ001328; Thu, 24 Mar 2005 08:03:32 GMT (envelope-from Diego.Caviglia@marconi.com) Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: "Adrian Farrel" Cc: ", " X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Thu, 24 Mar 2005 09:03:52 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 24/03/2005 08:03:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Hi Adrian, thanks for taking part to this discussion. Please find my comments in line. Regards Diego "Adrian Farrel" on 23/03/2005 15.58.42 Please respond to "Adrian Farrel" To: "Diego Caviglia" , cc: Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Hi, My initial reaction is that this is way out of scope for CCAMP for a bunch of reasons. In particular order: - The GMPLS control plane does not necessarily want to define data plane failures. Rather, it wants to signal (report) errors and allow the control plane state (and data plane state) to remain in place. [dc] Agreed and that was my initial point. Which kind of data plane (e.g. SDG) defects have to advertised to control plane to trigger restoration? Given that control plane is concerned in restore the data plane it should also define what is a failure. It is a fiber break or we have also to consider other defects? Of course we have. What happens if one restoration TNE consider as failure only Loss Of Light (LOS) while the other starts restoration even if there is a e.g. Loss Of Pointer? Is that acceptable? - Control plane and data plane protection actions need to be carefully separated. [dc] Agreed. - Decisions that trigger control plane protection actions are fundamentally implementation choices. [dc] Here we are. This is the point. IMHO CCAMP should provide some guidance on this. Maybe we should make a statement that this type of thing SHOULD be configurable so that there is some sort of consistency within a network. [dc] Something like "..control plane restoration mechanism SHOULD be triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1). - Existing alarm procedures should not be impacted by the use of GMPLS. [dc] Absolutely agreed - Data plane technology is not what we do. [dc] Absolutely agreed But I'm open to discussion. Finally, to follow on Sasha's comments, such a draft would probably be informational. [dc] Ok for me no problem on that. Cheers, Adrian ----- Original Message ----- From: "Diego Caviglia" To: "Sasha Vainshtein Cc: "ccamp Sent: Wednesday, March 23, 2005 2:01 PM Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n > > May be Adrian can put come light on the question you raised. > > Regards > > Diego > > > > Sasha Vainshtein on 23/03/2005 14.44.23 > > To: "'Diego Caviglia'" > cc: ccamp > > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoratio n > > > Diego, > I do not see any technical problems with placing such > a definition in an Internet-Draft. > > But there may be problems associated with the IETF process: > > 1. Do you want to pursue this activity in the CCAMP WG? > I am not sure this is really in the scope as defined > by the CCAMP Charter > > 2. For interoperability the IETF document should be > a Standards Track RFC. On the other hand, CCAMP is in > the Routing Area meaning that you need an implementation > to publish a Standards Track RFC - but what could be > considered as an implementation in this case? > > Regards, > Sasha Vainshtein > email: sasha@axerra.com > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833 > > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Wednesday, March 23, 2005 3:37 PM > > To: Sasha Vainshtein > > Cc: ccamp > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > Protection/Restoratio n > > > > > > > > Hi Sasha, > > I agree with you but in any case for > > interop issues > > and for sake of clarity I'd like to have that written in some IETF > > document. > > > > Regards > > > > Diego > > > > > > > > > > > > Sasha Vainshtein on 23/03/2005 12.23.12 > > > > To: "'Diego Caviglia'" > > cc: ccamp@ops.ietf.org > > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > Protection/Restoratio n > > > > > > Diego and all, > > IMHO it is reasonable to assume that a failure is > > a defect that results in sending downstream AIS > > (and upstream RDI) as consequent action(s). > > > > For SDH consecutive actions for each defect > > are specified in ITU-T G.783. > > > > Note also that for some defects the consecutive action > > can be disabled by configuration. Hence I'd say that > > the same defect can be a failure in one case and > > not a failure in another case. The typical example > > is Trail Identifier Mismatch (TIM). > > > > Hopefully this note will help. > > > > Regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > > > phone: +972-3-7569993 (office) > > fax: +972-3-6487779 > > mobile: +972-52-8674833 > > > > > > > -----Original Message----- > > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > > Sent: Wednesday, March 23, 2005 1:06 PM > > > To: ccamp@ops.ietf.org > > > Subject: Failure definition w.r.t. SONET/SDH and > > > Protection/Restoration > > > > > > > > > Hi all, > > > is it defined somewhere, with respect to > > > SDH/SONET, which > > > defect has to be consider as a failure? > > > > > > It seems to me that for interoperability could be useful to > > > have a list of > > > defect that must be considered as failure, the same applies > > > for defect that > > > optionally can be considered as defect. > > > > > > May be also a communication between restoration TNEs in order > > > to agree on > > > the list could be useful. > > > > > > Does anyone agree on that? > > > > > > Regards > > > > > > Diego > > > > > > PS I apologise if the list is defined somewhere but I wasn't > > > able to find > > > it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Thu Mar 24 05:21:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22873 for ; Thu, 24 Mar 2005 05:21:43 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEPYs-0005cH-Os for ccamp-archive@ietf.org; Thu, 24 Mar 2005 05:27:37 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEPKU-000Cef-GF for ccamp-data@psg.com; Thu, 24 Mar 2005 10:12:42 +0000 Received: from [63.250.163.245] (helo=huawei.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEPKM-000Cds-Kp for ccamp@ops.ietf.org; Thu, 24 Mar 2005 10:12:40 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IDU008W4P0OBA@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Thu, 24 Mar 2005 01:58:00 -0800 (PST) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IDU006GDP0HS4@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Thu, 24 Mar 2005 01:58:00 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.78.230.163]) by szxmc02-in.huawei.com (mshttpd); Thu, 24 Mar 2005 18:01:48 +0800 Date: Thu, 24 Mar 2005 18:01:48 +0800 From: Amit 70405 Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: Adrian Farrel , Diego Caviglia Cc: ", " Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Content-Transfer-Encoding: 7BIT Hi Adrian, Do you mean to say that Data plane & Control plane protection should be independant of each other?? If so, in case of MSP protection in SDH, Control plane should not have any control over the resource pool used for MSP switch. This may lead to lot of unused resource in the network. Regards, Amit. ----- Original Message ----- From: Diego Caviglia Date: Thursday, March 24, 2005 4:03 pm Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration > > Hi Adrian, > thanks for taking part to this discussion. > > Please find my comments in line. > > Regards > > Diego > > > > "Adrian Farrel" on 23/03/2005 15.58.42 > > Please respond to "Adrian Farrel" > > To: "Diego Caviglia" , > cc: > > Subject: Re: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > > Hi, > > My initial reaction is that this is way out of scope for CCAMP for > a bunch > of reasons. In particular order: > > - The GMPLS control plane does not necessarily want to define data > plane failures. Rather, it wants to signal (report) errors and allow > the control plane state (and data plane state) to remain in place. > [dc] Agreed and that was my initial point. Which kind of data > plane (e.g. > SDG) defects > have to advertised to control plane to trigger restoration? Given > thatcontrol plane is concerned in restore the data plane it should > also define > what is a failure. It is a fiber break or we have also to > consider other > defects? Of course we have. What happens if one restoration TNE > consideras failure only Loss Of Light (LOS) while the other starts > restoration even > if there is a e.g. Loss Of Pointer? Is that acceptable? > > - Control plane and data plane protection actions need to be carefully > separated. > [dc] Agreed. > > - Decisions that trigger control plane protection actions are > fundamentally implementation choices. > [dc] Here we are. This is the point. IMHO CCAMP should provide some > guidance on this. > > Maybe we should make a statement that this type > of thing SHOULD be configurable so that there is some sort of > consistency within a network. > [dc] Something like "..control plane restoration mechanism SHOULD be > triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1). > > - Existing alarm procedures should not be impacted by the use of > GMPLS.[dc] Absolutely agreed > > - Data plane technology is not what we do. > [dc] Absolutely agreed > > But I'm open to discussion. > > Finally, to follow on Sasha's comments, such a draft would > probably be > informational. > [dc] Ok for me no problem on that. > > Cheers, > Adrian > > ----- Original Message ----- > From: "Diego Caviglia" > To: "Sasha Vainshtein > Cc: "ccamp > Sent: Wednesday, March 23, 2005 2:01 PM > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > > > > > May be Adrian can put come light on the question you raised. > > > > Regards > > > > Diego > > > > > > > > Sasha Vainshtein on 23/03/2005 14.44.23 > > > > To: "'Diego Caviglia'" > > cc: ccamp > > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > Protection/Restoratio n > > > > > > Diego, > > I do not see any technical problems with placing such > > a definition in an Internet-Draft. > > > > But there may be problems associated with the IETF process: > > > > 1. Do you want to pursue this activity in the CCAMP WG? > > I am not sure this is really in the scope as defined > > by the CCAMP Charter > > > > 2. For interoperability the IETF document should be > > a Standards Track RFC. On the other hand, CCAMP is in > > the Routing Area meaning that you need an implementation > > to publish a Standards Track RFC - but what could be > > considered as an implementation in this case? > > > > Regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > > phone: +972-3-7569993 (office) > > fax: +972-3-6487779 > > mobile: +972-52-8674833 > > > > > > > -----Original Message----- > > > From: Diego Caviglia [Diego.Caviglia@marconi.com] > > > Sent: Wednesday, March 23, 2005 3:37 PM > > > To: Sasha Vainshtein > > > Cc: ccamp > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > > Protection/Restoratio n > > > > > > > > > > > > Hi Sasha, > > > I agree with you but in any case for > > > interop issues > > > and for sake of clarity I'd like to have that written in some IETF > > > document. > > > > > > Regards > > > > > > Diego > > > > > > > > > > > > > > > > > > Sasha Vainshtein on 23/03/2005 12.23.12 > > > > > > To: "'Diego Caviglia'" > > > cc: ccamp@ops.ietf.org > > > > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > > Protection/Restoratio n > > > > > > > > > Diego and all, > > > IMHO it is reasonable to assume that a failure is > > > a defect that results in sending downstream AIS > > > (and upstream RDI) as consequent action(s). > > > > > > For SDH consecutive actions for each defect > > > are specified in ITU-T G.783. > > > > > > Note also that for some defects the consecutive action > > > can be disabled by configuration. Hence I'd say that > > > the same defect can be a failure in one case and > > > not a failure in another case. The typical example > > > is Trail Identifier Mismatch (TIM). > > > > > > Hopefully this note will help. > > > > > > Regards, > > > Sasha Vainshtein > > > email: sasha@axerra.com > > > > > > phone: +972-3-7569993 (office) > > > fax: +972-3-6487779 > > > mobile: +972-52-8674833 > > > > > > > > > > -----Original Message----- > > > > From: Diego Caviglia [Diego.Caviglia@marconi.com] > > > > Sent: Wednesday, March 23, 2005 1:06 PM > > > > To: ccamp@ops.ietf.org > > > > Subject: Failure definition w.r.t. SONET/SDH and > > > > Protection/Restoration > > > > > > > > > > > > Hi all, > > > > is it defined somewhere, with respect to > > > > SDH/SONET, which > > > > defect has to be consider as a failure? > > > > > > > > It seems to me that for interoperability could be useful to > > > > have a list of > > > > defect that must be considered as failure, the same applies > > > > for defect that > > > > optionally can be considered as defect. > > > > > > > > May be also a communication between restoration TNEs in order > > > > to agree on > > > > the list could be useful. > > > > > > > > Does anyone agree on that? > > > > > > > > Regards > > > > > > > > Diego > > > > > > > > PS I apologise if the list is defined somewhere but I wasn't > > > > able to find > > > > it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Thu Mar 24 08:03:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07870 for ; Thu, 24 Mar 2005 08:03:54 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DES5o-0002Bd-LM for ccamp-archive@ietf.org; Thu, 24 Mar 2005 08:09:47 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DERr4-000FkA-Eg for ccamp-data@psg.com; Thu, 24 Mar 2005 12:54:30 +0000 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DERr0-000FiH-Gv for ccamp@ops.ietf.org; Thu, 24 Mar 2005 12:54:26 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id DCB71E0001AA; Thu, 24 Mar 2005 12:54:24 +0000 (GMT) Received: from Puppy ([212.43.203.224] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 12:54:08 +0000 Message-ID: <0e7a01c53070$cdb4b650$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Diego Caviglia" Cc: , References: Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Date: Thu, 24 Mar 2005 11:53:32 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E0E_01C53068.1A6EFAE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 24 Mar 2005 12:54:09.0793 (UTC) FILETIME=[923DEF10:01C53070] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 This is a multi-part message in MIME format. ------=_NextPart_000_0E0E_01C53068.1A6EFAE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Diego, >> - The GMPLS control plane does not necessarily want to define data >> plane failures. Rather, it wants to signal (report) errors and = allow >> the control plane state (and data plane state) to remain in place. > [dc] Agreed and that was my initial point. Which kind of data plane = (e.g. > SDG) defects have to advertised to control plane to trigger = restoration? =20 > Given that control plane is concerned in restore the data plane it = should=20 > also define what is a failure. It is a fiber break or we have also to = > consider other defects? Of course we have. What happens if one > restoration TNE consider as failure only Loss Of Light (LOS) while the > other starts restoration even if there is a e.g. Loss Of Pointer? Is=20 > that acceptable? Let's look at two things. First, the trigger for protection switchover. If you look at section 6.2 = of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt (currently in = working group last call, so please comment now!) you will see... To co-ordinate the switchover between end-points, an end-to-end=20 switchover request is needed since a failure affecting one the LSPs=20 results in both end-points switching to the other LSP (resulting in=20 receiving traffic from the other LSP) in their respective=20 directions. This is done using the Notify message with a new Error=20 Code indicating "Working LSP Failure (Switchover Request)". This clearly indicates that the objective is not to report a failure, = but to request a switchover. Which takes us to your second point: which data plane errors should be = reported to the control plane to trigger switchover signaling, and would = it matter if different transport nodes applied different policies? My contention is that this is entirely an implementation issue. I think = it would be a wise implementation that included some degree of = configurability to this function, but that is not in CCAMP's scope. If = two "TNEs" have different trigger thresholds I do not see that any harm = will be done, it might even be desirable. >> - Decisions that trigger control plane protection actions are >> fundamentally implementation choices. > [dc] Here we are. This is the point. IMHO CCAMP should provide some > guidance on this. >=20 >> Maybe we should make a statement that this type >> of thing SHOULD be configurable so that there is some sort of >> consistency within a network. > [dc] Something like "..control plane restoration mechanism SHOULD be > triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1). But why? It is not enough to know that this is a difficult question for an = implementaiton to answer. Why is it not enough to say that the Data Plane should trigger control = plane recovery action when the data plane deems that there is a fault = from which it determines that recovery is required and from which it is = unable or unwilling to recover on its own? If you can show that there is a need to make a more definitive statement = then we can consider it. Cheers, Adrian ------=_NextPart_000_0E0E_01C53068.1A6EFAE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Diego,
 
>> - The GMPLS control plane = does not=20 necessarily want to define data
>>   plane failures. = Rather, it=20 wants to signal (report) errors and allow
>>   the control = plane=20 state (and data plane state) to remain in place.
> [dc] Agreed and = that=20 was my initial point.  Which kind of data plane (e.g.
> SDG)=20 defects have to advertised to control plane to trigger = restoration? =20
> Given that control plane is = concerned in=20 restore the data plane it should
> also define what is a = failure.  It is a=20 fiber break or we have also to
> consider other defects? Of = course we=20 have.  What happens if one
> restoration TNE consider as = failure=20 only Loss Of Light (LOS) while the
> other starts restoration = even if there=20 is a e.g. Loss Of Pointer?  Is
> that acceptable?
 
Let's look at two = things.
 
First, the trigger for protection = switchover. If=20 you look at section 6.2 of = draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt=20 (currently in working group last call, so please comment now!) you will=20 see...
 
   To co-ordinate the = switchover=20 between end-points, an end-to-end
   switchover request is = needed=20 since a failure affecting one the LSPs
   results in both=20 end-points switching to the other LSP (resulting in
   = receiving=20 traffic from the other LSP) in their respective
   = directions.=20 This is done using the Notify message with a new Error
   = Code=20 indicating "Working LSP Failure (Switchover Request)".
This clearly indicates that the = objective is not=20 to report a failure, but to request a switchover.
 
Which takes us to your second point: = which data=20 plane errors should be reported to the control plane to trigger = switchover=20 signaling, and would it matter if different transport nodes applied = different=20 policies?
 
My contention is that this is = entirely an=20 implementation issue. I think it would be a wise implementation that = included=20 some degree of configurability to this function, but that is not in = CCAMP's=20 scope. If two "TNEs" have different trigger thresholds I do not see that = any=20 harm will be done, it might even be desirable.
 
>> - Decisions that trigger = control plane=20 protection actions are
>>   fundamentally implementation=20 choices.
> [dc] Here we are.  This is the point.  IMHO = CCAMP=20 should provide some
> guidance on this.
>
>> =   Maybe=20 we should make a statement that this type
>>   of thing = SHOULD be=20 configurable so that there is some sort of
>>   = consistency within=20 a network.
> [dc] Something like "..control plane restoration = mechanism=20 SHOULD be
> triggered as the SNC/I defined in ITU-T G.783 (section = 12.1.1.1).
 
But why?
 
It is not enough to know that this is = a difficult=20 question for an implementaiton to answer.
 
Why is it not enough to say that the = Data Plane=20 should trigger control plane recovery action when the data plane deems = that=20 there is a fault from which it determines that recovery is required and = from=20 which it is unable or unwilling to recover on its own?
 
If you can show that there is a need to make a more definitive = statement=20 then we can consider it.

Cheers,
Adrian
------=_NextPart_000_0E0E_01C53068.1A6EFAE0-- From owner-ccamp@ops.ietf.org Thu Mar 24 08:22:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10120 for ; Thu, 24 Mar 2005 08:22:48 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DESO9-0002st-Ot for ccamp-archive@ietf.org; Thu, 24 Mar 2005 08:28:42 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DESCr-000Kcl-Ep for ccamp-data@psg.com; Thu, 24 Mar 2005 13:17:01 +0000 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DESCo-000KcO-A3 for ccamp@ops.ietf.org; Thu, 24 Mar 2005 13:16:58 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 0C158E00023A; Thu, 24 Mar 2005 12:54:07 +0000 (GMT) Received: from Puppy ([212.43.203.224] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 12:54:05 +0000 Message-ID: <0e7901c53070$cc1696b0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Amit 70405" , "Diego Caviglia" Cc: , References: Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Date: Thu, 24 Mar 2005 11:40:01 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 24 Mar 2005 12:54:06.0543 (UTC) FILETIME=[904E05F0:01C53070] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Hi Amit, > Do you mean to say that Data plane & Control plane protection should be independant of each other?? No, I mean that they MAY be independent. In particular, if you are using the control plane *and* the data plane to manage protection on the same set of resources you are bound to get in a horrible mess. Seems more reasonable that you would apply data plane protection first and then apply control plane protection at a higher level. > If so, in case of MSP protection in SDH, > Control plane should not have any control over the resource pool > used for MSP switch. > This may lead to lot of unused resource in the network. It is certain that each layer of protection that you install MAY result in unused resources. Building multiple layers of protection will, therefore, potentially build up more and more unused resources. It is the job of CCAMP to produce the tools that allow operators to build the protection schemes that they want. It's not really our business to tell them which schemes to build and when. Cheers, Adrian From owner-ccamp@ops.ietf.org Thu Mar 24 14:33:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19876 for ; Thu, 24 Mar 2005 14:33:53 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEYBJ-0006xB-Sw for ccamp-archive@ietf.org; Thu, 24 Mar 2005 14:39:51 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEXxR-0002se-Fo for ccamp-data@psg.com; Thu, 24 Mar 2005 19:25:29 +0000 Received: from [68.142.200.146] (helo=web30803.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DEXxM-0002sE-Mi for ccamp@ops.ietf.org; Thu, 24 Mar 2005 19:25:24 +0000 Received: (qmail 48787 invoked by uid 60001); 24 Mar 2005 19:25:23 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=V7lvIqRw/FDpfP5FaYLKCXfWElLRQ0sbOet4HzqpJI+t6g33BGl3o3EMg8fGsbmbc+5WYVhgUKbXgeGMCf7EJUK0kj5nWMTyLcXj9MdFybzO/BjC0rQmxuENs0jo5dhekjmot/mtX4IasdYJtxv84qYEjLh6saYMnVy+z8ea2Jo= ; Message-ID: <20050324192523.48785.qmail@web30803.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30803.mail.mud.yahoo.com via HTTP; Thu, 24 Mar 2005 11:25:23 PST Date: Thu, 24 Mar 2005 11:25:23 -0800 (PST) From: Igor Bryskin Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: Amit 70405 , Adrian Farrel , Diego Caviglia Cc: ", " In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2077387970-1111692323=:48357" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00, FORGED_YAHOO_RCVD,HTML_30_40,HTML_MESSAGE autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.0 (+) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 --0-2077387970-1111692323=:48357 Content-Type: text/plain; charset=us-ascii Hi, I agree that recovery supervised by data and control plane should be correlated in a sense that control plane shouldn’t not trigger any recovery activities before giving a chance to the data plane (of course, capable of doing so) to provide the recovery. In fact, the similar strategy could be applied as in case of a multi-layer recovery, when, say, a higher layer does not start recovery procedures immediately on the fault detection, rather, waits for some time to let the lower layer(s) do the job, and starts recovery only if the fault situation still exists after the hold off time. Igor Amit 70405 wrote: Hi Adrian, Do you mean to say that Data plane & Control plane protection should be independant of each other?? If so, in case of MSP protection in SDH, Control plane should not have any control over the resource pool used for MSP switch. This may lead to lot of unused resource in the network. Regards, Amit. ----- Original Message ----- From: Diego Caviglia Date: Thursday, March 24, 2005 4:03 pm Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration > > Hi Adrian, > thanks for taking part to this discussion. > > Please find my comments in line. > > Regards > > Diego > > > > "Adrian Farrel" on 23/03/2005 15.58.42 > > Please respond to "Adrian Farrel" > > To: "Diego Caviglia" , > cc: > > Subject: Re: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > > Hi, > > My initial reaction is that this is way out of scope for CCAMP for > a bunch > of reasons. In particular order: > > - The GMPLS control plane does not necessarily want to define data > plane failures. Rather, it wants to signal (report) errors and allow > the control plane state (and data plane state) to remain in place. > [dc] Agreed and that was my initial point. Which kind of data > plane (e.g. > SDG) defects > have to advertised to control plane to trigger restoration? Given > thatcontrol plane is concerned in restore the data plane it should > also define > what is a failure. It is a fiber break or we have also to > consider other > defects? Of course we have. What happens if one restoration TNE > consideras failure only Loss Of Light (LOS) while the other starts > restoration even > if there is a e.g. Loss Of Pointer? Is that acceptable? > > - Control plane and data plane protection actions need to be carefully > separated. > [dc] Agreed. > > - Decisions that trigger control plane protection actions are > fundamentally implementation choices. > [dc] Here we are. This is the point. IMHO CCAMP should provide some > guidance on this. > > Maybe we should make a statement that this type > of thing SHOULD be configurable so that there is some sort of > consistency within a network. > [dc] Something like "..control plane restoration mechanism SHOULD be > triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1). > > - Existing alarm procedures should not be impacted by the use of > GMPLS.[dc] Absolutely agreed > > - Data plane technology is not what we do. > [dc] Absolutely agreed > > But I'm open to discussion. > > Finally, to follow on Sasha's comments, such a draft would > probably be > informational. > [dc] Ok for me no problem on that. > > Cheers, > Adrian > > ----- Original Message ----- > From: "Diego Caviglia" > To: "Sasha Vainshtein > Cc: "ccamp > Sent: Wednesday, March 23, 2005 2:01 PM > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > > > > > May be Adrian can put come light on the question you raised. > > > > Regards > > > > Diego > > > > > > > > Sasha Vainshtein on 23/03/2005 14.44.23 > > > > To: "'Diego Caviglia'" > > cc: ccamp > > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > Protection/Restoratio n > > > > > > Diego, > > I do not see any technical problems with placing such > > a definition in an Internet-Draft. > > > > But there may be problems associated with the IETF process: > > > > 1. Do you want to pursue this activity in the CCAMP WG? > > I am not sure this is really in the scope as defined > > by the CCAMP Charter > > > > 2. For interoperability the IETF document should be > > a Standards Track RFC. On the other hand, CCAMP is in > > the Routing Area meaning that you need an implementation > > to publish a Standards Track RFC - but what could be > > considered as an implementation in this case? > > > > Regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > > phone: +972-3-7569993 (office) > > fax: +972-3-6487779 > > mobile: +972-52-8674833 > > > > > > > -----Original Message----- > > > From: Diego Caviglia [Diego.Caviglia@marconi.com] > > > Sent: Wednesday, March 23, 2005 3:37 PM > > > To: Sasha Vainshtein > > > Cc: ccamp > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > > Protection/Restoratio n > > > > > > > > > > > > Hi Sasha, > > > I agree with you but in any case for > > > interop issues > > > and for sake of clarity I'd like to have that written in some IETF > > > document. > > > > > > Regards > > > > > > Diego > > > > > > > > > > > > > > > > > > Sasha Vainshtein on 23/03/2005 12.23.12 > > > > > > To: "'Diego Caviglia'" > > > cc: ccamp@ops.ietf.org > > > > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > > Protection/Restoratio n > > > > > > > > > Diego and all, > > > IMHO it is reasonable to assume that a failure is > > > a defect that results in sending downstream AIS > > > (and upstream RDI) as consequent action(s). > > > > > > For SDH consecutive actions for each defect > > > are specified in ITU-T G.783. > > > > > > Note also that for some defects the consecutive action > > > can be disabled by configuration. Hence I'd say that > > > the same defect can be a failure in one case and > > > not a failure in another case. The typical example > > > is Trail Identifier Mismatch (TIM). > > > > > > Hopefully this note will help. > > > > > > Regards, > > > Sasha Vainshtein > > > email: sasha@axerra.com > > > > > > phone: +972-3-7569993 (office) > > > fax: +972-3-6487779 > > > mobile: +972-52-8674833 > > > > > > > > > > -----Original Message----- > > > > From: Diego Caviglia [Diego.Caviglia@marconi.com] > > > > Sent: Wednesday, March 23, 2005 1:06 PM > > > > To: ccamp@ops.ietf.org > > > > Subject: Failure definition w.r.t. SONET/SDH and > > > > Protection/Restoration > > > > > > > > > > > > Hi all, > > > > is it defined somewhere, with respect to > > > > SDH/SONET, which > > > > defect has to be consider as a failure? > > > > > > > > It seems to me that for interoperability could be useful to > > > > have a list of > > > > defect that must be considered as failure, the same applies > > > > for defect that > > > > optionally can be considered as defect. > > > > > > > > May be also a communication between restoration TNEs in order > > > > to agree on > > > > the list could be useful. > > > > > > > > Does anyone agree on that? > > > > > > > > Regards > > > > > > > > Diego > > > > > > > > PS I apologise if the list is defined somewhere but I wasn't > > > > able to find > > > > it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------- Do you Yahoo!? Yahoo! Small Business - Try our new resources site! --0-2077387970-1111692323=:48357 Content-Type: text/html; charset=us-ascii

Hi,

 

I agree that recovery supervised by data and control plane should be correlated in a sense that control plane shouldn’t not trigger any recovery activities before giving a chance to the data plane (of course, capable of doing so) to provide the recovery. In fact, the similar strategy could be applied as in case of a multi-layer recovery, when, say, a higher layer does not start recovery procedures immediately on the fault detection, rather, waits for some time to let the lower layer(s) do the job, and starts recovery  only if the fault situation still exists after the hold off time.

 

Igor

Amit 70405 <AmitG@huawei.com> wrote:

Hi Adrian,
Do you mean to say that Data plane & Control plane protection should be independant of each other??
If so, in case of MSP protection in SDH,
Control plane should not have any control over the resource pool
used for MSP switch.
This may lead to lot of unused resource in the network.
Regards,
Amit.


----- Original Message -----
From: Diego Caviglia
Date: Thursday, March 24, 2005 4:03 pm
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

>
> Hi Adrian,
> thanks for taking part to this discussion.
>
> Please find my comments in line.
>
> Regards
>
> Diego
>
>
>
> "Adrian Farrel" on 23/03/2005 15.58.42
>
> Please respond to "Adrian Farrel"
>
> To: "Diego Caviglia" ,
> cc:
>
> Subject: Re: Failure definition w.r.t. SONET/SDH and
> Protection/Restoration
>
>
> Hi,
>
> My initial reaction is that this is way out of scope for CCAMP for
> a bunch
> of reasons. In particular order:
>
> - The GMPLS control plane does not necessarily want to define data
> plane failures. Rather, it wants to signal (report) errors and allow
> the control plane state (and data plane state) to remain in place.
> [dc] Agreed and that was my initial point. Which kind of data
> plane (e.g.
> SDG) defects
> have to advertised to control plane to trigger restoration? Given
> thatcontrol plane is concerned in restore the data plane it should
> also define
> what is a failure. It is a fiber break or we have also to
> consider other
> defects? Of course we have. What happens if one restoration TNE
> consideras failure only Loss Of Light (LOS) while the other starts
> restoration even
> if there is a e.g. Loss Of Pointer? Is that acceptable?
>
> - Control plane and data plane protection actions need to be carefully
> separated.
> [dc] Agreed.
>
> - Decisions that trigger control plane protection actions are
> fundamentally implementation choices.
> [dc] Here we are. This is the point. IMHO CCAMP should provide some
> guidance on this.
>
> Maybe we should make a statement that this type
> of thing SHOULD be configurable so that there is some sort of
> consistency within a network.
> [dc] Something like "..control plane restoration mechanism SHOULD be
> triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1).
>
> - Existing alarm procedures should not be impacted by the use of
> GMPLS.[dc] Absolutely agreed
>
> - Data plane technology is not what we do.
> [dc] Absolutely agreed
>
> But I'm open to discussion.
>
> Finally, to follow on Sasha's comments, such a draft would
> probably be
> informational.
> [dc] Ok for me no problem on that.
>
> Cheers,
> Adrian
>
> ----- Original Message -----
> From: "Diego Caviglia"
> To: "Sasha Vainshtein
> Cc: "ccamp
> Sent: Wednesday, March 23, 2005 2:01 PM
> Subject: RE: Failure definition w.r.t. SONET/SDH and
> Protection/Restoration
>
>
> >
> > May be Adrian can put come light on the question you raised.
> >
> > Regards
> >
> > Diego
> >
> >
> >
> > Sasha Vainshtein on 23/03/2005 14.44.23
> >
> > To: "'Diego Caviglia'"
> > cc: ccamp
> >
> > Subject: RE: Failure definition w.r.t. SONET/SDH and
> > Protection/Restoratio n
> >
> >
> > Diego,
> > I do not see any technical problems with placing such
> > a definition in an Internet-Draft.
> >
> > But there may be problems associated with the IETF process:
> >
> > 1. Do you want to pursue this activity in the CCAMP WG?
> > I am not sure this is really in the scope as defined
> > by the CCAMP Charter
> >
> > 2. For interoperability the IETF document should be
> > a Standards Track RFC. On the other hand, CCAMP is in
> > the Routing Area meaning that you need an implementation
> > to publish a Standards Track RFC - but what could be
> > considered as an implementation in this case?
> >
> > Regards,
> > Sasha Vainshtein
> > email: sasha@axerra.com
>
> > phone: +972-3-7569993 (office)
> > fax: +972-3-6487779
> > mobile: +972-52-8674833
> >
> >
> > > -----Original Message-----
> > > From: Diego Caviglia [Diego.Caviglia@marconi.com]
> > > Sent: Wednesday, March 23, 2005 3:37 PM
> > > To: Sasha Vainshtein
> > > Cc: ccamp
> > > Subject: RE: Failure definition w.r.t. SONET/SDH and
> > > Protection/Restoratio n
> > >
> > >
> > >
> > > Hi Sasha,
> > > I agree with you but in any case for
> > > interop issues
> > > and for sake of clarity I'd like to have that written in some IETF
> > > document.
> > >
> > > Regards
> > >
> > > Diego
> > >
> > >
> > >
> > >
> > >
> > > Sasha Vainshtein on 23/03/2005 12.23.12
> > >
> > > To: "'Diego Caviglia'"
> > > cc: ccamp@ops.ietf.org
> > >
> > > Subject: RE: Failure definition w.r.t. SONET/SDH and
> > > Protection/Restoratio n
> > >
> > >
> > > Diego and all,
> > > IMHO it is reasonable to assume that a failure is
> > > a defect that results in sending downstream AIS
> > > (and upstream RDI) as consequent action(s).
> > >
> > > For SDH consecutive actions for each defect
> > > are specified in ITU-T G.783.
> > >
> > > Note also that for some defects the consecutive action
> > > can be disabled by configuration. Hence I'd say that
> > > the same defect can be a failure in one case and
> > > not a failure in another case. The typical example
> > > is Trail Identifier Mismatch (TIM).
> > >
> > > Hopefully this note will help.
> > >
> > > Regards,
> > > Sasha Vainshtein
> > > email: sasha@axerra.com
> > >
> > > phone: +972-3-7569993 (office)
> > > fax: +972-3-6487779
> > > mobile: +972-52-8674833
> > >
> > >
> > > > -----Original Message-----
> > > > From: Diego Caviglia [Diego.Caviglia@marconi.com]
> > > > Sent: Wednesday, March 23, 2005 1:06 PM
> > > > To: ccamp@ops.ietf.org
> > > > Subject: Failure definition w.r.t. SONET/SDH and
> > > > Protection/Restoration
> > > >
> > > >
> > > > Hi all,
> > > > is it defined somewhere, with respect to
> > > > SDH/SONET, which
> > > > defect has to be consider as a failure?
> > > >
> > > > It seems to me that for interoperability could be useful to
> > > > have a list of
> > > > defect that must be considered as failure, the same applies
> > > > for defect that
> > > > optionally can be considered as defect.
> > > >
> > > > May be also a communication between restoration TNEs in order
> > > > to agree on
> > > > the list could be useful.
> > > >
> > > > Does anyone agree on that?
> > > >
> > > > Regards
> > > >
> > > > Diego
> > > >
> > > > PS I apologise if the list is defined somewhere but I wasn't
> > > > able to find
> > > > it.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
>
>
>

 

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! --0-2077387970-1111692323=:48357-- From owner-ccamp@ops.ietf.org Thu Mar 24 20:52:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02842 for ; Thu, 24 Mar 2005 20:52:15 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEe5W-0003jy-42 for ccamp-archive@ietf.org; Thu, 24 Mar 2005 20:58:16 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEdoq-0003Zs-VQ for ccamp-data@psg.com; Fri, 25 Mar 2005 01:41:00 +0000 Received: from [63.250.163.245] (helo=huawei.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEdof-0003X3-U7 for ccamp@ops.ietf.org; Fri, 25 Mar 2005 01:40:50 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IDV008L2WI1BA@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Thu, 24 Mar 2005 17:37:13 -0800 (PST) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IDV007HTWHZ0X@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Thu, 24 Mar 2005 17:37:13 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.78.230.163]) by szxmc02-in.huawei.com (mshttpd); Fri, 25 Mar 2005 09:41:04 +0800 Date: Fri, 25 Mar 2005 09:41:04 +0800 From: Amit 70405 Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: Adrian Farrel , Igor Bryskin Cc: Diego Caviglia , ccamp@ops.ietf.org, Sasha@AXERRA.com Message-id: <1016620101793f.101793f1016620@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7BIT Hi Adrian & Igor, But there is one issue with this multilayer protection. Say in the case if the link gets broken, and the lower layer protection has succeeded. In this case, should the control plane(higher layer) be notified by the lower layer of link?? If yes than it has following consequences: - As control plane is unaware of any failure, control plane will continue to setup new connections on the failed. - This may not be a good thing to do. - Some means may be needed to avoid this link in Path computation. If no than following are the consequences: - Control plane too will go ahead with its protection mechanism. Let me know your view. Regards, Amit. ----- Original Message ----- From: Adrian Farrel Date: Thursday, March 24, 2005 7:40 pm Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration > Hi Amit, > > > Do you mean to say that Data plane & Control plane protection > shouldbe independant of each other?? > > No, I mean that they MAY be independent. > In particular, if you are using the control plane *and* the data > plane to > manage protection on the same set of resources you are bound to > get in a > horrible mess. > > Seems more reasonable that you would apply data plane protection > first and > then apply control plane protection at a higher level. > > > If so, in case of MSP protection in SDH, > > Control plane should not have any control over the resource pool > > used for MSP switch. > > This may lead to lot of unused resource in the network. > > It is certain that each layer of protection that you install MAY > result in > unused resources. Building multiple layers of protection will, > therefore,potentially build up more and more unused resources. It > is the job of > CCAMP to produce the tools that allow operators to build the > protectionschemes that they want. It's not really our business to > tell them which > schemes to build and when. > > Cheers, > Adrian > > From owner-ccamp@ops.ietf.org Fri Mar 25 02:36:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22395 for ; Fri, 25 Mar 2005 02:36:43 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEjSx-0005T1-1q for ccamp-archive@ietf.org; Fri, 25 Mar 2005 02:42:47 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEjC6-000ETJ-2W for ccamp-data@psg.com; Fri, 25 Mar 2005 07:25:22 +0000 Received: from [128.87.251.113] (helo=smtpoutuk02.marconi.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEjC1-000ESt-K3 for ccamp@ops.ietf.org; Fri, 25 Mar 2005 07:25:17 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id j2P7PBWV016164; Fri, 25 Mar 2005 07:25:12 GMT (envelope-from Diego.Caviglia@marconi.com) Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: "Amit 70405 Cc: "Adrian Farrel , "Igor Bryskin , "ccamp" , "Sasha" X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Fri, 25 Mar 2005 08:25:22 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 25/03/2005 07:25:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.4 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Hi Amit, actally for link/span protection I don't see any problem with control plane restoration and data plane protection interworking. It is sufficient to hide protection resourse to control plane. I see a lot of problems (there are SPs opened in the ITU-T documents about that) when you want an MS-SPRing protected ring to interwork with GMPLS restoration. Actually I'm not sure if that topic is in the charter of the CCAMP (Adrian what is your feeling about this?) but in any case it is a problem. Regards Diego Amit 70405 on 25/03/2005 02.41.04 To: Adrian Farrel , Igor Bryskin cc: Diego Caviglia , ccamp@ops.ietf.org, Sasha@AXERRA.com Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Hi Adrian & Igor, But there is one issue with this multilayer protection. Say in the case if the link gets broken, and the lower layer protection has succeeded. In this case, should the control plane(higher layer) be notified by the lower layer of link?? If yes than it has following consequences: - As control plane is unaware of any failure, control plane will continue to setup new connections on the failed. - This may not be a good thing to do. - Some means may be needed to avoid this link in Path computation. If no than following are the consequences: - Control plane too will go ahead with its protection mechanism. Let me know your view. Regards, Amit. ----- Original Message ----- From: Adrian Farrel Date: Thursday, March 24, 2005 7:40 pm Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration > Hi Amit, > > > Do you mean to say that Data plane & Control plane protection > shouldbe independant of each other?? > > No, I mean that they MAY be independent. > In particular, if you are using the control plane *and* the data > plane to > manage protection on the same set of resources you are bound to > get in a > horrible mess. > > Seems more reasonable that you would apply data plane protection > first and > then apply control plane protection at a higher level. > > > If so, in case of MSP protection in SDH, > > Control plane should not have any control over the resource pool > > used for MSP switch. > > This may lead to lot of unused resource in the network. > > It is certain that each layer of protection that you install MAY > result in > unused resources. Building multiple layers of protection will, > therefore,potentially build up more and more unused resources. It > is the job of > CCAMP to produce the tools that allow operators to build the > protectionschemes that they want. It's not really our business to > tell them which > schemes to build and when. > > Cheers, > Adrian > > From owner-ccamp@ops.ietf.org Fri Mar 25 02:38:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22554 for ; Fri, 25 Mar 2005 02:38:51 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEjUz-0005Ul-Sa for ccamp-archive@ietf.org; Fri, 25 Mar 2005 02:44:55 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEjIz-000F4Y-59 for ccamp-data@psg.com; Fri, 25 Mar 2005 07:32:29 +0000 Received: from [128.87.251.113] (helo=smtpoutuk02.marconi.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEjIx-000F4I-M6 for ccamp@ops.ietf.org; Fri, 25 Mar 2005 07:32:28 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id j2P7WLWY018152; Fri, 25 Mar 2005 07:32:21 GMT (envelope-from Diego.Caviglia@marconi.com) MIME-Version: 1.0 To: "Adrian Farrel" Cc: ", " Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Fri, 25 Mar 2005 08:32:28 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 25/03/2005 07:32:14, Serialize complete at 25/03/2005 07:32:14 Content-Type: multipart/alternative; boundary="=_alternative 00296FB3C1256FCF_=" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.9 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 This is a multipart message in MIME format. --=_alternative 00296FB3C1256FCF_= Content-Type: text/plain; charset="us-ascii" Hi Adrian, I see your points (that doesn't mean I agree ;-)). Given that seems that I'm the only one to ask such kind of statement I think the discussion could stop here. Regards and thanks Diego Please respond to "Adrian Farrel" To: "Diego Caviglia" cc: , Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Hi Diego, >> - The GMPLS control plane does not necessarily want to define data >> plane failures. Rather, it wants to signal (report) errors and allow >> the control plane state (and data plane state) to remain in place. > [dc] Agreed and that was my initial point. Which kind of data plane (e.g. > SDG) defects have to advertised to control plane to trigger restoration? > Given that control plane is concerned in restore the data plane it should > also define what is a failure. It is a fiber break or we have also to > consider other defects? Of course we have. What happens if one > restoration TNE consider as failure only Loss Of Light (LOS) while the > other starts restoration even if there is a e.g. Loss Of Pointer? Is > that acceptable? Let's look at two things. First, the trigger for protection switchover. If you look at section 6.2 of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt (currently in working group last call, so please comment now!) you will see... To co-ordinate the switchover between end-points, an end-to-end switchover request is needed since a failure affecting one the LSPs results in both end-points switching to the other LSP (resulting in receiving traffic from the other LSP) in their respective directions. This is done using the Notify message with a new Error Code indicating "Working LSP Failure (Switchover Request)". This clearly indicates that the objective is not to report a failure, but to request a switchover. Which takes us to your second point: which data plane errors should be reported to the control plane to trigger switchover signaling, and would it matter if different transport nodes applied different policies? My contention is that this is entirely an implementation issue. I think it would be a wise implementation that included some degree of configurability to this function, but that is not in CCAMP's scope. If two "TNEs" have different trigger thresholds I do not see that any harm will be done, it might even be desirable. >> - Decisions that trigger control plane protection actions are >> fundamentally implementation choices. > [dc] Here we are. This is the point. IMHO CCAMP should provide some > guidance on this. > >> Maybe we should make a statement that this type >> of thing SHOULD be configurable so that there is some sort of >> consistency within a network. > [dc] Something like "..control plane restoration mechanism SHOULD be > triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1). But why? It is not enough to know that this is a difficult question for an implementaiton to answer. Why is it not enough to say that the Data Plane should trigger control plane recovery action when the data plane deems that there is a fault from which it determines that recovery is required and from which it is unable or unwilling to recover on its own? If you can show that there is a need to make a more definitive statement then we can consider it. Cheers, Adrian --=_alternative 00296FB3C1256FCF_= Content-Type: text/html; charset="us-ascii"
Hi Adrian,
                  I see your points (that doesn't mean I agree ;-)).

Given that seems that I'm the only one to ask such kind of statement I think the discussion could stop here.

Regards and thanks

Diego

Please respond to "Adrian Farrel" <adrian@olddog.co.uk>

To:        "Diego Caviglia" <Diego.Caviglia@marconi.com>
cc:        <ccamp@ops.ietf.org>, <Sasha@AXERRA.com>

Subject:        Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration



Hi Diego,
 
>> - The GMPLS control plane does not  necessarily want to define data
>>   plane failures. Rather, it  wants to signal (report) errors and allow
>>   the control plane  state (and data plane state) to remain in place.
> [dc] Agreed and that  was my initial point.  Which kind of data plane (e.g.
> SDG)  defects have to advertised to control plane to trigger restoration?   
> Given that control plane is concerned in  restore the data plane it should
> also define what is a failure.  It is a  fiber break or we have also to
> consider other defects? Of course we  have.  What happens if one
> restoration TNE consider as failure  only Loss Of Light (LOS) while the
> other starts restoration even if there  is a e.g. Loss Of Pointer?  Is
> that acceptable?
 
Let's look at two things.
 
First, the trigger for protection switchover. If  you look at section 6.2 of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt  (currently in working group last call, so please comment now!) you will  see...
 
   To co-ordinate the switchover  between end-points, an end-to-end
   switchover request is needed  since a failure affecting one the LSPs
   results in both  end-points switching to the other LSP (resulting in
   receiving  traffic from the other LSP) in their respective
   directions.  This is done using the Notify message with a new Error
   Code  indicating "Working LSP Failure (Switchover Request)".

This clearly indicates that the objective is not  to report a failure, but to request a switchover.
 
Which takes us to your second point: which data  plane errors should be reported to the control plane to trigger switchover  signaling, and would it matter if different transport nodes applied different  policies?
 
My contention is that this is entirely an  implementation issue. I think it would be a wise implementation that included  some degree of configurability to this function, but that is not in CCAMP's  scope. If two "TNEs" have different trigger thresholds I do not see that any  harm will be done, it might even be desirable.
 
>> - Decisions that trigger control plane  protection actions are
>>   fundamentally implementation  choices.
> [dc] Here we are.  This is the point.  IMHO CCAMP  should provide some
> guidance on this.
>
>>   Maybe  we should make a statement that this type
>>   of thing SHOULD be  configurable so that there is some sort of
>>   consistency within  a network.
> [dc] Something like "..control plane restoration mechanism  SHOULD be
> triggered as the SNC/I defined in ITU-T G.783 (section  12.1.1.1).
 
But why?
 
It is not enough to know that this is a difficult  question for an implementaiton to answer.
 
Why is it not enough to say that the Data Plane  should trigger control plane recovery action when the data plane deems that  there is a fault from which it determines that recovery is required and from  which it is unable or unwilling to recover on its own?
 
If you can show that there is a need to make a more definitive statement  then we can consider it.

Cheers,
Adrian

--=_alternative 00296FB3C1256FCF_=-- From owner-ccamp@ops.ietf.org Fri Mar 25 03:33:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27782 for ; Fri, 25 Mar 2005 03:33:38 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEkLw-0007DM-PP for ccamp-archive@ietf.org; Fri, 25 Mar 2005 03:39:43 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEk5V-000K5P-AD for ccamp-data@psg.com; Fri, 25 Mar 2005 08:22:37 +0000 Received: from [63.250.163.245] (helo=huawei.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEk5S-000K58-8o for ccamp@ops.ietf.org; Fri, 25 Mar 2005 08:22:35 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IDW00FUJF3LT2@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Fri, 25 Mar 2005 00:18:57 -0800 (PST) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IDW007KPF3J0X@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Fri, 25 Mar 2005 00:18:57 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.78.230.163]) by szxmc02-in.huawei.com (mshttpd); Fri, 25 Mar 2005 16:22:49 +0800 Date: Fri, 25 Mar 2005 16:22:49 +0800 From: Amit 70405 Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: Diego Caviglia Cc: "Adrian Farrel , "Igor Bryskin , ccamp , Sasha Message-id: <104b584104956e.104956e104b584@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7BIT Hi Diego, Its not only the case with MSP protection. For that matter any Multilayer protection will have the interworking issues. According to me lower layer restoration should be mandatorily independant of higher layer restoration. And let the Network operator be aware of the consequences(mainly some unutilised resources). This is the point which I feel that CCAMP should clarify. Regards, Amit. ----- Original Message ----- From: Diego Caviglia Date: Friday, March 25, 2005 3:25 pm Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration > Hi Amit, > actally for link/span protection I don't see any > problem > with control plane restoration and data plane protection interworking. > > It is sufficient to hide protection resourse to control plane. > > I see a lot of problems (there are SPs opened in the ITU-T > documents about > that) when you want an MS-SPRing protected ring to interwork with > GMPLS > restoration. > > Actually I'm not sure if that topic is in the charter of the CCAMP > (Adrian > what is your feeling about this?) but in any case it is a problem. > > Regards > > Diego > > > To: Adrian Farrel , Igor Bryskin > cc: Diego Caviglia > , ccamp@ops.ietf.org, > Sasha@AXERRA.com > > Subject: Re: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > Hi Adrian & Igor, > But there is one issue with this multilayer protection. > Say in the case if the link gets broken, and the lower layer > protection > has succeeded. > In this case, should the control plane(higher layer) be > notified by the > lower layer of link?? > > If yes than it has following consequences: > - As control plane is unaware of any failure, control plane > will > continue to setup new connections on the failed. > - This may not be a good thing to do. > - Some means may be needed to avoid this link in Path computation. > > If no than following are the consequences: > - Control plane too will go ahead with its protection mechanism. > > Let me know your view. > Regards, > Amit. > > > ----- Original Message ----- > From: Adrian Farrel > Date: Thursday, March 24, 2005 7:40 pm > Subject: Re: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > > Hi Amit, > > > > > Do you mean to say that Data plane & Control plane protection > > shouldbe independant of each other?? > > > > No, I mean that they MAY be independent. > > In particular, if you are using the control plane *and* the data > > plane to > > manage protection on the same set of resources you are bound to > > get in a > > horrible mess. > > > > Seems more reasonable that you would apply data plane protection > > first and > > then apply control plane protection at a higher level. > > > > > If so, in case of MSP protection in SDH, > > > Control plane should not have any control over the > resource pool > > > used for MSP switch. > > > This may lead to lot of unused resource in the network. > > > > It is certain that each layer of protection that you install MAY > > result in > > unused resources. Building multiple layers of protection will, > > therefore,potentially build up more and more unused resources. It > > is the job of > > CCAMP to produce the tools that allow operators to build the > > protectionschemes that they want. It's not really our business to > > tell them which > > schemes to build and when. > > > > Cheers, > > Adrian > > > > > > > > From owner-ccamp@ops.ietf.org Fri Mar 25 07:15:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19505 for ; Fri, 25 Mar 2005 07:15:25 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEnoj-0005St-3V for ccamp-archive@ietf.org; Fri, 25 Mar 2005 07:21:33 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEnXn-000Lqx-7v for ccamp-data@psg.com; Fri, 25 Mar 2005 12:04:03 +0000 Received: from [217.32.164.139] (helo=smtp5.smtp.bt.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEnXh-000LqH-Pp for ccamp@ops.ietf.org; Fri, 25 Mar 2005 12:03:57 +0000 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Fri, 25 Mar 2005 12:03:55 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Mar 2005 12:03:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoration Date: Fri, 25 Mar 2005 12:03:54 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1A8C@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Failure definition w.r.t. SONET/SDH and Protection/Restoration Thread-Index: AcUxE+cYWcvvMc0ISg6FWV8FowB2kQAHNVYg From: To: , Cc: , , , X-OriginalArrivalTime: 25 Mar 2005 12:03:55.0207 (UTC) FILETIME=[B7D25D70:01C53132] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: quoted-printable You are quite correct Amit. What you need is proper client/server functional decoupling between the layer networks involved. The ideas of a 'common' control-plane (esp routing) from IP to Optics is rather a nonsence in our view.....not just technically either, you need this to provide the key 'network builder service' capability in commercial relationships between operators. Historically things have worked OK in practice because there has been a common-sense approach about how the 3 networking modes of co-cs, co-ps and cl-ps have been nested (there are 9 possible client/server relationships here are there are no formal rules governing how many up/down transitions are allowed in some end-end reference architecture...and remember, a client layer network will inherit the performance of its server layer network, and this is recursive to the duct). PWE3 stuff is turning this on its head wrt XoverY relationships (not that these even ensure the key requirement of client/server independence/transparency anyway)....hopefully most operator folks should have the common sense to see the problems and avoid the pitfalls. In the 2 co modes the defect handling MUST be done in the data-plane and it MUST be unidirectional. There is an OAM requirement to send a signal called FDI (Forward Defect Indication...sometimes know as AIS in co-cs technologies) which is intended to suppress alarm storms (which would otherwise occur in all higher client co mode networks). Has to be like this, esp in the co-cs mode as the control/management-plane is forced to run OOB and it must work the *same* for all methods of trail set-up....be this by signalling protocols X, Y or Z of via management provisioning. regards, neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Amit 70405 > Sent: 25 March 2005 08:23 > To: Diego Caviglia > Cc: Adrian Farrel Subject: Re: Failure definition w.r.t. SONET/SDH and=20 > Protection/Restoration >=20 >=20 > Hi Diego, > Its not only the case with MSP protection. > For that matter any Multilayer protection will have the=20 > interworking issues. > According to me lower layer restoration should be=20 > mandatorily independant of higher layer restoration. > And let the Network operator be aware of the=20 > consequences(mainly some unutilised resources). > =20 > This is the point which I feel that CCAMP should clarify. >=20 > Regards, > Amit. >=20 >=20 >=20 > ----- Original Message ----- > From: Diego Caviglia > Date: Friday, March 25, 2005 3:25 pm > Subject: Re: Failure definition w.r.t. SONET/SDH and=20 > Protection/Restoration >=20 > > Hi Amit, > > actally for link/span protection I don't see any > > problem=20 > > with control plane restoration and data plane protection=20 > interworking. > >=20 > > It is sufficient to hide protection resourse to control plane. > >=20 > > I see a lot of problems (there are SPs opened in the ITU-T > > documents about=20 > > that) when you want an MS-SPRing protected ring to interwork with=20 > > GMPLS=20 > > restoration. > >=20 > > Actually I'm not sure if that topic is in the charter of the CCAMP > > (Adrian=20 > > what is your feeling about this?) but in any case it is a problem. > >=20 > > Regards > >=20 > > Diego > >=20 > >=20 > > To: Adrian Farrel , Igor Bryskin=20 > > cc: Diego Caviglia=20 > > , ccamp@ops.ietf.org, > > Sasha@AXERRA.com=20 > >=20 > > Subject: Re: Failure definition w.r.t. SONET/SDH and=20 > > Protection/Restoration > >=20 > > Hi Adrian & Igor, > > But there is one issue with this multilayer protection. > > Say in the case if the link gets broken, and the lower layer > > protection=20 > > has succeeded. > > In this case, should the control plane(higher layer) be=20 > > notified by the=20 > > lower layer of link?? > >=20 > > If yes than it has following consequences: > > - As control plane is unaware of any failure, control plane > > will=20 > > continue to setup new connections on the failed. > > - This may not be a good thing to do. > > - Some means may be needed to avoid this link in Path computation. > >=20 > > If no than following are the consequences: > > - Control plane too will go ahead with its protection mechanism. > >=20 > > Let me know your view. > > Regards, > > Amit. > >=20 > >=20 > > ----- Original Message ----- > > From: Adrian Farrel > > Date: Thursday, March 24, 2005 7:40 pm > > Subject: Re: Failure definition w.r.t. SONET/SDH and > > Protection/Restoration > >=20 > > > Hi Amit, > > > > > > > Do you mean to say that Data plane & Control plane protection > > > shouldbe independant of each other?? > > > > > > No, I mean that they MAY be independent. > > > In particular, if you are using the control plane *and* the data=20 > > > plane to manage protection on the same set of resources you are=20 > > > bound to get in a > > > horrible mess. > > > > > > Seems more reasonable that you would apply data plane protection=20 > > > first and then apply control plane protection at a higher level. > > > > > > > If so, in case of MSP protection in SDH, > > > > Control plane should not have any control over the > > resource pool > > > > used for MSP switch. > > > > This may lead to lot of unused resource in the network. > > > > > > It is certain that each layer of protection that you install MAY=20 > > > result in unused resources. Building multiple layers of=20 > protection=20 > > > will, therefore,potentially build up more and more unused=20 > resources.=20 > > > It is the job of > > > CCAMP to produce the tools that allow operators to build the > > > protectionschemes that they want. It's not really our business to > > > tell them which > > > schemes to build and when. > > > > > > Cheers, > > > Adrian > > > > > > > >=20 > >=20 > >=20 > >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Fri Mar 25 11:01:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11126 for ; Fri, 25 Mar 2005 11:01:48 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DErLp-0003wk-3l for ccamp-archive@ietf.org; Fri, 25 Mar 2005 11:07:57 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEr5h-0005fY-Pu for ccamp-data@psg.com; Fri, 25 Mar 2005 15:51:17 +0000 Received: from [68.142.200.152] (helo=web30809.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DEr5d-0005eh-Rr for ccamp@ops.ietf.org; Fri, 25 Mar 2005 15:51:14 +0000 Received: (qmail 77766 invoked by uid 60001); 25 Mar 2005 15:51:13 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=5Vsmz/y0dZPHcAnEKdwD2O2B5G9jV45cj84cpVvKpM24qkJz63y1NXm18Kn+cpchGBdR1Ww5iJb6GAQAlD4L/f1QEfJWsyZC5BFDioa7QSztx6I4U10GqxXoEeK2Yp6iokgD0aWhskGr+FGe41uDT6gJsHwpXugK+rCAzg5lsrc= ; Message-ID: <20050325155113.77764.qmail@web30809.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30809.mail.mud.yahoo.com via HTTP; Fri, 25 Mar 2005 07:51:12 PST Date: Fri, 25 Mar 2005 07:51:12 -0800 (PST) From: Igor Bryskin Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: Amit 70405 , Adrian Farrel Cc: Diego Caviglia , ccamp@ops.ietf.org, Sasha@AXERRA.com In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1031285146-1111765872=:74671" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00, FORGED_YAHOO_RCVD,HTML_50_60,HTML_MESSAGE,HTML_NONELEMENT_00_10 autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.3 (+) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --0-1031285146-1111765872=:74671 Content-Type: text/plain; charset=us-ascii Please, ee in-line. Amit 70405 wrote: Hi Adrian & Igor, But there is one issue with this multilayer protection. Say in the case if the link gets broken, and the lower layer protection has succeeded. In this case, should the control plane(higher layer) be notified by the lower layer of link?? IIB>> Control plane needs to verify with the data plane if the fault condition still exists after the hold-off time and start recovery procedures only if necessary. Igor If yes than it has following consequences: - As control plane is unaware of any failure, control plane will continue to setup new connections on the failed. - This may not be a good thing to do. - Some means may be needed to avoid this link in Path computation. If no than following are the consequences: - Control plane too will go ahead with its protection mechanism. Let me know your view. Regards, Amit. ----- Original Message ----- From: Adrian Farrel Date: Thursday, March 24, 2005 7:40 pm Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration > Hi Amit, > > > Do you mean to say that Data plane & Control plane protection > shouldbe independant of each other?? > > No, I mean that they MAY be independent. > In particular, if you are using the control plane *and* the data > plane to > manage protection on the same set of resources you are bound to > get in a > horrible mess. > > Seems more reasonable that you would apply data plane protection > first and > then apply control plane protection at a higher level. > > > If so, in case of MSP protection in SDH, > > Control plane should not have any control over the resource pool > > used for MSP switch. > > This may lead to lot of unused resource in the network. > > It is certain that each layer of protection that you install MAY > result in > unused resources. Building multiple layers of protection will, > therefore,potentially build up more and more unused resources. It > is the job of > CCAMP to produce the tools that allow operators to build the > protectionschemes that they want. It's not really our business to > tell them which > schemes to build and when. > > Cheers, > Adrian > > --------------------------------- Do you Yahoo!? Yahoo! Small Business - Try our new resources site! --0-1031285146-1111765872=:74671 Content-Type: text/html; charset=us-ascii

Please, ee in-line.

Amit 70405 <AmitG@huawei.com> wrote:

Hi Adrian & Igor,
But there is one issue with this multilayer protection.
Say in the case if the link gets broken, and the lower layer protection has succeeded.
In this case, should the control plane(higher layer) be notified by the lower layer of link??

IIB>> Control plane needs to verify with the data plane if the fault condition still exists after the hold-off time and start recovery procedures only if necessary.

Igor

If yes than it has following consequences:
- As control plane is unaware of any failure, control plane will continue to setup new connections on the failed.
- This may not be a good thing to do.
- Some means may be needed to avoid this link in Path computation.

If no than following are the consequences:
- Control plane too will go ahead with its protection mechanism.

Let me know your view.
Regards,
Amit.


----- Original Message -----
From: Adrian Farrel
Date: Thursday, March 24, 2005 7:40 pm
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

> Hi Amit,
>
> > Do you mean to say that Data plane & Control plane protection
> shouldbe independant of each other??
>
> No, I mean that they MAY be independent.
> In particular, if you are using the control plane *and* the data
> plane to
> manage protection on the same set of resources you are bound to
> get in a
> horrible mess.
>
> Seems more reasonable that you would apply data plane protection
> first and
> then apply control plane protection at a higher level.
>
> > If so, in case of MSP protection in SDH,
> > Control plane should not have any control over the resource pool
> > used for MSP switch.
> > This may lead to lot of unused resource in the network.
>
> It is certain that each layer of protection that you install MAY
> result in
> unused resources. Building multiple layers of protection will,
> therefore,potentially build up more and more unused resources. It
> is the job of
> CCAMP to produce the tools that allow operators to build the
> protectionschemes that they want. It's not really our business to
> tell them which
> schemes to build and when.
>
> Cheers,
> Adrian
>
>

 

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! --0-1031285146-1111765872=:74671-- From owner-ccamp@ops.ietf.org Fri Mar 25 16:39:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19577 for ; Fri, 25 Mar 2005 16:39:46 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEwcu-0007MC-R0 for ccamp-archive@ietf.org; Fri, 25 Mar 2005 16:45:58 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DEwNk-000MAv-CS for ccamp-data@psg.com; Fri, 25 Mar 2005 21:30:16 +0000 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DEwNd-000M9w-Rs for ccamp@ops.ietf.org; Fri, 25 Mar 2005 21:30:10 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk01.marconi.com (8.12.11/8.12.11) with ESMTP id j2PLTw0u002184; Fri, 25 Mar 2005 21:29:58 GMT (envelope-from Diego.Caviglia@marconi.com) Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: "Amit 70405 Cc: "Adrian Farrel , "Igor Bryskin , "ccamp" , "Sasha" X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Fri, 25 Mar 2005 22:30:10 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 25/03/2005 21:29:55 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.4 (++) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Hi Amit, it seems to me that we are mixing different issues here (a part from the fact that may be we need to change the subject of the thread). First point I think that link protection and path protection leads to different problem. In case of link protection it is quite simple to solve the issue; data plane protecting link is hidden to the control plane and a hold-off timer is used in order to separate data plane protection mechanism from control plane restoration. In case of path protection thing are different and I think are not solved, or at least not solved in CCAMP/ITU-T. The main issue I see in this field is the interworking between MS-SPRing protection and control plane restoration. It is a matter of fact that MS-SPRing is one of the most used inherent protection scheme in SDH network but up to now we don't have a 'standard' way to let MS-SPRing to interwork with control plane restoration scheme (e.g. timeslot interchange and squelching problem) I've again to mention the WG chair here and ask him if this kind issues are in the scope of the CCAMP. Regards Diego Amit 70405 on 25/03/2005 02.41.04 To: Adrian Farrel , Igor Bryskin cc: Diego Caviglia , ccamp@ops.ietf.org, Sasha@AXERRA.com Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Hi Adrian & Igor, But there is one issue with this multilayer protection. Say in the case if the link gets broken, and the lower layer protection has succeeded. In this case, should the control plane(higher layer) be notified by the lower layer of link?? If yes than it has following consequences: - As control plane is unaware of any failure, control plane will continue to setup new connections on the failed. - This may not be a good thing to do. - Some means may be needed to avoid this link in Path computation. If no than following are the consequences: - Control plane too will go ahead with its protection mechanism. Let me know your view. Regards, Amit. ----- Original Message ----- From: Adrian Farrel Date: Thursday, March 24, 2005 7:40 pm Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration > Hi Amit, > > > Do you mean to say that Data plane & Control plane protection > shouldbe independant of each other?? > > No, I mean that they MAY be independent. > In particular, if you are using the control plane *and* the data > plane to > manage protection on the same set of resources you are bound to > get in a > horrible mess. > > Seems more reasonable that you would apply data plane protection > first and > then apply control plane protection at a higher level. > > > If so, in case of MSP protection in SDH, > > Control plane should not have any control over the resource pool > > used for MSP switch. > > This may lead to lot of unused resource in the network. > > It is certain that each layer of protection that you install MAY > result in > unused resources. Building multiple layers of protection will, > therefore,potentially build up more and more unused resources. It > is the job of > CCAMP to produce the tools that allow operators to build the > protectionschemes that they want. It's not really our business to > tell them which > schemes to build and when. > > Cheers, > Adrian > > From owner-ccamp@ops.ietf.org Mon Mar 28 07:39:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10823 for ; Mon, 28 Mar 2005 07:39:38 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFtdO-0002Om-Jt for ccamp-archive@ietf.org; Mon, 28 Mar 2005 07:46:23 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DFtJH-000I2l-3e for ccamp-data@psg.com; Mon, 28 Mar 2005 12:25:35 +0000 Received: from [192.128.166.71] (helo=almso2.proxy.att.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DFtJF-000I2Q-Ps for ccamp@ops.ietf.org; Mon, 28 Mar 2005 12:25:34 +0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j2SCO8Sp023072 for ; Mon, 28 Mar 2005 07:25:32 -0500 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (7.2.052) id 423DAD7E00138EA5; Mon, 28 Mar 2005 07:25:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: WG drafts - My correction Date: Mon, 28 Mar 2005 06:25:32 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA060C8976@KCCLUST06EVS1.ugd.att.com> Thread-Topic: WG drafts - My correction Thread-Index: AcUvPpgKC5q1cD9uQm+wyVzO7ctyiAEUk1ZA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , Cc: "Ash, Gerald R \(Jerry\), ALABS" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable > 3. The name of the third draft is > draft-vasseur-ccamp-inter-domain-pd-path-comp. > This is the draft that we need to consider. > ... > are we content to accept this draft as a WG draft? Yes. Thanks, Jerry From owner-ccamp@ops.ietf.org Tue Mar 29 08:19:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26229 for ; Tue, 29 Mar 2005 08:19:09 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGGjL-0004EL-UF for ccamp-archive@ietf.org; Tue, 29 Mar 2005 08:26:06 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGGOk-000EUu-CZ for ccamp-data@psg.com; Tue, 29 Mar 2005 13:04:46 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGGOZ-000ERG-BN for ccamp@ops.ietf.org; Tue, 29 Mar 2005 13:04:35 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id 8E23FE0001C1 for ; Tue, 29 Mar 2005 14:04:31 +0100 (BST) Received: from Puppy ([212.43.203.67] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Mar 2005 14:01:52 +0100 Message-ID: <123501c5345f$b7c537a0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: WG last call complete on Recovery Signaling drafts Date: Tue, 29 Mar 2005 13:38:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 29 Mar 2005 13:01:52.0462 (UTC) FILETIME=[7A145EE0:01C5345F] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Authors/editors, Please pick up all of the comments from the mailing list and either demonstrate that no changes are needed or respin your drafts. Let me know when you are done. Thanks, Adrian From owner-ccamp@ops.ietf.org Tue Mar 29 08:19:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26255 for ; Tue, 29 Mar 2005 08:19:12 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGGjQ-0004Ea-RY for ccamp-archive@ietf.org; Tue, 29 Mar 2005 08:26:09 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGGOa-000ERf-Mv for ccamp-data@psg.com; Tue, 29 Mar 2005 13:04:36 +0000 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGGOW-000EQc-4G for ccamp@ops.ietf.org; Tue, 29 Mar 2005 13:04:32 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by astro.systems.pipex.net (Postfix) with ESMTP id CD3DDE00018C for ; Tue, 29 Mar 2005 14:04:21 +0100 (BST) Received: from Puppy ([212.43.203.67] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Mar 2005 14:01:45 +0100 Message-ID: <123401c5345f$b3d18f40$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Comments on draft-ietf-ccamp-gmpls-segment-recovery-01.txt Date: Tue, 29 Mar 2005 13:35:03 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_11EF_01C53464.1CEB8C20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 29 Mar 2005 13:01:46.0822 (UTC) FILETIME=[76B7C660:01C5345F] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.9 (++) X-Scan-Signature: 919b3965bd46f7460d234f848680b238 This is a multi-part message in MIME format. ------=_NextPart_000_11EF_01C53464.1CEB8C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Working group last call has ended for this draft. As a co-author I held = off making comments during WG last call, but as WG chair I wanted to = raise a couple of points. Thanks, Adrian =3D=3D=3D Need to run idnits and fix all errors and warnings =3D=3D=3D Opening boilerplate. Replace first paragraph with... This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. =3D=3D=3D Abstract Expand "LSP" =3D=3D=3D Abstract OLD intended to be compliment and be consistent with the Extensions for NEW intended to compliment and be consistent with the Extensions for =3D=3D=3D Abstract Don't use square brace citations in the abstract. =3D=3D=3D Section 1 OLD The extensions defined in this document allow for support of the full set of recovery types supported by [E2E-RECOVERY] on a segment, or portion of the LSP, basis.=20 NEW The extensions defined in this document allow for support of the full set of recovery types supported by [E2E-RECOVERY], but applied to any = segment, or to any portion of the LSP. =3D=3D=3D Section 2 OLD failure, or failure over a particularly portion of a network used by NEW failure, or failure over a particular portion of a network used by ^=20 =3D=3D=3D Section 2.1 OLD Three approaches of end-to-end protection are defined in [E2E- NEW Three approaches for end-to-end protection are defined in [E2E- =3D=3D=3D Section 2.1 OLD counterparts. Each behaves just like there end-to-end counterparts, NEW counterparts. Each behaves just like its end-to-end counterpart, ^^^ ^ =3D=3D=3D Section 2.1 and section 2.2 Cross-references are all (presumably) to [E2E-RECOVERY]. This is not = clear. =3D=3D=3D Section 3 OLD [E2E-RECOVERY]. In this document we define a new type to support NEW [E2E-RECOVERY]. In this document we define a new value for the = Association Type field to support =3D=3D=3D Section 4 OLD When upstream control of branch and merge nodes are not desired, NEW When upstream control of branch and merge nodes is not desired, =3D=3D=3D Section 4.1.1 The definition of the Type value for the Protection sub-object should = not be here. It should be in the IANA section and under IANA control. =3D=3D=3D Section 4.1.1 Need to include a definition of the Length field. This can point to = RFC3209. =3D=3D=3D Section 4.1.1 Need to state the rules for the Reserved bits. =3D=3D=3D Section 4.2.4.2 Once the ingress receives all expected Resv messages MUST follow the tear down procedure described in the Section 4.2.4. Assume this means 4.2.4.1? =3D=3D=3D Section 5.1 The protection subobject defined in [E2E-RECOVERY] can also be used in SECONDARY_RECORD_ROUTE objects. No. It is defined in section 4.1.1 of this document. =3D=3D=3D Section 6.1 OLD LSP Segment Recovery Flags are carried in the Protection object C- Type defined in [E2E-RECOVERY]. The format of the flags are: NEW LSP Segment Recovery Flags are carried in the Protection object of = the same C- Type defined in [E2E-RECOVERY]. The format of the flags are: =3D=3D=3D Section 6.1 *** Same question as for E2E-RECOVERY. Why do we need to use a new C-Type = (compared with the old definition of the Protection object)? It is possible to carry all of the additional information within the old = Protection object format. *** =3D=3D=3D Section 6.1 (LSP) Segment (Recovery) Flags: 6 bits Not _entirely_ clear which fields in the figure are referred to by this = text. =3D=3D=3D Section 8 Is it true that there are _no_ additional security considerations? Suppose that I am able to doctor a Path message by adding an SERO. This = would cause the data to be duplicated to my chosen destination without = impacting the real destination (i.e. without raising an alarm). Doesn't segment protection actually improve the security of the network = by making data delivery more robust? =3D=3D=3D Section 9 first para. It is not clear what action (if any) IANA is expected to take for this = information. If action is required, it would be helpful to point to the = relevant text within the draft. =3D=3D=3D Section 9 second para. There are some TBAs embedded in the text (section 4, section 5) that = relate to this paragraph). Need either to include "IANA" with the TBA, = or put a back pointer in this paragraph (or both). =3D=3D=3D Section 10 Obsoleted by section 14 =3D=3D=3D Section 11.1 Does [FRR] need to be a normative reference? ------=_NextPart_000_11EF_01C53464.1CEB8C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Working group last call has ended for = this draft.=20 As a co-author I held off making comments during WG last call, but = as WG=20 chair I wanted to raise a couple of points.
 
Thanks,
Adrian
 
=3D=3D=3D
Need to run idnits and fix all errors = and=20 warnings
=3D=3D=3D
Opening boilerplate.
Replace first paragraph = with...
   This document is an = Internet-Draft=20 and is subject to all provisions
   of Section 3 of RFC = 3667. =20 By submitting this Internet-Draft, each
   author = represents that=20 any applicable patent or other IPR claims of
   which he or = she is=20 aware have been or will be disclosed, and any of
   which = he or she=20 become aware will be disclosed, in accordance with
   RFC=20 3668.
=3D=3D=3D
Abstract
Expand "LSP"
=3D=3D=3D
Abstract
OLD
   intended to be = compliment and be=20 consistent with the Extensions for
NEW
   intended = to compliment and be=20 consistent with the Extensions for
=3D=3D=3D
Abstract
Don't use square brace citations in = the=20 abstract.
=3D=3D=3D
Section 1
OLD
   The extensions defined = in this=20 document allow for support of the full
   set of recovery = types=20 supported by [E2E-RECOVERY] on a segment, or
   portion of = the LSP,=20 basis. 
NEW
   The extensions defined = in this=20 document allow for support of the full
   set of recovery = types=20 supported by [E2E-RECOVERY], but applied to any
   segment, or to = any portion of=20 the LSP.
=3D=3D=3D
Section 2
OLD
   failure, or failure over = a=20 particularly portion of a network used by
NEW
   failure, or failure over = a=20 particular portion of a network used by
          &nbs= p;            = ;            =      ^=20
=3D=3D=3D
Section 2.1
OLD
   Three approaches of = end-to-end=20 protection are defined in [E2E-
NEW
   Three = approaches for end-to-end=20 protection are defined in [E2E-
=3D=3D=3D
Section 2.1
OLD
   = counterparts.  Each=20 behaves just like there end-to-end counterparts,
NEW
   counterparts.  Each = behaves=20 just like its end-to-end counterpart,
          &nbs= p;            = ;            =       ^^^     &nbs= p;            = ;    =20 ^
=3D=3D=3D
Section 2.1 and section = 2.2
Cross-references are all (presumably) = to=20 [E2E-RECOVERY]. This is not clear.
=3D=3D=3D
Section 3
OLD
   [E2E-RECOVERY].  In = this=20 document we define a new type to support
NEW
   [E2E-RECOVERY].  In = this=20 document we define a new value for the Association Type field to=20 support
=3D=3D=3D
Section 4
OLD
   When upstream control of = branch and=20 merge nodes are not desired,
NEW
   When upstream control of = branch and=20 merge nodes is not desired,
=3D=3D=3D
Section 4.1.1
The definition of the Type value for = the=20 Protection sub-object should not be here. It should be in the IANA = section and=20 under IANA control.
=3D=3D=3D
Section 4.1.1
Need to include a definition of the = Length field.=20 This can point to RFC3209.
=3D=3D=3D
Section 4.1.1
Need to state the rules for the = Reserved=20 bits.
=3D=3D=3D
Section 4.2.4.2
   Once the ingress = receives all=20 expected Resv messages MUST follow the
   tear down = procedure=20 described in the Section 4.2.4.
Assume this means = 4.2.4.1?
=3D=3D=3D
Section 5.1
   The protection subobject = defined in=20 [E2E-RECOVERY] can also be used
   in = SECONDARY_RECORD_ROUTE=20 objects.
No. It is defined in section 4.1.1 of this = document.
=3D=3D=3D
Section 6.1
OLD
   LSP Segment Recovery = Flags are=20 carried in the Protection object C-
   Type defined in=20 [E2E-RECOVERY].  The format of the flags are:
NEW
   LSP Segment Recovery = Flags are=20 carried in the Protection object of the same C-
   Type defined in=20 [E2E-RECOVERY].  The format of the flags = are:
=3D=3D=3D
Section 6.1
***
Same question as for E2E-RECOVERY. = Why do we need=20 to use a new C-Type (compared with the old definition of the Protection=20 object)?
It is possible to carry all of the = additional=20 information within the old Protection object format.
***
=3D=3D=3D
Section 6.1
      (LSP) = Segment=20 (Recovery) Flags: 6 bits
Not _entirely_ clear which fields in = the figure=20 are referred to by this text.
=3D=3D=3D
Section 8
Is it true that there are _no_ = additional=20 security considerations?
Suppose that I am able to doctor a = Path message=20 by adding an SERO. This would cause the data to be duplicated to my = chosen=20 destination without impacting the real destination (i.e. without raising = an=20 alarm).
Doesn't segment protection actually = improve the=20 security of the network by making data delivery more = robust?
=3D=3D=3D
Section 9 first para.
It is not clear what action (if any) = IANA is=20 expected to take for this information. If action is required, it would = be=20 helpful to point to the relevant text within the draft.
=3D=3D=3D
Section 9 second para.
There are some TBAs embedded in the = text (section=20 4, section 5) that relate to this paragraph). Need either to include = "IANA" with=20 the TBA, or put a back pointer in this paragraph (or both).
=3D=3D=3D
Section 10
Obsoleted by = section 14
=3D=3D=3D
Section 11.1
Does [FRR] need to be a normative=20 reference?
------=_NextPart_000_11EF_01C53464.1CEB8C20-- From owner-ccamp@ops.ietf.org Tue Mar 29 08:37:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27585 for ; Tue, 29 Mar 2005 08:37:28 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGH17-0004kB-Dk for ccamp-archive@ietf.org; Tue, 29 Mar 2005 08:44:25 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGGmG-000I4K-Pp for ccamp-data@psg.com; Tue, 29 Mar 2005 13:29:04 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGGmA-000I3j-VB for ccamp@ops.ietf.org; Tue, 29 Mar 2005 13:28:59 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 3E4EAE000329 for ; Tue, 29 Mar 2005 14:28:48 +0100 (BST) Received: from Puppy ([212.43.203.239] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Mar 2005 14:19:24 +0100 Message-ID: <127e01c53462$2a7f1ca0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: I-D ACTION:draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt Date: Tue, 29 Mar 2005 14:17:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 29 Mar 2005 13:19:26.0157 (UTC) FILETIME=[EE2177D0:01C53461] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Hi, Not sure why this was not copied to the CCAMP list. Anyway... Alan raised an interesting question about how to handle IPv6 sources and destinations in the TE MIBs for MPLS and GMPLS. This draft is an attempt to define a process for managing the existing MPLS TE MIB so that it can handle this case. Since the GMPLS MIBs are built on the MPLS MIBs, this is equally applicable to the GMPLS TE MIB. In the long term it will become clearer whether IPv6 and MPLS/GMPLS need to become more closely integrated, but this is probably a few years away. At that time the MPLS MIBs are quite likely to be ready for a rework, and so IPv6 sources and destinations can be included at that time. We would appreciate a quick turn-around from you in commenting on this draft so that we can: - make it a CCAMP draft if appropriate - last call it at the same time as the GMPLS MIB drafts. Thanks, Adrian ----- Original Message ----- From: To: Sent: Monday, March 28, 2005 5:03 PM Subject: I-D ACTION:draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Handling IPv6 Sources and Destinations in the MPLS > and GMPLS TE MIB Modules > Author(s) : A. Davey, et al. > Filename : draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt > Pages : 7 > Date : 2005-3-25 > > This document describes how to configure or monitor a Multiprotocol > Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineered > (TE) Label Switched Path (LSP) using the MPLS and GMPLS TE MIB module > where the ingress and/or egress routers are identified using IPv6 > addresses. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------- ------ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > From owner-ccamp@ops.ietf.org Tue Mar 29 11:08:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14874 for ; Tue, 29 Mar 2005 11:08:00 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGJMn-0001wi-Qh for ccamp-archive@ietf.org; Tue, 29 Mar 2005 11:15:00 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGJ4y-000FCR-T3 for ccamp-data@psg.com; Tue, 29 Mar 2005 15:56:32 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGJ4x-000FC9-OD for ccamp@ops.ietf.org; Tue, 29 Mar 2005 15:56:32 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11395; Tue, 29 Mar 2005 10:56:28 -0500 (EST) Message-Id: <200503291556.KAA11395@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-01.txt Date: Tue, 29 Mar 2005 10:56:28 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within The Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture Author(s) : I. Bryskin, A. Farrel Filename : draft-ietf-ccamp-gmpls-ason-lexicography-01.txt Pages : 15 Date : 2005-3-28 Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of physical technologies and across several architectural models. The ITU-T has specified an architecture for the management of Automatically Switched Optical Networks (ASON). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ason-lexicography-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-29112842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-lexicography-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-29112842.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Mar 30 07:02:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17955 for ; Wed, 30 Mar 2005 07:02:20 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGc0p-0006rQ-8t for ccamp-archive@ietf.org; Wed, 30 Mar 2005 07:09:31 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGbkd-0001jC-Fg for ccamp-data@psg.com; Wed, 30 Mar 2005 11:52:47 +0000 Received: from [62.241.162.31] (helo=galaxy.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGbkZ-0001ia-Nx for ccamp@ops.ietf.org; Wed, 30 Mar 2005 11:52:44 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 7507AE0002CB; Wed, 30 Mar 2005 12:52:34 +0100 (BST) Received: from Puppy ([212.43.203.5] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 12:47:01 +0100 Message-ID: <134001c5351e$6dc9a630$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Igor Bryskin" References: <200503291556.KAA11395@ietf.org> Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-01.txt Date: Wed, 30 Mar 2005 12:26:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 30 Mar 2005 11:47:02.0934 (UTC) FILETIME=[30868360:01C5351E] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Hi, Igor and I have submitted a new copy of this draft and we now have our asbestos suits on. Please comment. This revision includes the outcome of quite a few discussions with the ASON cognoscenti, but we are pretty convinced that we do not have everything right yet. You review thoughts would be most appreciated if they were accompanied by suggested text revisions. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Tuesday, March 29, 2005 4:56 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : A Lexicography for the Interpretation of Generalized > Multiprotocol Label Switching (GMPLS) Terminology within > The Context of the ITU-T's Automatically Switched Optical > Network (ASON) Architecture > Author(s) : I. Bryskin, A. Farrel > Filename : draft-ietf-ccamp-gmpls-ason-lexicography-01.txt > Pages : 15 > Date : 2005-3-28 > > Generalized Multiprotocol Label Switching (GMPLS) has been developed > by the IETF to facilitate the establishment of Label Switched Paths > (LSPs) in a variety of physical technologies and across several > architectural models. The ITU-T has specified an architecture for > the management of Automatically Switched Optical Networks (ASON). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-gmpls-ason-lexicography-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------- ------ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > From owner-ccamp@ops.ietf.org Wed Mar 30 15:42:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08436 for ; Wed, 30 Mar 2005 15:42:03 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGk7o-0001hS-Uz for ccamp-archive@ietf.org; Wed, 30 Mar 2005 15:49:18 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGjsZ-000573-4S for ccamp-data@psg.com; Wed, 30 Mar 2005 20:33:31 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGjsY-00056q-6P for ccamp@ops.ietf.org; Wed, 30 Mar 2005 20:33:30 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07147; Wed, 30 Mar 2005 15:33:27 -0500 (EST) Message-Id: <200503302033.PAA07147@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-functional-04.txt Date: Wed, 30 Mar 2005 15:33:27 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification Author(s) : J. Lang, et al. Filename : draft-ietf-ccamp-gmpls-recovery-functional-04.txt Pages : 20 Date : 2005-3-30 This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e. protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-functional-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-30150921.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-functional-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-30150921.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Mar 30 15:42:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08456 for ; Wed, 30 Mar 2005 15:42:05 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGk7r-0001hW-Ay for ccamp-archive@ietf.org; Wed, 30 Mar 2005 15:49:19 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGjrj-00052B-Tp for ccamp-data@psg.com; Wed, 30 Mar 2005 20:32:39 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGjri-00051v-Sx for ccamp@ops.ietf.org; Wed, 30 Mar 2005 20:32:39 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07007; Wed, 30 Mar 2005 15:32:36 -0500 (EST) Message-Id: <200503302032.PAA07007@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-analysis-05.txt Date: Wed, 30 Mar 2005 15:32:35 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) Author(s) : D. Papadimitriou, E. Mannie Filename : draft-ietf-ccamp-gmpls-recovery-analysis-05.txt Pages : 42 Date : 2005-3-30 This document provides an analysis grid to evaluate, compare and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with respect to the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in a companion document. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-analysis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-30150909.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-analysis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-30150909.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Mar 30 15:43:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08871 for ; Wed, 30 Mar 2005 15:43:32 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGk9G-0001nd-Nx for ccamp-archive@ietf.org; Wed, 30 Mar 2005 15:50:47 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGjtj-0005F5-AL for ccamp-data@psg.com; Wed, 30 Mar 2005 20:34:43 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGjt4-00059d-A0 for ccamp@ops.ietf.org; Wed, 30 Mar 2005 20:34:02 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07181; Wed, 30 Mar 2005 15:33:58 -0500 (EST) Message-Id: <200503302033.PAA07181@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-06.txt Date: Wed, 30 Mar 2005 15:33:58 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-recovery-terminology-06.txt Pages : 20 Date : 2005-3-30 This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-terminology-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-30150928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-terminology-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-30150928.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Mar 30 18:36:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10647 for ; Wed, 30 Mar 2005 18:36:53 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGmr2-0002ds-Gf for ccamp-archive@ietf.org; Wed, 30 Mar 2005 18:44:10 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGmdg-000ODn-KL for ccamp-data@psg.com; Wed, 30 Mar 2005 23:30:20 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGmdP-000O8f-7j for ccamp@ops.ietf.org; Wed, 30 Mar 2005 23:30:03 +0000 Received: from movaz-hw.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id C9C86167E; Wed, 30 Mar 2005 18:30:02 -0500 (EST) Received: from lb.movaz.com (localhost [127.0.0.1]) by movaz-hw.movaz.com (Postfix) with ESMTP id A4365AFB3; Wed, 30 Mar 2005 18:29:59 -0500 (EST) Message-Id: <6.1.2.0.2.20050330180027.04a175b8@mo-ex1> X-Sender: lb@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 30 Mar 2005 18:29:57 -0500 To: "Adrian Farrel" From: Lou Berger Subject: Re: Comments on draft-ietf-ccamp-gmpls-segment-recovery-01.txt Cc: In-Reply-To: <123401c5345f$b3d18f40$dccb2bd4@Puppy> References: <123401c5345f$b3d18f40$dccb2bd4@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.0 (++) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Adrian, Thanks for the comments. The editorial comments will be integrated into the next rev. Will cover the 1 technical comment (on section 6.1) in a separate e-mail. Lou At 07:35 AM 3/29/2005, Adrian Farrel wrote: >Hi, > >Working group last call has ended for this draft. As a co-author I held >off making comments during WG last call, but as WG chair I wanted to raise >a couple of points. > >Thanks, >Adrian > >=== >Need to run idnits and fix all errors and warnings >=== >Opening boilerplate. >Replace first paragraph with... > This document is an Internet-Draft and is subject to all provisions > of Section 3 of RFC 3667. By submitting this Internet-Draft, each > author represents that any applicable patent or other IPR claims of > which he or she is aware have been or will be disclosed, and any of > which he or she become aware will be disclosed, in accordance with > RFC 3668. >=== >Abstract >Expand "LSP" >=== >Abstract >OLD > intended to be compliment and be consistent with the Extensions for >NEW > intended to compliment and be consistent with the Extensions for >=== >Abstract >Don't use square brace citations in the abstract. >=== >Section 1 >OLD > The extensions defined in this document allow for support of the full > set of recovery types supported by [E2E-RECOVERY] on a segment, or > portion of the LSP, basis. >NEW > The extensions defined in this document allow for support of the full > set of recovery types supported by [E2E-RECOVERY], but applied to any > segment, or to any portion of the LSP. >=== >Section 2 >OLD > failure, or failure over a particularly portion of a network used by >NEW > failure, or failure over a particular portion of a network used by > ^ >=== >Section 2.1 >OLD > Three approaches of end-to-end protection are defined in [E2E- >NEW > Three approaches for end-to-end protection are defined in [E2E- >=== >Section 2.1 >OLD > counterparts. Each behaves just like there end-to-end counterparts, >NEW > counterparts. Each behaves just like its end-to-end counterpart, > ^^^ ^ >=== >Section 2.1 and section 2.2 >Cross-references are all (presumably) to [E2E-RECOVERY]. This is not clear. >=== >Section 3 >OLD > [E2E-RECOVERY]. In this document we define a new type to support >NEW > [E2E-RECOVERY]. In this document we define a new value for the > Association Type field to support >=== >Section 4 >OLD > When upstream control of branch and merge nodes are not desired, >NEW > When upstream control of branch and merge nodes is not desired, >=== >Section 4.1.1 >The definition of the Type value for the Protection sub-object should not >be here. It should be in the IANA section and under IANA control. >=== >Section 4.1.1 >Need to include a definition of the Length field. This can point to RFC3209. >=== >Section 4.1.1 >Need to state the rules for the Reserved bits. >=== >Section 4.2.4.2 > Once the ingress receives all expected Resv messages MUST follow the > tear down procedure described in the Section 4.2.4. >Assume this means 4.2.4.1? >=== >Section 5.1 > The protection subobject defined in [E2E-RECOVERY] can also be used > in SECONDARY_RECORD_ROUTE objects. >No. It is defined in section 4.1.1 of this document. >=== >Section 6.1 >OLD > LSP Segment Recovery Flags are carried in the Protection object C- > Type defined in [E2E-RECOVERY]. The format of the flags are: >NEW > LSP Segment Recovery Flags are carried in the Protection object of the > same C- > Type defined in [E2E-RECOVERY]. The format of the flags are: >=== >Section 6.1 >*** >Same question as for E2E-RECOVERY. Why do we need to use a new C-Type >(compared with the old definition of the Protection object)? >It is possible to carry all of the additional information within the old >Protection object format. >*** >=== >Section 6.1 > (LSP) Segment (Recovery) Flags: 6 bits >Not _entirely_ clear which fields in the figure are referred to by this text. >=== >Section 8 >Is it true that there are _no_ additional security considerations? >Suppose that I am able to doctor a Path message by adding an SERO. This >would cause the data to be duplicated to my chosen destination without >impacting the real destination (i.e. without raising an alarm). >Doesn't segment protection actually improve the security of the network by >making data delivery more robust? >=== >Section 9 first para. >It is not clear what action (if any) IANA is expected to take for this >information. If action is required, it would be helpful to point to the >relevant text within the draft. >=== >Section 9 second para. >There are some TBAs embedded in the text (section 4, section 5) that >relate to this paragraph). Need either to include "IANA" with the TBA, or >put a back pointer in this paragraph (or both). >=== >Section 10 >Obsoleted by section 14 >=== >Section 11.1 >Does [FRR] need to be a normative reference? From owner-ccamp@ops.ietf.org Thu Mar 31 06:47:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10585 for ; Thu, 31 Mar 2005 06:47:20 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGyG2-0002Ui-TO for ccamp-archive@ietf.org; Thu, 31 Mar 2005 06:54:44 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DGy1Q-000Pte-GI for ccamp-data@psg.com; Thu, 31 Mar 2005 11:39:36 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGy1K-000PtK-AA for ccamp@ops.ietf.org; Thu, 31 Mar 2005 11:39:30 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id ACBAAE0002C1 for ; Thu, 31 Mar 2005 12:39:19 +0100 (BST) Received: from Puppy ([212.43.203.250] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 12:33:27 +0100 Message-ID: <13f501c535e5$b40d2370$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaison received from ITU-T Q3/15 Date: Thu, 31 Mar 2005 12:34:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 31 Mar 2005 11:33:28.0545 (UTC) FILETIME=[75865D10:01C535E5] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Hi, We have received a liaison statement from ITU-T Study Group 15 Question 3. This liaison is for our information and contains a copy of Recommendation G.8081 "Terms and definitions for Automatically Switched Optical Networks". The authors of the GMPLS/ASON lexicography will need to examine this Recommendation to ensure alignment with ASON terminology. The text of the liaison is found below. A copy of the liaison and the Recommendation can be found at http://www.olddog.co.uk/incoming.htm (Beware that the ITU-T FTP site is quite slow.) Thanks, Adrian === From: Hiroshi Ohta, Rapporteur, Q.3/15 To: IETF ccamp WG For: Information Subject: G.8081: Terms and definitions for ASON We are pleased to send you the ITU-T Recommendation G.8081, "Terms and definitions for Automatically Switched Optical Networks". We believe this Recommendation is useful to develop consistent standards related to GMPLS and ASON. We hope to collaborate further for future development. As usual a pdf version of ITU-T Recommendation G.8081 can be downloaded from the link below: ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html From owner-ccamp@ops.ietf.org Thu Mar 31 10:44:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05111 for ; Thu, 31 Mar 2005 10:44:27 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH1xW-0003S9-UW for ccamp-archive@ietf.org; Thu, 31 Mar 2005 10:51:52 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DH1jZ-000NwT-04 for ccamp-data@psg.com; Thu, 31 Mar 2005 15:37:25 +0000 Received: from [66.129.224.36] (helo=kummer.juniper.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DH1jY-000NwG-6v for ccamp@ops.ietf.org; Thu, 31 Mar 2005 15:37:24 +0000 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j2VFbNXg083389 for ; Thu, 31 Mar 2005 07:37:23 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j2VFbN2i083386 for ; Thu, 31 Mar 2005 07:37:23 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 31 Mar 2005 07:37:23 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: WG last calls Message-ID: <20050331073357.R83270@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi, This is to initiate CCAMP WG last calls on: draft-ietf-ccamp-crankback-04.txt and draft-ietf-ccamp-rsvp-te-exclude-route-03.txt Please send your comments to the list (preferably) or to the authors by April 14, 23:59 GMT (which is when the last calls end). Thanks, Kireeti. ------- From owner-ccamp@ops.ietf.org Thu Mar 31 13:37:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21101 for ; Thu, 31 Mar 2005 13:37:28 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4ez-0001rD-OU for ccamp-archive@ietf.org; Thu, 31 Mar 2005 13:44:56 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DH4Ql-0000jU-8h for ccamp-data@psg.com; Thu, 31 Mar 2005 18:30:11 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DH4Qh-0000iE-4O for ccamp@ops.ietf.org; Thu, 31 Mar 2005 18:30:07 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 1AA6EE000280; Thu, 31 Mar 2005 19:29:57 +0100 (BST) Received: from Puppy ([212.43.203.128] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 19:19:39 +0100 Message-ID: <148201c5361e$72138d90$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" , , "Scott Bradner" References: <037801c524d6$39035c50$a4858182@Puppy> Subject: Please review: Draft liaison to ITU-T Q14/15 on crankback Date: Thu, 31 Mar 2005 15:30:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 31 Mar 2005 18:19:40.0220 (UTC) FILETIME=[342CD7C0:01C5361E] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Based on the comments at Minneapolis and on the list, here is a draft liaison to go to ITU-T Q14/15. Please review and comment. Thanks, Adrian ======= To: Mr. Kam Lam, Rapporteur ITU-T Q14/15 From: Adrian Farrel and Kireeti Kompella Co-chairs of IETF CCAMP Working Group Subject: Inclusion of Crankback in G.7713 For: Action Deadline: May 1st 2005 Dear Mr. Lam, Thank you for your recent response liaison on Crankback. The CCAMP working group is pleased to hear that our work on crankback is of use to your Question and looks forward to seeing inclusion of crankback within G.7713, and to the specific inclusion of protocol elements in G.7713.2. In order to increase the convergence between the work of our two organizations, the CCAMP working group would welcome the opportunity to review and comment on these inclusions before they are presented for consent. Thank you. Adrian Farrel and Kireeti Kompella From owner-ccamp@ops.ietf.org Thu Mar 31 13:41:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21588 for ; Thu, 31 Mar 2005 13:41:44 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4j9-0001yl-41 for ccamp-archive@ietf.org; Thu, 31 Mar 2005 13:49:12 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DH4WX-0001PL-Lc for ccamp-data@psg.com; Thu, 31 Mar 2005 18:36:09 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DH4WM-0001O2-RE for ccamp@ops.ietf.org; Thu, 31 Mar 2005 18:35:58 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 19D69E000224; Thu, 31 Mar 2005 19:35:58 +0100 (BST) Received: from Puppy ([212.43.203.128] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 19:19:47 +0100 Message-ID: <148501c5361e$76d9ef40$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Jean Philippe Vasseur'" References: <9473683187ADC049A855ED2DA739ABCA060C8976@KCCLUST06EVS1.ugd.att.com> Subject: draft-vasseur-ccamp-inter-domain-pd-path-comp Date: Thu, 31 Mar 2005 18:02:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 31 Mar 2005 18:19:48.0095 (UTC) FILETIME=[38DE78F0:01C5361E] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Not exactly overwhelmed by positive response, but not negative comments received, so since this draft is one of the set of inter-domain drafts we will take it into the fold. JP, please republish as draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt with only the following changes: - dates, name etc. - inclusion of the agreed additional sentence for clarification - any changes to pass the idnits script Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Mar 31 13:42:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21696 for ; Thu, 31 Mar 2005 13:42:40 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4k3-000201-Pb for ccamp-archive@ietf.org; Thu, 31 Mar 2005 13:50:08 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DH4WT-0001Om-4D for ccamp-data@psg.com; Thu, 31 Mar 2005 18:36:05 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DH4WQ-0001OQ-27 for ccamp@ops.ietf.org; Thu, 31 Mar 2005 18:36:02 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 5FC29E0004CF for ; Thu, 31 Mar 2005 19:35:58 +0100 (BST) Received: from Puppy ([212.43.203.128] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 19:19:49 +0100 Message-ID: <148601c5361e$77d62990$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Considering draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt as a WG draft Date: Thu, 31 Mar 2005 18:06:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 31 Mar 2005 18:19:50.0407 (UTC) FILETIME=[3A3F4170:01C5361E] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Hi, This draft is the product of a DT set up by the WG so it is appropriate that the draft become a WG draft. Please speak up now if you feel strongly against this. Thanks, Adrian ----- Original Message ----- From: To: Sent: Wednesday, March 23, 2005 10:10 PM Subject: I-D ACTION:draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Evaluation of existing Routing Protocols against > ASON routing requirements > Author(s) : J. Drake, et al. > Filename : draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt > Pages : 0 > Date : 2005-3-23 > > The Generalized MPLS (GMPLS) suite of protocols has been defined to > control different switching technologies as well as different > applications. These include support for requesting TDM connections > including SONET/SDH and Optical Transport Networks (OTNs). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------- ------ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > From owner-ccamp@ops.ietf.org Thu Mar 31 13:51:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22705 for ; Thu, 31 Mar 2005 13:51:52 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4sv-0002Q1-NZ for ccamp-archive@ietf.org; Thu, 31 Mar 2005 13:59:18 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DH4f0-0002M9-Ms for ccamp-data@psg.com; Thu, 31 Mar 2005 18:44:54 +0000 Received: from [209.219.209.75] (helo=ckmso2.proxy.att.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DH4ez-0002Lv-Bj for ccamp@ops.ietf.org; Thu, 31 Mar 2005 18:44:53 +0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j2VIiYbt021415 for ; Thu, 31 Mar 2005 13:44:52 -0500 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (7.2.052) id 423DAD7E0020E8FC; Thu, 31 Mar 2005 13:44:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Please review: Draft liaison to ITU-T Q14/15 on crankback Date: Thu, 31 Mar 2005 12:44:51 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA060C89BE@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Please review: Draft liaison to ITU-T Q14/15 on crankback Thread-Index: AcU2IAlUlNvuVecuRp+fJMkCPzm0tgAAYlvA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , Cc: "Ash, Gerald R \(Jerry\), ALABS" , "Kireeti Kompella" , , "Scott Bradner" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: quoted-printable > Please review and comment. Looks good Adrian. From breton@accessus.net Thu Mar 31 14:30:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25995 for ; Thu, 31 Mar 2005 14:30:15 -0500 (EST) Received: from [218.13.45.107] (helo=218.13.45.107) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH5U2-0003vY-Bk for ccamp-archive@ietf.org; Thu, 31 Mar 2005 14:37:42 -0500 Message-ID: <7dab01c53625$2aa14d69$bb2c8771@accessus.net> From: "Paul A. Davis" To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?VmlhZ3JhIC0gJDEuOTkvZG9zZQ==?= Date: Thu, 31 Mar 2005 19:15:02 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_F340005A.287BEA54" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 14.7 (++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_F340005A.287BEA54 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_25C64538.13FE9764" ------=_NextPart_001_0001_25C64538.13FE9764 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Stable & full erections Long effects duration No prescription needed 2 popular medicines: Cialis - http://www.evermed.biz/sv/ Viagra - http://www.evermed.biz/vt/ Directly from the manufacturer! _________________________________________________________________________ To change your mail details, go here: http://www.evermed.biz/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_25C64538.13FE9764 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit

Rock hard erections
Long-lasting effects
No prescription required

Give it a try!
CIALIS - http://www.evermed.biz/sv/
VIAGRA - http://www.evermed.biz/vt/

Directly from the manufacturer!


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

------=_NextPart_001_0001_25C64538.13FE9764-- ------=_NextPart_000_0000_F340005A.287BEA54-- From owner-ccamp@ops.ietf.org Thu Mar 31 22:45:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13243 for ; Thu, 31 Mar 2005 22:45:32 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHDDS-0006aT-AU for ccamp-archive@ietf.org; Thu, 31 Mar 2005 22:53:04 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHCwf-000EBy-QN for ccamp-data@psg.com; Fri, 01 Apr 2005 03:35:41 +0000 Received: from [61.144.161.54] (helo=huawei.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHCwa-000EBR-NK for ccamp@ops.ietf.org; Fri, 01 Apr 2005 03:35:37 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IE9002K50S88P@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Fri, 01 Apr 2005 11:38:32 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IE9003Q60S7YJ@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Fri, 01 Apr 2005 11:38:32 +0800 (CST) Received: from z18605 ([10.110.100.105]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IE9006MT0S3WO@szxml02-in.huawei.com>; Fri, 01 Apr 2005 11:38:27 +0800 (CST) Date: Fri, 01 Apr 2005 11:13:28 +0800 From: Zhang Renhai Subject: Re: WG last calls To: Adrian Farrel , ccamp@ops.ietf.org, Kireeti Kompella Message-id: <000e01c53668$c9abb7e0$69646e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20050331073357.R83270@kummer.juniper.net> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7BIT Hi,Adrian From draft-ietf-ccamp-crankback-04.txt ,section 4.5, the number of crankback rerouting is limited, so there will be a result: there is another LSP,but for the reason of limiting, the path may be not found. I think sometimes it is unacceptable.The LSP may be prefered to enhancing performance. Regards, Zhang ----- Original Message ----- From: "Kireeti Kompella" To: Sent: Thursday, March 31, 2005 11:37 PM Subject: WG last calls > Hi, > > This is to initiate CCAMP WG last calls on: > > draft-ietf-ccamp-crankback-04.txt > > and > > draft-ietf-ccamp-rsvp-te-exclude-route-03.txt > > Please send your comments to the list (preferably) or to the authors > by April 14, 23:59 GMT (which is when the last calls end). > > Thanks, > Kireeti. > ------- > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 31 Mar 2005 18:46:09 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Please review: Draft liaison to ITU-T Q14/15 on crankback Date: Thu, 31 Mar 2005 12:44:51 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA060C89BE@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Please review: Draft liaison to ITU-T Q14/15 on crankback Thread-Index: AcU2IAlUlNvuVecuRp+fJMkCPzm0tgAAYlvA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , Cc: "Ash, Gerald R \(Jerry\), ALABS" , "Kireeti Kompella" , , "Scott Bradner" > Please review and comment. Looks good Adrian. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 31 Mar 2005 18:36:23 +0000 Message-ID: <148601c5361e$77d62990$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Considering draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt as a WG draft Date: Thu, 31 Mar 2005 18:06:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, This draft is the product of a DT set up by the WG so it is appropriate that the draft become a WG draft. Please speak up now if you feel strongly against this. Thanks, Adrian ----- Original Message ----- From: To: Sent: Wednesday, March 23, 2005 10:10 PM Subject: I-D ACTION:draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Evaluation of existing Routing Protocols against > ASON routing requirements > Author(s) : J. Drake, et al. > Filename : draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt > Pages : 0 > Date : 2005-3-23 > > The Generalized MPLS (GMPLS) suite of protocols has been defined to > control different switching technologies as well as different > applications. These include support for requesting TDM connections > including SONET/SDH and Optical Transport Networks (OTNs). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------- ------ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 31 Mar 2005 18:36:15 +0000 Message-ID: <148501c5361e$76d9ef40$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Jean Philippe Vasseur'" Subject: draft-vasseur-ccamp-inter-domain-pd-path-comp Date: Thu, 31 Mar 2005 18:02:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Not exactly overwhelmed by positive response, but not negative comments received, so since this draft is one of the set of inter-domain drafts we will take it into the fold. JP, please republish as draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt with only the following changes: - dates, name etc. - inclusion of the agreed additional sentence for clarification - any changes to pass the idnits script Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 31 Mar 2005 18:31:20 +0000 Message-ID: <148201c5361e$72138d90$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" , , "Scott Bradner" Subject: Please review: Draft liaison to ITU-T Q14/15 on crankback Date: Thu, 31 Mar 2005 15:30:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Based on the comments at Minneapolis and on the list, here is a draft liaison to go to ITU-T Q14/15. Please review and comment. Thanks, Adrian ======= To: Mr. Kam Lam, Rapporteur ITU-T Q14/15 From: Adrian Farrel and Kireeti Kompella Co-chairs of IETF CCAMP Working Group Subject: Inclusion of Crankback in G.7713 For: Action Deadline: May 1st 2005 Dear Mr. Lam, Thank you for your recent response liaison on Crankback. The CCAMP working group is pleased to hear that our work on crankback is of use to your Question and looks forward to seeing inclusion of crankback within G.7713, and to the specific inclusion of protocol elements in G.7713.2. In order to increase the convergence between the work of our two organizations, the CCAMP working group would welcome the opportunity to review and comment on these inclusions before they are presented for consent. Thank you. Adrian Farrel and Kireeti Kompella Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 31 Mar 2005 15:38:23 +0000 Date: Thu, 31 Mar 2005 07:37:23 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: WG last calls Message-ID: <20050331073357.R83270@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, This is to initiate CCAMP WG last calls on: draft-ietf-ccamp-crankback-04.txt and draft-ietf-ccamp-rsvp-te-exclude-route-03.txt Please send your comments to the list (preferably) or to the authors by April 14, 23:59 GMT (which is when the last calls end). Thanks, Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 31 Mar 2005 11:41:00 +0000 Message-ID: <13f501c535e5$b40d2370$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaison received from ITU-T Q3/15 Date: Thu, 31 Mar 2005 12:34:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, We have received a liaison statement from ITU-T Study Group 15 Question 3. This liaison is for our information and contains a copy of Recommendation G.8081 "Terms and definitions for Automatically Switched Optical Networks". The authors of the GMPLS/ASON lexicography will need to examine this Recommendation to ensure alignment with ASON terminology. The text of the liaison is found below. A copy of the liaison and the Recommendation can be found at http://www.olddog.co.uk/incoming.htm (Beware that the ITU-T FTP site is quite slow.) Thanks, Adrian === From: Hiroshi Ohta, Rapporteur, Q.3/15 To: IETF ccamp WG For: Information Subject: G.8081: Terms and definitions for ASON We are pleased to send you the ITU-T Recommendation G.8081, "Terms and definitions for Automatically Switched Optical Networks". We believe this Recommendation is useful to develop consistent standards related to GMPLS and ASON. We hope to collaborate further for future development. As usual a pdf version of ITU-T Recommendation G.8081 can be downloaded from the link below: ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Mar 2005 23:31:15 +0000 Message-Id: <6.1.2.0.2.20050330180027.04a175b8@mo-ex1> Date: Wed, 30 Mar 2005 18:29:57 -0500 To: "Adrian Farrel" From: Lou Berger Subject: Re: Comments on draft-ietf-ccamp-gmpls-segment-recovery-01.txt Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Adrian, Thanks for the comments. The editorial comments will be integrated into the next rev. Will cover the 1 technical comment (on section 6.1) in a separate e-mail. Lou At 07:35 AM 3/29/2005, Adrian Farrel wrote: >Hi, > >Working group last call has ended for this draft. As a co-author I held >off making comments during WG last call, but as WG chair I wanted to raise >a couple of points. > >Thanks, >Adrian > >=== >Need to run idnits and fix all errors and warnings >=== >Opening boilerplate. >Replace first paragraph with... > This document is an Internet-Draft and is subject to all provisions > of Section 3 of RFC 3667. By submitting this Internet-Draft, each > author represents that any applicable patent or other IPR claims of > which he or she is aware have been or will be disclosed, and any of > which he or she become aware will be disclosed, in accordance with > RFC 3668. >=== >Abstract >Expand "LSP" >=== >Abstract >OLD > intended to be compliment and be consistent with the Extensions for >NEW > intended to compliment and be consistent with the Extensions for >=== >Abstract >Don't use square brace citations in the abstract. >=== >Section 1 >OLD > The extensions defined in this document allow for support of the full > set of recovery types supported by [E2E-RECOVERY] on a segment, or > portion of the LSP, basis. >NEW > The extensions defined in this document allow for support of the full > set of recovery types supported by [E2E-RECOVERY], but applied to any > segment, or to any portion of the LSP. >=== >Section 2 >OLD > failure, or failure over a particularly portion of a network used by >NEW > failure, or failure over a particular portion of a network used by > ^ >=== >Section 2.1 >OLD > Three approaches of end-to-end protection are defined in [E2E- >NEW > Three approaches for end-to-end protection are defined in [E2E- >=== >Section 2.1 >OLD > counterparts. Each behaves just like there end-to-end counterparts, >NEW > counterparts. Each behaves just like its end-to-end counterpart, > ^^^ ^ >=== >Section 2.1 and section 2.2 >Cross-references are all (presumably) to [E2E-RECOVERY]. This is not clear. >=== >Section 3 >OLD > [E2E-RECOVERY]. In this document we define a new type to support >NEW > [E2E-RECOVERY]. In this document we define a new value for the > Association Type field to support >=== >Section 4 >OLD > When upstream control of branch and merge nodes are not desired, >NEW > When upstream control of branch and merge nodes is not desired, >=== >Section 4.1.1 >The definition of the Type value for the Protection sub-object should not >be here. It should be in the IANA section and under IANA control. >=== >Section 4.1.1 >Need to include a definition of the Length field. This can point to RFC3209. >=== >Section 4.1.1 >Need to state the rules for the Reserved bits. >=== >Section 4.2.4.2 > Once the ingress receives all expected Resv messages MUST follow the > tear down procedure described in the Section 4.2.4. >Assume this means 4.2.4.1? >=== >Section 5.1 > The protection subobject defined in [E2E-RECOVERY] can also be used > in SECONDARY_RECORD_ROUTE objects. >No. It is defined in section 4.1.1 of this document. >=== >Section 6.1 >OLD > LSP Segment Recovery Flags are carried in the Protection object C- > Type defined in [E2E-RECOVERY]. The format of the flags are: >NEW > LSP Segment Recovery Flags are carried in the Protection object of the > same C- > Type defined in [E2E-RECOVERY]. The format of the flags are: >=== >Section 6.1 >*** >Same question as for E2E-RECOVERY. Why do we need to use a new C-Type >(compared with the old definition of the Protection object)? >It is possible to carry all of the additional information within the old >Protection object format. >*** >=== >Section 6.1 > (LSP) Segment (Recovery) Flags: 6 bits >Not _entirely_ clear which fields in the figure are referred to by this text. >=== >Section 8 >Is it true that there are _no_ additional security considerations? >Suppose that I am able to doctor a Path message by adding an SERO. This >would cause the data to be duplicated to my chosen destination without >impacting the real destination (i.e. without raising an alarm). >Doesn't segment protection actually improve the security of the network by >making data delivery more robust? >=== >Section 9 first para. >It is not clear what action (if any) IANA is expected to take for this >information. If action is required, it would be helpful to point to the >relevant text within the draft. >=== >Section 9 second para. >There are some TBAs embedded in the text (section 4, section 5) that >relate to this paragraph). Need either to include "IANA" with the TBA, or >put a back pointer in this paragraph (or both). >=== >Section 10 >Obsoleted by section 14 >=== >Section 11.1 >Does [FRR] need to be a normative reference? Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Mar 2005 20:35:42 +0000 Message-Id: <200503302033.PAA07147@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-functional-04.txt Date: Wed, 30 Mar 2005 15:33:27 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification Author(s) : J. Lang, et al. Filename : draft-ietf-ccamp-gmpls-recovery-functional-04.txt Pages : 20 Date : 2005-3-30 This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e. protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-functional-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-30150921.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-functional-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-30150921.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Mar 2005 20:35:34 +0000 Message-Id: <200503302033.PAA07181@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-06.txt Date: Wed, 30 Mar 2005 15:33:58 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-recovery-terminology-06.txt Pages : 20 Date : 2005-3-30 This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-terminology-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-30150928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-terminology-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-30150928.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Mar 2005 20:35:26 +0000 Message-Id: <200503302032.PAA07007@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-analysis-05.txt Date: Wed, 30 Mar 2005 15:32:35 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) Author(s) : D. Papadimitriou, E. Mannie Filename : draft-ietf-ccamp-gmpls-recovery-analysis-05.txt Pages : 42 Date : 2005-3-30 This document provides an analysis grid to evaluate, compare and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with respect to the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in a companion document. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-analysis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-30150909.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-analysis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-30150909.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Mar 2005 11:54:59 +0000 Message-ID: <134001c5351e$6dc9a630$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Igor Bryskin" Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-01.txt Date: Wed, 30 Mar 2005 12:26:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Igor and I have submitted a new copy of this draft and we now have our asbestos suits on. Please comment. This revision includes the outcome of quite a few discussions with the ASON cognoscenti, but we are pretty convinced that we do not have everything right yet. You review thoughts would be most appreciated if they were accompanied by suggested text revisions. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Tuesday, March 29, 2005 4:56 PM Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : A Lexicography for the Interpretation of Generalized > Multiprotocol Label Switching (GMPLS) Terminology within > The Context of the ITU-T's Automatically Switched Optical > Network (ASON) Architecture > Author(s) : I. Bryskin, A. Farrel > Filename : draft-ietf-ccamp-gmpls-ason-lexicography-01.txt > Pages : 15 > Date : 2005-3-28 > > Generalized Multiprotocol Label Switching (GMPLS) has been developed > by the IETF to facilitate the establishment of Label Switched Paths > (LSPs) in a variety of physical technologies and across several > architectural models. The ITU-T has specified an architecture for > the management of Automatically Switched Optical Networks (ASON). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-gmpls-ason-lexicography-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------- ------ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Mar 2005 15:57:26 +0000 Message-Id: <200503291556.KAA11395@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-01.txt Date: Tue, 29 Mar 2005 10:56:28 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within The Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture Author(s) : I. Bryskin, A. Farrel Filename : draft-ietf-ccamp-gmpls-ason-lexicography-01.txt Pages : 15 Date : 2005-3-28 Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of physical technologies and across several architectural models. The ITU-T has specified an architecture for the management of Automatically Switched Optical Networks (ASON). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ason-lexicography-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-29112842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-lexicography-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-29112842.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Mar 2005 13:29:25 +0000 Message-ID: <127e01c53462$2a7f1ca0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: I-D ACTION:draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt Date: Tue, 29 Mar 2005 14:17:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Not sure why this was not copied to the CCAMP list. Anyway... Alan raised an interesting question about how to handle IPv6 sources and destinations in the TE MIBs for MPLS and GMPLS. This draft is an attempt to define a process for managing the existing MPLS TE MIB so that it can handle this case. Since the GMPLS MIBs are built on the MPLS MIBs, this is equally applicable to the GMPLS TE MIB. In the long term it will become clearer whether IPv6 and MPLS/GMPLS need to become more closely integrated, but this is probably a few years away. At that time the MPLS MIBs are quite likely to be ready for a rework, and so IPv6 sources and destinations can be included at that time. We would appreciate a quick turn-around from you in commenting on this draft so that we can: - make it a CCAMP draft if appropriate - last call it at the same time as the GMPLS MIB drafts. Thanks, Adrian ----- Original Message ----- From: To: Sent: Monday, March 28, 2005 5:03 PM Subject: I-D ACTION:draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Handling IPv6 Sources and Destinations in the MPLS > and GMPLS TE MIB Modules > Author(s) : A. Davey, et al. > Filename : draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt > Pages : 7 > Date : 2005-3-25 > > This document describes how to configure or monitor a Multiprotocol > Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineered > (TE) Label Switched Path (LSP) using the MPLS and GMPLS TE MIB module > where the ingress and/or egress routers are identified using IPv6 > addresses. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------- ------ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Mar 2005 13:07:22 +0000 Message-ID: <123501c5345f$b7c537a0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: WG last call complete on Recovery Signaling drafts Date: Tue, 29 Mar 2005 13:38:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Authors/editors, Please pick up all of the comments from the mailing list and either demonstrate that no changes are needed or respin your drafts. Let me know when you are done. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Mar 2005 13:07:18 +0000 Message-ID: <123401c5345f$b3d18f40$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Comments on draft-ietf-ccamp-gmpls-segment-recovery-01.txt Date: Tue, 29 Mar 2005 13:35:03 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_11EF_01C53464.1CEB8C20" This is a multi-part message in MIME format. ------=_NextPart_000_11EF_01C53464.1CEB8C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Working group last call has ended for this draft. As a co-author I held = off making comments during WG last call, but as WG chair I wanted to = raise a couple of points. Thanks, Adrian =3D=3D=3D Need to run idnits and fix all errors and warnings =3D=3D=3D Opening boilerplate. Replace first paragraph with... This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. =3D=3D=3D Abstract Expand "LSP" =3D=3D=3D Abstract OLD intended to be compliment and be consistent with the Extensions for NEW intended to compliment and be consistent with the Extensions for =3D=3D=3D Abstract Don't use square brace citations in the abstract. =3D=3D=3D Section 1 OLD The extensions defined in this document allow for support of the full set of recovery types supported by [E2E-RECOVERY] on a segment, or portion of the LSP, basis.=20 NEW The extensions defined in this document allow for support of the full set of recovery types supported by [E2E-RECOVERY], but applied to any = segment, or to any portion of the LSP. =3D=3D=3D Section 2 OLD failure, or failure over a particularly portion of a network used by NEW failure, or failure over a particular portion of a network used by ^=20 =3D=3D=3D Section 2.1 OLD Three approaches of end-to-end protection are defined in [E2E- NEW Three approaches for end-to-end protection are defined in [E2E- =3D=3D=3D Section 2.1 OLD counterparts. Each behaves just like there end-to-end counterparts, NEW counterparts. Each behaves just like its end-to-end counterpart, ^^^ ^ =3D=3D=3D Section 2.1 and section 2.2 Cross-references are all (presumably) to [E2E-RECOVERY]. This is not = clear. =3D=3D=3D Section 3 OLD [E2E-RECOVERY]. In this document we define a new type to support NEW [E2E-RECOVERY]. In this document we define a new value for the = Association Type field to support =3D=3D=3D Section 4 OLD When upstream control of branch and merge nodes are not desired, NEW When upstream control of branch and merge nodes is not desired, =3D=3D=3D Section 4.1.1 The definition of the Type value for the Protection sub-object should = not be here. It should be in the IANA section and under IANA control. =3D=3D=3D Section 4.1.1 Need to include a definition of the Length field. This can point to = RFC3209. =3D=3D=3D Section 4.1.1 Need to state the rules for the Reserved bits. =3D=3D=3D Section 4.2.4.2 Once the ingress receives all expected Resv messages MUST follow the tear down procedure described in the Section 4.2.4. Assume this means 4.2.4.1? =3D=3D=3D Section 5.1 The protection subobject defined in [E2E-RECOVERY] can also be used in SECONDARY_RECORD_ROUTE objects. No. It is defined in section 4.1.1 of this document. =3D=3D=3D Section 6.1 OLD LSP Segment Recovery Flags are carried in the Protection object C- Type defined in [E2E-RECOVERY]. The format of the flags are: NEW LSP Segment Recovery Flags are carried in the Protection object of = the same C- Type defined in [E2E-RECOVERY]. The format of the flags are: =3D=3D=3D Section 6.1 *** Same question as for E2E-RECOVERY. Why do we need to use a new C-Type = (compared with the old definition of the Protection object)? It is possible to carry all of the additional information within the old = Protection object format. *** =3D=3D=3D Section 6.1 (LSP) Segment (Recovery) Flags: 6 bits Not _entirely_ clear which fields in the figure are referred to by this = text. =3D=3D=3D Section 8 Is it true that there are _no_ additional security considerations? Suppose that I am able to doctor a Path message by adding an SERO. This = would cause the data to be duplicated to my chosen destination without = impacting the real destination (i.e. without raising an alarm). Doesn't segment protection actually improve the security of the network = by making data delivery more robust? =3D=3D=3D Section 9 first para. It is not clear what action (if any) IANA is expected to take for this = information. If action is required, it would be helpful to point to the = relevant text within the draft. =3D=3D=3D Section 9 second para. There are some TBAs embedded in the text (section 4, section 5) that = relate to this paragraph). Need either to include "IANA" with the TBA, = or put a back pointer in this paragraph (or both). =3D=3D=3D Section 10 Obsoleted by section 14 =3D=3D=3D Section 11.1 Does [FRR] need to be a normative reference? ------=_NextPart_000_11EF_01C53464.1CEB8C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Working group last call has ended for = this draft.=20 As a co-author I held off making comments during WG last call, but = as WG=20 chair I wanted to raise a couple of points.
 
Thanks,
Adrian
 
=3D=3D=3D
Need to run idnits and fix all errors = and=20 warnings
=3D=3D=3D
Opening boilerplate.
Replace first paragraph = with...
   This document is an = Internet-Draft=20 and is subject to all provisions
   of Section 3 of RFC = 3667. =20 By submitting this Internet-Draft, each
   author = represents that=20 any applicable patent or other IPR claims of
   which he or = she is=20 aware have been or will be disclosed, and any of
   which = he or she=20 become aware will be disclosed, in accordance with
   RFC=20 3668.
=3D=3D=3D
Abstract
Expand "LSP"
=3D=3D=3D
Abstract
OLD
   intended to be = compliment and be=20 consistent with the Extensions for
NEW
   intended = to compliment and be=20 consistent with the Extensions for
=3D=3D=3D
Abstract
Don't use square brace citations in = the=20 abstract.
=3D=3D=3D
Section 1
OLD
   The extensions defined = in this=20 document allow for support of the full
   set of recovery = types=20 supported by [E2E-RECOVERY] on a segment, or
   portion of = the LSP,=20 basis. 
NEW
   The extensions defined = in this=20 document allow for support of the full
   set of recovery = types=20 supported by [E2E-RECOVERY], but applied to any
   segment, or to = any portion of=20 the LSP.
=3D=3D=3D
Section 2
OLD
   failure, or failure over = a=20 particularly portion of a network used by
NEW
   failure, or failure over = a=20 particular portion of a network used by
          &nbs= p;            = ;            =      ^=20
=3D=3D=3D
Section 2.1
OLD
   Three approaches of = end-to-end=20 protection are defined in [E2E-
NEW
   Three = approaches for end-to-end=20 protection are defined in [E2E-
=3D=3D=3D
Section 2.1
OLD
   = counterparts.  Each=20 behaves just like there end-to-end counterparts,
NEW
   counterparts.  Each = behaves=20 just like its end-to-end counterpart,
          &nbs= p;            = ;            =       ^^^     &nbs= p;            = ;    =20 ^
=3D=3D=3D
Section 2.1 and section = 2.2
Cross-references are all (presumably) = to=20 [E2E-RECOVERY]. This is not clear.
=3D=3D=3D
Section 3
OLD
   [E2E-RECOVERY].  In = this=20 document we define a new type to support
NEW
   [E2E-RECOVERY].  In = this=20 document we define a new value for the Association Type field to=20 support
=3D=3D=3D
Section 4
OLD
   When upstream control of = branch and=20 merge nodes are not desired,
NEW
   When upstream control of = branch and=20 merge nodes is not desired,
=3D=3D=3D
Section 4.1.1
The definition of the Type value for = the=20 Protection sub-object should not be here. It should be in the IANA = section and=20 under IANA control.
=3D=3D=3D
Section 4.1.1
Need to include a definition of the = Length field.=20 This can point to RFC3209.
=3D=3D=3D
Section 4.1.1
Need to state the rules for the = Reserved=20 bits.
=3D=3D=3D
Section 4.2.4.2
   Once the ingress = receives all=20 expected Resv messages MUST follow the
   tear down = procedure=20 described in the Section 4.2.4.
Assume this means = 4.2.4.1?
=3D=3D=3D
Section 5.1
   The protection subobject = defined in=20 [E2E-RECOVERY] can also be used
   in = SECONDARY_RECORD_ROUTE=20 objects.
No. It is defined in section 4.1.1 of this = document.
=3D=3D=3D
Section 6.1
OLD
   LSP Segment Recovery = Flags are=20 carried in the Protection object C-
   Type defined in=20 [E2E-RECOVERY].  The format of the flags are:
NEW
   LSP Segment Recovery = Flags are=20 carried in the Protection object of the same C-
   Type defined in=20 [E2E-RECOVERY].  The format of the flags = are:
=3D=3D=3D
Section 6.1
***
Same question as for E2E-RECOVERY. = Why do we need=20 to use a new C-Type (compared with the old definition of the Protection=20 object)?
It is possible to carry all of the = additional=20 information within the old Protection object format.
***
=3D=3D=3D
Section 6.1
      (LSP) = Segment=20 (Recovery) Flags: 6 bits
Not _entirely_ clear which fields in = the figure=20 are referred to by this text.
=3D=3D=3D
Section 8
Is it true that there are _no_ = additional=20 security considerations?
Suppose that I am able to doctor a = Path message=20 by adding an SERO. This would cause the data to be duplicated to my = chosen=20 destination without impacting the real destination (i.e. without raising = an=20 alarm).
Doesn't segment protection actually = improve the=20 security of the network by making data delivery more = robust?
=3D=3D=3D
Section 9 first para.
It is not clear what action (if any) = IANA is=20 expected to take for this information. If action is required, it would = be=20 helpful to point to the relevant text within the draft.
=3D=3D=3D
Section 9 second para.
There are some TBAs embedded in the = text (section=20 4, section 5) that relate to this paragraph). Need either to include = "IANA" with=20 the TBA, or put a back pointer in this paragraph (or both).
=3D=3D=3D
Section 10
Obsoleted by = section 14
=3D=3D=3D
Section 11.1
Does [FRR] need to be a normative=20 reference?
------=_NextPart_000_11EF_01C53464.1CEB8C20-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 28 Mar 2005 12:29:22 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: WG drafts - My correction Date: Mon, 28 Mar 2005 06:25:32 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA060C8976@KCCLUST06EVS1.ugd.att.com> Thread-Topic: WG drafts - My correction Thread-Index: AcUvPpgKC5q1cD9uQm+wyVzO7ctyiAEUk1ZA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , Cc: "Ash, Gerald R \(Jerry\), ALABS" > 3. The name of the third draft is > draft-vasseur-ccamp-inter-domain-pd-path-comp. > This is the draft that we need to consider. > ... > are we content to accept this draft as a WG draft? Yes. Thanks, Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Mar 2005 21:31:41 +0000 Sensitivity: Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: "Amit 70405 Cc: "Adrian Farrel , "Igor Bryskin , "ccamp" , "Sasha" Message-ID: From: "Diego Caviglia" Date: Fri, 25 Mar 2005 22:30:10 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Amit, it seems to me that we are mixing different issues here (a part from the fact that may be we need to change the subject of the thread). First point I think that link protection and path protection leads to different problem. In case of link protection it is quite simple to solve the issue; data plane protecting link is hidden to the control plane and a hold-off timer is used in order to separate data plane protection mechanism from control plane restoration. In case of path protection thing are different and I think are not solved, or at least not solved in CCAMP/ITU-T. The main issue I see in this field is the interworking between MS-SPRing protection and control plane restoration. It is a matter of fact that MS-SPRing is one of the most used inherent protection scheme in SDH network but up to now we don't have a 'standard' way to let MS-SPRing to interwork with control plane restoration scheme (e.g. timeslot interchange and squelching problem) I've again to mention the WG chair here and ask him if this kind issues are in the scope of the CCAMP. Regards Diego Amit 70405 on 25/03/2005 02.41.04 To: Adrian Farrel , Igor Bryskin cc: Diego Caviglia , ccamp@ops.ietf.org, Sasha@AXERRA.com Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Hi Adrian & Igor, But there is one issue with this multilayer protection. Say in the case if the link gets broken, and the lower layer protection has succeeded. In this case, should the control plane(higher layer) be notified by the lower layer of link?? If yes than it has following consequences: - As control plane is unaware of any failure, control plane will continue to setup new connections on the failed. - This may not be a good thing to do. - Some means may be needed to avoid this link in Path computation. If no than following are the consequences: - Control plane too will go ahead with its protection mechanism. Let me know your view. Regards, Amit. ----- Original Message ----- From: Adrian Farrel Date: Thursday, March 24, 2005 7:40 pm Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration > Hi Amit, > > > Do you mean to say that Data plane & Control plane protection > shouldbe independant of each other?? > > No, I mean that they MAY be independent. > In particular, if you are using the control plane *and* the data > plane to > manage protection on the same set of resources you are bound to > get in a > horrible mess. > > Seems more reasonable that you would apply data plane protection > first and > then apply control plane protection at a higher level. > > > If so, in case of MSP protection in SDH, > > Control plane should not have any control over the resource pool > > used for MSP switch. > > This may lead to lot of unused resource in the network. > > It is certain that each layer of protection that you install MAY > result in > unused resources. Building multiple layers of protection will, > therefore,potentially build up more and more unused resources. It > is the job of > CCAMP to produce the tools that allow operators to build the > protectionschemes that they want. It's not really our business to > tell them which > schemes to build and when. > > Cheers, > Adrian > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Mar 2005 15:52:33 +0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=5Vsmz/y0dZPHcAnEKdwD2O2B5G9jV45cj84cpVvKpM24qkJz63y1NXm18Kn+cpchGBdR1Ww5iJb6GAQAlD4L/f1QEfJWsyZC5BFDioa7QSztx6I4U10GqxXoEeK2Yp6iokgD0aWhskGr+FGe41uDT6gJsHwpXugK+rCAzg5lsrc= ; Message-ID: <20050325155113.77764.qmail@web30809.mail.mud.yahoo.com> Date: Fri, 25 Mar 2005 07:51:12 -0800 (PST) From: Igor Bryskin Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: Amit 70405 , Adrian Farrel Cc: Diego Caviglia , ccamp@ops.ietf.org, Sasha@AXERRA.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1031285146-1111765872=:74671" --0-1031285146-1111765872=:74671 Content-Type: text/plain; charset=us-ascii Please, ee in-line. Amit 70405 wrote: Hi Adrian & Igor, But there is one issue with this multilayer protection. Say in the case if the link gets broken, and the lower layer protection has succeeded. In this case, should the control plane(higher layer) be notified by the lower layer of link?? IIB>> Control plane needs to verify with the data plane if the fault condition still exists after the hold-off time and start recovery procedures only if necessary. Igor If yes than it has following consequences: - As control plane is unaware of any failure, control plane will continue to setup new connections on the failed. - This may not be a good thing to do. - Some means may be needed to avoid this link in Path computation. If no than following are the consequences: - Control plane too will go ahead with its protection mechanism. Let me know your view. Regards, Amit. ----- Original Message ----- From: Adrian Farrel Date: Thursday, March 24, 2005 7:40 pm Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration > Hi Amit, > > > Do you mean to say that Data plane & Control plane protection > shouldbe independant of each other?? > > No, I mean that they MAY be independent. > In particular, if you are using the control plane *and* the data > plane to > manage protection on the same set of resources you are bound to > get in a > horrible mess. > > Seems more reasonable that you would apply data plane protection > first and > then apply control plane protection at a higher level. > > > If so, in case of MSP protection in SDH, > > Control plane should not have any control over the resource pool > > used for MSP switch. > > This may lead to lot of unused resource in the network. > > It is certain that each layer of protection that you install MAY > result in > unused resources. Building multiple layers of protection will, > therefore,potentially build up more and more unused resources. It > is the job of > CCAMP to produce the tools that allow operators to build the > protectionschemes that they want. It's not really our business to > tell them which > schemes to build and when. > > Cheers, > Adrian > > --------------------------------- Do you Yahoo!? Yahoo! Small Business - Try our new resources site! --0-1031285146-1111765872=:74671 Content-Type: text/html; charset=us-ascii

Please, ee in-line.

Amit 70405 <AmitG@huawei.com> wrote:

Hi Adrian & Igor,
But there is one issue with this multilayer protection.
Say in the case if the link gets broken, and the lower layer protection has succeeded.
In this case, should the control plane(higher layer) be notified by the lower layer of link??

IIB>> Control plane needs to verify with the data plane if the fault condition still exists after the hold-off time and start recovery procedures only if necessary.

Igor

If yes than it has following consequences:
- As control plane is unaware of any failure, control plane will continue to setup new connections on the failed.
- This may not be a good thing to do.
- Some means may be needed to avoid this link in Path computation.

If no than following are the consequences:
- Control plane too will go ahead with its protection mechanism.

Let me know your view.
Regards,
Amit.


----- Original Message -----
From: Adrian Farrel
Date: Thursday, March 24, 2005 7:40 pm
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

> Hi Amit,
>
> > Do you mean to say that Data plane & Control plane protection
> shouldbe independant of each other??
>
> No, I mean that they MAY be independent.
> In particular, if you are using the control plane *and* the data
> plane to
> manage protection on the same set of resources you are bound to
> get in a
> horrible mess.
>
> Seems more reasonable that you would apply data plane protection
> first and
> then apply control plane protection at a higher level.
>
> > If so, in case of MSP protection in SDH,
> > Control plane should not have any control over the resource pool
> > used for MSP switch.
> > This may lead to lot of unused resource in the network.
>
> It is certain that each layer of protection that you install MAY
> result in
> unused resources. Building multiple layers of protection will,
> therefore,potentially build up more and more unused resources. It
> is the job of
> CCAMP to produce the tools that allow operators to build the
> protectionschemes that they want. It's not really our business to
> tell them which
> schemes to build and when.
>
> Cheers,
> Adrian
>
>

 

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! --0-1031285146-1111765872=:74671-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Mar 2005 12:05:20 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoration Date: Fri, 25 Mar 2005 12:03:54 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F1A8C@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Failure definition w.r.t. SONET/SDH and Protection/Restoration Thread-Index: AcUxE+cYWcvvMc0ISg6FWV8FowB2kQAHNVYg From: To: , Cc: , , , You are quite correct Amit. What you need is proper client/server functional decoupling between the layer networks involved. The ideas of a 'common' control-plane (esp routing) from IP to Optics is rather a nonsence in our view.....not just technically either, you need this to provide the key 'network builder service' capability in commercial relationships between operators. Historically things have worked OK in practice because there has been a common-sense approach about how the 3 networking modes of co-cs, co-ps and cl-ps have been nested (there are 9 possible client/server relationships here are there are no formal rules governing how many up/down transitions are allowed in some end-end reference architecture...and remember, a client layer network will inherit the performance of its server layer network, and this is recursive to the duct). PWE3 stuff is turning this on its head wrt XoverY relationships (not that these even ensure the key requirement of client/server independence/transparency anyway)....hopefully most operator folks should have the common sense to see the problems and avoid the pitfalls. In the 2 co modes the defect handling MUST be done in the data-plane and it MUST be unidirectional. There is an OAM requirement to send a signal called FDI (Forward Defect Indication...sometimes know as AIS in co-cs technologies) which is intended to suppress alarm storms (which would otherwise occur in all higher client co mode networks). Has to be like this, esp in the co-cs mode as the control/management-plane is forced to run OOB and it must work the *same* for all methods of trail set-up....be this by signalling protocols X, Y or Z of via management provisioning. regards, neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Amit 70405 > Sent: 25 March 2005 08:23 > To: Diego Caviglia > Cc: Adrian Farrel Subject: Re: Failure definition w.r.t. SONET/SDH and=20 > Protection/Restoration >=20 >=20 > Hi Diego, > Its not only the case with MSP protection. > For that matter any Multilayer protection will have the=20 > interworking issues. > According to me lower layer restoration should be=20 > mandatorily independant of higher layer restoration. > And let the Network operator be aware of the=20 > consequences(mainly some unutilised resources). > =20 > This is the point which I feel that CCAMP should clarify. >=20 > Regards, > Amit. >=20 >=20 >=20 > ----- Original Message ----- > From: Diego Caviglia > Date: Friday, March 25, 2005 3:25 pm > Subject: Re: Failure definition w.r.t. SONET/SDH and=20 > Protection/Restoration >=20 > > Hi Amit, > > actally for link/span protection I don't see any > > problem=20 > > with control plane restoration and data plane protection=20 > interworking. > >=20 > > It is sufficient to hide protection resourse to control plane. > >=20 > > I see a lot of problems (there are SPs opened in the ITU-T > > documents about=20 > > that) when you want an MS-SPRing protected ring to interwork with=20 > > GMPLS=20 > > restoration. > >=20 > > Actually I'm not sure if that topic is in the charter of the CCAMP > > (Adrian=20 > > what is your feeling about this?) but in any case it is a problem. > >=20 > > Regards > >=20 > > Diego > >=20 > >=20 > > To: Adrian Farrel , Igor Bryskin=20 > > cc: Diego Caviglia=20 > > , ccamp@ops.ietf.org, > > Sasha@AXERRA.com=20 > >=20 > > Subject: Re: Failure definition w.r.t. SONET/SDH and=20 > > Protection/Restoration > >=20 > > Hi Adrian & Igor, > > But there is one issue with this multilayer protection. > > Say in the case if the link gets broken, and the lower layer > > protection=20 > > has succeeded. > > In this case, should the control plane(higher layer) be=20 > > notified by the=20 > > lower layer of link?? > >=20 > > If yes than it has following consequences: > > - As control plane is unaware of any failure, control plane > > will=20 > > continue to setup new connections on the failed. > > - This may not be a good thing to do. > > - Some means may be needed to avoid this link in Path computation. > >=20 > > If no than following are the consequences: > > - Control plane too will go ahead with its protection mechanism. > >=20 > > Let me know your view. > > Regards, > > Amit. > >=20 > >=20 > > ----- Original Message ----- > > From: Adrian Farrel > > Date: Thursday, March 24, 2005 7:40 pm > > Subject: Re: Failure definition w.r.t. SONET/SDH and > > Protection/Restoration > >=20 > > > Hi Amit, > > > > > > > Do you mean to say that Data plane & Control plane protection > > > shouldbe independant of each other?? > > > > > > No, I mean that they MAY be independent. > > > In particular, if you are using the control plane *and* the data=20 > > > plane to manage protection on the same set of resources you are=20 > > > bound to get in a > > > horrible mess. > > > > > > Seems more reasonable that you would apply data plane protection=20 > > > first and then apply control plane protection at a higher level. > > > > > > > If so, in case of MSP protection in SDH, > > > > Control plane should not have any control over the > > resource pool > > > > used for MSP switch. > > > > This may lead to lot of unused resource in the network. > > > > > > It is certain that each layer of protection that you install MAY=20 > > > result in unused resources. Building multiple layers of=20 > protection=20 > > > will, therefore,potentially build up more and more unused=20 > resources.=20 > > > It is the job of > > > CCAMP to produce the tools that allow operators to build the > > > protectionschemes that they want. It's not really our business to > > > tell them which > > > schemes to build and when. > > > > > > Cheers, > > > Adrian > > > > > > > >=20 > >=20 > >=20 > >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Mar 2005 08:23:05 +0000 Date: Fri, 25 Mar 2005 16:22:49 +0800 From: Amit 70405 Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: Diego Caviglia Cc: "Adrian Farrel , "Igor Bryskin , ccamp , Sasha Message-id: <104b584104956e.104956e104b584@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline Hi Diego, Its not only the case with MSP protection. For that matter any Multilayer protection will have the interworking issues. According to me lower layer restoration should be mandatorily independant of higher layer restoration. And let the Network operator be aware of the consequences(mainly some unutilised resources). This is the point which I feel that CCAMP should clarify. Regards, Amit. ----- Original Message ----- From: Diego Caviglia Date: Friday, March 25, 2005 3:25 pm Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration > Hi Amit, > actally for link/span protection I don't see any > problem > with control plane restoration and data plane protection interworking. > > It is sufficient to hide protection resourse to control plane. > > I see a lot of problems (there are SPs opened in the ITU-T > documents about > that) when you want an MS-SPRing protected ring to interwork with > GMPLS > restoration. > > Actually I'm not sure if that topic is in the charter of the CCAMP > (Adrian > what is your feeling about this?) but in any case it is a problem. > > Regards > > Diego > > > To: Adrian Farrel , Igor Bryskin > cc: Diego Caviglia > , ccamp@ops.ietf.org, > Sasha@AXERRA.com > > Subject: Re: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > Hi Adrian & Igor, > But there is one issue with this multilayer protection. > Say in the case if the link gets broken, and the lower layer > protection > has succeeded. > In this case, should the control plane(higher layer) be > notified by the > lower layer of link?? > > If yes than it has following consequences: > - As control plane is unaware of any failure, control plane > will > continue to setup new connections on the failed. > - This may not be a good thing to do. > - Some means may be needed to avoid this link in Path computation. > > If no than following are the consequences: > - Control plane too will go ahead with its protection mechanism. > > Let me know your view. > Regards, > Amit. > > > ----- Original Message ----- > From: Adrian Farrel > Date: Thursday, March 24, 2005 7:40 pm > Subject: Re: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > > Hi Amit, > > > > > Do you mean to say that Data plane & Control plane protection > > shouldbe independant of each other?? > > > > No, I mean that they MAY be independent. > > In particular, if you are using the control plane *and* the data > > plane to > > manage protection on the same set of resources you are bound to > > get in a > > horrible mess. > > > > Seems more reasonable that you would apply data plane protection > > first and > > then apply control plane protection at a higher level. > > > > > If so, in case of MSP protection in SDH, > > > Control plane should not have any control over the > resource pool > > > used for MSP switch. > > > This may lead to lot of unused resource in the network. > > > > It is certain that each layer of protection that you install MAY > > result in > > unused resources. Building multiple layers of protection will, > > therefore,potentially build up more and more unused resources. It > > is the job of > > CCAMP to produce the tools that allow operators to build the > > protectionschemes that they want. It's not really our business to > > tell them which > > schemes to build and when. > > > > Cheers, > > Adrian > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Mar 2005 07:32:37 +0000 MIME-Version: 1.0 Sensitivity: To: "Adrian Farrel" Cc: ", " Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Message-ID: From: "Diego Caviglia" Date: Fri, 25 Mar 2005 08:32:28 +0100 Content-Type: multipart/alternative; boundary="=_alternative 00296FB3C1256FCF_=" This is a multipart message in MIME format. --=_alternative 00296FB3C1256FCF_= Content-Type: text/plain; charset="us-ascii" Hi Adrian, I see your points (that doesn't mean I agree ;-)). Given that seems that I'm the only one to ask such kind of statement I think the discussion could stop here. Regards and thanks Diego Please respond to "Adrian Farrel" To: "Diego Caviglia" cc: , Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Hi Diego, >> - The GMPLS control plane does not necessarily want to define data >> plane failures. Rather, it wants to signal (report) errors and allow >> the control plane state (and data plane state) to remain in place. > [dc] Agreed and that was my initial point. Which kind of data plane (e.g. > SDG) defects have to advertised to control plane to trigger restoration? > Given that control plane is concerned in restore the data plane it should > also define what is a failure. It is a fiber break or we have also to > consider other defects? Of course we have. What happens if one > restoration TNE consider as failure only Loss Of Light (LOS) while the > other starts restoration even if there is a e.g. Loss Of Pointer? Is > that acceptable? Let's look at two things. First, the trigger for protection switchover. If you look at section 6.2 of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt (currently in working group last call, so please comment now!) you will see... To co-ordinate the switchover between end-points, an end-to-end switchover request is needed since a failure affecting one the LSPs results in both end-points switching to the other LSP (resulting in receiving traffic from the other LSP) in their respective directions. This is done using the Notify message with a new Error Code indicating "Working LSP Failure (Switchover Request)". This clearly indicates that the objective is not to report a failure, but to request a switchover. Which takes us to your second point: which data plane errors should be reported to the control plane to trigger switchover signaling, and would it matter if different transport nodes applied different policies? My contention is that this is entirely an implementation issue. I think it would be a wise implementation that included some degree of configurability to this function, but that is not in CCAMP's scope. If two "TNEs" have different trigger thresholds I do not see that any harm will be done, it might even be desirable. >> - Decisions that trigger control plane protection actions are >> fundamentally implementation choices. > [dc] Here we are. This is the point. IMHO CCAMP should provide some > guidance on this. > >> Maybe we should make a statement that this type >> of thing SHOULD be configurable so that there is some sort of >> consistency within a network. > [dc] Something like "..control plane restoration mechanism SHOULD be > triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1). But why? It is not enough to know that this is a difficult question for an implementaiton to answer. Why is it not enough to say that the Data Plane should trigger control plane recovery action when the data plane deems that there is a fault from which it determines that recovery is required and from which it is unable or unwilling to recover on its own? If you can show that there is a need to make a more definitive statement then we can consider it. Cheers, Adrian --=_alternative 00296FB3C1256FCF_= Content-Type: text/html; charset="us-ascii"
Hi Adrian,
                  I see your points (that doesn't mean I agree ;-)).

Given that seems that I'm the only one to ask such kind of statement I think the discussion could stop here.

Regards and thanks

Diego

Please respond to "Adrian Farrel" <adrian@olddog.co.uk>

To:        "Diego Caviglia" <Diego.Caviglia@marconi.com>
cc:        <ccamp@ops.ietf.org>, <Sasha@AXERRA.com>

Subject:        Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration



Hi Diego,
 
>> - The GMPLS control plane does not  necessarily want to define data
>>   plane failures. Rather, it  wants to signal (report) errors and allow
>>   the control plane  state (and data plane state) to remain in place.
> [dc] Agreed and that  was my initial point.  Which kind of data plane (e.g.
> SDG)  defects have to advertised to control plane to trigger restoration?   
> Given that control plane is concerned in  restore the data plane it should
> also define what is a failure.  It is a  fiber break or we have also to
> consider other defects? Of course we  have.  What happens if one
> restoration TNE consider as failure  only Loss Of Light (LOS) while the
> other starts restoration even if there  is a e.g. Loss Of Pointer?  Is
> that acceptable?
 
Let's look at two things.
 
First, the trigger for protection switchover. If  you look at section 6.2 of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt  (currently in working group last call, so please comment now!) you will  see...
 
   To co-ordinate the switchover  between end-points, an end-to-end
   switchover request is needed  since a failure affecting one the LSPs
   results in both  end-points switching to the other LSP (resulting in
   receiving  traffic from the other LSP) in their respective
   directions.  This is done using the Notify message with a new Error
   Code  indicating "Working LSP Failure (Switchover Request)".

This clearly indicates that the objective is not  to report a failure, but to request a switchover.
 
Which takes us to your second point: which data  plane errors should be reported to the control plane to trigger switchover  signaling, and would it matter if different transport nodes applied different  policies?
 
My contention is that this is entirely an  implementation issue. I think it would be a wise implementation that included  some degree of configurability to this function, but that is not in CCAMP's  scope. If two "TNEs" have different trigger thresholds I do not see that any  harm will be done, it might even be desirable.
 
>> - Decisions that trigger control plane  protection actions are
>>   fundamentally implementation  choices.
> [dc] Here we are.  This is the point.  IMHO CCAMP  should provide some
> guidance on this.
>
>>   Maybe  we should make a statement that this type
>>   of thing SHOULD be  configurable so that there is some sort of
>>   consistency within  a network.
> [dc] Something like "..control plane restoration mechanism  SHOULD be
> triggered as the SNC/I defined in ITU-T G.783 (section  12.1.1.1).
 
But why?
 
It is not enough to know that this is a difficult  question for an implementaiton to answer.
 
Why is it not enough to say that the Data Plane  should trigger control plane recovery action when the data plane deems that  there is a fault from which it determines that recovery is required and from  which it is unable or unwilling to recover on its own?
 
If you can show that there is a need to make a more definitive statement  then we can consider it.

Cheers,
Adrian

--=_alternative 00296FB3C1256FCF_=-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Mar 2005 07:26:41 +0000 Sensitivity: Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: "Amit 70405 Cc: "Adrian Farrel , "Igor Bryskin , "ccamp" , "Sasha" Message-ID: From: "Diego Caviglia" Date: Fri, 25 Mar 2005 08:25:22 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Amit, actally for link/span protection I don't see any problem with control plane restoration and data plane protection interworking. It is sufficient to hide protection resourse to control plane. I see a lot of problems (there are SPs opened in the ITU-T documents about that) when you want an MS-SPRing protected ring to interwork with GMPLS restoration. Actually I'm not sure if that topic is in the charter of the CCAMP (Adrian what is your feeling about this?) but in any case it is a problem. Regards Diego Amit 70405 on 25/03/2005 02.41.04 To: Adrian Farrel , Igor Bryskin cc: Diego Caviglia , ccamp@ops.ietf.org, Sasha@AXERRA.com Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Hi Adrian & Igor, But there is one issue with this multilayer protection. Say in the case if the link gets broken, and the lower layer protection has succeeded. In this case, should the control plane(higher layer) be notified by the lower layer of link?? If yes than it has following consequences: - As control plane is unaware of any failure, control plane will continue to setup new connections on the failed. - This may not be a good thing to do. - Some means may be needed to avoid this link in Path computation. If no than following are the consequences: - Control plane too will go ahead with its protection mechanism. Let me know your view. Regards, Amit. ----- Original Message ----- From: Adrian Farrel Date: Thursday, March 24, 2005 7:40 pm Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration > Hi Amit, > > > Do you mean to say that Data plane & Control plane protection > shouldbe independant of each other?? > > No, I mean that they MAY be independent. > In particular, if you are using the control plane *and* the data > plane to > manage protection on the same set of resources you are bound to > get in a > horrible mess. > > Seems more reasonable that you would apply data plane protection > first and > then apply control plane protection at a higher level. > > > If so, in case of MSP protection in SDH, > > Control plane should not have any control over the resource pool > > used for MSP switch. > > This may lead to lot of unused resource in the network. > > It is certain that each layer of protection that you install MAY > result in > unused resources. Building multiple layers of protection will, > therefore,potentially build up more and more unused resources. It > is the job of > CCAMP to produce the tools that allow operators to build the > protectionschemes that they want. It's not really our business to > tell them which > schemes to build and when. > > Cheers, > Adrian > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Mar 2005 01:43:50 +0000 Date: Fri, 25 Mar 2005 09:41:04 +0800 From: Amit 70405 Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: Adrian Farrel , Igor Bryskin Cc: Diego Caviglia , ccamp@ops.ietf.org, Sasha@AXERRA.com Message-id: <1016620101793f.101793f1016620@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline Hi Adrian & Igor, But there is one issue with this multilayer protection. Say in the case if the link gets broken, and the lower layer protection has succeeded. In this case, should the control plane(higher layer) be notified by the lower layer of link?? If yes than it has following consequences: - As control plane is unaware of any failure, control plane will continue to setup new connections on the failed. - This may not be a good thing to do. - Some means may be needed to avoid this link in Path computation. If no than following are the consequences: - Control plane too will go ahead with its protection mechanism. Let me know your view. Regards, Amit. ----- Original Message ----- From: Adrian Farrel Date: Thursday, March 24, 2005 7:40 pm Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration > Hi Amit, > > > Do you mean to say that Data plane & Control plane protection > shouldbe independant of each other?? > > No, I mean that they MAY be independent. > In particular, if you are using the control plane *and* the data > plane to > manage protection on the same set of resources you are bound to > get in a > horrible mess. > > Seems more reasonable that you would apply data plane protection > first and > then apply control plane protection at a higher level. > > > If so, in case of MSP protection in SDH, > > Control plane should not have any control over the resource pool > > used for MSP switch. > > This may lead to lot of unused resource in the network. > > It is certain that each layer of protection that you install MAY > result in > unused resources. Building multiple layers of protection will, > therefore,potentially build up more and more unused resources. It > is the job of > CCAMP to produce the tools that allow operators to build the > protectionschemes that they want. It's not really our business to > tell them which > schemes to build and when. > > Cheers, > Adrian > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Mar 2005 19:26:39 +0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=V7lvIqRw/FDpfP5FaYLKCXfWElLRQ0sbOet4HzqpJI+t6g33BGl3o3EMg8fGsbmbc+5WYVhgUKbXgeGMCf7EJUK0kj5nWMTyLcXj9MdFybzO/BjC0rQmxuENs0jo5dhekjmot/mtX4IasdYJtxv84qYEjLh6saYMnVy+z8ea2Jo= ; Message-ID: <20050324192523.48785.qmail@web30803.mail.mud.yahoo.com> Date: Thu, 24 Mar 2005 11:25:23 -0800 (PST) From: Igor Bryskin Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: Amit 70405 , Adrian Farrel , Diego Caviglia Cc: ", " MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2077387970-1111692323=:48357" --0-2077387970-1111692323=:48357 Content-Type: text/plain; charset=us-ascii Hi, I agree that recovery supervised by data and control plane should be correlated in a sense that control plane shouldn’t not trigger any recovery activities before giving a chance to the data plane (of course, capable of doing so) to provide the recovery. In fact, the similar strategy could be applied as in case of a multi-layer recovery, when, say, a higher layer does not start recovery procedures immediately on the fault detection, rather, waits for some time to let the lower layer(s) do the job, and starts recovery only if the fault situation still exists after the hold off time. Igor Amit 70405 wrote: Hi Adrian, Do you mean to say that Data plane & Control plane protection should be independant of each other?? If so, in case of MSP protection in SDH, Control plane should not have any control over the resource pool used for MSP switch. This may lead to lot of unused resource in the network. Regards, Amit. ----- Original Message ----- From: Diego Caviglia Date: Thursday, March 24, 2005 4:03 pm Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration > > Hi Adrian, > thanks for taking part to this discussion. > > Please find my comments in line. > > Regards > > Diego > > > > "Adrian Farrel" on 23/03/2005 15.58.42 > > Please respond to "Adrian Farrel" > > To: "Diego Caviglia" , > cc: > > Subject: Re: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > > Hi, > > My initial reaction is that this is way out of scope for CCAMP for > a bunch > of reasons. In particular order: > > - The GMPLS control plane does not necessarily want to define data > plane failures. Rather, it wants to signal (report) errors and allow > the control plane state (and data plane state) to remain in place. > [dc] Agreed and that was my initial point. Which kind of data > plane (e.g. > SDG) defects > have to advertised to control plane to trigger restoration? Given > thatcontrol plane is concerned in restore the data plane it should > also define > what is a failure. It is a fiber break or we have also to > consider other > defects? Of course we have. What happens if one restoration TNE > consideras failure only Loss Of Light (LOS) while the other starts > restoration even > if there is a e.g. Loss Of Pointer? Is that acceptable? > > - Control plane and data plane protection actions need to be carefully > separated. > [dc] Agreed. > > - Decisions that trigger control plane protection actions are > fundamentally implementation choices. > [dc] Here we are. This is the point. IMHO CCAMP should provide some > guidance on this. > > Maybe we should make a statement that this type > of thing SHOULD be configurable so that there is some sort of > consistency within a network. > [dc] Something like "..control plane restoration mechanism SHOULD be > triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1). > > - Existing alarm procedures should not be impacted by the use of > GMPLS.[dc] Absolutely agreed > > - Data plane technology is not what we do. > [dc] Absolutely agreed > > But I'm open to discussion. > > Finally, to follow on Sasha's comments, such a draft would > probably be > informational. > [dc] Ok for me no problem on that. > > Cheers, > Adrian > > ----- Original Message ----- > From: "Diego Caviglia" > To: "Sasha Vainshtein > Cc: "ccamp > Sent: Wednesday, March 23, 2005 2:01 PM > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > > > > > May be Adrian can put come light on the question you raised. > > > > Regards > > > > Diego > > > > > > > > Sasha Vainshtein on 23/03/2005 14.44.23 > > > > To: "'Diego Caviglia'" > > cc: ccamp > > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > Protection/Restoratio n > > > > > > Diego, > > I do not see any technical problems with placing such > > a definition in an Internet-Draft. > > > > But there may be problems associated with the IETF process: > > > > 1. Do you want to pursue this activity in the CCAMP WG? > > I am not sure this is really in the scope as defined > > by the CCAMP Charter > > > > 2. For interoperability the IETF document should be > > a Standards Track RFC. On the other hand, CCAMP is in > > the Routing Area meaning that you need an implementation > > to publish a Standards Track RFC - but what could be > > considered as an implementation in this case? > > > > Regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > > phone: +972-3-7569993 (office) > > fax: +972-3-6487779 > > mobile: +972-52-8674833 > > > > > > > -----Original Message----- > > > From: Diego Caviglia [Diego.Caviglia@marconi.com] > > > Sent: Wednesday, March 23, 2005 3:37 PM > > > To: Sasha Vainshtein > > > Cc: ccamp > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > > Protection/Restoratio n > > > > > > > > > > > > Hi Sasha, > > > I agree with you but in any case for > > > interop issues > > > and for sake of clarity I'd like to have that written in some IETF > > > document. > > > > > > Regards > > > > > > Diego > > > > > > > > > > > > > > > > > > Sasha Vainshtein on 23/03/2005 12.23.12 > > > > > > To: "'Diego Caviglia'" > > > cc: ccamp@ops.ietf.org > > > > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > > Protection/Restoratio n > > > > > > > > > Diego and all, > > > IMHO it is reasonable to assume that a failure is > > > a defect that results in sending downstream AIS > > > (and upstream RDI) as consequent action(s). > > > > > > For SDH consecutive actions for each defect > > > are specified in ITU-T G.783. > > > > > > Note also that for some defects the consecutive action > > > can be disabled by configuration. Hence I'd say that > > > the same defect can be a failure in one case and > > > not a failure in another case. The typical example > > > is Trail Identifier Mismatch (TIM). > > > > > > Hopefully this note will help. > > > > > > Regards, > > > Sasha Vainshtein > > > email: sasha@axerra.com > > > > > > phone: +972-3-7569993 (office) > > > fax: +972-3-6487779 > > > mobile: +972-52-8674833 > > > > > > > > > > -----Original Message----- > > > > From: Diego Caviglia [Diego.Caviglia@marconi.com] > > > > Sent: Wednesday, March 23, 2005 1:06 PM > > > > To: ccamp@ops.ietf.org > > > > Subject: Failure definition w.r.t. SONET/SDH and > > > > Protection/Restoration > > > > > > > > > > > > Hi all, > > > > is it defined somewhere, with respect to > > > > SDH/SONET, which > > > > defect has to be consider as a failure? > > > > > > > > It seems to me that for interoperability could be useful to > > > > have a list of > > > > defect that must be considered as failure, the same applies > > > > for defect that > > > > optionally can be considered as defect. > > > > > > > > May be also a communication between restoration TNEs in order > > > > to agree on > > > > the list could be useful. > > > > > > > > Does anyone agree on that? > > > > > > > > Regards > > > > > > > > Diego > > > > > > > > PS I apologise if the list is defined somewhere but I wasn't > > > > able to find > > > > it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------- Do you Yahoo!? Yahoo! Small Business - Try our new resources site! --0-2077387970-1111692323=:48357 Content-Type: text/html; charset=us-ascii

Hi,

 

I agree that recovery supervised by data and control plane should be correlated in a sense that control plane shouldn’t not trigger any recovery activities before giving a chance to the data plane (of course, capable of doing so) to provide the recovery. In fact, the similar strategy could be applied as in case of a multi-layer recovery, when, say, a higher layer does not start recovery procedures immediately on the fault detection, rather, waits for some time to let the lower layer(s) do the job, and starts recovery  only if the fault situation still exists after the hold off time.

 

Igor

Amit 70405 <AmitG@huawei.com> wrote:

Hi Adrian,
Do you mean to say that Data plane & Control plane protection should be independant of each other??
If so, in case of MSP protection in SDH,
Control plane should not have any control over the resource pool
used for MSP switch.
This may lead to lot of unused resource in the network.
Regards,
Amit.


----- Original Message -----
From: Diego Caviglia
Date: Thursday, March 24, 2005 4:03 pm
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

>
> Hi Adrian,
> thanks for taking part to this discussion.
>
> Please find my comments in line.
>
> Regards
>
> Diego
>
>
>
> "Adrian Farrel" on 23/03/2005 15.58.42
>
> Please respond to "Adrian Farrel"
>
> To: "Diego Caviglia" ,
> cc:
>
> Subject: Re: Failure definition w.r.t. SONET/SDH and
> Protection/Restoration
>
>
> Hi,
>
> My initial reaction is that this is way out of scope for CCAMP for
> a bunch
> of reasons. In particular order:
>
> - The GMPLS control plane does not necessarily want to define data
> plane failures. Rather, it wants to signal (report) errors and allow
> the control plane state (and data plane state) to remain in place.
> [dc] Agreed and that was my initial point. Which kind of data
> plane (e.g.
> SDG) defects
> have to advertised to control plane to trigger restoration? Given
> thatcontrol plane is concerned in restore the data plane it should
> also define
> what is a failure. It is a fiber break or we have also to
> consider other
> defects? Of course we have. What happens if one restoration TNE
> consideras failure only Loss Of Light (LOS) while the other starts
> restoration even
> if there is a e.g. Loss Of Pointer? Is that acceptable?
>
> - Control plane and data plane protection actions need to be carefully
> separated.
> [dc] Agreed.
>
> - Decisions that trigger control plane protection actions are
> fundamentally implementation choices.
> [dc] Here we are. This is the point. IMHO CCAMP should provide some
> guidance on this.
>
> Maybe we should make a statement that this type
> of thing SHOULD be configurable so that there is some sort of
> consistency within a network.
> [dc] Something like "..control plane restoration mechanism SHOULD be
> triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1).
>
> - Existing alarm procedures should not be impacted by the use of
> GMPLS.[dc] Absolutely agreed
>
> - Data plane technology is not what we do.
> [dc] Absolutely agreed
>
> But I'm open to discussion.
>
> Finally, to follow on Sasha's comments, such a draft would
> probably be
> informational.
> [dc] Ok for me no problem on that.
>
> Cheers,
> Adrian
>
> ----- Original Message -----
> From: "Diego Caviglia"
> To: "Sasha Vainshtein
> Cc: "ccamp
> Sent: Wednesday, March 23, 2005 2:01 PM
> Subject: RE: Failure definition w.r.t. SONET/SDH and
> Protection/Restoration
>
>
> >
> > May be Adrian can put come light on the question you raised.
> >
> > Regards
> >
> > Diego
> >
> >
> >
> > Sasha Vainshtein on 23/03/2005 14.44.23
> >
> > To: "'Diego Caviglia'"
> > cc: ccamp
> >
> > Subject: RE: Failure definition w.r.t. SONET/SDH and
> > Protection/Restoratio n
> >
> >
> > Diego,
> > I do not see any technical problems with placing such
> > a definition in an Internet-Draft.
> >
> > But there may be problems associated with the IETF process:
> >
> > 1. Do you want to pursue this activity in the CCAMP WG?
> > I am not sure this is really in the scope as defined
> > by the CCAMP Charter
> >
> > 2. For interoperability the IETF document should be
> > a Standards Track RFC. On the other hand, CCAMP is in
> > the Routing Area meaning that you need an implementation
> > to publish a Standards Track RFC - but what could be
> > considered as an implementation in this case?
> >
> > Regards,
> > Sasha Vainshtein
> > email: sasha@axerra.com
>
> > phone: +972-3-7569993 (office)
> > fax: +972-3-6487779
> > mobile: +972-52-8674833
> >
> >
> > > -----Original Message-----
> > > From: Diego Caviglia [Diego.Caviglia@marconi.com]
> > > Sent: Wednesday, March 23, 2005 3:37 PM
> > > To: Sasha Vainshtein
> > > Cc: ccamp
> > > Subject: RE: Failure definition w.r.t. SONET/SDH and
> > > Protection/Restoratio n
> > >
> > >
> > >
> > > Hi Sasha,
> > > I agree with you but in any case for
> > > interop issues
> > > and for sake of clarity I'd like to have that written in some IETF
> > > document.
> > >
> > > Regards
> > >
> > > Diego
> > >
> > >
> > >
> > >
> > >
> > > Sasha Vainshtein on 23/03/2005 12.23.12
> > >
> > > To: "'Diego Caviglia'"
> > > cc: ccamp@ops.ietf.org
> > >
> > > Subject: RE: Failure definition w.r.t. SONET/SDH and
> > > Protection/Restoratio n
> > >
> > >
> > > Diego and all,
> > > IMHO it is reasonable to assume that a failure is
> > > a defect that results in sending downstream AIS
> > > (and upstream RDI) as consequent action(s).
> > >
> > > For SDH consecutive actions for each defect
> > > are specified in ITU-T G.783.
> > >
> > > Note also that for some defects the consecutive action
> > > can be disabled by configuration. Hence I'd say that
> > > the same defect can be a failure in one case and
> > > not a failure in another case. The typical example
> > > is Trail Identifier Mismatch (TIM).
> > >
> > > Hopefully this note will help.
> > >
> > > Regards,
> > > Sasha Vainshtein
> > > email: sasha@axerra.com
> > >
> > > phone: +972-3-7569993 (office)
> > > fax: +972-3-6487779
> > > mobile: +972-52-8674833
> > >
> > >
> > > > -----Original Message-----
> > > > From: Diego Caviglia [Diego.Caviglia@marconi.com]
> > > > Sent: Wednesday, March 23, 2005 1:06 PM
> > > > To: ccamp@ops.ietf.org
> > > > Subject: Failure definition w.r.t. SONET/SDH and
> > > > Protection/Restoration
> > > >
> > > >
> > > > Hi all,
> > > > is it defined somewhere, with respect to
> > > > SDH/SONET, which
> > > > defect has to be consider as a failure?
> > > >
> > > > It seems to me that for interoperability could be useful to
> > > > have a list of
> > > > defect that must be considered as failure, the same applies
> > > > for defect that
> > > > optionally can be considered as defect.
> > > >
> > > > May be also a communication between restoration TNEs in order
> > > > to agree on
> > > > the list could be useful.
> > > >
> > > > Does anyone agree on that?
> > > >
> > > > Regards
> > > >
> > > > Diego
> > > >
> > > > PS I apologise if the list is defined somewhere but I wasn't
> > > > able to find
> > > > it.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
>
>
>

 

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! --0-2077387970-1111692323=:48357-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Mar 2005 13:17:23 +0000 Message-ID: <0e7901c53070$cc1696b0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Amit 70405" , "Diego Caviglia" Cc: , Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Date: Thu, 24 Mar 2005 11:40:01 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Amit, > Do you mean to say that Data plane & Control plane protection should be independant of each other?? No, I mean that they MAY be independent. In particular, if you are using the control plane *and* the data plane to manage protection on the same set of resources you are bound to get in a horrible mess. Seems more reasonable that you would apply data plane protection first and then apply control plane protection at a higher level. > If so, in case of MSP protection in SDH, > Control plane should not have any control over the resource pool > used for MSP switch. > This may lead to lot of unused resource in the network. It is certain that each layer of protection that you install MAY result in unused resources. Building multiple layers of protection will, therefore, potentially build up more and more unused resources. It is the job of CCAMP to produce the tools that allow operators to build the protection schemes that they want. It's not really our business to tell them which schemes to build and when. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Mar 2005 12:56:08 +0000 Message-ID: <0e7a01c53070$cdb4b650$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Diego Caviglia" Cc: , Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Date: Thu, 24 Mar 2005 11:53:32 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E0E_01C53068.1A6EFAE0" This is a multi-part message in MIME format. ------=_NextPart_000_0E0E_01C53068.1A6EFAE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Diego, >> - The GMPLS control plane does not necessarily want to define data >> plane failures. Rather, it wants to signal (report) errors and = allow >> the control plane state (and data plane state) to remain in place. > [dc] Agreed and that was my initial point. Which kind of data plane = (e.g. > SDG) defects have to advertised to control plane to trigger = restoration? =20 > Given that control plane is concerned in restore the data plane it = should=20 > also define what is a failure. It is a fiber break or we have also to = > consider other defects? Of course we have. What happens if one > restoration TNE consider as failure only Loss Of Light (LOS) while the > other starts restoration even if there is a e.g. Loss Of Pointer? Is=20 > that acceptable? Let's look at two things. First, the trigger for protection switchover. If you look at section 6.2 = of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt (currently in = working group last call, so please comment now!) you will see... To co-ordinate the switchover between end-points, an end-to-end=20 switchover request is needed since a failure affecting one the LSPs=20 results in both end-points switching to the other LSP (resulting in=20 receiving traffic from the other LSP) in their respective=20 directions. This is done using the Notify message with a new Error=20 Code indicating "Working LSP Failure (Switchover Request)". This clearly indicates that the objective is not to report a failure, = but to request a switchover. Which takes us to your second point: which data plane errors should be = reported to the control plane to trigger switchover signaling, and would = it matter if different transport nodes applied different policies? My contention is that this is entirely an implementation issue. I think = it would be a wise implementation that included some degree of = configurability to this function, but that is not in CCAMP's scope. If = two "TNEs" have different trigger thresholds I do not see that any harm = will be done, it might even be desirable. >> - Decisions that trigger control plane protection actions are >> fundamentally implementation choices. > [dc] Here we are. This is the point. IMHO CCAMP should provide some > guidance on this. >=20 >> Maybe we should make a statement that this type >> of thing SHOULD be configurable so that there is some sort of >> consistency within a network. > [dc] Something like "..control plane restoration mechanism SHOULD be > triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1). But why? It is not enough to know that this is a difficult question for an = implementaiton to answer. Why is it not enough to say that the Data Plane should trigger control = plane recovery action when the data plane deems that there is a fault = from which it determines that recovery is required and from which it is = unable or unwilling to recover on its own? If you can show that there is a need to make a more definitive statement = then we can consider it. Cheers, Adrian ------=_NextPart_000_0E0E_01C53068.1A6EFAE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Diego,
 
>> - The GMPLS control plane = does not=20 necessarily want to define data
>>   plane failures. = Rather, it=20 wants to signal (report) errors and allow
>>   the control = plane=20 state (and data plane state) to remain in place.
> [dc] Agreed and = that=20 was my initial point.  Which kind of data plane (e.g.
> SDG)=20 defects have to advertised to control plane to trigger = restoration? =20
> Given that control plane is = concerned in=20 restore the data plane it should
> also define what is a = failure.  It is a=20 fiber break or we have also to
> consider other defects? Of = course we=20 have.  What happens if one
> restoration TNE consider as = failure=20 only Loss Of Light (LOS) while the
> other starts restoration = even if there=20 is a e.g. Loss Of Pointer?  Is
> that acceptable?
 
Let's look at two = things.
 
First, the trigger for protection = switchover. If=20 you look at section 6.2 of = draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt=20 (currently in working group last call, so please comment now!) you will=20 see...
 
   To co-ordinate the = switchover=20 between end-points, an end-to-end
   switchover request is = needed=20 since a failure affecting one the LSPs
   results in both=20 end-points switching to the other LSP (resulting in
   = receiving=20 traffic from the other LSP) in their respective
   = directions.=20 This is done using the Notify message with a new Error
   = Code=20 indicating "Working LSP Failure (Switchover Request)".
This clearly indicates that the = objective is not=20 to report a failure, but to request a switchover.
 
Which takes us to your second point: = which data=20 plane errors should be reported to the control plane to trigger = switchover=20 signaling, and would it matter if different transport nodes applied = different=20 policies?
 
My contention is that this is = entirely an=20 implementation issue. I think it would be a wise implementation that = included=20 some degree of configurability to this function, but that is not in = CCAMP's=20 scope. If two "TNEs" have different trigger thresholds I do not see that = any=20 harm will be done, it might even be desirable.
 
>> - Decisions that trigger = control plane=20 protection actions are
>>   fundamentally implementation=20 choices.
> [dc] Here we are.  This is the point.  IMHO = CCAMP=20 should provide some
> guidance on this.
>
>> =   Maybe=20 we should make a statement that this type
>>   of thing = SHOULD be=20 configurable so that there is some sort of
>>   = consistency within=20 a network.
> [dc] Something like "..control plane restoration = mechanism=20 SHOULD be
> triggered as the SNC/I defined in ITU-T G.783 (section = 12.1.1.1).
 
But why?
 
It is not enough to know that this is = a difficult=20 question for an implementaiton to answer.
 
Why is it not enough to say that the = Data Plane=20 should trigger control plane recovery action when the data plane deems = that=20 there is a fault from which it determines that recovery is required and = from=20 which it is unable or unwilling to recover on its own?
 
If you can show that there is a need to make a more definitive = statement=20 then we can consider it.

Cheers,
Adrian
------=_NextPart_000_0E0E_01C53068.1A6EFAE0-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Mar 2005 10:13:35 +0000 Date: Thu, 24 Mar 2005 18:01:48 +0800 From: Amit 70405 Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: Adrian Farrel , Diego Caviglia Cc: ", " Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline Hi Adrian, Do you mean to say that Data plane & Control plane protection should be independant of each other?? If so, in case of MSP protection in SDH, Control plane should not have any control over the resource pool used for MSP switch. This may lead to lot of unused resource in the network. Regards, Amit. ----- Original Message ----- From: Diego Caviglia Date: Thursday, March 24, 2005 4:03 pm Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration > > Hi Adrian, > thanks for taking part to this discussion. > > Please find my comments in line. > > Regards > > Diego > > > > "Adrian Farrel" on 23/03/2005 15.58.42 > > Please respond to "Adrian Farrel" > > To: "Diego Caviglia" , > cc: > > Subject: Re: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > > Hi, > > My initial reaction is that this is way out of scope for CCAMP for > a bunch > of reasons. In particular order: > > - The GMPLS control plane does not necessarily want to define data > plane failures. Rather, it wants to signal (report) errors and allow > the control plane state (and data plane state) to remain in place. > [dc] Agreed and that was my initial point. Which kind of data > plane (e.g. > SDG) defects > have to advertised to control plane to trigger restoration? Given > thatcontrol plane is concerned in restore the data plane it should > also define > what is a failure. It is a fiber break or we have also to > consider other > defects? Of course we have. What happens if one restoration TNE > consideras failure only Loss Of Light (LOS) while the other starts > restoration even > if there is a e.g. Loss Of Pointer? Is that acceptable? > > - Control plane and data plane protection actions need to be carefully > separated. > [dc] Agreed. > > - Decisions that trigger control plane protection actions are > fundamentally implementation choices. > [dc] Here we are. This is the point. IMHO CCAMP should provide some > guidance on this. > > Maybe we should make a statement that this type > of thing SHOULD be configurable so that there is some sort of > consistency within a network. > [dc] Something like "..control plane restoration mechanism SHOULD be > triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1). > > - Existing alarm procedures should not be impacted by the use of > GMPLS.[dc] Absolutely agreed > > - Data plane technology is not what we do. > [dc] Absolutely agreed > > But I'm open to discussion. > > Finally, to follow on Sasha's comments, such a draft would > probably be > informational. > [dc] Ok for me no problem on that. > > Cheers, > Adrian > > ----- Original Message ----- > From: "Diego Caviglia" > To: "Sasha Vainshtein > Cc: "ccamp > Sent: Wednesday, March 23, 2005 2:01 PM > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > > > > > May be Adrian can put come light on the question you raised. > > > > Regards > > > > Diego > > > > > > > > Sasha Vainshtein on 23/03/2005 14.44.23 > > > > To: "'Diego Caviglia'" > > cc: ccamp > > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > Protection/Restoratio n > > > > > > Diego, > > I do not see any technical problems with placing such > > a definition in an Internet-Draft. > > > > But there may be problems associated with the IETF process: > > > > 1. Do you want to pursue this activity in the CCAMP WG? > > I am not sure this is really in the scope as defined > > by the CCAMP Charter > > > > 2. For interoperability the IETF document should be > > a Standards Track RFC. On the other hand, CCAMP is in > > the Routing Area meaning that you need an implementation > > to publish a Standards Track RFC - but what could be > > considered as an implementation in this case? > > > > Regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > > phone: +972-3-7569993 (office) > > fax: +972-3-6487779 > > mobile: +972-52-8674833 > > > > > > > -----Original Message----- > > > From: Diego Caviglia [Diego.Caviglia@marconi.com] > > > Sent: Wednesday, March 23, 2005 3:37 PM > > > To: Sasha Vainshtein > > > Cc: ccamp > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > > Protection/Restoratio n > > > > > > > > > > > > Hi Sasha, > > > I agree with you but in any case for > > > interop issues > > > and for sake of clarity I'd like to have that written in some IETF > > > document. > > > > > > Regards > > > > > > Diego > > > > > > > > > > > > > > > > > > Sasha Vainshtein on 23/03/2005 12.23.12 > > > > > > To: "'Diego Caviglia'" > > > cc: ccamp@ops.ietf.org > > > > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > > Protection/Restoratio n > > > > > > > > > Diego and all, > > > IMHO it is reasonable to assume that a failure is > > > a defect that results in sending downstream AIS > > > (and upstream RDI) as consequent action(s). > > > > > > For SDH consecutive actions for each defect > > > are specified in ITU-T G.783. > > > > > > Note also that for some defects the consecutive action > > > can be disabled by configuration. Hence I'd say that > > > the same defect can be a failure in one case and > > > not a failure in another case. The typical example > > > is Trail Identifier Mismatch (TIM). > > > > > > Hopefully this note will help. > > > > > > Regards, > > > Sasha Vainshtein > > > email: sasha@axerra.com > > > > > > phone: +972-3-7569993 (office) > > > fax: +972-3-6487779 > > > mobile: +972-52-8674833 > > > > > > > > > > -----Original Message----- > > > > From: Diego Caviglia [Diego.Caviglia@marconi.com] > > > > Sent: Wednesday, March 23, 2005 1:06 PM > > > > To: ccamp@ops.ietf.org > > > > Subject: Failure definition w.r.t. SONET/SDH and > > > > Protection/Restoration > > > > > > > > > > > > Hi all, > > > > is it defined somewhere, with respect to > > > > SDH/SONET, which > > > > defect has to be consider as a failure? > > > > > > > > It seems to me that for interoperability could be useful to > > > > have a list of > > > > defect that must be considered as failure, the same applies > > > > for defect that > > > > optionally can be considered as defect. > > > > > > > > May be also a communication between restoration TNEs in order > > > > to agree on > > > > the list could be useful. > > > > > > > > Does anyone agree on that? > > > > > > > > Regards > > > > > > > > Diego > > > > > > > > PS I apologise if the list is defined somewhere but I wasn't > > > > able to find > > > > it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Mar 2005 08:05:23 +0000 Sensitivity: Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: "Adrian Farrel" Cc: ", " Message-ID: From: "Diego Caviglia" Date: Thu, 24 Mar 2005 09:03:52 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Adrian, thanks for taking part to this discussion. Please find my comments in line. Regards Diego "Adrian Farrel" on 23/03/2005 15.58.42 Please respond to "Adrian Farrel" To: "Diego Caviglia" , cc: Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Hi, My initial reaction is that this is way out of scope for CCAMP for a bunch of reasons. In particular order: - The GMPLS control plane does not necessarily want to define data plane failures. Rather, it wants to signal (report) errors and allow the control plane state (and data plane state) to remain in place. [dc] Agreed and that was my initial point. Which kind of data plane (e.g. SDG) defects have to advertised to control plane to trigger restoration? Given that control plane is concerned in restore the data plane it should also define what is a failure. It is a fiber break or we have also to consider other defects? Of course we have. What happens if one restoration TNE consider as failure only Loss Of Light (LOS) while the other starts restoration even if there is a e.g. Loss Of Pointer? Is that acceptable? - Control plane and data plane protection actions need to be carefully separated. [dc] Agreed. - Decisions that trigger control plane protection actions are fundamentally implementation choices. [dc] Here we are. This is the point. IMHO CCAMP should provide some guidance on this. Maybe we should make a statement that this type of thing SHOULD be configurable so that there is some sort of consistency within a network. [dc] Something like "..control plane restoration mechanism SHOULD be triggered as the SNC/I defined in ITU-T G.783 (section 12.1.1.1). - Existing alarm procedures should not be impacted by the use of GMPLS. [dc] Absolutely agreed - Data plane technology is not what we do. [dc] Absolutely agreed But I'm open to discussion. Finally, to follow on Sasha's comments, such a draft would probably be informational. [dc] Ok for me no problem on that. Cheers, Adrian ----- Original Message ----- From: "Diego Caviglia" To: "Sasha Vainshtein Cc: "ccamp Sent: Wednesday, March 23, 2005 2:01 PM Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n > > May be Adrian can put come light on the question you raised. > > Regards > > Diego > > > > Sasha Vainshtein on 23/03/2005 14.44.23 > > To: "'Diego Caviglia'" > cc: ccamp > > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoratio n > > > Diego, > I do not see any technical problems with placing such > a definition in an Internet-Draft. > > But there may be problems associated with the IETF process: > > 1. Do you want to pursue this activity in the CCAMP WG? > I am not sure this is really in the scope as defined > by the CCAMP Charter > > 2. For interoperability the IETF document should be > a Standards Track RFC. On the other hand, CCAMP is in > the Routing Area meaning that you need an implementation > to publish a Standards Track RFC - but what could be > considered as an implementation in this case? > > Regards, > Sasha Vainshtein > email: sasha@axerra.com > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833 > > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Wednesday, March 23, 2005 3:37 PM > > To: Sasha Vainshtein > > Cc: ccamp > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > Protection/Restoratio n > > > > > > > > Hi Sasha, > > I agree with you but in any case for > > interop issues > > and for sake of clarity I'd like to have that written in some IETF > > document. > > > > Regards > > > > Diego > > > > > > > > > > > > Sasha Vainshtein on 23/03/2005 12.23.12 > > > > To: "'Diego Caviglia'" > > cc: ccamp@ops.ietf.org > > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > Protection/Restoratio n > > > > > > Diego and all, > > IMHO it is reasonable to assume that a failure is > > a defect that results in sending downstream AIS > > (and upstream RDI) as consequent action(s). > > > > For SDH consecutive actions for each defect > > are specified in ITU-T G.783. > > > > Note also that for some defects the consecutive action > > can be disabled by configuration. Hence I'd say that > > the same defect can be a failure in one case and > > not a failure in another case. The typical example > > is Trail Identifier Mismatch (TIM). > > > > Hopefully this note will help. > > > > Regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > > > phone: +972-3-7569993 (office) > > fax: +972-3-6487779 > > mobile: +972-52-8674833 > > > > > > > -----Original Message----- > > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > > Sent: Wednesday, March 23, 2005 1:06 PM > > > To: ccamp@ops.ietf.org > > > Subject: Failure definition w.r.t. SONET/SDH and > > > Protection/Restoration > > > > > > > > > Hi all, > > > is it defined somewhere, with respect to > > > SDH/SONET, which > > > defect has to be consider as a failure? > > > > > > It seems to me that for interoperability could be useful to > > > have a list of > > > defect that must be considered as failure, the same applies > > > for defect that > > > optionally can be considered as defect. > > > > > > May be also a communication between restoration TNEs in order > > > to agree on > > > the list could be useful. > > > > > > Does anyone agree on that? > > > > > > Regards > > > > > > Diego > > > > > > PS I apologise if the list is defined somewhere but I wasn't > > > able to find > > > it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 22:08:57 +0000 Date: Wed, 23 Mar 2005 14:08:13 -0800 (PST) From: Arthi Ayyangar To: Dimitri.Papadimitriou@alcatel.be cc: Adrian Farrel , ccamp@ops.ietf.org Subject: Re: WG drafts - My correction Message-ID: <20050323140317.F66554@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dimitri, > 2. I have seen consensus for draft-ayyangar-ccamp-lsp-stitching to be > published as a WG draft and the authors will submit it as > draft-ietf-ccamp-lsp-stitching soon > > -> agreed - note: would you tell us (or authors) when comments made on > this list would then be incorporated ? -------> I think the plan was to first republish as WG draft with *no* changes. Following that, we could submit another version shortly incorporating the comments made on the list. thanks, -arthi > > 3. The name of the third draft is > draft-vasseur-ccamp-inter-domain-pd-path-comp. This is the draft that we > need to consider. > > As JP says, he plans to add the sentence "In the context of this draft, > the node in charge of any ERO expansion within its domain is always along > the inter-domain TE LSP path" to this draft. > > -> reading through the document and taking section 4 as the core, i > wonder why examples of the same section are prescriptive ? is there by no > means a way to re-write this document in prescriptive mode (since afaik > this is intended to become a proposed standard and not an informational > document) and only give examples in appendix and not use examples to > describe its core content - > > > Question: With the addition of this sentence, are we content to accept > this draft as a WG draft? > > Thanks, > Adrian > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 22:05:00 +0000 Message-ID: <0da201c52ff4$77bb5aa0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Diego Caviglia" , Cc: Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration Date: Wed, 23 Mar 2005 14:58:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, My initial reaction is that this is way out of scope for CCAMP for a bunch of reasons. In particular order: - The GMPLS control plane does not necessarily want to define data plane failures. Rather, it wants to signal (report) errors and allow the control plane state (and data plane state) to remain in place. - Control plane and data plane protection actions need to be carefully separated. - Decisions that trigger control plane protection actions are fundamentally implementation choices. Maybe we should make a statement that this type of thing SHOULD be configurable so that there is some sort of consistency within a network. - Existing alarm procedures should not be impacted by the use of GMPLS. - Data plane technology is not what we do. But I'm open to discussion. Finally, to follow on Sasha's comments, such a draft would probably be informational. Cheers, Adrian ----- Original Message ----- From: "Diego Caviglia" To: "Sasha Vainshtein Cc: "ccamp Sent: Wednesday, March 23, 2005 2:01 PM Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n > > May be Adrian can put come light on the question you raised. > > Regards > > Diego > > > > Sasha Vainshtein on 23/03/2005 14.44.23 > > To: "'Diego Caviglia'" > cc: ccamp > > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoratio n > > > Diego, > I do not see any technical problems with placing such > a definition in an Internet-Draft. > > But there may be problems associated with the IETF process: > > 1. Do you want to pursue this activity in the CCAMP WG? > I am not sure this is really in the scope as defined > by the CCAMP Charter > > 2. For interoperability the IETF document should be > a Standards Track RFC. On the other hand, CCAMP is in > the Routing Area meaning that you need an implementation > to publish a Standards Track RFC - but what could be > considered as an implementation in this case? > > Regards, > Sasha Vainshtein > email: sasha@axerra.com > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833 > > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Wednesday, March 23, 2005 3:37 PM > > To: Sasha Vainshtein > > Cc: ccamp > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > Protection/Restoratio n > > > > > > > > Hi Sasha, > > I agree with you but in any case for > > interop issues > > and for sake of clarity I'd like to have that written in some IETF > > document. > > > > Regards > > > > Diego > > > > > > > > > > > > Sasha Vainshtein on 23/03/2005 12.23.12 > > > > To: "'Diego Caviglia'" > > cc: ccamp@ops.ietf.org > > > > Subject: RE: Failure definition w.r.t. SONET/SDH and > > Protection/Restoratio n > > > > > > Diego and all, > > IMHO it is reasonable to assume that a failure is > > a defect that results in sending downstream AIS > > (and upstream RDI) as consequent action(s). > > > > For SDH consecutive actions for each defect > > are specified in ITU-T G.783. > > > > Note also that for some defects the consecutive action > > can be disabled by configuration. Hence I'd say that > > the same defect can be a failure in one case and > > not a failure in another case. The typical example > > is Trail Identifier Mismatch (TIM). > > > > Hopefully this note will help. > > > > Regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > > > phone: +972-3-7569993 (office) > > fax: +972-3-6487779 > > mobile: +972-52-8674833 > > > > > > > -----Original Message----- > > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > > Sent: Wednesday, March 23, 2005 1:06 PM > > > To: ccamp@ops.ietf.org > > > Subject: Failure definition w.r.t. SONET/SDH and > > > Protection/Restoration > > > > > > > > > Hi all, > > > is it defined somewhere, with respect to > > > SDH/SONET, which > > > defect has to be consider as a failure? > > > > > > It seems to me that for interoperability could be useful to > > > have a list of > > > defect that must be considered as failure, the same applies > > > for defect that > > > optionally can be considered as defect. > > > > > > May be also a communication between restoration TNEs in order > > > to agree on > > > the list could be useful. > > > > > > Does anyone agree on that? > > > > > > Regards > > > > > > Diego > > > > > > PS I apologise if the list is defined somewhere but I wasn't > > > able to find > > > it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 21:07:25 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair , ccamp chair Subject: Protocol Action: 'Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model' to Proposed Standard Message-Id: Date: Wed, 23 Mar 2005 16:07:16 -0500 The IESG has approved the following document: - 'Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model ' as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. Working Group Summary The WG had a consensus on advancing this document. Protocol Quality Dimitri Papadimitriou reviewed this document for the RTG-DIR, and Alex Zinin reviewed this document for the IESG. RFC Editor Note: Section 8. Security Considerations OLD: This draft imposes no new security risks over [RFC3473]. In fact it represents a lower trust model between the core and edge-nodes as the core is permitted to hide its topology from the edge-nodes. The core is also permitted to restrict the actions of edge-nodes by filtering out specific RSVP objects. NEW: The trust model between the core and edge-nodes is different than the one described in [RFC3473], as the core is permitted to hide its topology from the edge-nodes, and the core is permitted to restrict the actions of edge-nodes by filtering out specific RSVP objects. IANA Note: This document requires no IANA action. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 21:06:53 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair , ccamp chair Subject: Protocol Action: 'Generalized MPLS (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control' to Proposed Standard Message-Id: Date: Wed, 23 Mar 2005 16:05:55 -0500 The IESG has approved the following document: - 'Generalized MPLS (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control ' as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary This document is a companion to the Generalized MPLS (GMPLS) signaling documents. It describes the technology specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. Working Group Summary The WG had a consensus on advancing this document. Protocol Quality Alex Zinin reviewed this document for the IESG. There is at least one implementation of the described mechanisms. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 19:49:41 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair , ccamp chair Subject: Document Action: 'Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON)' to Informational RFC Message-Id: Date: Wed, 23 Mar 2005 14:47:50 -0500 The IESG has approved the following document: - 'Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON) ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the routing requirements on the GMPLS suite of protocols to support the capabilities and functionalities for an Automatically Switched Optical Network (ASON) as defined by ITU-T. Working Group Summary This document is the product of a design team that included IETF and ITU members. The goal of the document was to represent routing-related requirements for ASON networks received from ITU in a liaison statement in the form understandable for a usual IETF participant. Protocol Quality This document has been reviewed for IESG by Alex Zinin. Adrian Farrel followed up with the WG on the provided comments. IANA Note This document required no specific IANA action. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 16:11:30 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Date: Wed, 23 Mar 2005 10:10:25 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF094ACDF4@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Thread-Index: AcUvvSyGOamZm8+CQ9enJZOhhSTyBgAAgq5w From: "Brungard, Deborah A, ALABS" To: "Stephen J Trowbridge" , "Sasha Vainshtein" Cc: "Diego Caviglia" , "ccamp" Not sure the context of your question Diego? ITU provides the definitions allowing interop. And CCAMP does have documents referencing - CCAMP's recovery documents (terminology, analysis, functional, signaling). CCAMP's documents were based on the approach as Steve described - terminology alignment with ITU/T1X1 (e.g. defect, failure, SF, SD) and references to the T1X1/ITU documents (T1.105, G.806, G.783, G.841/842, G.808.1). These ITU documents also include differences between SONET and SDH. If you have questions on specific defects/failures (eg TIM), suggest sending mail on the ITU's SG15 q9 exploder. Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Stephen J Trowbridge Sent: Wednesday, March 23, 2005 10:27 AM To: Sasha Vainshtein Cc: 'Diego Caviglia'; ccamp Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Sasha and Diego, IMHO, it is a very bad idea to have two "normative" places where something is standardized. You already have the SDH standards in ITU-T documents (G.707, G.783, etc.) and the SONET standards in ATIS OPTXS (formerly T1X1) documents (mostly the T1.105 series). There is no reason that standards track RFCs cannot make normative references to these documents where needed. It would be inappropriate for IETF to attempt to replicate these documents as RFCs. Regards, Steve On 3/23/2005 6:44 AM, Sasha Vainshtein wrote: > Diego, > I do not see any technical problems with placing such > a definition in an Internet-Draft. >=20 > But there may be problems associated with the IETF process: >=20 > 1. Do you want to pursue this activity in the CCAMP WG?=20 > I am not sure this is really in the scope as defined > by the CCAMP Charter >=20 > 2. For interoperability the IETF document should be > a Standards Track RFC. On the other hand, CCAMP is in > the Routing Area meaning that you need an implementation > to publish a Standards Track RFC - but what could be > considered as an implementation in this case? >=20 > Regards, > Sasha Vainshtein > email: sasha@axerra.com =20 > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833=20 >=20 >=20 >=20 >>-----Original Message----- >>From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] >>Sent: Wednesday, March 23, 2005 3:37 PM >>To: Sasha Vainshtein >>Cc: ccamp >>Subject: RE: Failure definition w.r.t. SONET/SDH and=20 >>Protection/Restoratio n >> >> >> >>Hi Sasha, >> I agree with you but in any case for=20 >>interop issues >>and for sake of clarity I'd like to have that written in some IETF >>document. >> >>Regards >> >>Diego >> >> >> >> >> >>Sasha Vainshtein on 23/03/2005 12.23.12 >> >>To: "'Diego Caviglia'" >>cc: ccamp@ops.ietf.org >> >>Subject: RE: Failure definition w.r.t. SONET/SDH and >> Protection/Restoratio n >> >> >>Diego and all, >>IMHO it is reasonable to assume that a failure is >>a defect that results in sending downstream AIS >>(and upstream RDI) as consequent action(s). >> >>For SDH consecutive actions for each defect >>are specified in ITU-T G.783. >> >>Note also that for some defects the consecutive action >>can be disabled by configuration. Hence I'd say that >>the same defect can be a failure in one case and >>not a failure in another case. The typical example >>is Trail Identifier Mismatch (TIM). >> >>Hopefully this note will help. >> >>Regards, >> Sasha Vainshtein >>email: sasha@axerra.com=20 >> >>phone: +972-3-7569993 (office) >>fax: +972-3-6487779 >>mobile: +972-52-8674833 >> >> >> >>>-----Original Message----- >>>From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] >>>Sent: Wednesday, March 23, 2005 1:06 PM >>>To: ccamp@ops.ietf.org >>>Subject: Failure definition w.r.t. SONET/SDH and >>>Protection/Restoration >>> >>> >>>Hi all, >>> is it defined somewhere, with respect to >>>SDH/SONET, which >>>defect has to be consider as a failure? >>> >>>It seems to me that for interoperability could be useful to >>>have a list of >>>defect that must be considered as failure, the same applies >>>for defect that >>>optionally can be considered as defect. >>> >>>May be also a communication between restoration TNEs in order >>>to agree on >>>the list could be useful. >>> >>>Does anyone agree on that? >>> >>>Regards >>> >>>Diego >>> >>>PS I apologise if the list is defined somewhere but I wasn't >>>able to find >>>it. >>> >>> >>> >>> >> >> >> >> >> >> >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 15:42:13 +0000 Sensitivity: Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n To: "Stephen J Trowbridge Cc: "Sasha Vainshtein , "ccamp Message-ID: From: "Diego Caviglia" Date: Wed, 23 Mar 2005 16:41:47 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Stephen, for me is ok to have a reference to the ITU-T doc in a IETF doc. The point is that seems there is no reference to that in any IETF ID/RFC. So if your proposal is to add a reference to ITU-T in some already existing IETF draft that is ok for me. Regards Diego Stephen J Trowbridge on 23/03/2005 16.26.47 To: Sasha Vainshtein cc: "'Diego Caviglia'" , ccamp Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Sasha and Diego, IMHO, it is a very bad idea to have two "normative" places where something is standardized. You already have the SDH standards in ITU-T documents (G.707, G.783, etc.) and the SONET standards in ATIS OPTXS (formerly T1X1) documents (mostly the T1.105 series). There is no reason that standards track RFCs cannot make normative references to these documents where needed. It would be inappropriate for IETF to attempt to replicate these documents as RFCs. Regards, Steve On 3/23/2005 6:44 AM, Sasha Vainshtein wrote: > Diego, > I do not see any technical problems with placing such > a definition in an Internet-Draft. > > But there may be problems associated with the IETF process: > > 1. Do you want to pursue this activity in the CCAMP WG? > I am not sure this is really in the scope as defined > by the CCAMP Charter > > 2. For interoperability the IETF document should be > a Standards Track RFC. On the other hand, CCAMP is in > the Routing Area meaning that you need an implementation > to publish a Standards Track RFC - but what could be > considered as an implementation in this case? > > Regards, > Sasha Vainshtein > email: sasha@axerra.com > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833 > > > >>-----Original Message----- >>From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] >>Sent: Wednesday, March 23, 2005 3:37 PM >>To: Sasha Vainshtein >>Cc: ccamp >>Subject: RE: Failure definition w.r.t. SONET/SDH and >>Protection/Restoratio n >> >> >> >>Hi Sasha, >> I agree with you but in any case for >>interop issues >>and for sake of clarity I'd like to have that written in some IETF >>document. >> >>Regards >> >>Diego >> >> >> >> >> >>Sasha Vainshtein on 23/03/2005 12.23.12 >> >>To: "'Diego Caviglia'" >>cc: ccamp@ops.ietf.org >> >>Subject: RE: Failure definition w.r.t. SONET/SDH and >> Protection/Restoratio n >> >> >>Diego and all, >>IMHO it is reasonable to assume that a failure is >>a defect that results in sending downstream AIS >>(and upstream RDI) as consequent action(s). >> >>For SDH consecutive actions for each defect >>are specified in ITU-T G.783. >> >>Note also that for some defects the consecutive action >>can be disabled by configuration. Hence I'd say that >>the same defect can be a failure in one case and >>not a failure in another case. The typical example >>is Trail Identifier Mismatch (TIM). >> >>Hopefully this note will help. >> >>Regards, >> Sasha Vainshtein >>email: sasha@axerra.com >> >>phone: +972-3-7569993 (office) >>fax: +972-3-6487779 >>mobile: +972-52-8674833 >> >> >> >>>-----Original Message----- >>>From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] >>>Sent: Wednesday, March 23, 2005 1:06 PM >>>To: ccamp@ops.ietf.org >>>Subject: Failure definition w.r.t. SONET/SDH and >>>Protection/Restoration >>> >>> >>>Hi all, >>> is it defined somewhere, with respect to >>>SDH/SONET, which >>>defect has to be consider as a failure? >>> >>>It seems to me that for interoperability could be useful to >>>have a list of >>>defect that must be considered as failure, the same applies >>>for defect that >>>optionally can be considered as defect. >>> >>>May be also a communication between restoration TNEs in order >>>to agree on >>>the list could be useful. >>> >>>Does anyone agree on that? >>> >>>Regards >>> >>>Diego >>> >>>PS I apologise if the list is defined somewhere but I wasn't >>>able to find >>>it. >>> >>> >>> >>> >> >> >> >> >> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 15:38:17 +0000 To: "Adrian Farrel" Cc: MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: WG drafts - My correction Date: Wed, 23 Mar 2005 16:37:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 PFA+aGkgYWRyaWFuIC0gdHdvIHBvaW50cyBoZXJlIGJlbG93IDxCUj48QlI+PEZPTlQgU0laRT0y PjxCPiZxdW90O0FkcmlhbiBGYXJyZWwmcXVvdDsgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7 PC9CPjwvRk9OVD48QlI+PEZPTlQgU0laRT0yPlNlbnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRm Lm9yZzwvRk9OVD48QlI+PEZPTlQgU0laRT0yPjAzLzIzLzIwMDUgMDA6MTYgR01UPC9GT05UPjxC Uj48Rk9OVCBTSVpFPTI+UGxlYXNlIHJlc3BvbmQgdG8gJnF1b3Q7QWRyaWFuIEZhcnJlbCZxdW90 OzwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+Jmx0 O2NjYW1wQG9wcy5pZXRmLm9yZyZndDs8L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+Y2M6PC9GT05U PiA8QlI+IDxGT05UIFNJWkU9Mj5iY2M6PC9GT05UPiA8QlI+IDxGT05UIFNJWkU9Mj5TdWJqZWN0 OjwvRk9OVD4gPEZPTlQgU0laRT0yPldHIGRyYWZ0cyAtIE15IGNvcnJlY3Rpb248L0ZPTlQ+PEJS PiA8QlI+PEJSPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+VGhhbmtzIHRv IHRob3NlIG9mIHlvdSB3aG8gcG9pbnRlZCBvdXQgbXkgbWlzdGFrZSBvbiBhbmQgb2ZmIHRoZSBs aXN0LjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5UbyBzZXQg dGhpbmdzIHN0cmFpZ2h0Li4uPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENv dXJpZXIiPjEuIFdlIGhhdmUgYWxyZWFkeSBhY2NlcHRlZCBkcmFmdC1heXlhbmdhci1jY2FtcC1p bnRlci1kb21haW4tcnN2cC10ZSBhcyBhPEJSPldHIGRyYWZ0IGFuZCBpdCBoYXMgYmVlbiBwdWJs aXNoZWQgYXM8QlI+ZHJhZnQtaWV0Zi1jY2FtcC1pbnRlci1kb21haW4tcnN2cC10ZTxCUj48L0ZP TlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4yLiBJIGhhdmUgc2VlbiBjb25z ZW5zdXMgZm9yIGRyYWZ0LWF5eWFuZ2FyLWNjYW1wLWxzcC1zdGl0Y2hpbmcgdG8gYmU8QlI+cHVi bGlzaGVkIGFzIGEgV0cgZHJhZnQgYW5kIHRoZSBhdXRob3JzIHdpbGwgc3VibWl0IGl0IGFzPEJS PmRyYWZ0LWlldGYtY2NhbXAtbHNwLXN0aXRjaGluZyBzb29uPEJSPjwvRk9OVD48L1A+PFA+PEZP TlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPi0mZ3Q7IGFncmVlZCAtIG5vdGU6IHdvdWxkIHlv dSB0ZWxsIHVzIChvciBhdXRob3JzKSB3aGVuIGNvbW1lbnRzIG1hZGUgb24gdGhpcyBsaXN0IHdv dWxkIHRoZW4gYmUgaW5jb3Jwb3JhdGVkID88L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9z cGFjZSxDb3VyaWVyIj48QlI+My4gVGhlIG5hbWUgb2YgdGhlIHRoaXJkIGRyYWZ0IGlzPEJSPmRy YWZ0LXZhc3NldXItY2NhbXAtaW50ZXItZG9tYWluLXBkLXBhdGgtY29tcC4gVGhpcyBpcyB0aGUg ZHJhZnQgdGhhdCB3ZTxCUj5uZWVkIHRvIGNvbnNpZGVyLjxCUj48QlI+QXMgSlAgc2F5cywgaGUg cGxhbnMgdG8gYWRkIHRoZSBzZW50ZW5jZSAmcXVvdDtJbiB0aGUgY29udGV4dCBvZiB0aGlzIGRy YWZ0LDxCUj50aGUgbm9kZSBpbiBjaGFyZ2Ugb2YgYW55IEVSTyBleHBhbnNpb24gd2l0aGluIGl0 cyBkb21haW4gaXMgYWx3YXlzIGFsb25nPEJSPnRoZSBpbnRlci1kb21haW4gVEUgTFNQIHBhdGgm cXVvdDsgdG8gdGhpcyBkcmFmdC48QlI+PC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3Bh Y2UsQ291cmllciI+LSZndDsgcmVhZGluZyB0aHJvdWdoIHRoZSBkb2N1bWVudCBhbmQgdGFraW5n IHNlY3Rpb24gNCBhcyB0aGUgY29yZSwgaSB3b25kZXIgd2h5IGV4YW1wbGVzIG9mIHRoZSBzYW1l IHNlY3Rpb24gYXJlIHByZXNjcmlwdGl2ZSA/IGlzIHRoZXJlIGJ5IG5vIG1lYW5zIGEgd2F5IHRv IHJlLXdyaXRlIHRoaXMgZG9jdW1lbnQgaW4gcHJlc2NyaXB0aXZlIG1vZGUgKHNpbmNlIGFmYWlr IHRoaXMgaXMgaW50ZW5kZWQgdG8gYmVjb21lIGEgcHJvcG9zZWQgc3RhbmRhcmQgYW5kIG5vdCBh biBpbmZvcm1hdGlvbmFsIGRvY3VtZW50KSBhbmQgb25seSBnaXZlIGV4YW1wbGVzIGluIGFwcGVu ZGl4IGFuZCBub3QgdXNlIGV4YW1wbGVzIHRvIGRlc2NyaWJlIGl0cyBjb3JlIGNvbnRlbnQgLSA8 L0ZPTlQ+PC9QPjxQPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+UXVlc3Rpb246 IFdpdGggdGhlIGFkZGl0aW9uIG9mIHRoaXMgc2VudGVuY2UsIGFyZSB3ZSBjb250ZW50IHRvIGFj Y2VwdDxCUj50aGlzIGRyYWZ0IGFzIGEgV0cgZHJhZnQ/PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFD RT0iTW9ub3NwYWNlLENvdXJpZXIiPlRoYW5rcyw8QlI+QWRyaWFuPEJSPjwvRk9OVD48L1A+ Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 15:29:02 +0000 Message-ID: <42418AB7.5070807@lucent.com> Date: Wed, 23 Mar 2005 08:26:47 -0700 From: Stephen J Trowbridge Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) MIME-Version: 1.0 To: Sasha Vainshtein CC: "'Diego Caviglia'" , ccamp Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Content-Type: text/plain; charset=ISO-8859-8 Content-Transfer-Encoding: 7bit Sasha and Diego, IMHO, it is a very bad idea to have two "normative" places where something is standardized. You already have the SDH standards in ITU-T documents (G.707, G.783, etc.) and the SONET standards in ATIS OPTXS (formerly T1X1) documents (mostly the T1.105 series). There is no reason that standards track RFCs cannot make normative references to these documents where needed. It would be inappropriate for IETF to attempt to replicate these documents as RFCs. Regards, Steve On 3/23/2005 6:44 AM, Sasha Vainshtein wrote: > Diego, > I do not see any technical problems with placing such > a definition in an Internet-Draft. > > But there may be problems associated with the IETF process: > > 1. Do you want to pursue this activity in the CCAMP WG? > I am not sure this is really in the scope as defined > by the CCAMP Charter > > 2. For interoperability the IETF document should be > a Standards Track RFC. On the other hand, CCAMP is in > the Routing Area meaning that you need an implementation > to publish a Standards Track RFC - but what could be > considered as an implementation in this case? > > Regards, > Sasha Vainshtein > email: sasha@axerra.com > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833 > > > >>-----Original Message----- >>From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] >>Sent: Wednesday, March 23, 2005 3:37 PM >>To: Sasha Vainshtein >>Cc: ccamp >>Subject: RE: Failure definition w.r.t. SONET/SDH and >>Protection/Restoratio n >> >> >> >>Hi Sasha, >> I agree with you but in any case for >>interop issues >>and for sake of clarity I'd like to have that written in some IETF >>document. >> >>Regards >> >>Diego >> >> >> >> >> >>Sasha Vainshtein on 23/03/2005 12.23.12 >> >>To: "'Diego Caviglia'" >>cc: ccamp@ops.ietf.org >> >>Subject: RE: Failure definition w.r.t. SONET/SDH and >> Protection/Restoratio n >> >> >>Diego and all, >>IMHO it is reasonable to assume that a failure is >>a defect that results in sending downstream AIS >>(and upstream RDI) as consequent action(s). >> >>For SDH consecutive actions for each defect >>are specified in ITU-T G.783. >> >>Note also that for some defects the consecutive action >>can be disabled by configuration. Hence I'd say that >>the same defect can be a failure in one case and >>not a failure in another case. The typical example >>is Trail Identifier Mismatch (TIM). >> >>Hopefully this note will help. >> >>Regards, >> Sasha Vainshtein >>email: sasha@axerra.com >> >>phone: +972-3-7569993 (office) >>fax: +972-3-6487779 >>mobile: +972-52-8674833 >> >> >> >>>-----Original Message----- >>>From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] >>>Sent: Wednesday, March 23, 2005 1:06 PM >>>To: ccamp@ops.ietf.org >>>Subject: Failure definition w.r.t. SONET/SDH and >>>Protection/Restoration >>> >>> >>>Hi all, >>> is it defined somewhere, with respect to >>>SDH/SONET, which >>>defect has to be consider as a failure? >>> >>>It seems to me that for interoperability could be useful to >>>have a list of >>>defect that must be considered as failure, the same applies >>>for defect that >>>optionally can be considered as defect. >>> >>>May be also a communication between restoration TNEs in order >>>to agree on >>>the list could be useful. >>> >>>Does anyone agree on that? >>> >>>Regards >>> >>>Diego >>> >>>PS I apologise if the list is defined somewhere but I wasn't >>>able to find >>>it. >>> >>> >>> >>> >> >> >> >> >> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 14:01:55 +0000 Sensitivity: Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n To: "Sasha Vainshtein Cc: "ccamp Message-ID: From: "Diego Caviglia" Date: Wed, 23 Mar 2005 15:01:48 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii May be Adrian can put come light on the question you raised. Regards Diego Sasha Vainshtein on 23/03/2005 14.44.23 To: "'Diego Caviglia'" cc: ccamp Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Diego, I do not see any technical problems with placing such a definition in an Internet-Draft. But there may be problems associated with the IETF process: 1. Do you want to pursue this activity in the CCAMP WG? I am not sure this is really in the scope as defined by the CCAMP Charter 2. For interoperability the IETF document should be a Standards Track RFC. On the other hand, CCAMP is in the Routing Area meaning that you need an implementation to publish a Standards Track RFC - but what could be considered as an implementation in this case? Regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7569993 (office) fax: +972-3-6487779 mobile: +972-52-8674833 > -----Original Message----- > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > Sent: Wednesday, March 23, 2005 3:37 PM > To: Sasha Vainshtein > Cc: ccamp > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoratio n > > > > Hi Sasha, > I agree with you but in any case for > interop issues > and for sake of clarity I'd like to have that written in some IETF > document. > > Regards > > Diego > > > > > > Sasha Vainshtein on 23/03/2005 12.23.12 > > To: "'Diego Caviglia'" > cc: ccamp@ops.ietf.org > > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoratio n > > > Diego and all, > IMHO it is reasonable to assume that a failure is > a defect that results in sending downstream AIS > (and upstream RDI) as consequent action(s). > > For SDH consecutive actions for each defect > are specified in ITU-T G.783. > > Note also that for some defects the consecutive action > can be disabled by configuration. Hence I'd say that > the same defect can be a failure in one case and > not a failure in another case. The typical example > is Trail Identifier Mismatch (TIM). > > Hopefully this note will help. > > Regards, > Sasha Vainshtein > email: sasha@axerra.com > > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833 > > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Wednesday, March 23, 2005 1:06 PM > > To: ccamp@ops.ietf.org > > Subject: Failure definition w.r.t. SONET/SDH and > > Protection/Restoration > > > > > > Hi all, > > is it defined somewhere, with respect to > > SDH/SONET, which > > defect has to be consider as a failure? > > > > It seems to me that for interoperability could be useful to > > have a list of > > defect that must be considered as failure, the same applies > > for defect that > > optionally can be considered as defect. > > > > May be also a communication between restoration TNEs in order > > to agree on > > the list could be useful. > > > > Does anyone agree on that? > > > > Regards > > > > Diego > > > > PS I apologise if the list is defined somewhere but I wasn't > > able to find > > it. > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 13:52:12 +0000 Message-ID: From: Sasha Vainshtein To: "'Diego Caviglia'" Cc: ccamp Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Date: Wed, 23 Mar 2005 15:44:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Diego, I do not see any technical problems with placing such a definition in an Internet-Draft. But there may be problems associated with the IETF process: 1. Do you want to pursue this activity in the CCAMP WG? I am not sure this is really in the scope as defined by the CCAMP Charter 2. For interoperability the IETF document should be a Standards Track RFC. On the other hand, CCAMP is in the Routing Area meaning that you need an implementation to publish a Standards Track RFC - but what could be considered as an implementation in this case? Regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7569993 (office) fax: +972-3-6487779 mobile: +972-52-8674833 > -----Original Message----- > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > Sent: Wednesday, March 23, 2005 3:37 PM > To: Sasha Vainshtein > Cc: ccamp > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoratio n > > > > Hi Sasha, > I agree with you but in any case for > interop issues > and for sake of clarity I'd like to have that written in some IETF > document. > > Regards > > Diego > > > > > > Sasha Vainshtein on 23/03/2005 12.23.12 > > To: "'Diego Caviglia'" > cc: ccamp@ops.ietf.org > > Subject: RE: Failure definition w.r.t. SONET/SDH and > Protection/Restoratio n > > > Diego and all, > IMHO it is reasonable to assume that a failure is > a defect that results in sending downstream AIS > (and upstream RDI) as consequent action(s). > > For SDH consecutive actions for each defect > are specified in ITU-T G.783. > > Note also that for some defects the consecutive action > can be disabled by configuration. Hence I'd say that > the same defect can be a failure in one case and > not a failure in another case. The typical example > is Trail Identifier Mismatch (TIM). > > Hopefully this note will help. > > Regards, > Sasha Vainshtein > email: sasha@axerra.com > > phone: +972-3-7569993 (office) > fax: +972-3-6487779 > mobile: +972-52-8674833 > > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Wednesday, March 23, 2005 1:06 PM > > To: ccamp@ops.ietf.org > > Subject: Failure definition w.r.t. SONET/SDH and > > Protection/Restoration > > > > > > Hi all, > > is it defined somewhere, with respect to > > SDH/SONET, which > > defect has to be consider as a failure? > > > > It seems to me that for interoperability could be useful to > > have a list of > > defect that must be considered as failure, the same applies > > for defect that > > optionally can be considered as defect. > > > > May be also a communication between restoration TNEs in order > > to agree on > > the list could be useful. > > > > Does anyone agree on that? > > > > Regards > > > > Diego > > > > PS I apologise if the list is defined somewhere but I wasn't > > able to find > > it. > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 13:38:43 +0000 Sensitivity: Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n To: "Sasha Vainshtein Cc: "ccamp" Message-ID: From: "Diego Caviglia" Date: Wed, 23 Mar 2005 14:36:59 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Sasha, I agree with you but in any case for interop issues and for sake of clarity I'd like to have that written in some IETF document. Regards Diego Sasha Vainshtein on 23/03/2005 12.23.12 To: "'Diego Caviglia'" cc: ccamp@ops.ietf.org Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Diego and all, IMHO it is reasonable to assume that a failure is a defect that results in sending downstream AIS (and upstream RDI) as consequent action(s). For SDH consecutive actions for each defect are specified in ITU-T G.783. Note also that for some defects the consecutive action can be disabled by configuration. Hence I'd say that the same defect can be a failure in one case and not a failure in another case. The typical example is Trail Identifier Mismatch (TIM). Hopefully this note will help. Regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7569993 (office) fax: +972-3-6487779 mobile: +972-52-8674833 > -----Original Message----- > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > Sent: Wednesday, March 23, 2005 1:06 PM > To: ccamp@ops.ietf.org > Subject: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > > Hi all, > is it defined somewhere, with respect to > SDH/SONET, which > defect has to be consider as a failure? > > It seems to me that for interoperability could be useful to > have a list of > defect that must be considered as failure, the same applies > for defect that > optionally can be considered as defect. > > May be also a communication between restoration TNEs in order > to agree on > the list could be useful. > > Does anyone agree on that? > > Regards > > Diego > > PS I apologise if the list is defined somewhere but I wasn't > able to find > it. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 11:30:41 +0000 Message-ID: From: Sasha Vainshtein To: "'Diego Caviglia'" Cc: ccamp@ops.ietf.org Subject: RE: Failure definition w.r.t. SONET/SDH and Protection/Restoratio n Date: Wed, 23 Mar 2005 13:23:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Diego and all, IMHO it is reasonable to assume that a failure is a defect that results in sending downstream AIS (and upstream RDI) as consequent action(s). For SDH consecutive actions for each defect are specified in ITU-T G.783. Note also that for some defects the consecutive action can be disabled by configuration. Hence I'd say that the same defect can be a failure in one case and not a failure in another case. The typical example is Trail Identifier Mismatch (TIM). Hopefully this note will help. Regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7569993 (office) fax: +972-3-6487779 mobile: +972-52-8674833 > -----Original Message----- > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > Sent: Wednesday, March 23, 2005 1:06 PM > To: ccamp@ops.ietf.org > Subject: Failure definition w.r.t. SONET/SDH and > Protection/Restoration > > > Hi all, > is it defined somewhere, with respect to > SDH/SONET, which > defect has to be consider as a failure? > > It seems to me that for interoperability could be useful to > have a list of > defect that must be considered as failure, the same applies > for defect that > optionally can be considered as defect. > > May be also a communication between restoration TNEs in order > to agree on > the list could be useful. > > Does anyone agree on that? > > Regards > > Diego > > PS I apologise if the list is defined somewhere but I wasn't > able to find > it. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 11:06:55 +0000 Sensitivity: Subject: Failure definition w.r.t. SONET/SDH and Protection/Restoration To: ccamp@ops.ietf.org Message-ID: From: "Diego Caviglia" Date: Wed, 23 Mar 2005 12:05:49 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi all, is it defined somewhere, with respect to SDH/SONET, which defect has to be consider as a failure? It seems to me that for interoperability could be useful to have a list of defect that must be considered as failure, the same applies for defect that optionally can be considered as defect. May be also a communication between restoration TNEs in order to agree on the list could be useful. Does anyone agree on that? Regards Diego PS I apologise if the list is defined somewhere but I wasn't able to find it. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 09:55:05 +0000 Message-ID: <0cd001c52f8e$8c5465d0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: IETF-62 Proceedings Submission Date: Wed, 23 Mar 2005 09:55:59 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Common Control and Measurement Plane WG (ccamp) Tuesday, March 8, 2005 at 0900-1130 Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen Working group status - chairs - No changes to the agenda made. - Adrian reviewed status of drafts, reviewed charter milestones. We are holding off on new charter until finish last call of 8 drafts, expect 1-2 months. - Bill summarized ADs view, should wait for re-chartering until finish last call considering expectation will be very soon for last calls. * Dimitri asked about IPR assertion on re-optimization draft - Adrian said it did not give the same terms that have been seen in some recent IPR claims. The WG has to decide what to do. - Scott Bradner said we need to be very careful. Advised there may be anti-trust issues. Best to have no IETF interaction other than to ask for clarity. Scott offered to review emails on the subject. - JP said we can take that as a way to go forward and continue technical work. ASON considerations ITU liaison - Lyndon Ong presented Wesam's slides - Thanks to the IETF for liaisons and participation of Adrian and Igor at last meetings - Crankback and the comparison of LMP and ASON discovery will be incorporated in SG15 Q14's work. - There are two liaisons from ITU to CCAMP on the way. - Routing - ITU not planning any routing exts work, looking to IETF's work. - Continuing work on ASON management. - An FTP site is available for liaison statements. * Adrian asked if ITU plans to liaise G.7713 on new text for crankback before consent? - Lyndon said a meeting is upcoming and will ask for it to be considered. * Kireeti asked if there is any problem in that the crankback draft is not an RFC yet? - Adrian - RFC is desirable, not required? - Scott Bradner - it is required to have an RFC number for final balloting. The IESG can request expedited publication. * Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU terminology, and may want to consider including it. - Adrian - can that be liaised to us? - Steve Trowbridge - Yes, we can do that. ASON Routing Evaluation * Adrian - The design team on routing has members from both ITU and IETF, although we did not do the correct process, so ITU reps are individuals, not ITU representatives. - Adrian will work with Steve to formalize the process. * Adrian - Would like to make the draft from the team on evaluation of routing protocols into a working group draft - we will take to the list to see if any objection. * Dimitri - asked if we can use formal liaison process to send this draft to ITU, does it need to be WG draft? And encourages comments now, before it goes to last call. - Adrian - we can liaise the draft and our intention to consider it as a WG draft Lexicography draft (Adrian) - Q14 indicates meeting went well, authors summarized comments and incorporated in this release. * Adrian asked if should be WG draft - Kireeti said we could do that, need to ask the list, also need to compare with G.8081 * Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC or drafts, are there definitions? - Adrian thinks there are good terms, though in multiple RFCs/drafts. - Ben - if someone is new to the IETF, they have difficulty on where to go for definitions. - Adrian - if people want to do a draft to collect definitions of all GMPLS terms (more general than just ASON as in lexi draft), then they are welcome to do it. Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi) LSP Stitching (Arthi) - Need feedback on several items. * Adrian - it would be inappropriate to move extensions to be a WG draft without first stitching draft becoming a wg draft. If no one objects, see no reason why not to be WG draft. * Dimitri - Question: the draft was to originally do signaling exts, do we need to do more on routing aspects? - Arthi - agree, however this comment would have applied to the previous merged draft. The whole point of splitting the ID was because the scope was wider and generic. In that case, it becomes necessary to include the routing aspects as well. * Dimitri - if allow stitching of end-to-end LSP with LSP segment through different switching caps, then this changes the LSP switching type along the path and thus this becomes a FA - Arthi - but end-to-end does not change. * Zafar - we need to be careful what advertising because of scalability concerns, need further consideration. - Kireeti - As Arthi said the LSP segment does not *have to* be advertised but *can be* if desired. - Arthi - You, of course, need to be careful about advertising anything as TE-links dictated by correct policies. And as far as scaling is concerned, Igor is standing right behind you and will probably say (and I agree) that LSP segments can also be bundled in which case you are no longer advertising each LSP segment as a TE-link. We are simply having the same discussion again that was on the mailing list. * Igor - thought stitching maybe more appropriate for LSP hierarchy draft, but as this already in editor's queue, will add here. * Lou - sw cap can change hop by hop just needs to match end to end of hop. - Arthi - agree, we were thinking the same. * Discussion sent to mailing list Per-domain path computation method for computing inter-domain traffic engineering (TE) LSP. (JP) Draft-vasseur-ccamp-inter-domain-path-comp-00.txt: routing and path computation aspects. * Zafar asked clarification on ccamp-pce relationship - Kireeti - this draft discusses ASBR on the path, if not then it's PCE, suggest add this to draft to clarify that this is for when computation is done by elements on the path. - JP - ok * Adrian and Kireeti asked if this should be a WG draft? Good consensus in the room to be WG draft, will take it to the list. Automesh (JP) - Agreement to rehash work a bit to put these together. - Now 2 drafts - Not a new ID, no changes. - Deployed networks using that. - No major changes planned * Igor - asked how to reflect constraints in a node for switching? - JP - we are discussing auto mesh, not node switching. - Igor - but how do we reflect node capabilities? - JP - this draft is not about node capability discovery (for this, see draft-vasseur-ccamp-te-node-cap) - Igor - how to reflect for computation any internal constraints, could do via node caps advertisement. - JP agrees, though here just doing a discovery, doesn't think related as discovering members of mesh. - Adrian - two drafts, this is not node capability that is next one by JP, cut discussion said to take it to list. Routing extensions for discovery of TE node capabilities (JL Le Roux) * Adrian - on process, authors did a group job of splitting draft and sending to OSPF and ISIS groups, chairs will follow up with those groups. * Dimitri - should for terminology call TE router? - JL - yes. - Dimitri - should the TLV be exclusive to this function? - JL - yes. * Igor - how to distinguish node capabilities? - Adrian - do by TLVs, need to do a draft to propose, this draft gives you the TLVs, then can follow-up with other drafts to describe function want to use it for, take discussion to list. * JL asked that this be adopted as a WG document. - Adrian - Take it to the list Extensions to GMPLS RSVP graceful restart (Lou Berger) * Adrian - do editorial respin, let us know, and we will take to last call * Any implementations? - Yes - two! MRN Requirements (Kohei Shiomoto) Evaluation draft (JL Le Roux) Protocol extensions (Dimitri) * Arthi - what does virtual FA have to do with MRN, isn't it general? - Dimitri - should we have a specific doc on virtual FA for wider scope? - Arthi - did you want to scope only to MRN context? - Dimitri - no, just not sure if soln doc should be split. - Arthi - could be general - so prefer a separate doc on virtual FA. * Zafar - we need to give a priority capability for TE. - Dimitri - new TLV may be needed to describe relationships of multiple interfaces * Zafar - how relates to hierarchy draft? - Dimitri - maybe should be as applicability statement, - Kireeti - should do on mailing list * Kireeti - requests to continue work, when re-charter will consider for WG drafts. Routing considerations and CSPF for inter-as (Tomohiro Otani) * JP - very useful draft. Concerned about the advertisement of DYNAMIC summarized TE resource information across domains (static capabilities are perfectly fine). Too much of aggregation renders the solution inefficient and not enough of aggregation seriously compromises the routing scalability. Furthermore, there are other confidentiality issues to sort out in the context of inter-provider. - Otani - ok, we need more on summarizing capability. * Kireeti - thinks good and hopes to be a WG draft, though for now would request for this draft to continue work, though lets finish what ccamp has now and then when re-charter will make this as a WG doc. * Otani - how to handle inter-as cspf constraints? - Kireeti - as noted before (continue work). L2LSP (Dimitri) * Adrian asked clarification, is this "single hop"? - Dimitri - multiple hops each is a LSR, will clarify this in draft * Kireeti - ADs request a framework doc and include how it relates to other SDOs, max 10 pages - Dimitri - ok GMPLS addressing (Richard Rabbat) * Adrian - as this is first version, recommend continue discussion, re-spin draft, and then review again. * Adrian asked for feedback on the topics, not the technical content initially. * Loa - BCP is a specific type of RFC, describes what we have experience with not necessarily what should be (as in this draft) * Kireeti - warns for everyone with implementations to review the draft to ensure direction taken by this draft is right one. * Lou - should we wait for re-spin or now? - Kireeti - wait for re-spin. L1VPN (Tomonori Takeda) Framework draft Applicability draft * Alex - by next IETF will decide if it should be included in ccamp or as separate WG. Control plane saturation (JL Le Roux) * Arthi - Do you think the LSRs would really want to advertise such control plane limitations ? Secondly, what implication does this have in case of inter-domain, especially inter-provider LSPs ? * Kireeti - because of time, lets do on list. Graceful shutdown (Zafar Ali) * Kireeti - will consider for wg doc after re-charter * JP - is this part of current charter - Kireeti - doesn't matter, we just can not include anymore as WG doc until re-charter. Deployment-augmented (Zafar Ali) * Arthi - This is good work. My only concern is the use of terminology. Do you actually expect to use LSP-Hierarchy extensions (say Hop3) while signaling an MPLS LSP over that FA in the MPLS domain ? - Zafar - no just TE link GMPLS interworking (Kenji) * Dimitri - why need to adv priority of LSP? - Adrian - need to ask on list. GMPLS interworking (Kohei Shiomoto) * Adrian - WG doc will be decided after re-charter - Welcome that will merge with other draft on augmented, - Suggest also look at Kenji's interworking draft to merge. Cho - ARP signal * Kireeti - request work with Dimitri on framework draft, - When decide direction and interactions with other SDO, may decide to form a design team to work on L2, - First we need a framework. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 09:36:46 +0000 Date: Wed, 23 Mar 2005 18:36:21 +0900 From: Kenji Kumaki To: "Adrian Farrel" Subject: Re: WG drafts - My correction Cc: Message-Id: <20050323183615.6609.KE-KUMAKI@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > > Question: With the addition of this sentence, are we content to accept > this draft as a WG draft? > Yes. Thanks, Kenji > Thanks, > Adrian > -- Kenji Kumaki Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 09:28:11 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : WG drafts - My correction Date: Wed, 23 Mar 2005 10:26:10 +0100 Message-ID: Thread-Topic: WG drafts - My correction Thread-Index: AcUvPvt+pKkACTm3QGmj+hNaAyrvMAASzGDQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , >Question: With the addition of this sentence, are we content=20 >to accept this draft as a WG draft? yes JL >-----Message d'origine----- >De : owner-ccamp@ops.ietf.org=20 >[mailto:owner-ccamp@ops.ietf.org] De la part de Adrian Farrel >Envoy=E9 : mercredi 23 mars 2005 01:17 >=C0 : ccamp@ops.ietf.org >Objet : WG drafts - My correction > > >Thanks to those of you who pointed out my mistake on and off the list. > >To set things straight... > >1. We have already accepted=20 >draft-ayyangar-ccamp-inter-domain-rsvp-te as a WG draft and it=20 >has been published as draft-ietf-ccamp-inter-domain-rsvp-te > >2. I have seen consensus for=20 >draft-ayyangar-ccamp-lsp-stitching to be published as a WG=20 >draft and the authors will submit it as=20 >draft-ietf-ccamp-lsp-stitching soon > >3. The name of the third draft is=20 >draft-vasseur-ccamp-inter-domain-pd-path-comp. This is the=20 >draft that we need to consider. > >As JP says, he plans to add the sentence "In the context of=20 >this draft, the node in charge of any ERO expansion within its=20 >domain is always along the inter-domain TE LSP path" to this draft. > >Question: With the addition of this sentence, are we content=20 >to accept this draft as a WG draft? > >Thanks, >Adrian > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 00:37:15 +0000 Message-Id: <200503230036.j2N0ao1j011634@rtp-core-1.cisco.com> From: "Zafar Ali" To: "'Adrian Farrel'" , Subject: RE: WG drafts - My correction Date: Tue, 22 Mar 2005 19:36:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcUvPqHcj/FQyz7MQ8OO/bjV2G6CUQAAawkQ > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Tuesday, March 22, 2005 7:17 PM > To: ccamp@ops.ietf.org > Subject: WG drafts - My correction > > Thanks to those of you who pointed out my mistake on and off the list. > > To set things straight... > > 1. We have already accepted > draft-ayyangar-ccamp-inter-domain-rsvp-te as a WG draft and > it has been published as draft-ietf-ccamp-inter-domain-rsvp-te > > 2. I have seen consensus for > draft-ayyangar-ccamp-lsp-stitching to be published as a WG > draft and the authors will submit it as > draft-ietf-ccamp-lsp-stitching soon > > 3. The name of the third draft is > draft-vasseur-ccamp-inter-domain-pd-path-comp. This is the > draft that we need to consider. > > As JP says, he plans to add the sentence "In the context of > this draft, the node in charge of any ERO expansion within > its domain is always along the inter-domain TE LSP path" to > this draft. > > Question: With the addition of this sentence, are we content > to accept this draft as a WG draft? Yes, Thanks Regards... Zafar > > Thanks, > Adrian > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Mar 2005 00:23:22 +0000 Message-ID: <0c8a01c52f3e$7f9de820$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: WG drafts - My correction Date: Wed, 23 Mar 2005 00:16:55 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks to those of you who pointed out my mistake on and off the list. To set things straight... 1. We have already accepted draft-ayyangar-ccamp-inter-domain-rsvp-te as a WG draft and it has been published as draft-ietf-ccamp-inter-domain-rsvp-te 2. I have seen consensus for draft-ayyangar-ccamp-lsp-stitching to be published as a WG draft and the authors will submit it as draft-ietf-ccamp-lsp-stitching soon 3. The name of the third draft is draft-vasseur-ccamp-inter-domain-pd-path-comp. This is the draft that we need to consider. As JP says, he plans to add the sentence "In the context of this draft, the node in charge of any ERO expansion within its domain is always along the inter-domain TE LSP path" to this draft. Question: With the addition of this sentence, are we content to accept this draft as a WG draft? Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Mar 2005 18:26:44 +0000 Date: Tue, 22 Mar 2005 10:26:13 -0800 (PST) From: Rahul Aggarwal To: mohanss cc: ccamp@ops.ietf.org Subject: Re: Doubts on draft-ietf-mpls-rsvp-te-p2mp-01 Message-ID: <20050322101913.J14683@sapphire.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Mohan, On Tue, 22 Mar 2005, mohanss wrote: > Hi all, > > I have few doubts regarding the following drafts. > > Draft: draft-ietf-mpls-rsvp-te-p2mp-01.txt > 1) In this draft what is the role of sub-group ID. What will be the > value of this? I mean IP address or some other number? If it is IP > address which one? > The sub-group ID is intended to distinguish different Path Messages tha are signaling sub-LSPs for the same P2MP LSP. Its value is chosen by the originator of the PathMessage and doesn't have to be an IP address. > 2) Any vendor is already supporting this feature? > Setup of RSVP-TE P2MP LSPs? Can anyone list the vendors? > I will respond offline to this. rahul > 3) Which one of the following is best suitable for CSPF in P2MP? > Core Based Trees, Reverse Path Forwarding and Spanning trees? > > If available, please send the links for the same. > > Thanks and Regards, > -Mohan > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Mar 2005 18:23:54 +0000 Message-ID: <09b201c52f0c$3d1d4a90$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Subject: Re: Doubts on draft-ietf-mpls-rsvp-te-p2mp-01 Date: Tue, 22 Mar 2005 18:23:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Mohan, The correct place for your question is really the MPLS mailing list (see http://www.ietf.org/html.charters/mpls-charter.html) Brief answers to your questions below. > Draft: draft-ietf-mpls-rsvp-te-p2mp-01.txt > 1) In this draft what is the role of sub-group ID. What will be the > value of this? I mean IP address or some other number? If it is IP > address which one? The sub-group ID allows you to distinguish different sub-trees of the same P2MP tree. this allows the signaling state to be separated and managed distinctly (for example, using separate Path messages). The ability to provide such a distinction is important when more than one Path message for the same P2MP LSP might be received by the same LSR. For more details, see the section 3.3 of the draft. Sub-Group Originator ID should be set to the TE Router ID of the transit LSR. Sub-Group ID should be chosen as unique within the context of the Sub-Group Originator ID. > 2) Any vendor is already supporting this feature? > Setup of RSVP-TE P2MP LSPs? Can anyone list the vendors? I am aware of three vendors with "early" implementations of this draft. I must let them come forward and announce their own names. > 3) Which one of the following is best suitable for CSPF in P2MP? > Core Based Trees, Reverse Path Forwarding and Spanning trees? There are many choices. Since this is traffic engineering, all algorithms are acceptable, and vendors might expect to make significant marketing through their implementation of path computation. Regards, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Mar 2005 07:06:24 +0000 Date: Tue, 22 Mar 2005 12:29:43 +0530 From: mohanss Subject: Doubts on draft-ietf-mpls-rsvp-te-p2mp-01 To: ccamp@ops.ietf.org Reply-to: mohanss@huawei.com Message-id: Organization: huawei technlogies MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_hyhY3/59Wfsg2rowyeZRVQ)" This is a multi-part message in MIME format. --Boundary_(ID_hyhY3/59Wfsg2rowyeZRVQ) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi all, I have few doubts regarding the following drafts. Draft: draft-ietf-mpls-rsvp-te-p2mp-01.txt 1) In this draft what is the role of sub-group ID. What will be the value of this? I mean IP address or some other number? If it is IP address which one? 2) Any vendor is already supporting this feature? Setup of RSVP-TE P2MP LSPs? Can anyone list the vendors? 3) Which one of the following is best suitable for CSPF in P2MP? Core Based Trees, Reverse Path Forwarding and Spanning trees? If available, please send the links for the same. Thanks and Regards, -Mohan --Boundary_(ID_hyhY3/59Wfsg2rowyeZRVQ) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT Doubts on draft-ietf-mpls-rsvp-te-p2mp-01

Hi all,

I have few doubts regarding the following drafts.

Draft: draft-ietf-mpls-rsvp-te-p2mp-01.txt
1) In this draft what is the role of sub-group ID. What will be the value of this? I mean IP address or some other number? If it is IP address which one?

2) Any vendor is already supporting this feature?
Setup of RSVP-TE P2MP LSPs? Can anyone list the vendors?

3) Which one of the following is best suitable for CSPF in P2MP?
Core Based Trees, Reverse Path Forwarding and Spanning trees?

If available, please send the links for the same.

Thanks and Regards,
-Mohan







--Boundary_(ID_hyhY3/59Wfsg2rowyeZRVQ)-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Mar 2005 23:01:05 +0000 Message-ID: <08f801c52e69$c9cd0eb0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: "'Kireeti Kompella'" , Subject: Nortel Networks Statement on IPR claimed in draft-ietf-ccamp-loose-path-reopt-00.txt Date: Mon, 21 Mar 2005 21:32:27 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_088E_01C52E5D.7A7129C0" This is a multi-part message in MIME format. ------=_NextPart_000_088E_01C52E5D.7A7129C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Richard and Michelle, =20 Thank you for submitting your Patent Disclosure=20 (http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-path-reop= t-00.txt)=20 with respect to IETF Internet Draft = draft-ietf-ccamp-loose-path-reopt-00.txt. =20 I would be grateful if you could clarify two points to help me = understand this discolsure further. 1. The disclosure states that: Nortel Networks U.S. Patent No. 6,560,654 entitled "Apparatus and method of maintaining timely topology data within a link state = routing network" may contain claims that may be necessary for practicing a resulting IETF Standard based on this Internet Draft. Could you provide more detail about what aspects of draft-ietf-ccamp-loose-path-reopt-00.txt you believe may be impacted = by this disclosure? =20 2. Can you clarify whether the "fair, reasonable, reciprocal, and non-discriminatory terms" referenced in the disclosure include the intention, in the event that the referenced draft becomes an Internet Standard, not to assert the patent except that some party asserts a = patent patent it owns or controls against Nortel? By way of an example of wording that covers this intention, can I = draw your attention to a completely unrelated IPR disclosure at http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure.txt =20 Thank you for any clarification you are able to offer. Please note that I am copying this email to Kireeti Kompella who = co-chairs the IETF's CCAMP working group with me. The CCAMP working = group developed the Internet-Draft in question = (draft-ietf-ccamp-loose-path-reopt-00.txt) and so I am also copying this = email to the CCAMP mailing list. Best regards, Adrian Farrel -- Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978-860944 Fax: +44 (0) 870-130-5411 adrian@olddog.co.uk ------=_NextPart_000_088E_01C52E5D.7A7129C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Richard and = Michelle,
 
Thank you=20 for submitting your Patent Disclosure
(http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-p= ath-reopt-00.txt)
with respect to IETF Internet Draft=20 draft-ietf-ccamp-loose-path-reopt-00.txt.
 
I would be = grateful if=20 you could clarify two points to help me understand this discolsure=20 further.

1. The disclosure states = that:
    =20 Nortel Networks U.S. Patent No. 6,560,654 entitled "Apparatus=20 and
   =   method of=20 maintaining timely topology data within a link state=20 routing
     network" may contain claims that may = be=20 necessary for practicing a
     resulting IETF = Standard=20 based on this Internet Draft.
  Could you provide more detail = about what=20 aspects of
  draft-ietf-ccamp-loose-path-reopt-00.txt you = believe may be=20 impacted by
  this disclosure?
 
2. Can you = clarify=20 whether the "fair, reasonable, reciprocal, and
 =20  non-discriminatory terms" referenced in the disclosure include=20 the
   intention, in the event that the referenced draft = becomes an=20 Internet
   Standard, not to assert the patent except that = some=20 party asserts a patent
   patent it owns or controls = against=20 Nortel?
   By way of an = example=20 of wording that covers this intention, can I draw
   your attention to a = completely=20 unrelated IPR disclosure at
   http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure= .txt
 
Thank you for any clarification you = are able to=20 offer.
 
Please note that I am copying this = email to=20 Kireeti Kompella who co-chairs the IETF's CCAMP working group with me. = The CCAMP=20 working group developed the Internet-Draft in question=20 (draft-ietf-ccamp-loose-path-reopt-00.txt) and so I am also copying this = email=20 to the CCAMP mailing list.
 
Best regards,
Adrian Farrel
--
Adrian Farrel
Old Dog=20 Consulting
Phone: +44 (0) 1978-860944
Fax: +44 (0) = 870-130-5411
adrian@olddog.co.uk
 
 
------=_NextPart_000_088E_01C52E5D.7A7129C0-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Mar 2005 20:31:22 +0000 Message-Id: <200503212029.PAA14891@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-02.txt Date: Mon, 21 Mar 2005 15:29:50 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Extensions to GMPLS RSVP Graceful Restart Author(s) : A. Satyanarayana, R. Rahman Filename : draft-ietf-ccamp-rsvp-restart-ext-02.txt Pages : 20 Date : 2005-3-21 This document describes extensions to the RSVP Graceful Restart mechanisms defined in [RFC3473]. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. These mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The presented extensions use the RSVP Hello extensions defined in [RFC3209], and extensions for state recovery on nodal faults defined in [RFC3473]. With the presented extensions the restarting node can recover all previously transmitted Path state including the ERO and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. The extensions optionally support the use of Summary Refresh, defined in [RFC2961], to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSP's. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-rsvp-restart-ext-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-21154155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-restart-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-21154155.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Mar 2005 13:10:54 +0000 Mime-Version: 1.0 (Apple Message framework v619.2) To: ccamp@ops.ietf.org Message-Id: <6f124df9bedb7c3dcd8aa6ba517b07ee@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-25--40678782 From: JP Vasseur Subject: Fwd: Opinion on two new WG drafts (CORRECTION) Date: Mon, 21 Mar 2005 08:08:27 -0500 --Apple-Mail-25--40678782 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I just had a brief discussion with Adrian. As requested per Kireeti I will add the following sentence to draft-vasseur-ccamp-inter-domain-pd-path-comp: "In the context of this draft, the node in charge of any ERO expansion within its domain is always along the inter-domain TE LSP path". Then the question for the WG should read: Is the WG in favor of adopting draft-vasseur-ccamp-inter-domain-pd-path-comp as a WG document (yes/no) ? thanks. JP. Begin forwarded message: > From: "Adrian Farrel" > Date: March 18, 2005 3:04:51 PM EST > To: > Subject: Opinion on two new WG drafts > Reply-To: "Adrian Farrel" > > Our charter encourages us to work on inter-domain solutions. > There are two drafts which we should consider as working group drafts: > - draft-vasseur-ccamp-inter-domain-path-comp-00.txt > - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt > > In Minneapolis the room seemed to be in favor with two caveats: > - draft-vasseur-ccamp-inter-domain-path-comp must include a > statement clarifying that in the context of this draft, the node in > charge of any ERO expansion within its domain is always along > the inter-domain TE LSP path > - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt must wait > for draft-ayyangar-ccamp-lsp-stitching-00.txt to become a > CCAMP draft > > Assuming these requirements to be fulfilled, please say whether you > support these drafts becoming CCAMP drafts. A simple yes/no is enough, > but > reasons against are useful. > > Thanks, > Adrian > --Apple-Mail-25--40678782 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII I just had a brief discussion with Adrian. As requested per Kireeti I will add the following sentence to draft-vasseur-ccamp-inter-domain-pd-path-comp: "In the context of this draft, the node in charge of any ERO expansion within its domain is always along the inter-domain TE LSP path". Then the question for the WG should read: Is the WG in favor of adopting draft-vasseur-ccamp-inter-domain-pd-path-comp as a WG document (yes/no) ? thanks. JP. Begin forwarded message: Helvetica0000,0000,0000From: Helvetica"Adrian Farrel" < 0000,0000,0000Date: March 18, 2005 3:04:51 PM EST 0000,0000,0000To: < 0000,0000,0000Subject: Opinion on two new WG drafts 0000,0000,0000Reply-To: "Adrian Farrel" < Our charter encourages us to work on inter-domain solutions. There are two drafts which we should consider as working group drafts: - draft-vasseur-ccamp-inter-domain-path-comp-00.txt - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt In Minneapolis the room seemed to be in favor with two caveats: - draft-vasseur-ccamp-inter-domain-path-comp must include a statement clarifying that in the context of this draft, the node in charge of any ERO expansion within its domain is always along the inter-domain TE LSP path - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt must wait for draft-ayyangar-ccamp-lsp-stitching-00.txt to become a CCAMP draft Assuming these requirements to be fulfilled, please say whether you support these drafts becoming CCAMP drafts. A simple yes/no is enough, but reasons against are useful. Thanks, Adrian --Apple-Mail-25--40678782-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 19 Mar 2005 16:38:59 +0000 Message-ID: <423C5526.5070908@psg.com> Date: Sat, 19 Mar 2005 17:36:54 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Opinion on two new WG drafts Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit adrian, just to be sure the first reference is not available, so be sure that we are discussing the correct document do you refer to now the second document appears to me to be already a working group document - so would you clarify the below question ? i have already send a bunch of comment on this document (from its non-WG version so expect to see some discussion on the next version), an additional remark would be that the sentence "There are three ways in which an RSVP-TE LSP could be signaled across multiple domains:" is not precise enough to translate the fact there are two ways (and not three) one that does use a unique end-to-end RSVP session (contiguous) and another that allows usage of intermediate RSVP session(s) used to establish the end-to-end session; currently there are three (and not two) methods that can be used for the second way: stitching (the head-end intermediate node performs selection of the segment), splicing (the LSP head-end node performs selection of the segment, using explicit label control), and nesting note: the second method is detailed in RFC 3471, section 6, thanks, - dimitri. Adrian Farrel wrote: > Our charter encourages us to work on inter-domain solutions. > There are two drafts which we should consider as working group drafts: > - draft-vasseur-ccamp-inter-domain-path-comp-00.txt > - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt > > In Minneapolis the room seemed to be in favor with two caveats: > - draft-vasseur-ccamp-inter-domain-path-comp must include a > statement clarifying that in the context of this draft, the node in > charge of any ERO expansion within its domain is always along > the inter-domain TE LSP path > - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt must wait > for draft-ayyangar-ccamp-lsp-stitching-00.txt to become a > CCAMP draft > > Assuming these requirements to be fulfilled, please say whether you > support these drafts becoming CCAMP drafts. A simple yes/no is enough, but > reasons against are useful. > > Thanks, > Adrian > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Mar 2005 20:35:20 +0000 Message-Id: <200503182034.PAA22974@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-00.txt Date: Fri, 18 Mar 2005 15:34:21 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within The Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture Author(s) : I. Bryskin, A. Farrel Filename : draft-ietf-ccamp-gmpls-ason-lexicography-00.txt Pages : 12 Date : 2005-3-18 Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of physical technologies and across several architectural models. The ITU-T has specified an architecture for the management of Automatically Switched Optical Networks (ASON). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ason-lexicography-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-18153745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-lexicography-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-18153745.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Mar 2005 20:26:08 +0000 Message-ID: <065701c52bf8$31885830$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Opinion on two new WG drafts Date: Fri, 18 Mar 2005 20:04:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Our charter encourages us to work on inter-domain solutions. There are two drafts which we should consider as working group drafts: - draft-vasseur-ccamp-inter-domain-path-comp-00.txt - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt In Minneapolis the room seemed to be in favor with two caveats: - draft-vasseur-ccamp-inter-domain-path-comp must include a statement clarifying that in the context of this draft, the node in charge of any ERO expansion within its domain is always along the inter-domain TE LSP path - draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt must wait for draft-ayyangar-ccamp-lsp-stitching-00.txt to become a CCAMP draft Assuming these requirements to be fulfilled, please say whether you support these drafts becoming CCAMP drafts. A simple yes/no is enough, but reasons against are useful. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Mar 2005 20:26:00 +0000 Message-ID: <065401c52bf8$2cbd3b90$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Arthi Ayyangar" Subject: Stitching draft to WG status Date: Fri, 18 Mar 2005 19:56:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, We discussed making draft-ayyangar-ccamp-lsp-stitching-00.txt a CCAMP draft before Minneapolis. I judge that the consensus was that this should now be a WG draft. Arthi, please republish as draft-ietf-ccamp-lsp-stitching-00.txt with no other changes (except boilerplate as needed). We can then discuss the draft within the WG and move it forward rapidly. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Mar 2005 19:43:50 +0000 Message-ID: <017601c52be9$eef2efc0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , Subject: Yet more on drraft-ietf-ccamp-gmpls-te-mib-08.txt Date: Fri, 18 Mar 2005 19:38:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Digging deeper (sorry, I should done this before sending any e-mail:-( RFC 3471 says in IANA considerations "This document defines the following namespaces: o LSP Encoding Type: 8 bits o Switching Type: 8 bits o Generalized PID (G-PID): 16 bits All future assignments should be allocated through IETF Consensus action or documented in a Specification. LSP Encoding Type - valid value range is 1-255. This document defines values 1-11. Switching Type - valid value range is 1-255. This document defines values 1-4, 100, 150 and 200. Generalized PID (G-PID) - valid value range is 0-1500. This document defines values 0-46." fine no problem Switching type draft-ietf-ccamp-ospf-gmpls-extensions-12.txt adds 51 Layer-2 Switch Capable (L2SC) but makes no mention of that in IANA considerations; should it? The MIB text cites as reference draft-ietf-ccamp-gmpls-routing-09.txt which has no IANA considerations and I cannot see adding a value; should this be OSPF-gmpls-extensions? And draft-ietf-ccamp-gmpls-g709-09.txt says "Switching Type: Assigned by IANA via IETF Standards Track RFC Action. " ie this is now more restrictive than RFC 3471; is this really intended? LSP encoding type The MIB cites draft-ietf-ccamp-gmpls-g709-06.txt, This should be -09 which says - LSP Encoding Type: 12 defined in Section 3.1.1 13 defined in Section 3.1.1 Allocation Policy: [0..239] Assigned by IANA via IETF Standards Track RFC Action. ie this is now more restrictive than RFC3471; was this intended? Generalized PID Same story, MIB cites draft-ietf-ccamp-gmpls-g709-06.txt, which should be -09, does add values but again is more restrictive about how the values can be updated. Standing back, there are these three enumerations, they will be added to over the years, what is the right policy for updating them? Standards track, expert review, IETF consensus? How best to keep the MIBS in line with the I-Ds at least at initial publication, which is the authoritative document?(define it all in the MIB:-) Are there any more in other documents, perhaps for which no MIB yet exists? (RFC 3471 does list five sets of numbers - I have only looked at these three - and there an awfully large number of GMPLS documents most of which I have not looked at) Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Mar 2005 17:54:54 +0000 Message-ID: <05b001c52be1$8ebd3e10$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" Subject: Discussion about IPR claim in draft-ietf-ccamp-loose-path-reopt Date: Fri, 18 Mar 2005 17:18:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, As mentioned in Minneapolis, draft-ietf-ccamp-loose-path-reopt is the subject of an IPR disclosure http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-path-reopt-00.txt The working group must decide whether we wish to pursue this I-D in the face of this IPR disclosure. Clearly it is a significant step to create an RFC that might require implementers to license technology. I would welcome opinions on this subject. In the mean time I will work with Scott Bradner to see if we can get any additional information or clarification about this disclosure. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Mar 2005 17:54:46 +0000 Message-ID: <05b401c52be1$93bf4930$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , Subject: Re: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Fri, 18 Mar 2005 17:38:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Tom, Good advice. We'll look at how to do this. Adrian ----- Original Message ----- From: "Tom Petch" To: "Adrian Farrel" ; Sent: Friday, March 18, 2005 8:29 AM Subject: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt > This MIB contains several 'enumerations' except they are not enumerations but > text in > DESCRIPTION clauses - gmplsTunnelGPid gmplsTunnelSwitchingType > gmplsTunnelLSPEncoding - with RFC 3471 (not a MIB) as a reference. So these are > not defined anywhere in SMI; and as this points out, these values will be added > to in future RFC. > > I think these should be in a MIB under IANA control and there is already a way > to do just that, namely to put them in an IANA MIB (as opposed to a standards > track MIB) with the RFC specifying under what conditions the IANA MIB can be > updated (standards track, IESG, expert etc). > > This procedure is described in draft-ietf-ops-mib-review-guidelines-04.txt which > also points to previous examples of this. And this issue has already surfaced, > albeit obliquely, on this list once before in the context of > IANAItuProbableCause which uses this procedure and is now published as part of > the Alarm MIB (RFC 3877). > > Not to do this now creates extra work in the future; when an implementor has to > create their own SMI and whenever these values need to be updated. > > Tom Petch > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Mar 2005 14:21:55 +0000 Message-ID: <423AE3EA.5030002@psg.com> Date: Fri, 18 Mar 2005 15:21:30 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Updated minutes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi adrian a brief comment to clarify < "* Dimitri - if allow different switching caps, then this changes the < type, and this a FA" > * Dimitri - if allow stitching of end-to-end LSP with LSP segment > through different switching caps, then this changes the LSP switching > type along the path and thus this becomes a FA thanks, - dimitri. Adrian Farrel wrote: > Here with updates from Jean-Louis, JP and Arthi. > > Short call for further comments before I submit. > > Thanks, > Adrian > > === > > Common Control and Measurement Plane WG (ccamp) > > Tuesday, March 8, 2005 at 0900-1130 > Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen > > Working group status - chairs > - No changes to the agenda made. > - Adrian reviewed status of drafts, reviewed charter milestones. > We are holding off on new charter until finish last call of 8 > drafts, expect 1-2 months. > - Bill summarized ADs view, should wait for re-chartering until > finish last call considering expectation will be very soon for > last calls. > * Dimitri asked about IPR assertion on re-optimization draft > - Adrian said it did not give the same terms that have been seen > in some recent IPR claims. The WG has to desice what to do. > - Scott Bradner said we need to be very careful. Advised there > may be anti-trust issues. Best to have no IETF interaction > other than to ask for clarity. > Scott offered to review emails on the subject. > - JP said we can take that as a way to go forward and continue > technical work. > > ASON considerations > > ITU liaison - Lyndon Ong presented Wesam's slides > - Thanks to the IETF for liaisons and participation of Adrian and > Igor at last meetings > - Crankback and the comparison of LMP and ASON discovery will be > incorporated in SG15 Q14's work. > - There are two liaisons from ITU to CCAMP on the way. > - Routing - ITU not planning any routing exts work, looking to > IETF's work. > - Continuing work on ASON management. > - An FTP site is available for liaison statements. > * Adrian asked if ITU plans to liaise G.7713 on new text for > crankback before consent? > - Lyndon said a meeting is upcoming and will ask for it to be > considered. > * Kireeti asked if there is any problem in that the crankback draft > is not an RFC yet? > - Adrian - RFC is desirable, not required? > - Scott Bradner - it is required to have an RFC number for final > balloting. The IESG can request expedited publication. > * Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU > terminology, and may want to consider including it. > - Adrian - can that be liaisoned to us? > - Steve Trowbridge - Yes, we can do that. > > ASON Routing Evaluation > * Adrian - The design team on routing has members from both ITU and > IETF, although we did not do the correct process, so ITU reps are > individuals, not ITU representatives. > - Adrian will work with Steve to formalize the process. > * Adrian - Would like to make the draft from the team on evaluation > of routing protocols into a working group draft > - we will take to the list to see if any objection. > * Dimitri - asked if we can use formal liaison process to send this > draft to ITU, does it need to be WG draft? And encourages comments > now, before it goes to last call. > - Adrian - we can liaise the draft and our intention to consider it > as a WG draft > > Lexicography draft (Adrian) > - Q14 indicates meeting went well, authors summarized comments and > incorporated in this release. > * Adrian asked if should be WG draft > - Kireeti said we could do that, need to ask the list, also need to > compare with G.8081 > * Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC > or drafts, are there definitions? > - Adrian thinks there are good terms, though in multiple > RFCs/drafts. > - Ben - if someone is new to the IETF, they have difficulty on > where to go for definitions. > - Adrian - if people want to do a draft to collect defintions of all > GMPLS terms (more general than just ASON as in lexi draft), then > they are welcome to do it. > > Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi) > LSP Stitching (Arthi) > - Need feedback on several items. > * Adrian - it would be inappropriate to move extensions to be a WG > draft without first stitching draft becoming a wg draft. If no one > objects, see no reason why not to be WG draft. > * Dimitri - Question: the draft was to originally do signaling exts, > do we need to do more on routing aspects? > - Arthi - agree, however this comment would have applied to the > previous merged draft. The whole point of splitting the ID was > because the scope was wider and generic. In that case, it becomes > necessary to include the routing aspects as well. > * Dimitri - if allow different switching caps, then this changes the > type, and this a FA > - Arthi - but end-to-end does not change. > * Zafar - we need to be careful what advertising because of scalability > concerns, need further consideration. > - Kireeti - As Arthi said the LSP segment does not *have to* be > advertised but *can be* if desired. > - Arthi - You, of course, need to be careful about advertising > anything as TE-links dictated by correct policies. And as far as > scaling is concerned, Igor is standing right behind you and will > probably say (and I agree) that LSP segments can also be bundled > in which case you are no longer advertising each LSP segment as a > TE-link. We are simply having the same discussion again that was on > the mailing list. > * Igor - thought stitching maybe more appropriate for LSP hierarchy > draft, but as this already in editor's queue, will add here. > * Lou - sw cap can change hop by hop just needs to match end to end of > hop. > - Arthi - agree, we were thinking the same. > * Discussion sent to mailing list > > Per-domain path computation method for computing inter-domain traffic > engineering (TE) LSP. (JP) > Draft-vasseur-ccamp-inter-domain-path-comp-00.txt: > routing and path computation aspects. > * Zafar asked clarification on ccamp-pce relationship > - Kireeti - this draft discusses ASBR on the path, if not then it's > PCE, suggest add this to draft to clarify that this is for when > computation is done by elements on the path. > - JP - ok > * Adrian and Kireeti asked if this should be a WG draft? Good consensus > in the room to be WG draft, will take it to the list. > > Automesh (JP) > - Agreement to rehash work a bit to put these together. > - Now 2 drafts > - Not a new ID, no changes. > - Deployed networks using that. > - No major changes planned > * Igor - asked how to reflect constraints in a node for switching? > - JP - we are discussing auto mesh, not node switching. > - Igor - but how do we reflect node capabilities? > - JP - this draft is not about node capability discovery (for this, > see draft-vasseur-ccamp-te-node-cap) > - Igor - how to reflect for computation any internal constraints, > could do via node caps advertisement. > - JP agrees, though here just doing a discovery, doesn't think > related as discovering members of mesh. > - Adrian - two drafts, this is not node capability that is next one > by JP, cut discussion said to take it to list. > > Routing extensions for discovery of TE node capabilities (JL Le Roux) > * Adrian - on process, authors did a group job of splitting draft > and sending to OSPF and ISIS groups, chairs will follow up with > those groups. > * Dimitri - should for terminology call TE router? > - JL - yes. > - Dimitri - should the TLV be exclusive to this function? > - JL - yes. > * Igor - how to distinguish node capabilities? > - Adrian - do by TLVs, need to do a draft to propose, this draft > gives you the TLVs, then can follow-up with other drafts to > describe function want to use it for, take discussion to list. > * JL asked that this be adopted as a WG document. > - Adrian - Take it to the list > > Extensions to GMPLS RSVP graceful restart (Lou Berger) > * Adrian - do editorial respin, let us know, and we will take to > last call > * Any implementations? > - Yes - two! > > MRN > Requirements (Kohei Shiomoto) > Evaluation draft (JL Le Roux) > Protocol extensions (Dimitri) > * Arthi - what does virtual FA have to do with MRN, > isn't it general? > - Dimitri - should we have a specific doc on virtual FA for > wider scope? > - Arthi - did you want to scope only to MRN context? > - Dimitri - no, just not sure if soln doc should be split. > - Arthi - could be general - so prefer a separate doc on virtual FA. > * Zafar - we need to give a priority capability for TE. > - Dimitri - new TLV may be needed to describe relationships of > multiple interfaces > * Zafar - how relates to hierarchy draft? > - Dimitri - maybe should be as applicability statement, > - Kireeti - should do on mailing list > * Kireeti - requests to continue work, when re-charter will consider > for WG drafts. > > Routing considerations and CSPF for inter-as (Tomohiro Otani) > * JP - very useful draft. Concerned about the advertisement of DYNAMIC > summarized TE resource information across domains (static > capabilities are perfectly fine). Too much of aggregation renders > the solution inefficient and not enough of aggregation seriously > compromises the routing scalability. Furthermore, there are other > confidentiality issues to sort out in the context of inter-provider. > - Otani - ok, we need more on summarizing capability. > * Kireeti - thinks good and hopes to be a WG draft, though for now > would request for this draft to continue work, though lets finish > what ccamp has now and then when re-charter will make this as a > WG doc. > * Otani - how to handle inter-as cspf constraints? > - Kireeti - as noted before (continue work). > > L2LSP (Dimitri) > * Adrian asked clarification, is this "single hop"? > - Dimitri - multiple hops each is a LSR, will clarify this in draft > * Kireeti - ADs request a framework doc and include how it relates to > other SDOs, max 10 pages > - Dimitri - ok > > GMPLS addressing (Richard Rabbat) > * Adrian - as this is first version, recommend continue discussion, > re-spin draft, and then review again. > * Adrian asked for feedback on the topics, not the technical content > initially. > * Loa - BCP is a specific type of RFC, describes what we have > experience with not necessarily what should be (as in this draft) > * Kireeti - warns for everyone with implementations to review the > draft to ensure direction taken by this draft is right one. > * Lou - should we wait for re-spin or now? > - Kireeti - wait for re-spin. > > L1VPN (Tomonori Takeda) > Framework draft > Applicability draft > * Alex - by next IETF will decide if it should be included in ccamp or > as separate WG. > > Control plane saturation (JL Le Roux) > * Arthi - Do you think the LSRs would really want to advertise such > control plane limitations ? Secondly, what implication does this have > in case of inter-domain, especially inter-provider LSPs ? > * Kireeti - because of time, lets do on list. > > Graceful shutdown (Zafar Ali) > * Kireeti - will consider for wg doc after re-charter > * JP - is this part of current charter > - Kireeti - doesn't matter, we just can not include anymore as WG > doc until re-charter. > > Deployment-augumented (Zafar Ali) > * Arthi - This is good work. My only concern is the use of terminology. > Do you actually expect to use LSP-Hierarchy extensions (say Hop3) > while signaling an MPLS LSP over that FA in the MPLS domain ? > - Zafar - no just TE link > > GMPLS interworking (Kenji) > * Dimitri - why need to adv priority of LSP? > - Adrian - need to ask on list. > > GMPLS interworking (Kohei Shiomoto) > * Adrian - WG doc will be decided after re-charter > - Welcome that will merge with other draft on augumented, > - Suggest also look at Kenji's interworking draft to merge. > > Cho - ARP signal > * Kireeti - request work with Dimitri on framework draft, > - When decide direction and interactions with other SDO, may > decide to form a design team to work on L2, > - First we need a framework. > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Mar 2005 13:28:14 +0000 Message-ID: <04cc01c52bbd$1dec83e0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Updated minutes Date: Fri, 18 Mar 2005 12:34:37 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Here with updates from Jean-Louis, JP and Arthi. Short call for further comments before I submit. Thanks, Adrian === Common Control and Measurement Plane WG (ccamp) Tuesday, March 8, 2005 at 0900-1130 Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen Working group status - chairs - No changes to the agenda made. - Adrian reviewed status of drafts, reviewed charter milestones. We are holding off on new charter until finish last call of 8 drafts, expect 1-2 months. - Bill summarized ADs view, should wait for re-chartering until finish last call considering expectation will be very soon for last calls. * Dimitri asked about IPR assertion on re-optimization draft - Adrian said it did not give the same terms that have been seen in some recent IPR claims. The WG has to desice what to do. - Scott Bradner said we need to be very careful. Advised there may be anti-trust issues. Best to have no IETF interaction other than to ask for clarity. Scott offered to review emails on the subject. - JP said we can take that as a way to go forward and continue technical work. ASON considerations ITU liaison - Lyndon Ong presented Wesam's slides - Thanks to the IETF for liaisons and participation of Adrian and Igor at last meetings - Crankback and the comparison of LMP and ASON discovery will be incorporated in SG15 Q14's work. - There are two liaisons from ITU to CCAMP on the way. - Routing - ITU not planning any routing exts work, looking to IETF's work. - Continuing work on ASON management. - An FTP site is available for liaison statements. * Adrian asked if ITU plans to liaise G.7713 on new text for crankback before consent? - Lyndon said a meeting is upcoming and will ask for it to be considered. * Kireeti asked if there is any problem in that the crankback draft is not an RFC yet? - Adrian - RFC is desirable, not required? - Scott Bradner - it is required to have an RFC number for final balloting. The IESG can request expedited publication. * Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU terminology, and may want to consider including it. - Adrian - can that be liaisoned to us? - Steve Trowbridge - Yes, we can do that. ASON Routing Evaluation * Adrian - The design team on routing has members from both ITU and IETF, although we did not do the correct process, so ITU reps are individuals, not ITU representatives. - Adrian will work with Steve to formalize the process. * Adrian - Would like to make the draft from the team on evaluation of routing protocols into a working group draft - we will take to the list to see if any objection. * Dimitri - asked if we can use formal liaison process to send this draft to ITU, does it need to be WG draft? And encourages comments now, before it goes to last call. - Adrian - we can liaise the draft and our intention to consider it as a WG draft Lexicography draft (Adrian) - Q14 indicates meeting went well, authors summarized comments and incorporated in this release. * Adrian asked if should be WG draft - Kireeti said we could do that, need to ask the list, also need to compare with G.8081 * Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC or drafts, are there definitions? - Adrian thinks there are good terms, though in multiple RFCs/drafts. - Ben - if someone is new to the IETF, they have difficulty on where to go for definitions. - Adrian - if people want to do a draft to collect defintions of all GMPLS terms (more general than just ASON as in lexi draft), then they are welcome to do it. Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi) LSP Stitching (Arthi) - Need feedback on several items. * Adrian - it would be inappropriate to move extensions to be a WG draft without first stitching draft becoming a wg draft. If no one objects, see no reason why not to be WG draft. * Dimitri - Question: the draft was to originally do signaling exts, do we need to do more on routing aspects? - Arthi - agree, however this comment would have applied to the previous merged draft. The whole point of splitting the ID was because the scope was wider and generic. In that case, it becomes necessary to include the routing aspects as well. * Dimitri - if allow different switching caps, then this changes the type, and this a FA - Arthi - but end-to-end does not change. * Zafar - we need to be careful what advertising because of scalability concerns, need further consideration. - Kireeti - As Arthi said the LSP segment does not *have to* be advertised but *can be* if desired. - Arthi - You, of course, need to be careful about advertising anything as TE-links dictated by correct policies. And as far as scaling is concerned, Igor is standing right behind you and will probably say (and I agree) that LSP segments can also be bundled in which case you are no longer advertising each LSP segment as a TE-link. We are simply having the same discussion again that was on the mailing list. * Igor - thought stitching maybe more appropriate for LSP hierarchy draft, but as this already in editor's queue, will add here. * Lou - sw cap can change hop by hop just needs to match end to end of hop. - Arthi - agree, we were thinking the same. * Discussion sent to mailing list Per-domain path computation method for computing inter-domain traffic engineering (TE) LSP. (JP) Draft-vasseur-ccamp-inter-domain-path-comp-00.txt: routing and path computation aspects. * Zafar asked clarification on ccamp-pce relationship - Kireeti - this draft discusses ASBR on the path, if not then it's PCE, suggest add this to draft to clarify that this is for when computation is done by elements on the path. - JP - ok * Adrian and Kireeti asked if this should be a WG draft? Good consensus in the room to be WG draft, will take it to the list. Automesh (JP) - Agreement to rehash work a bit to put these together. - Now 2 drafts - Not a new ID, no changes. - Deployed networks using that. - No major changes planned * Igor - asked how to reflect constraints in a node for switching? - JP - we are discussing auto mesh, not node switching. - Igor - but how do we reflect node capabilities? - JP - this draft is not about node capability discovery (for this, see draft-vasseur-ccamp-te-node-cap) - Igor - how to reflect for computation any internal constraints, could do via node caps advertisement. - JP agrees, though here just doing a discovery, doesn't think related as discovering members of mesh. - Adrian - two drafts, this is not node capability that is next one by JP, cut discussion said to take it to list. Routing extensions for discovery of TE node capabilities (JL Le Roux) * Adrian - on process, authors did a group job of splitting draft and sending to OSPF and ISIS groups, chairs will follow up with those groups. * Dimitri - should for terminology call TE router? - JL - yes. - Dimitri - should the TLV be exclusive to this function? - JL - yes. * Igor - how to distinguish node capabilities? - Adrian - do by TLVs, need to do a draft to propose, this draft gives you the TLVs, then can follow-up with other drafts to describe function want to use it for, take discussion to list. * JL asked that this be adopted as a WG document. - Adrian - Take it to the list Extensions to GMPLS RSVP graceful restart (Lou Berger) * Adrian - do editorial respin, let us know, and we will take to last call * Any implementations? - Yes - two! MRN Requirements (Kohei Shiomoto) Evaluation draft (JL Le Roux) Protocol extensions (Dimitri) * Arthi - what does virtual FA have to do with MRN, isn't it general? - Dimitri - should we have a specific doc on virtual FA for wider scope? - Arthi - did you want to scope only to MRN context? - Dimitri - no, just not sure if soln doc should be split. - Arthi - could be general - so prefer a separate doc on virtual FA. * Zafar - we need to give a priority capability for TE. - Dimitri - new TLV may be needed to describe relationships of multiple interfaces * Zafar - how relates to hierarchy draft? - Dimitri - maybe should be as applicability statement, - Kireeti - should do on mailing list * Kireeti - requests to continue work, when re-charter will consider for WG drafts. Routing considerations and CSPF for inter-as (Tomohiro Otani) * JP - very useful draft. Concerned about the advertisement of DYNAMIC summarized TE resource information across domains (static capabilities are perfectly fine). Too much of aggregation renders the solution inefficient and not enough of aggregation seriously compromises the routing scalability. Furthermore, there are other confidentiality issues to sort out in the context of inter-provider. - Otani - ok, we need more on summarizing capability. * Kireeti - thinks good and hopes to be a WG draft, though for now would request for this draft to continue work, though lets finish what ccamp has now and then when re-charter will make this as a WG doc. * Otani - how to handle inter-as cspf constraints? - Kireeti - as noted before (continue work). L2LSP (Dimitri) * Adrian asked clarification, is this "single hop"? - Dimitri - multiple hops each is a LSR, will clarify this in draft * Kireeti - ADs request a framework doc and include how it relates to other SDOs, max 10 pages - Dimitri - ok GMPLS addressing (Richard Rabbat) * Adrian - as this is first version, recommend continue discussion, re-spin draft, and then review again. * Adrian asked for feedback on the topics, not the technical content initially. * Loa - BCP is a specific type of RFC, describes what we have experience with not necessarily what should be (as in this draft) * Kireeti - warns for everyone with implementations to review the draft to ensure direction taken by this draft is right one. * Lou - should we wait for re-spin or now? - Kireeti - wait for re-spin. L1VPN (Tomonori Takeda) Framework draft Applicability draft * Alex - by next IETF will decide if it should be included in ccamp or as separate WG. Control plane saturation (JL Le Roux) * Arthi - Do you think the LSRs would really want to advertise such control plane limitations ? Secondly, what implication does this have in case of inter-domain, especially inter-provider LSPs ? * Kireeti - because of time, lets do on list. Graceful shutdown (Zafar Ali) * Kireeti - will consider for wg doc after re-charter * JP - is this part of current charter - Kireeti - doesn't matter, we just can not include anymore as WG doc until re-charter. Deployment-augumented (Zafar Ali) * Arthi - This is good work. My only concern is the use of terminology. Do you actually expect to use LSP-Hierarchy extensions (say Hop3) while signaling an MPLS LSP over that FA in the MPLS domain ? - Zafar - no just TE link GMPLS interworking (Kenji) * Dimitri - why need to adv priority of LSP? - Adrian - need to ask on list. GMPLS interworking (Kohei Shiomoto) * Adrian - WG doc will be decided after re-charter - Welcome that will merge with other draft on augumented, - Suggest also look at Kenji's interworking draft to merge. Cho - ARP signal * Kireeti - request work with Dimitri on framework draft, - When decide direction and interactions with other SDO, may decide to form a design team to work on L2, - First we need a framework. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Mar 2005 13:28:06 +0000 Message-ID: <04c801c52bbd$13a39c70$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Re: ASON Lexicography Date: Fri, 18 Mar 2005 12:31:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Sounds like no-one against, but recognition that this is work in progress. We will submit as a WG draft. The authors are busy with a new revision. Thanks, Adrian > > Dear CCAMP, > > > > In our meeting this week we heard about > > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > > > There is some more discussion to be done on the content of > > this draft but the chairs and the meeting thought that the > > work is a very important part of CCAMP's job. > > > > Please indicate your opinion on whether this draft should be > > made a working draft document by March 20, 2005. > > > > Thanks, > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Mar 2005 09:36:32 +0000 Message-ID: <000e01c52b94$e310a440$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , Subject: Enumerations in draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Fri, 18 Mar 2005 09:29:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This MIB contains several 'enumerations' except they are not enumerations but text in DESCRIPTION clauses - gmplsTunnelGPid gmplsTunnelSwitchingType gmplsTunnelLSPEncoding - with RFC 3471 (not a MIB) as a reference. So these are not defined anywhere in SMI; and as this points out, these values will be added to in future RFC. I think these should be in a MIB under IANA control and there is already a way to do just that, namely to put them in an IANA MIB (as opposed to a standards track MIB) with the RFC specifying under what conditions the IANA MIB can be updated (standards track, IESG, expert etc). This procedure is described in draft-ietf-ops-mib-review-guidelines-04.txt which also points to previous examples of this. And this issue has already surfaced, albeit obliquely, on this list once before in the context of IANAItuProbableCause which uses this procedure and is now published as part of the Alarm MIB (RFC 3877). Not to do this now creates extra work in the future; when an implementor has to create their own SMI and whenever these values need to be updated. Tom Petch Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Mar 2005 18:00:51 +0000 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1102d0a73fb4ff283e558b6d9fe0f2ed@cisco.com> Content-Transfer-Encoding: 7bit Cc: From: JP Vasseur Subject: Re: Draft minutes Date: Thu, 17 Mar 2005 12:59:03 -0500 To: "Adrian Farrel" Hi Adrian, Few comments, On Mar 16, 2005, at 5:44 PM, Adrian Farrel wrote: > Hi, > > Please comment on the draft minutes. > > Thanks to Richard, Zafar and Tove for putting these together. > > Adrian > > ======== > > Common Control and Measurement Plane WG (ccamp) > > Tuesday, March 8, 2005 at 0900-1130 > Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen > > Working group status - chairs > - No changes to the agenda made. > - Adrian reviewed status of drafts, reviewed charter milestones. > We are holding off on new charter until finish last call of 8 > drafts, expect 1-2 months. > - Bill summarized ADs view, should wait for re-chartering until > finish last call considering expectation will be very soon for > last calls. > * Dimitri asked about IPR assertion on re-optimization draft > - Adrian said it did not give the same terms that have been seen > in some recent IPR claims. The WG has to decide what to do. > - Scott Bradner said we need to be very careful. Advised there > may be anti-trust issues. Best to have no IETF interaction > other than to ask for clarity. > Scott offered to review emails on the subject. > - JP said we can take that as a way to go forward and continue > technical work. > > ASON considerations > > ITU liaison - Lyndon Ong presented Wesam's slides > - Thanks to the IETF for liaisons and participation of Adrian and > Igor at last meetings > - Crankback and the comparison of LMP and ASON discovery will be > incorporated in SG15 Q14's work. > - There are two liaisons from ITU to CCAMP on the way. > - Routing - ITU not planning any routing exts work, looking to > IETF's work. > - Continuing work on ASON management. > - An FTP site is available for liaison statements. > * Adrian asked if ITU plans to liaise G.7713 on new text for > crankback before consent? > - Lyndon said a meeting is upcoming and will ask for it to be > considered. > * Kireeti asked if there is any problem in that the crankback draft > is not an RFC yet? > - Adrian - RFC is desirable, not required? > - Scott Bradner - it is required to have an RFC number for final > balloting. The IESG can request expedited publication. > * Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU > terminology, and may want to consider including it. > - Adrian - can that be liaised to us? > - Steve Trowbridge - Yes, we can do that. > > ASON Routing Evaluation > * Adrian - The design team on routing has members from both ITU and > IETF, although we did not do the correct process, so ITU reps are > individuals, not ITU representatives. > - Adrian will work with Steve to formalize the process. > * Adrian - Would like to make the draft from the team on evaluation > of routing protocols into a working group draft > - we will take to the list to see if any objection. > * Dimitri - asked if we can use formal liaison process to send this > draft to ITU, does it need to be WG draft? And encourages comments > now, before it goes to last call. > - Adrian - we can liaise the draft and our intention to consider it > as a WG draft > > Lexicography draft (Adrian) > - Q14 indicates meeting went well, authors summarized comments and > incorporated in this release. > * Adrian asked if should be WG draft > - Kireeti said we could do that, need to ask the list, also need to > compare with G.8081 > * Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC > or drafts, are there definitions? > - Adrian thinks there are good terms, though in multiple > RFCs/drafts. > - Ben - if someone is new to the IETF, they have difficulty on > where to go for definitions. > - Adrian - if people want to do a draft to collect definitions of all > GMPLS terms (more general than just ASON as in lexi draft), then > they are welcome to do it. > > Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi) > LSP Stitching (Arthi) > - Need feedback on several items. > * Adrian - it would be inappropriate to move extensions to be a WG > draft without first stitching draft becoming a wg draft. If no one > objects, see no reason why not to be WG draft. > * Dimitri - Question: the draft was to originally do signaling exts, > do we need to do more on routing aspects? > - Arthi - agree, if we do now as separate doc from exts draft, then > should include routing aspects. > * Dimitri - if allow different switching caps, then this changes the > type, and this a FA > - Arthi - but end-to-end does not change. > * Zafar - we need to be careful what advertising because of scalability > concerns, need further consideration. > - Arthi - yes need more discussion. > * Igor - thought stitching maybe more appropriate for LSP hierarchy > draft, but as this already in editor's queue, will add here. > * Lou - sw cap can change hop by hop just needs to match end to end of > hop. > - Arthi - agree, we were thinking the same. > * Discussion sent to mailing list > > Per-domain path computation method for computing inter-domain traffic > engineering (TE) LSP. (JP) > Draft-vasseur-ccamp-inter-domain-path-comp-00.txt: > routing and path computation aspects. > * Zafar asked clarification on ccamp-pce relationship > - Kireeti - this draft discusses ASBR on the path, if not then it's > PCE, suggest add this to draft to clarify that this is for when > computation is done by elements on the path. > - JP - ok > * Adrian and Kireeti asked if this should be a WG draft? Good consensus > in the room to be WG draft, will take it to the list. > > Automesh (JP) > - Agreement to rehash work a bit to put these together. > - Now 2 drafts > - Not a new ID, no changes. > - Deployed networks using that. > - No major changes planned > * Igor - asked how to reflect constraints in a node for switching? > - JP - we are discussing auto mesh, not node switching. > - Igor - but how do we reflect node capabilities? > - JP - this we do, we carry in OSPF a TLV to describe. Please replace by: JP - this draft is not about node capability discovery (for this, see draft-vasseur-ccamp-te-node-cap) > - Igor - how to reflect for computation any internal constraints, > could do via node caps advertisement. > - JP agrees, though here just doing a discovery, doesn't think > related as discovering members of mesh. > - Adrian - two drafts, this is not node capability that is next one > by JP, cut discussion said to take it to list. > > JP - Routing extensions for discovery of TE node capabilities > * Adrian - on process, authors did a group job of splitting draft > and sending to OSPF and ISIS groups, chairs will follow up with > those groups. > * Dimitri - should for terminology call TE router? > - JP - yes. > - Dimitri - shouldn't be exclusive the TLV? not sure of what the question was ... > - JP - yes. > * Igor - how to distinguish node capabilities? > - Adrian - do by TLVs, need to do a draft to propose, this draft > gives you the TLVs, then can follow-up with other drafts to > describe function want to use it for, take discussion to list. > * JP asked that this be adopted as a WG document. > - Adrian - Take it to the list > > Extensions to GMPLS RSVP graceful restart (Lou Berger) > * Adrian - do editorial respin, let us know, and we will take to > last call > * Any implementations? > - Yes - two! > > MRN > Requirements (Kohei Shiomoto) > Evaluation draft (JL Le Roux) > Protocol extensions (Dimitri) > * Arthi - what does virtual FA have to do with MRN, > isn't it general? > - Dimitri - should we have a specific doc on virtual FA for > wider scope? > - Arthi - did you want to scope only to MRN context? > - Dimitri - no, just not sure if soln doc should be split. > - Arthi - could be general - so prefer a separate doc on virtual FA. > * Zafar - we need to give a priority capability for TE. > - Dimitri - new TLV may be needed to describe relationships of > multiple interfaces > * Zafar - how relates to hierarchy draft? > - Dimitri - maybe should be as applicability statement, > - Kireeti - should do on mailing list > * Kireeti - requests to continue work, when re-charter will consider > for WG drafts. > > Routing considerations and CSPF for inter-as (Tomohiro Otani) > * JP - very useful draft, not sure (and concerned) on capability and > scalability as depends on constraint trying to summarize. Please replace by: JP - very useful draft, concerned about the advertisement of DYNAMIC summarized TE resource information across domains (static capabilities are perfectly fine). Too much of aggregation renders the solution inefficient and not enough of aggregation seriously compromises the routing scalability. Furthermore, there are other confidentiality issues to sort out in the context of inter-provider. > - Otani - ok, we need more on summarizing capability. > * Kireeti - thinks good and hopes to be a WG draft, though for now > would request for this draft to continue work, though lets finish > what ccamp has now and then when re-charter will make this as a > WG doc. > * Otani - how to handle inter-as cspf constraints? > - Kireeti - as noted before (continue work). > > L2LSP (Dimitri) > * Adrian asked clarification, is this "single hop"? > - Dimitri - multiple hops each is a LSR, will clarify this in draft > * Kireeti - ADs request a framework doc and include how it relates to > other SDOs, max 10 pages > - Dimitri - ok > > GMPLS addressing (Richard Rabbat) > * Adrian - as this is first version, recommend continue discussion, > re-spin draft, and then review again. > * Adrian asked for feedback on the topics, not the technical content > initially. > * Loa - BCP is a specific type of RFC, describes what we have > experience with not necessarily what should be (as in this draft) > * Kireeti - warns for everyone with implementations to review the > draft to ensure direction taken by this draft is right one. > * Lou - should we wait for re-spin or now? > - Kireeti - wait for re-spin. > > L1VPN (Tomonori Takeda) > Framework draft > Applicability draft > * Alex - by next IETF will decide if it should be included in ccamp or > as separate WG. > > Control plane saturation (JL Le Roux) > * Arthi - do we really want to advertise limitations and implications? > * Kireeti - because of time, lets do on list. > > Graceful shutdown (Zafar Ali) > * Kireeti - will consider for wg doc after re-charter > * JP - is this part of current charter > - Kireeti - doesn't matter, we just can not include anymore as WG > doc until re-charter. > > Deployment-augmented (Zafar Ali) > * Arthi- comment is this a FA for router to optical domain > - Zafar - no just TE link > > GMPLS interworking (Kenji) > * Dimitri - why need to adv priority of LSP? > - Adrian - need to ask on list. > > GMPLS interworking (Kohei Shiomoto) > * Adrian - WG doc will be decided after re-charter > - Welcome that will merge with other draft on augmented, > - Suggest also look at Kenji's interworking draft to merge. > > Cho - ARP signal > * Kireeti - request work with Dimitri on framework draft, > - When decide direction and interactions with other SDO, may > decide to form a design team to work on L2, > - First we need a framework. > Thanks. JP. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Mar 2005 17:30:41 +0000 Message-ID: <03ef01c52b16$e8513c40$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: Subject: Re: Last call review of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt Date: Thu, 17 Mar 2005 17:26:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Dimitri, > > Abstract: > > This document describes protocol specific procedures and extensions > > for Generalized Multi-Protocol Label Switching (GMPLS) Resource > > ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to > > support end-to-end Label Switched Path (LSP) recovery that denotes > > protection and restoration. > > Not sure what is meant by "denotes" in this context. > > Perhaps "is used to provide" ? > > -> was meant to say "that means..." - so any better wording ? OK... "...to support end-to-end Label Switched Path (LSP) recovery, that is protection and restoration of end-to-end LSPs." > > === > > Section 3 > > Although the second paragraph defines "end-to-end protection" I would like to see this pulled out into its own paragraph for emphasis, and also a little more clarity added to the definition. For example, it would appear that your four types of e2e protection are all have the protecting and protected LSPs disjoint in some way - this makes it appear that this is a property of e2e protection in general and you should state this if it is true. > > -> so you would like to see as part of the introduction a statement > about end-to-end protection concept - i don't think there is any > specific issue in adding this OK. Thanks. I don't need a whole essay; just a short paragraph. > > === > > Section 3 > > Note that in both > > cases, any lower priority LSP that would use the pre-reserved > > resources for the protecting LSP(s) MUST be preempted during the > > activation of the protecting LSP. > > This sentence comes out of the blue. The whole of the paragraph up to then has not even mentioned extra traffic. > > -> don't understand your comment as it is mentioned at the beginning of > the paragraph OK. It's a long paragraph with a page throw in the middle. I guess I fell asleep by the time I got to the end of the paragraph! > > === > > Section 4.2.1 > > - S (Secondary) bit: enables distinction between primary and > > secondary LSPs. A primary LSP is a fully established LSP for > > which the resource allocation has been committed at the data plane > > (i.e. full cross-connection has been performed). Both working and > > protecting LSPs can be primary LSPs. A secondary LSP is an LSP > > I am uneasy about this definition of "primary". In [TERM] the only mention of "primary" is in section 2... > > Recovery typically involves the activation of a recovery (or > > alternate) LSP when a failure is encountered in the working (or > > primary) LSP. > > -> this definition needs to be updated as - by removing primary in the > second parenthesis - it comes from a initial phase where no solution > where yet started OK. So please make sure that this happens during RFC Ed or authors 48 hours on [TERM]. > > This implies that "primary" is a synonym for "working". > > Further, RFC3471 has a subtly different meaning for "secondary" in section 7. > > Protection Information also indicates if the LSP is a primary or > > secondary LSP. A secondary LSP is a backup to a primary LSP. The > > resources of a secondary LSP are not used until the primary LSP > > fails. The resources allocated for a secondary LSP MAY be used by > > other LSPs until the primary LSP fails over to the secondary LSP. At > > that point, any LSP that is using the resources for the secondary LSP > > MUST be preempted. > > Can we please not modify the interpretation of the S-bit. > > -> this is what the draft does as also explained in > > " In this document, the PROTECTION object uses as a basis the > PROTECTION object defined in [RFC3471] and [RFC3473] and defines > additional fields within it. The fields defined in [RFC3471] and > [RFC3473] are unchanged by this memo. " > > > If you need to flag a new piece of information (to distinguish between resource allocated and not) then please introduce a new flag. > > Note that the P-bit appears to be slightly orthogonal because the text seems to describe the *current* role of the LSP. (The S-bit in RFC3471 describes the role at the time the LSP is set up, I think). > > -> note this has already been explained to you - where we came to the > conclusion for clarity to add the above mentioned paragraph Well, then I guess I find RFC3471 poorly drafted. > > === > > Section 5 > > When a failure occurs (say at node B) and is detected at end-node D, > > the receiver at D selects the normal traffic from the other LSP. > > From this perspective, 1+1 unidirectional protection can be seen as > > an uncoordinated protection switching mechanism acting independently > > at both end-points. Also, for the protected LSP under failure > > condition, the Path_State_Removed Flag of the ERROR_SPEC object (see > > [RFC3473]) SHOULD NOT be set upon PathErr message generation. > > So, what you are saying is that in 1+1 protection the network may *never* know that the error is so bad that the LSP is dead, but MUST leave that choice to the ingress. While this is the operational practice in many transport networks, I don't see why you make this as strong as a SHOULD NOT. > > -> what i mean is that this LSP in a 1+1 mode should not be released > after failure (which is the common usage of such a scheme) Agree about comon usage. Think SHOULD NOT is too strong. Would accept RECOMMENDED. > > === > > Section 5.1 > > A new PROTECTION object is included in the Path message. This object > > carries the desired end-to-end LSP Protection Type (in this case, > > "1+1 Unidirectional"). This LSP Protection Type value is applicable > > to both uni- and bi-directional LSPs. > > This is unclear. In section 14.1 you have > > 0x08 1+1 Unidirectional Protection > > 0x10 1+1 Bi-directional Protection > > -> in 5.1 "This LSP Protection Type value is applicable > to both uni- and bi-directional LSPs. " > > -> in 6.1 "This LSP Protection Type > value is only applicable to bi-directional LSPs. Ah! Very sorry. I wonder if my stupidity is also present in others. That is (of course), the protection type uni/bi is not the same as the LSP direction uni/bi. And that bi protection is meaningless for a uni LSP. Any hope of a couple of lines to avoid this confusion? > > === > > Section 6.2 > > directions. This is done using the Notify message with a new Error > > Code indicating "Working LSP Failure (Switchover Request)". The > > I don't see this in the IANA section, and I wonder if you also mean Error Value? > > -> it corresponds to the entry "Notify Error/LSP Failure" > (suggested value = 6)" error value is thus appropriate Ah. OK, then just update the text in section 6.2. > > === > > Section 7.2 > > This operation may be done using a Notify message exchange with a > > new Error Code indicating "(Working) LSP Failure (Switchover > > Request)". The Notify Ack message MUST be sent to confirm the > > reception of the Notify message. > > All of the same comments as for section 6.2. > > Also: > > - Why do you say "may be done"? > > -> "initiated" or "performed" It is the "may be" that I question. It implies there is a choice of ways to do it. Section 6.2 uses "this is done". > > === > > Section 13 (D and E) > > This, unless a fault condition exists on > > ? "This is allowed"? "This is possible"? "This is successful"? > > -> would you clarify what you mean here I am suggesting meaning (and therefore replacement text) for the phrase "This, unless a fault condition exists" > > === > > Section 14.1 > > I believe we have had this discussion before. > > We don't introduce reserved fields for future extensibility. We only do it for padding. > > If you are certain that we need to extend in the future then please use sub-objects or TLVs. > > This means that you can: > > a. Remove the last four bytes of the Protection object. > > b. Retain the C-Type from RFC3473 > > -> will add a reference to segment recovery (that does not make use of > TLVs) - see section 6.1 of SEG-REC Suppose this is OK. But, notwithstanding the fact that I am an author of SEG-REC, it appears that the additional info that is defined in SEG-REC would fit within the existing 64 bit structure. (Appologies for not reviewing that draft first.) > > === > > Section 15 > > In the case where my protecting LSP protects only one working LSP and where the full path of the protecting LSP is known by the ingress (strict and explicit) and there is no resource sharing between the protected and protecting LSP, I can't see why I must include a PPRO. > > In other words, PPRO is an enabler of function (as stated in section 15.4 "The PPRO enables of sharing recovery resources between a given secondary protecting LSP and one or more secondary protecting LSPs if their corresponding primary working LSPs have mutually (link/node/SRLG)disjoint paths."), but that does not make its presence mandatory. No comment? > > === > > Section 15.1 > > The contents of a PRIMARY_PATH_ROUTE object are a series of > > variable-length data items called subobjects. The subobjects are > > identical to those that can constitute an EXPLICIT/RECORD ROUTE > > object as defined in [RFC3209], [RFC3473] and [RFC3477]. > > This seems in contradiction with section 15.3 > > -> identical in terms of content definition 15.3 says The following subobjects are currently defined for the PRIMARY PATH ROUTE object: - Sub-Type 1: IPv4 Address (see [RFC3209]) - Sub-Type 2: IPv6 Address (see [RFC3209]) - Sub-Type 3: Label (see [RFC3473]) - Sub-Type 4: Unnumbered Interface (see [RFC3477]) but RFC3209 defines 32 Autonomous system number Hence a contradiction. If you are prepared to accept type 32 in the PPRO I suggest that you remove the list of accepted values and simply state that anything that can go in an ERO *or* an RRO is acceptable in a PPRO. > > === > > Section 17 > > Isn't Notify modified as well? > > And I thought Resv was, but I may have been sleeping. > > -> Resv needs to be added (Notify is not modified) This section describes the extensions to the PROTECTION object to broaden its applicability to end-to-end LSP recovery. In addition to modifications to the format of the PROTECTION object, we extend its use so that the object can be included in the Notify message to act a switchover request for 1+1 bi-directional and 1:1 protection. Looks like a modification to me. > > === > > Section 19 > > The IANA section needs some gardening to make it really easy for IANA to implement. > > - Only have suggested values in one place in the document > > -> ok (do think put the proposed value as part of the text and the IANA > section ease reading) Don't feel strongly. Have seen too many drafts go to RFC with mixed values or TBD still in place. > > === > > Section 19 > > Should the IANA section also cover the bits in the ADMIN STATUS object? > > -> we did not register these bits since if you think we need to register > them as part of this section just let me know Asking your opinion, really. Question is, what is the risk of losing track of Admin Status bits? Note, I keep an informal registry on the alternate CCAMP pages. Thanks for the hard work. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Mar 2005 14:38:34 +0000 Message-ID: <423995B6.7000800@psg.com> Date: Thu, 17 Mar 2005 15:35:34 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Last call review of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi adrian thanks for commenting - in-line responses to your question Adrian Farrel wrote: > Hi, > I've got a couple of comments in what seems like quite a long draft. > Adrian > > Abstract: > This document describes protocol specific procedures and extensions > for Generalized Multi-Protocol Label Switching (GMPLS) Resource > ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to > support end-to-end Label Switched Path (LSP) recovery that denotes > protection and restoration. > Not sure what is meant by "denotes" in this context. > Perhaps "is used to provide" ? -> was meant to say "that means..." - so any better wording ? > === > Section 2 > OLD > In addition, the reader is assumed to be familiar with the > terminology used in [RFC3945], [RFC3471], [RFC3473] and referenced > as well as [TERM] and [FUNCT]. > NEW > In addition, the reader is assumed to be familiar with the > terminology used in [RFC3945], [RFC3471], [RFC3473], > as well as in [TERM] and [FUNCT]. -> ok > === > Section 2 > Checklog List from revision v01.txt: > Please either remove this text or mark it so that the RFC editor will remove it. -> ok > === > Section 3 > Although the second paragraph defines "end-to-end protection" I would like to see this pulled out into its own paragraph for emphasis, and also a little more clarity added to the definition. For example, it would appear that your four types of e2e protection are all have the protecting and protected LSPs disjoint in some way - this makes it appear that this is a property of e2e protection in general and you should state this if it is true. -> so you would like to see as part of the introduction a statement about end-to-end protection concept - i don't think there is any specific issue in adding this > === > Section 3 para 5 > In 1:N (N =< 1) protection with extra-traffic, > Hopefully you mean N >= 1 -> yes > === > Section 3 para 5 > I note that you do not distinguish between 1:N and 1:N-with-extra-traffic. > If there is a reason for this perhaps you could add a note to the text. -> indeed > === > Section 3 > OLD > working one. Here, the recovery resources for the protecting LSP are > pre-reserved and explicit action is required to activate (i.e. > NEW > working one. Here, the recovery resources for the protecting LSP are > pre-reserved but explicit action is required to activate (i.e. > ^^^ -> ok > === > Section 3 > OLD > requirements by allowing multiple protecting LSPs to share common > link and node resources. The recovery resources are pre-reserved and > NEW > requirements by allowing multiple protecting LSPs to share common > link and node resources. The recovery resources are pre-reserved but > ^^^ -> ok > === > Section 3 > Note that in both > cases, any lower priority LSP that would use the pre-reserved > resources for the protecting LSP(s) MUST be preempted during the > activation of the protecting LSP. > This sentence comes out of the blue. The whole of the paragraph up to then has not even mentioned extra traffic. -> don't understand your comment as it is mentioned at the beginning of the paragraph > I suggest you insert a paragraph break and a sentence explaining how the pre-reserved resources may be used to support an extra-traffic LSP... > Also, delete "would". -> ok - this could indeed ease reading > === > Section 3 > Full LSP re-routing (or restoration) switches normal traffic to an > alternate LSP that is fully established only after working LSP > failure occurs. > This text does not read well in English. In fact, the same is true of pre-planned. What you mean is, I think, as follows... > Full LSP re-routing (or restoration) switches normal traffic to an > alternate LSP that is not even partially established until after > the working LSP failure occurs. -> indeed as none pre-provisioning actions are performed for the alternate > === > Section 3 > Note that crankback signaling (see [CRANK]) and LSP segment recovery > are further detailed in dedicated companion documents. Also, there > Need to add a citation for LSP segment recovery. -> ok > === > Section 4.2 > OLD > The recovery attributes includes all the parameters that determine > NEW > The recovery attributes include all the parameters that determine -> ok > === > Section 4.2.1 > - S (Secondary) bit: enables distinction between primary and > secondary LSPs. A primary LSP is a fully established LSP for > which the resource allocation has been committed at the data plane > (i.e. full cross-connection has been performed). Both working and > protecting LSPs can be primary LSPs. A secondary LSP is an LSP > I am uneasy about this definition of "primary". In [TERM] the only mention of "primary" is in section 2... > Recovery typically involves the activation of a recovery (or > alternate) LSP when a failure is encountered in the working (or > primary) LSP. -> this definition needs to be updated as - by removing primary in the second parenthesis - it comes from a initial phase where no solution where yet started > This implies that "primary" is a synonym for "working". > Further, RFC3471 has a subtly different meaning for "secondary" in section 7. > Protection Information also indicates if the LSP is a primary or > secondary LSP. A secondary LSP is a backup to a primary LSP. The > resources of a secondary LSP are not used until the primary LSP > fails. The resources allocated for a secondary LSP MAY be used by > other LSPs until the primary LSP fails over to the secondary LSP. At > that point, any LSP that is using the resources for the secondary LSP > MUST be preempted. > Can we please not modify the interpretation of the S-bit. -> this is what the draft does as also explained in " In this document, the PROTECTION object uses as a basis the PROTECTION object defined in [RFC3471] and [RFC3473] and defines additional fields within it. The fields defined in [RFC3471] and [RFC3473] are unchanged by this memo. " > If you need to flag a new piece of information (to distinguish between resource allocated and not) then please introduce a new flag. > Note that the P-bit appears to be slightly orthogonal because the text seems to describe the *current* role of the LSP. (The S-bit in RFC3471 describes the role at the time the LSP is set up, I think). -> note this has already been explained to you - where we came to the conclusion for clarity to add the above mentioned paragraph > === > Section 4.3 > OLD > When used for the working LSP signaling, the Association ID of the > NEW > When used for signaling the working LSP, the Association ID of the -> ok > === > Section 4.3 > OLD > When used for the protecting LSP signaling, this field identifies > NEW > When used for signaling the protecting LSP, this field identifies -> ok > === > Section 5 > When a failure occurs (say at node B) and is detected at end-node D, > the receiver at D selects the normal traffic from the other LSP. > From this perspective, 1+1 unidirectional protection can be seen as > an uncoordinated protection switching mechanism acting independently > at both end-points. Also, for the protected LSP under failure > condition, the Path_State_Removed Flag of the ERROR_SPEC object (see > [RFC3473]) SHOULD NOT be set upon PathErr message generation. > So, what you are saying is that in 1+1 protection the network may *never* know that the error is so bad that the LSP is dead, but MUST leave that choice to the ingress. While this is the operational practice in many transport networks, I don't see why you make this as strong as a SHOULD NOT. -> what i mean is that this LSP in a 1+1 mode should not be released after failure (which is the common usage of such a scheme) > === > Section 5 > Note: one should assume that both paths are SRLG disjoint otherwise, > a failure would impact both working and protecting LSPs. > What is this supposed to tell the reader? That he should make the assumption or that he should ensure SRLG diversity? ;-) > Actually, I think you want to say that the quality of 1+1 protection may vary. Allowing link diverse, node diverse or SRLG diverse 1+1 protection. > (ditto section 6 and 7) -> indeed i can phrase this in a more prescriptive way (rather than the descriptive currently proposed) > === > Section 5.1 > Since both LSPs belong to the same session, the SESSION object MUST > be the same for both LSPs. > An undisputable conclusion drawn from an unproven premise. > Why must both LSPs belong to the same session? A one line explanation would start the section off nicely. -> ok > === > Section 5.1 > A new PROTECTION object is included in the Path message. This object > What is the implication of "new"? I guess you mean the new type defined in this draft. -> yes > === > Section 5.1 > A new PROTECTION object is included in the Path message. This object > carries the desired end-to-end LSP Protection Type (in this case, > "1+1 Unidirectional"). This LSP Protection Type value is applicable > to both uni- and bi-directional LSPs. > This is unclear. In section 14.1 you have > 0x08 1+1 Unidirectional Protection > 0x10 1+1 Bi-directional Protection -> in 5.1 "This LSP Protection Type value is applicable to both uni- and bi-directional LSPs. " -> in 6.1 "This LSP Protection Type value is only applicable to bi-directional LSPs. > === > Section 5.1 > Your description of the use of the P-bit for 1+1 protection isn't clear. You mean to say that the P-bit indicates which LSP the ingress would *prefer* to be the protecting LSP if all other things are equal, but your text (and the description of the P-bit in sections 4.2.1 and 14) don't make this clear. -> ok instead of stating it is desirable i will provide a more deterministic statement > === > Section 6.2 > directions. This is done using the Notify message with a new Error > Code indicating "Working LSP Failure (Switchover Request)". The > I don't see this in the IANA section, and I wonder if you also mean Error Value? -> it corresponds to the entry "Notify Error/LSP Failure" (suggested value = 6)" error value is thus appropriate > === > Section 6.2 > directions. This is done using the Notify message with a new Error > Code indicating "Working LSP Failure (Switchover Request)". The > Notify Ack message MUST be sent to confirm the reception of the > Notify message (see [RFC3473], Section 4.3). > I see no definition of a "Notify Ack message" in RFC3473 (in any section). > I am worried that you are confusing the Ack message with a new procedure requiring a handshake of Notify messages. -> ok i will rephrase that one > === > Section 6.2 > 1. If an end-node (A or D) detects the failure of the working > LSP (or a degradation of signal quality over the working > LSP) or receives a Notify message including its SESSION > object within the (see > [RFC3473]), it MUST begin receiving on the protecting LSP > Note that the sender descriptor or flow descriptor is also present in the Notify and this will considerably help resolve ambiguities and race conditions since it identifies the LSP. -> ok i will add a statement along these lines > === > Section 6.2 > 1. If an end-node (A or D) detects the failure of the working > LSP (or a degradation of signal quality over the working > LSP) or receives a Notify message including its SESSION > object within the (see > [RFC3473]), it MUST begin receiving on the protecting LSP > I don't think the receipt of a Notify message is sufficient, per se. I think the error code and value need to indicate a problem with the LSP. -> this is explained in the next paragraph, but i will add a statement with respect to this error code/value processing " Note: in this case, the IF_ID ERROR_SPEC replaces the ERROR_SPEC in the Notify message, otherwise the corresponding (data plane) information SHOULD be received in the PathErr/ResvErr message. " > === > Section 6.2 > 1. If an end-node (A or D) detects the failure of the working > LSP (or a degradation of signal quality over the working > LSP) or receives a Notify message including its SESSION > object within the (see > [RFC3473]), it MUST begin receiving on the protecting LSP > and send a Notify message reliably to the other end-node (D > or A, respectively). > "...send a Notify message reliably" will certainly be misunderstood. > You presumably mean "...send a Notify message including the Message_ID object". -> yes > === > Section 6.2 > 2. Upon receipt of the switchover message, the end-node > (D or A, respectively) MUST begin receiving from the > protection LSP and send a (Notify) Ack message to the other > end-node (A or D, respectively) using reliable message > delivery (see [RFC2961]). > While this clarifies the use of Ack rather than Notify Ack (not sure why you need to include "(Notify)") it is now confused about the delivery of the Ack message. How do we achieve reliable delivery of an Ack message?! -> needs to be rephrased as the only to achieve reliable bi-directional exchange is by ensuring three way handshake (Notify ->, Notify + Ack <-, Ack ->) > === > Section 7 > Although the resources for the protecting LSP are pre-allocated, > preemptable traffic may be carried end-to-end using this LSP (i.e. > the protecting LSP is capable of carrying extra-traffic) with the > caveat that this traffic will be preempted if the working LSP fails. > Do you mean that the extra traffic is carried "using this LSP" or "using some or all of the resources assigned to this LSP"? -> the first "using this LSP" > === > Section 7 > Also, if extra-traffic is carried over the protecting LSP, the > corresponding end-nodes may be notified of the failure in order to > complete the switchover. > I think this is "end-nodes may need to be notified" -> ok > === > Section 7.2 > To co-ordinate the switchover between end-points, an end-to-end > switchover request is needed such that the affected LSP(s) are moved > to the protecting LSP. > In what way may there be more than one affected LSP moved to a single protecting LSP? -> if someone uses the multiplier field of the SONET/SDH TSPEC, but there is a typo in the last LSP (missed a "s") > === > Section 7.2 > This operation may be done using a Notify message exchange with a > new Error Code indicating "(Working) LSP Failure (Switchover > Request)". The Notify Ack message MUST be sent to confirm the > reception of the Notify message. > All of the same comments as for section 6.2. > Also: > - Why do you say "may be done"? -> "initiated" or "performed" > - Is this the same error code as in 6.2? (the text is slightly different) -> i will adapt error value per IANA section - the same for the error codes as part of section 6.2 > === > Section 7.3 > OLD > provisioned protecting LSP is resource-disjoint LSP from the N > NEW > provisioned protecting LSP is resource-disjoint from the N -> ok > === > Section 7.3 > Can you highlight that the N working LSPs are all between the same pair of end points. -> ok > === > Section 8 > OLD > this does not mean that the corresponding resources can not used by > NEW > this does not mean that the corresponding resources can not be used by -> ok > === > Section 8 > To make bandwidth pre-reserved for a protecting (but not activated) > LSP, available for extra traffic this bandwidth could be included in > the advertised Unreserved Bandwidth at priority lower (means > numerically higher) than the Setup Priority of the protecting LSP. > This feels like it should be the Holding Priority. That is, the Setup Priority was only important for how it could displace pre-existing LSPs. -> ok (it will clarify) - but there was an implicit statement here that both are actually equal > === > Section 8.3 > OLD > From [GMPLS-ARCH], the secondary LSP is setup with resource pre- > NEW > From [RFC3945], the secondary LSP is setup with resource pre- -> ok > === > Section 9 > OLD > plane) a specific protecting LSP instantiated during the (pre- > )provisioning phase. This requires restoration signaling along the > NEW > plane) a specific protecting LSP instantiated during the (pre-) > provisioning phase. This requires restoration signaling along the -> ok > === > Section 9 > resource sharing), the LSPs must have the same Session Ids, but the > Session Id includes the target (egress) IP address. These addresses > 2xs/Id/ID/ > Suggest a search for "id" -> will use "ID" > === > Section 9.3 > OLD > From [GMPLS-ARCH], the secondary LSP is setup with resource pre- > NEW > From [RFC3945], the secondary LSP is setup with resource pre- -> ok > === > Section 10 > OLD > activated. Additional condition raises from mis-connection avoidance > NEW > activated. An additional condition arises from mis-connection avoidance -> ok > === > Section 10 > OLD > Note that step 1 may cause alarms to be raised for the pre-empted > LSP. If alarm suppression is desired the pre-empting node MAY expand > before applying step 1 act as follows. > NEW > Note that step 1 may cause alarms to be raised for the pre-empted > LSP. If alarm suppression is desired the pre-empting node MAY insert > the following steps before step 1. -> ok > === > Section 10 > At the downstream node (with respect to the pre-empting LSP) the > processing is RECOMMENDED to be as follows: > > 1. Receive PathTear (and/or PathErr) message for the pre-empted > LSP(s). > > 2a.Release the resources associated with the LSP on the interface > to the pre-empting LSP, remove any cross-connection and release > all other resources associated with the pre-empted LSP. > 2b.Forward the PathTear (and/or PathErr) message per [RFC 3473]. > > C. Receive the Path message for the pre-empting LSP and process as > normal, forwarding it to the downstream node. > > D. Receive the Resv for the pre-empting LSP and process as normal, > forwarding it to the upstream node. > Cool numbering scheme :-) > Any chance of settling on something more conventional? -> ok - will use 1, 2a, 2b, 3, 4 > === > Section 11.2 > Note: when the end-to-end LSP Protection Type is set to > "Unprotected", both S and P bit MUST be set to 0 and the LSP SHOULD > NOT be re-routed at the head-end node after failure occurrence. The > Association_ID value MUST be set to the LSP_ID value of the signaled > LSP. > Please explain the difference between an attempt to "re-route" and an attempt to "re-establish". presumably it could involve: > - a time difference > - the use of make-before-break for failed LSPs. > - the use of the ASSOCIATION object. > I would like to make sure that you are not applying "SHOULD NOT" to LSP re-establishment. -> it means do not apply re-routing as specified in this document, i will add a paragraph around these lines > === > Section 12 > OLD > allocated to the LSP that was originally routed over it even after a > NEW > allocated to the LSP that was originally routed over them even after a -> ok > === > Section 12 > - then, apply the reverse 1-phase APS switchover request/response > (or 2-phase APS) described in Section 6.2 (or Section 7.2, > This is the first mention of APS -> see section 7.2 in this section 12 i will use the term "protection switching signaling" instead > === > Section 13 > I think this section is going to give us grief during IESG review :-( > Why do we need to tie this so closely with NMS etc. And why describe it as external? > Can't we simply describe the function by: > - dropping the first para > - in C, D and E drop "externally" > - in D and E replace "manual" with "requested" -> ok > === > Section 13 TWICE > OLD > Recovery signaling operation is initiated externally that switches > NEW > Recovery signaling is initiated externally that switches -> ok > === > Section 13 (A and B) > is set to either 0x04, or 0x08 or 0x10. > I would prefer you to use the meanings rather than the values. -> ok will add the description > === > Section 13 (D and E) > This, unless a fault condition exists on > ? "This is allowed"? "This is possible"? "This is successful"? -> would you clarify what you mean here > === > Section 14 > OLD > use so that the object can be included in the Notify message to act > a switchover request for 1+1 bi-directional and 1:1 protection. > NEW > use so that the object can be included in the Notify message to act > as a switchover request for 1+1 bi-directional and 1:1 protection. -> ok > === > Section 14.1 > I believe we have had this discussion before. > We don't introduce reserved fields for future extensibility. We only do it for padding. > If you are certain that we need to extend in the future then please use sub-objects or TLVs. > This means that you can: > a. Remove the last four bytes of the Protection object. > b. Retain the C-Type from RFC3473 -> will add a reference to segment recovery (that does not make use of TLVs) - see section 6.1 of SEG-REC > === > Section 15 > This object MUST be > present in the Path message (for the pre-provisioning of the > secondary protecting LSP) if and only if the LSP Protection Type > value is set to "0x02". > "MUST if and only if" is not really in RFC2119. > Can we two statements. One with "MUST" and one with "MUST NOT". -> ok (but i don't understand why this logical statement is not allowed) > === > Section 15 > In the case where my protecting LSP protects only one working LSP and where the full path of the protecting LSP is known by the ingress (strict and explicit) and there is no resource sharing between the protected and protecting LSP, I can't see why I must include a PPRO. > In other words, PPRO is an enabler of function (as stated in section 15.4 "The PPRO enables of sharing recovery resources between a given secondary protecting LSP and one or more secondary protecting LSPs if their corresponding primary working LSPs have mutually (link/node/SRLG)disjoint paths."), but that does not make its presence mandatory. > === > Section 15.1 > The contents of a PRIMARY_PATH_ROUTE object are a series of > variable-length data items called subobjects. The subobjects are > identical to those that can constitute an EXPLICIT/RECORD ROUTE > object as defined in [RFC3209], [RFC3473] and [RFC3477]. > This seems in contradiction with section 15.3 -> identical in terms of content definition > === > Section 15.4 > OLD > The PPRO enables of sharing recovery resources between a given > NEW > The PPRO enables sharing of recovery resources between a given -> ok > === > Section 16 > The ASSOCIATION object is used to associate LSPs with each other. In > the context of end-to-end LSP recovery, the association MUST only > identify LSPs that support the same Tunnel ID. > Hmmm. presumably same source and destination is relatively important too. -> ok i will add a statement here even if it is already part of the next sentence > === > Section 16 > The ASSOCIATION object is used to associate LSPs with each other. > You already said this. -> i will remove it > === > Section 16.1 > Association ID: 16 bits > > A value that when combined with Association Type and > Association Source uniquely identifies an association. > It would be helpful to state who assigns this value. -> it is the sender (i will add this) > === > Section 16.1 > Association Source: 4 or 16 bytes > > The IP address of the node that originated the association. > "The IP address"? > Question. Are two associations with the same Association ID equivalent if the Association Source addresses are different but identify the same node? > Answer (it transpires) is "no". > You need to make this much clearer here. -> ok i will add a statement along these lines, note this statement will be added such that relationship between values is clearer > === > Section 17 > Isn't Notify modified as well? > And I thought Resv was, but I may have been sleeping. -> Resv needs to be added (Notify is not modified) > === > Section 18 > This is a bit poor. > If you don't modify the "external commands" section, you'll certainly have to discuss security for them. After all, a forced failover can be pretty disruptive. > But I think you need to discuss misconnection here. In particular when there is mesh protection going on. -> i will include specifics inlight with the text provided in the functional specification > === > Section 19 > The IANA section needs some gardening to make it really easy for IANA to implement. > - Break it up into clearer subsections. > - Make sure you have included all of the information needed in the registry > - Point back at the defining sections of the draft > - Only have suggested values in one place in the document > - Be consistend in using TBD or TBA in the document -> ok (do think put the proposed value as part of the text and the IANA section ease reading) > === > Section 19 > Should the IANA section also cover the bits in the ADMIN STATUS object? -> we did not register these bits since if you think we need to register them as part of this section just let me know > === > Section 21 > Missing references [CRANK], [RFC2205]. Suspect you need to check them all. > Will need to add a reference for LSP segment recovery. -> ok > === > Section 21.1 > This seems a very long list of normative references. I hope you can split this so that most of the references are informational. -> ok > === > Section 22 > You might change this to "Editors' Addresses" -> ok Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Mar 2005 22:56:15 +0000 Message-ID: <037901c52a7a$d8d96630$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Wed, 16 Mar 2005 22:51:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks for the references. This fits with what I thought. Viz. Augments means that an entry in the augmenting table is created whenever an entry in the base table is created. Extends means that an entry in the extending table is created only when required. The indexing in the two cases is the same. Cheers, Adrian ----- Original Message ----- From: "Tom Petch" To: "Adrian Farrel" ; Sent: Wednesday, March 16, 2005 9:09 PM Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt > To quote from RFC2578 > " Instances of subordinate columnar > objects of a conceptual row augmentation are identified according to > the INDEX clause of the base conceptual row corresponding to the > object named in the AUGMENTS clause. Further, instances of > subordinate columnar objects of a conceptual row augmentation exist > according to the same semantics as instances of subordinate columnar > objects of the base conceptual row being augmented. As such, note > that creation of a base conceptual row implies the correspondent > creation of any conceptual row augmentations" > > exactly; or > > - AUGMENTS is an alternative to INDEX in SMIv2 > - there is a one to one correspondence between rows in the base table and rows > in the AUGMENTS table(s - can be more than one), same index columns, same index > values > - the column objects in the AUGMENTS table(s) are created when the row in the > base table is created; assuming that the agent implements those columns in the > AUGMENTS table(s) - that is a matter of conformance clauses etc. > > Reading the text, I thought these conditions were met - but I was not sure; > seeing the INDEX clauses makes me think I am not understanding the text, I am > missing something:-) > > Tom Petch > > ----- Original Message ----- > From: "Adrian Farrel" > To: "Tom Petch" ; > Sent: Wednesday, March 16, 2005 5:34 PM > Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt > > > > Hi Tom, > > > > > A minor comment; this document has > > > false (0), > > > in several places; following RFC 2579, I think this should be > > > false (2) > > > > Good catch. This is in the example which is why we didn't catch it by > > compiling. > > > > > A larger question,; this mib augments tables in the mpls mib (RFC3812); > > is there > > > a reason why the AUGMENTS construct was not used? > > > > This is not my area of expertise! > > I think that there are two strict augmentations and in these cases > > AUGMENTS was used. > > > > The other cases are, I believe, extensions. > > > > I *think* the difference is that an AUGMENT is always present and an > > extension is only present if used. > > (Feels like I'm on shaky ground!) > > > > Cheers, > > Adrian > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Mar 2005 22:56:08 +0000 Message-ID: <036b01c52a7a$5dea9ac0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft minutes Date: Wed, 16 Mar 2005 22:44:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Please comment on the draft minutes. Thanks to Richard, Zafar and Tove for putting these together. Adrian ======== Common Control and Measurement Plane WG (ccamp) Tuesday, March 8, 2005 at 0900-1130 Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen Working group status - chairs - No changes to the agenda made. - Adrian reviewed status of drafts, reviewed charter milestones. We are holding off on new charter until finish last call of 8 drafts, expect 1-2 months. - Bill summarized ADs view, should wait for re-chartering until finish last call considering expectation will be very soon for last calls. * Dimitri asked about IPR assertion on re-optimization draft - Adrian said it did not give the same terms that have been seen in some recent IPR claims. The WG has to decide what to do. - Scott Bradner said we need to be very careful. Advised there may be anti-trust issues. Best to have no IETF interaction other than to ask for clarity. Scott offered to review emails on the subject. - JP said we can take that as a way to go forward and continue technical work. ASON considerations ITU liaison - Lyndon Ong presented Wesam's slides - Thanks to the IETF for liaisons and participation of Adrian and Igor at last meetings - Crankback and the comparison of LMP and ASON discovery will be incorporated in SG15 Q14's work. - There are two liaisons from ITU to CCAMP on the way. - Routing - ITU not planning any routing exts work, looking to IETF's work. - Continuing work on ASON management. - An FTP site is available for liaison statements. * Adrian asked if ITU plans to liaise G.7713 on new text for crankback before consent? - Lyndon said a meeting is upcoming and will ask for it to be considered. * Kireeti asked if there is any problem in that the crankback draft is not an RFC yet? - Adrian - RFC is desirable, not required? - Scott Bradner - it is required to have an RFC number for final balloting. The IESG can request expedited publication. * Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU terminology, and may want to consider including it. - Adrian - can that be liaised to us? - Steve Trowbridge - Yes, we can do that. ASON Routing Evaluation * Adrian - The design team on routing has members from both ITU and IETF, although we did not do the correct process, so ITU reps are individuals, not ITU representatives. - Adrian will work with Steve to formalize the process. * Adrian - Would like to make the draft from the team on evaluation of routing protocols into a working group draft - we will take to the list to see if any objection. * Dimitri - asked if we can use formal liaison process to send this draft to ITU, does it need to be WG draft? And encourages comments now, before it goes to last call. - Adrian - we can liaise the draft and our intention to consider it as a WG draft Lexicography draft (Adrian) - Q14 indicates meeting went well, authors summarized comments and incorporated in this release. * Adrian asked if should be WG draft - Kireeti said we could do that, need to ask the list, also need to compare with G.8081 * Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC or drafts, are there definitions? - Adrian thinks there are good terms, though in multiple RFCs/drafts. - Ben - if someone is new to the IETF, they have difficulty on where to go for definitions. - Adrian - if people want to do a draft to collect definitions of all GMPLS terms (more general than just ASON as in lexi draft), then they are welcome to do it. Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi) LSP Stitching (Arthi) - Need feedback on several items. * Adrian - it would be inappropriate to move extensions to be a WG draft without first stitching draft becoming a wg draft. If no one objects, see no reason why not to be WG draft. * Dimitri - Question: the draft was to originally do signaling exts, do we need to do more on routing aspects? - Arthi - agree, if we do now as separate doc from exts draft, then should include routing aspects. * Dimitri - if allow different switching caps, then this changes the type, and this a FA - Arthi - but end-to-end does not change. * Zafar - we need to be careful what advertising because of scalability concerns, need further consideration. - Arthi - yes need more discussion. * Igor - thought stitching maybe more appropriate for LSP hierarchy draft, but as this already in editor's queue, will add here. * Lou - sw cap can change hop by hop just needs to match end to end of hop. - Arthi - agree, we were thinking the same. * Discussion sent to mailing list Per-domain path computation method for computing inter-domain traffic engineering (TE) LSP. (JP) Draft-vasseur-ccamp-inter-domain-path-comp-00.txt: routing and path computation aspects. * Zafar asked clarification on ccamp-pce relationship - Kireeti - this draft discusses ASBR on the path, if not then it's PCE, suggest add this to draft to clarify that this is for when computation is done by elements on the path. - JP - ok * Adrian and Kireeti asked if this should be a WG draft? Good consensus in the room to be WG draft, will take it to the list. Automesh (JP) - Agreement to rehash work a bit to put these together. - Now 2 drafts - Not a new ID, no changes. - Deployed networks using that. - No major changes planned * Igor - asked how to reflect constraints in a node for switching? - JP - we are discussing auto mesh, not node switching. - Igor - but how do we reflect node capabilities? - JP - this we do, we carry in OSPF a TLV to describe. - Igor - how to reflect for computation any internal constraints, could do via node caps advertisement. - JP agrees, though here just doing a discovery, doesn't think related as discovering members of mesh. - Adrian - two drafts, this is not node capability that is next one by JP, cut discussion said to take it to list. JP - Routing extensions for discovery of TE node capabilities * Adrian - on process, authors did a group job of splitting draft and sending to OSPF and ISIS groups, chairs will follow up with those groups. * Dimitri - should for terminology call TE router? - JP - yes. - Dimitri - shouldn't be exclusive the TLV? - JP - yes. * Igor - how to distinguish node capabilities? - Adrian - do by TLVs, need to do a draft to propose, this draft gives you the TLVs, then can follow-up with other drafts to describe function want to use it for, take discussion to list. * JP asked that this be adopted as a WG document. - Adrian - Take it to the list Extensions to GMPLS RSVP graceful restart (Lou Berger) * Adrian - do editorial respin, let us know, and we will take to last call * Any implementations? - Yes - two! MRN Requirements (Kohei Shiomoto) Evaluation draft (JL Le Roux) Protocol extensions (Dimitri) * Arthi - what does virtual FA have to do with MRN, isn't it general? - Dimitri - should we have a specific doc on virtual FA for wider scope? - Arthi - did you want to scope only to MRN context? - Dimitri - no, just not sure if soln doc should be split. - Arthi - could be general - so prefer a separate doc on virtual FA. * Zafar - we need to give a priority capability for TE. - Dimitri - new TLV may be needed to describe relationships of multiple interfaces * Zafar - how relates to hierarchy draft? - Dimitri - maybe should be as applicability statement, - Kireeti - should do on mailing list * Kireeti - requests to continue work, when re-charter will consider for WG drafts. Routing considerations and CSPF for inter-as (Tomohiro Otani) * JP - very useful draft, not sure (and concerned) on capability and scalability as depends on constraint trying to summarize. - Otani - ok, we need more on summarizing capability. * Kireeti - thinks good and hopes to be a WG draft, though for now would request for this draft to continue work, though lets finish what ccamp has now and then when re-charter will make this as a WG doc. * Otani - how to handle inter-as cspf constraints? - Kireeti - as noted before (continue work). L2LSP (Dimitri) * Adrian asked clarification, is this "single hop"? - Dimitri - multiple hops each is a LSR, will clarify this in draft * Kireeti - ADs request a framework doc and include how it relates to other SDOs, max 10 pages - Dimitri - ok GMPLS addressing (Richard Rabbat) * Adrian - as this is first version, recommend continue discussion, re-spin draft, and then review again. * Adrian asked for feedback on the topics, not the technical content initially. * Loa - BCP is a specific type of RFC, describes what we have experience with not necessarily what should be (as in this draft) * Kireeti - warns for everyone with implementations to review the draft to ensure direction taken by this draft is right one. * Lou - should we wait for re-spin or now? - Kireeti - wait for re-spin. L1VPN (Tomonori Takeda) Framework draft Applicability draft * Alex - by next IETF will decide if it should be included in ccamp or as separate WG. Control plane saturation (JL Le Roux) * Arthi - do we really want to advertise limitations and implications? * Kireeti - because of time, lets do on list. Graceful shutdown (Zafar Ali) * Kireeti - will consider for wg doc after re-charter * JP - is this part of current charter - Kireeti - doesn't matter, we just can not include anymore as WG doc until re-charter. Deployment-augmented (Zafar Ali) * Arthi- comment is this a FA for router to optical domain - Zafar - no just TE link GMPLS interworking (Kenji) * Dimitri - why need to adv priority of LSP? - Adrian - need to ask on list. GMPLS interworking (Kohei Shiomoto) * Adrian - WG doc will be decided after re-charter - Welcome that will merge with other draft on augmented, - Suggest also look at Kenji's interworking draft to merge. Cho - ARP signal * Kireeti - request work with Dimitri on framework draft, - When decide direction and interactions with other SDO, may decide to form a design team to work on L2, - First we need a framework. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Mar 2005 22:19:21 +0000 Message-ID: <021c01c52a6c$fb0572c0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Wed, 16 Mar 2005 22:09:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit To quote from RFC2578 " Instances of subordinate columnar objects of a conceptual row augmentation are identified according to the INDEX clause of the base conceptual row corresponding to the object named in the AUGMENTS clause. Further, instances of subordinate columnar objects of a conceptual row augmentation exist according to the same semantics as instances of subordinate columnar objects of the base conceptual row being augmented. As such, note that creation of a base conceptual row implies the correspondent creation of any conceptual row augmentations" exactly; or - AUGMENTS is an alternative to INDEX in SMIv2 - there is a one to one correspondence between rows in the base table and rows in the AUGMENTS table(s - can be more than one), same index columns, same index values - the column objects in the AUGMENTS table(s) are created when the row in the base table is created; assuming that the agent implements those columns in the AUGMENTS table(s) - that is a matter of conformance clauses etc. Reading the text, I thought these conditions were met - but I was not sure; seeing the INDEX clauses makes me think I am not understanding the text, I am missing something:-) Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: "Tom Petch" ; Sent: Wednesday, March 16, 2005 5:34 PM Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt > Hi Tom, > > > A minor comment; this document has > > false (0), > > in several places; following RFC 2579, I think this should be > > false (2) > > Good catch. This is in the example which is why we didn't catch it by > compiling. > > > A larger question,; this mib augments tables in the mpls mib (RFC3812); > is there > > a reason why the AUGMENTS construct was not used? > > This is not my area of expertise! > I think that there are two strict augmentations and in these cases > AUGMENTS was used. > > The other cases are, I believe, extensions. > > I *think* the difference is that an AUGMENT is always present and an > extension is only present if used. > (Feels like I'm on shaky ground!) > > Cheers, > Adrian > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Mar 2005 16:42:48 +0000 Message-ID: <024901c52a46$d2018740$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , Subject: Re: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Wed, 16 Mar 2005 16:34:06 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Tom, > A minor comment; this document has > false (0), > in several places; following RFC 2579, I think this should be > false (2) Good catch. This is in the example which is why we didn't catch it by compiling. > A larger question,; this mib augments tables in the mpls mib (RFC3812); is there > a reason why the AUGMENTS construct was not used? This is not my area of expertise! I think that there are two strict augmentations and in these cases AUGMENTS was used. The other cases are, I believe, extensions. I *think* the difference is that an AUGMENT is always present and an extension is only present if used. (Feels like I'm on shaky ground!) Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Mar 2005 12:33:19 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52A23.B41368C0" Subject: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt. Date: Wed, 16 Mar 2005 12:28:48 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8046217D5@baker.datcon.co.uk> Thread-Topic: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt. Thread-Index: AcUqI7dv+wfsAdkETi+h/pzAGwMY7Q== From: "Philip Crocker" To: Cc: , , This is a multi-part message in MIME format. ------_=_NextPart_001_01C52A23.B41368C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have some comments / questions on = draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt. 1) Section 3. If out-of-band verification is in use, and the passive = LMP node receives an out-of-band test message with a trace pattern that = does not correlate to any trace pattern of any data link configured on = the node, the draft does not specify what should happen and it seems to = me that there are two possibilities. a) The passive node sends a TestStatusFailure message back to the = active node to fail verification. b) The passive node discards the received test message. The active = node will continue to retransmit the test message. Either a subsequent = test message leads to a successful verification, or the passive node = eventually times out the verification process of this data link. Note that this is a new situation occurring only in the out-of-band = verification procedure, and therefore I believe should be addressed in = the draft (in the standard link verification procedure an incoming = in-band test message can always, necessarily, be correlated to the data = link it was received on). =20 In my opinion, if it is possible for a trace pattern used on a data link = to be changed and for the change not to be noticed immediately by the = passive node, then it is more robust if the test message is = retransmitted as in b) above allowing multiple opportunities for the = verification to succeed. =20 However, for other implementations this possibility may not exist and so = option a) would be preferable. My preference is therefore for this to = be left as an implementation decision, but for the draft to mention that = both options are equally valid. Would anyone care to comment on this? 2) Section 4.1.9 (InsertTrace Message) specifies that the use of this = message 'assumes that the remote [node] knows the mapping between the = local and remote interface_Ids before fulfilling such [a] request'. = Isn't this same assumption also true for the TraceMonitor and TraceReq = messages defined in sections 4.1.1 and 4.1.6 respectively? If so, I = suggest copying the text above from section 4.1.9 to the introductory = paragraphs of sections 4.1.1 and 4.1.6 also. 3) Section 4. Is there a good reason why both the TraceMonitor and = TraceReq (and associated) messages are required? It seems to me that = the function of a TraceMonitor message can be replicated by using a = TraceReq message, then comparing the observed trace pattern to the = expected pattern. I realize that the TraceMismatch message is allowed = to contain information about multiple mismatches at once, and a similar = function is not available in the TraceReport message, but is this the = only functional difference between the two sets of messages? Thanks, Phil ------_=_NextPart_001_01C52A23.B41368C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.

Hi all,

I have some comments / questions on = draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.

1)  Section 3.  If = out-of-band verification is in use, and the passive LMP node receives an = out-of-band test message with a trace pattern that does not correlate to = any trace pattern of any data link configured on the node, the draft = does not specify what should happen and it seems to me that there are = two possibilities.

    a) The passive node sends a = TestStatusFailure message back to the active node to fail = verification.

    b) The passive node discards the = received test message.  The active node will continue to retransmit = the test message.  Either a subsequent test message leads to a = successful verification, or the passive node eventually times out the = verification process of this data link.

Note that this is a new situation = occurring only in the out-of-band verification procedure, and therefore = I believe should be addressed in the draft (in the standard link = verification procedure an incoming in-band test message can always, = necessarily, be correlated to the data link it was received on).  =

In my opinion, if it is possible for a = trace pattern used on a data link to be changed and for the change not = to be noticed immediately by the passive node, then it is more robust if = the test message is retransmitted as in b) above allowing multiple = opportunities for the verification to succeed. 

However, for other implementations this = possibility may not exist and so option a) would be preferable.  My = preference is therefore for this to be left as an implementation = decision, but for the draft to mention that both options are equally = valid.  Would anyone care to comment on this?

2)  Section 4.1.9 (InsertTrace = Message) specifies that the use of this message 'assumes that the remote = [node] knows the mapping between the local and remote interface_Ids = before fulfilling such [a] request'.  Isn't this same assumption = also true for the TraceMonitor and TraceReq messages defined in sections = 4.1.1 and 4.1.6 respectively?  If so, I suggest copying the text = above from section 4.1.9 to the introductory paragraphs of sections = 4.1.1 and 4.1.6 also.

3)  Section 4.  Is there a = good reason why both the TraceMonitor and TraceReq (and associated) = messages are required?  It seems to me that the function of a = TraceMonitor message can be replicated by using a TraceReq message, then = comparing the observed trace pattern to the expected pattern.  I = realize that the TraceMismatch message is allowed to contain information = about multiple mismatches at once, and a similar function is not = available in the TraceReport message, but is this the only functional = difference between the two sets of messages?

Thanks,

Phil

------_=_NextPart_001_01C52A23.B41368C0-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Mar 2005 00:46:28 +0000 Message-ID: <01f501c529c0$198d56c0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Last call review of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt Date: Wed, 16 Mar 2005 00:30:42 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E5_01C529BF.63405520" This is a multi-part message in MIME format. ------=_NextPart_000_01E5_01C529BF.63405520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I've got a couple of comments in what seems like quite a long draft. Adrian Abstract: This document describes protocol specific procedures and extensions=20 for Generalized Multi-Protocol Label Switching (GMPLS) Resource=20 ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to=20 support end-to-end Label Switched Path (LSP) recovery that denotes=20 protection and restoration. Not sure what is meant by "denotes" in this context. Perhaps "is used to provide" ? =3D=3D=3D Section 2 OLD In addition, the reader is assumed to be familiar with the=20 terminology used in [RFC3945], [RFC3471], [RFC3473] and referenced=20 as well as [TERM] and [FUNCT].=20 NEW In addition, the reader is assumed to be familiar with the=20 terminology used in [RFC3945], [RFC3471], [RFC3473], as well as in [TERM] and [FUNCT].=20 =3D=3D=3D Section 2 Checklog List from revision v01.txt: =20 Please either remove this text or mark it so that the RFC editor will = remove it. =3D=3D=3D Section 3 Although the second paragraph defines "end-to-end protection" I would = like to see this pulled out into its own paragraph for emphasis, and = also a little more clarity added to the definition. For example, it = would appear that your four types of e2e protection are all have the = protecting and protected LSPs disjoint in some way - this makes it = appear that this is a property of e2e protection in general and you = should state this if it is true. =3D=3D=3D Section 3 para 5 In 1:N (N =3D< 1) protection with extra-traffic, Hopefully you mean N >=3D 1 =20 =3D=3D=3D Section 3 para 5 I note that you do not distinguish between 1:N and = 1:N-with-extra-traffic. If there is a reason for this perhaps you could add a note to the text. =3D=3D=3D Section 3 OLD working one. Here, the recovery resources for the protecting LSP are=20 pre-reserved and explicit action is required to activate (i.e.=20 NEW working one. Here, the recovery resources for the protecting LSP are=20 pre-reserved but explicit action is required to activate (i.e.=20 ^^^ =3D=3D=3D Section 3 OLD requirements by allowing multiple protecting LSPs to share common=20 link and node resources. The recovery resources are pre-reserved and=20 NEW requirements by allowing multiple protecting LSPs to share common=20 link and node resources. The recovery resources are pre-reserved but ^^^=20 =3D=3D=3D Section 3 Note that in both=20 cases, any lower priority LSP that would use the pre-reserved=20 resources for the protecting LSP(s) MUST be preempted during the=20 activation of the protecting LSP.=20 This sentence comes out of the blue. The whole of the paragraph up to = then has not even mentioned extra traffic. I suggest you insert a = paragraph break and a sentence explaining how the pre-reserved resources = may be used to support an extra-traffic LSP... Also, delete "would". =3D=3D=3D Section 3 Full LSP re-routing (or restoration) switches normal traffic to an=20 alternate LSP that is fully established only after working LSP=20 failure occurs. This text does not read well in English. In fact, the same is true of = pre-planned. What you mean is, I think, as follows... Full LSP re-routing (or restoration) switches normal traffic to an=20 alternate LSP that is not even partially established until after=20 the working LSP failure occurs.=20 =3D=3D=3D Section 3 Note that crankback signaling (see [CRANK]) and LSP segment recovery=20 are further detailed in dedicated companion documents. Also, there=20 Need to add a citation for LSP segment recovery. =3D=3D=3D Section 4.2 OLD The recovery attributes includes all the parameters that determine=20 NEW The recovery attributes include all the parameters that determine=20 =3D=3D=3D Section 4.2.1 - S (Secondary) bit: enables distinction between primary and =20 secondary LSPs. A primary LSP is a fully established LSP for =20 which the resource allocation has been committed at the data plane = (i.e. full cross-connection has been performed). Both working and =20 protecting LSPs can be primary LSPs. A secondary LSP is an LSP =20 I am uneasy about this definition of "primary". In [TERM] the only = mention of "primary" is in section 2... Recovery typically involves the activation of a recovery (or alternate) LSP when a failure is encountered in the working (or primary) LSP. This implies that "primary" is a synonym for "working". Further, RFC3471 has a subtly different meaning for "secondary" in = section 7. Protection Information also indicates if the LSP is a primary or secondary LSP. A secondary LSP is a backup to a primary LSP. The resources of a secondary LSP are not used until the primary LSP fails. The resources allocated for a secondary LSP MAY be used by other LSPs until the primary LSP fails over to the secondary LSP. At that point, any LSP that is using the resources for the secondary LSP MUST be preempted. Can we please not modify the interpretation of the S-bit. If you need to flag a new piece of information (to distinguish between = resource allocated and not) then please introduce a new flag. Note that the P-bit appears to be slightly orthogonal because the text = seems to describe the *current* role of the LSP. (The S-bit in RFC3471 = describes the role at the time the LSP is set up, I think). =3D=3D=3D Section 4.3 OLD When used for the working LSP signaling, the Association ID of the=20 NEW When used for signaling the working LSP, the Association ID of the=20 =3D=3D=3D Section 4.3 OLD When used for the protecting LSP signaling, this field identifies=20 NEW When used for signaling the protecting LSP, this field identifies=20 =3D=3D=3D Section 5 When a failure occurs (say at node B) and is detected at end-node D,=20 the receiver at D selects the normal traffic from the other LSP.=20 From this perspective, 1+1 unidirectional protection can be seen as=20 an uncoordinated protection switching mechanism acting independently=20 at both end-points. Also, for the protected LSP under failure=20 condition, the Path_State_Removed Flag of the ERROR_SPEC object (see=20 [RFC3473]) SHOULD NOT be set upon PathErr message generation.=20 So, what you are saying is that in 1+1 protection the network may = *never* know that the error is so bad that the LSP is dead, but MUST = leave that choice to the ingress. While this is the operational practice = in many transport networks, I don't see why you make this as strong as a = SHOULD NOT. =3D=3D=3D Section 5 Note: one should assume that both paths are SRLG disjoint otherwise,=20 a failure would impact both working and protecting LSPs.=20 What is this supposed to tell the reader? That he should make the = assumption or that he should ensure SRLG diversity? ;-) Actually, I think you want to say that the quality of 1+1 protection may = vary. Allowing link diverse, node diverse or SRLG diverse 1+1 = protection. (ditto section 6 and 7) =3D=3D=3D Section 5.1 Since both LSPs belong to the same session, the SESSION object MUST=20 be the same for both LSPs.=20 An undisputable conclusion drawn from an unproven premise. Why must both LSPs belong to the same session? A one line explanation = would start the section off nicely. =3D=3D=3D Section 5.1 A new PROTECTION object is included in the Path message. This object=20 What is the implication of "new"? I guess you mean the new type defined = in this draft. =3D=3D=3D Section 5.1 A new PROTECTION object is included in the Path message. This object=20 carries the desired end-to-end LSP Protection Type (in this case,=20 "1+1 Unidirectional"). This LSP Protection Type value is applicable=20 to both uni- and bi-directional LSPs.=20 This is unclear. In section 14.1 you have=20 0x08 1+1 Unidirectional Protection =20 0x10 1+1 Bi-directional Protection=20 =3D=3D=3D Section 5.1 Your description of the use of the P-bit for 1+1 protection isn't clear. = You mean to say that the P-bit indicates which LSP the ingress would = *prefer* to be the protecting LSP if all other things are equal, but = your text (and the description of the P-bit in sections 4.2.1 and 14) = don't make this clear. =3D=3D=3D Section 6.2 directions. This is done using the Notify message with a new Error=20 Code indicating "Working LSP Failure (Switchover Request)". The=20 I don't see this in the IANA section, and I wonder if you also mean = Error Value? =3D=3D=3D Section 6.2 directions. This is done using the Notify message with a new Error=20 Code indicating "Working LSP Failure (Switchover Request)". The=20 Notify Ack message MUST be sent to confirm the reception of the=20 Notify message (see [RFC3473], Section 4.3). =20 I see no definition of a "Notify Ack message" in RFC3473 (in any = section). I am worried that you are confusing the Ack message with a new procedure = requiring a handshake of Notify messages. =3D=3D=3D Section 6.2 1. If an end-node (A or D) detects the failure of the working =20 LSP (or a degradation of signal quality over the working =20 LSP) or receives a Notify message including its SESSION =20 object within the (see =20 [RFC3473]), it MUST begin receiving on the protecting LSP =20 Note that the sender descriptor or flow descriptor is also present in = the Notify and this will considerably help resolve ambiguities and race = conditions since it identifies the LSP. =3D=3D=3D Section 6.2 1. If an end-node (A or D) detects the failure of the working =20 LSP (or a degradation of signal quality over the working =20 LSP) or receives a Notify message including its SESSION =20 object within the (see =20 [RFC3473]), it MUST begin receiving on the protecting LSP =20 I don't think the receipt of a Notify message is sufficient, per se. I = think the error code and value need to indicate a problem with the LSP. =3D=3D=3D Section 6.2 1. If an end-node (A or D) detects the failure of the working =20 LSP (or a degradation of signal quality over the working =20 LSP) or receives a Notify message including its SESSION =20 object within the (see =20 [RFC3473]), it MUST begin receiving on the protecting LSP =20 and send a Notify message reliably to the other end-node (D =20 or A, respectively). "...send a Notify message reliably" will certainly be misunderstood. You presumably mean "...send a Notify message including the Message_ID = object". =3D=3D=3D Section 6.2 2. Upon receipt of the switchover message, the end-node =20 (D or A, respectively) MUST begin receiving from the =20 protection LSP and send a (Notify) Ack message to the other =20 end-node (A or D, respectively) using reliable message =20 delivery (see [RFC2961]).=20 While this clarifies the use of Ack rather than Notify Ack (not sure why = you need to include "(Notify)") it is now confused about the delivery of = the Ack message. How do we achieve reliable delivery of an Ack message?! =3D=3D=3D Section 7 Although the resources for the protecting LSP are pre-allocated,=20 preemptable traffic may be carried end-to-end using this LSP (i.e.=20 the protecting LSP is capable of carrying extra-traffic) with the=20 caveat that this traffic will be preempted if the working LSP fails.=20 Do you mean that the extra traffic is carried "using this LSP" or "using = some or all of the resources assigned to this LSP"? =3D=3D=3D Section 7 Also, if extra-traffic is carried over the protecting LSP, the=20 corresponding end-nodes may be notified of the failure in order to=20 complete the switchover. =20 I think this is "end-nodes may need to be notified" =3D=3D=3D Section 7.2 To co-ordinate the switchover between end-points, an end-to-end=20 switchover request is needed such that the affected LSP(s) are moved=20 to the protecting LSP. In what way may there be more than one affected LSP moved to a single = protecting LSP? =3D=3D=3D Section 7.2 This operation may be done using a Notify message exchange with a=20 new Error Code indicating "(Working) LSP Failure (Switchover=20 Request)". The Notify Ack message MUST be sent to confirm the=20 reception of the Notify message. =20 All of the same comments as for section 6.2. Also: - Why do you say "may be done"? - Is this the same error code as in 6.2? (the text is slightly = different) =3D=3D=3D=20 Section 7.3 OLD provisioned protecting LSP is resource-disjoint LSP from the N=20 NEW provisioned protecting LSP is resource-disjoint from the N=20 =3D=3D=3D Section 7.3 Can you highlight that the N working LSPs are all between the same pair = of end points. =3D=3D=3D Section 8 OLD this does not mean that the corresponding resources can not used by=20 NEW this does not mean that the corresponding resources can not be used = by=20 =3D=3D=3D Section 8 To make bandwidth pre-reserved for a protecting (but not activated)=20 LSP, available for extra traffic this bandwidth could be included in=20 the advertised Unreserved Bandwidth at priority lower (means=20 numerically higher) than the Setup Priority of the protecting LSP.=20 This feels like it should be the Holding Priority. That is, the Setup = Priority was only important for how it could displace pre-existing LSPs. =3D=3D=3D Section 8.3 OLD From [GMPLS-ARCH], the secondary LSP is setup with resource pre- NEW From [RFC3945], the secondary LSP is setup with resource pre- =3D=3D=3D Section 9 OLD plane) a specific protecting LSP instantiated during the (pre- )provisioning phase. This requires restoration signaling along the=20 NEW plane) a specific protecting LSP instantiated during the (pre-) provisioning phase. This requires restoration signaling along the=20 =3D=3D=3D Section 9 resource sharing), the LSPs must have the same Session Ids, but the=20 Session Id includes the target (egress) IP address. These addresses=20 2xs/Id/ID/ Suggest a search for "id" =3D=3D=3D Section 9.3 OLD From [GMPLS-ARCH], the secondary LSP is setup with resource pre- NEW From [RFC3945], the secondary LSP is setup with resource pre- =3D=3D=3D Section 10 OLD activated. Additional condition raises from mis-connection avoidance=20 NEW activated. An additional condition arises from mis-connection = avoidance=20 =3D=3D=3D Section 10 OLD Note that step 1 may cause alarms to be raised for the pre-empted=20 LSP. If alarm suppression is desired the pre-empting node MAY expand=20 before applying step 1 act as follows.=20 NEW Note that step 1 may cause alarms to be raised for the pre-empted=20 LSP. If alarm suppression is desired the pre-empting node MAY insert the following steps before step 1.=20 =3D=3D=3D Section 10 At the downstream node (with respect to the pre-empting LSP) the=20 processing is RECOMMENDED to be as follows:=20 =20 1. Receive PathTear (and/or PathErr) message for the pre-empted =20 LSP(s).=20 =20 2a.Release the resources associated with the LSP on the interface=20 to the pre-empting LSP, remove any cross-connection and release =20 all other resources associated with the pre-empted LSP.=20 2b.Forward the PathTear (and/or PathErr) message per [RFC 3473].=20 =20 C. Receive the Path message for the pre-empting LSP and process as =20 normal, forwarding it to the downstream node.=20 =20 D. Receive the Resv for the pre-empting LSP and process as normal,=20 forwarding it to the upstream node.=20 Cool numbering scheme :-) Any chance of settling on something more conventional? =3D=3D=3D Section 11.2 Note: when the end-to-end LSP Protection Type is set to=20 "Unprotected", both S and P bit MUST be set to 0 and the LSP SHOULD=20 NOT be re-routed at the head-end node after failure occurrence. The=20 Association_ID value MUST be set to the LSP_ID value of the signaled=20 LSP.=20 Please explain the difference between an attempt to "re-route" and an = attempt to "re-establish". presumably it could involve: - a time difference - the use of make-before-break for failed LSPs. - the use of the ASSOCIATION object. I would like to make sure that you are not applying "SHOULD NOT" to LSP = re-establishment. =3D=3D=3D Section 12 OLD allocated to the LSP that was originally routed over it even after a=20 NEW allocated to the LSP that was originally routed over them even after = a=20 =3D=3D=3D Section 12 - then, apply the reverse 1-phase APS switchover request/response =20 (or 2-phase APS) described in Section 6.2 (or Section 7.2, =20 This is the first mention of APS =3D=3D=3D Section 13 I think this section is going to give us grief during IESG review :-( Why do we need to tie this so closely with NMS etc. And why describe it = as external? Can't we simply describe the function by: - dropping the first para - in C, D and E drop "externally" - in D and E replace "manual" with "requested" =3D=3D=3D Section 13 TWICE OLD Recovery signaling operation is initiated externally that switches=20 NEW Recovery signaling is initiated externally that switches=20 =3D=3D=3D Section 13 (A and B) is set to either 0x04, or 0x08 or 0x10.=20 I would prefer you to use the meanings rather than the values. =3D=3D=3D Section 13 (D and E) This, unless a fault condition exists on=20 ? "This is allowed"? "This is possible"? "This is successful"? =3D=3D=3D Section 14 OLD use so that the object can be included in the Notify message to act=20 a switchover request for 1+1 bi-directional and 1:1 protection. =20 NEW use so that the object can be included in the Notify message to act=20 as a switchover request for 1+1 bi-directional and 1:1 protection. =20 =3D=3D=3D Section 14.1 I believe we have had this discussion before. We don't introduce reserved fields for future extensibility. We only do = it for padding. If you are certain that we need to extend in the future then please use = sub-objects or TLVs. This means that you can: a. Remove the last four bytes of the Protection object. b. Retain the C-Type from RFC3473 =3D=3D=3D Section 15 This object MUST be=20 present in the Path message (for the pre-provisioning of the=20 secondary protecting LSP) if and only if the LSP Protection Type=20 value is set to "0x02". "MUST if and only if" is not really in RFC2119. Can we two statements. One with "MUST" and one with "MUST NOT". =3D=3D=3D Section 15 In the case where my protecting LSP protects only one working LSP and = where the full path of the protecting LSP is known by the ingress = (strict and explicit) and there is no resource sharing between the = protected and protecting LSP, I can't see why I must include a PPRO. In other words, PPRO is an enabler of function (as stated in section = 15.4 "The PPRO enables of sharing recovery resources between a given = secondary protecting LSP and one or more secondary protecting LSPs if = their corresponding primary working LSPs have mutually = (link/node/SRLG)disjoint paths."), but that does not make its presence = mandatory. =3D=3D=3D Section 15.1 The contents of a PRIMARY_PATH_ROUTE object are a series of=20 variable-length data items called subobjects. The subobjects are=20 identical to those that can constitute an EXPLICIT/RECORD ROUTE=20 object as defined in [RFC3209], [RFC3473] and [RFC3477].=20 This seems in contradiction with section 15.3 =3D=3D=3D Section 15.4 OLD The PPRO enables of sharing recovery resources between a given=20 NEW The PPRO enables sharing of recovery resources between a given=20 =3D=3D=3D Section 16 The ASSOCIATION object is used to associate LSPs with each other. In=20 the context of end-to-end LSP recovery, the association MUST only=20 identify LSPs that support the same Tunnel ID. Hmmm. presumably same source and destination is relatively important = too. =3D=3D=3D Section 16 The ASSOCIATION object is used to associate LSPs with each other. =20 You already said this. =3D=3D=3D Section 16.1 Association ID: 16 bits=20 =20 A value that when combined with Association Type and =20 Association Source uniquely identifies an association. =20 It would be helpful to state who assigns this value. =3D=3D=3D Section 16.1 Association Source: 4 or 16 bytes=20 =20 The IP address of the node that originated the association.=20 "The IP address"? Question. Are two associations with the same Association ID equivalent = if the Association Source addresses are different but identify the same = node? Answer (it transpires) is "no".=20 You need to make this much clearer here. =3D=3D=3D Section 17 Isn't Notify modified as well? And I thought Resv was, but I may have been sleeping. =3D=3D=3D Section 18 This is a bit poor. If you don't modify the "external commands" section, you'll certainly = have to discuss security for them. After all, a forced failover can be = pretty disruptive. But I think you need to discuss misconnection here. In particular when = there is mesh protection going on. =3D=3D=3D Section 19 The IANA section needs some gardening to make it really easy for IANA to = implement. - Break it up into clearer subsections. - Make sure you have included all of the information needed in the = registry - Point back at the defining sections of the draft - Only have suggested values in one place in the document - Be consistend in using TBD or TBA in the document =3D=3D=3D Section 19 Should the IANA section also cover the bits in the ADMIN STATUS object? =3D=3D=3D Section 21 Missing references [CRANK], [RFC2205]. Suspect you need to check them = all. Will need to add a reference for LSP segment recovery. =3D=3D=3D Section 21.1 This seems a very long list of normative references. I hope you can = split this so that most of the references are informational. =3D=3D=3D Section 22 You might change this to "Editors' Addresses" ------=_NextPart_000_01E5_01C529BF.63405520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I've got a couple of comments in what = seems like=20 quite a long draft.
Adrian
 
Abstract:
   This document describes = protocol=20 specific procedures and extensions
   for Generalized=20 Multi-Protocol Label Switching (GMPLS) Resource
   = ReserVation=20 Protocol - Traffic Engineering (RSVP-TE) signaling to
   = support=20 end-to-end Label Switched Path (LSP) recovery that denotes =
  =20 protection and restoration.
Not sure what is meant by "denotes" = in this=20 context.
Perhaps "is used to provide" = ?
=3D=3D=3D
Section 2
OLD
   In addition, the reader = is assumed=20 to be familiar with the
   terminology used in [RFC3945],=20 [RFC3471], [RFC3473] and referenced
   as well as [TERM] = and=20 [FUNCT].
NEW
   In addition, the reader = is assumed=20 to be familiar with the
   terminology used in [RFC3945],=20 [RFC3471], [RFC3473],
   as well as in [TERM] and = [FUNCT].=20
=3D=3D=3D
Section 2
   Checklog List from = revision=20 v01.txt: 
Please either remove this text or = mark it so that=20 the RFC editor will remove it.
=3D=3D=3D
Section 3
Although the second paragraph defines = "end-to-end=20 protection" I would like to see this pulled out into its own paragraph = for=20 emphasis, and also a little more clarity added to the definition. For = example,=20 it would appear that your four types of e2e protection are all have the=20 protecting and protected LSPs disjoint in some way - this makes it = appear that=20 this is a property of e2e protection in general and you should state = this if it=20 is true.
=3D=3D=3D
Section 3 para 5
   In 1:N (N =3D< 1) = protection with=20 extra-traffic,
Hopefully you mean N >=3D 1  =
=3D=3D=3D
Section 3 para 5
I note that you do not distinguish = between 1:N=20 and 1:N-with-extra-traffic.
If there is a reason for this perhaps = you could=20 add a note to the text.
=3D=3D=3D
Section 3
OLD
   working one. Here, the = recovery=20 resources for the protecting LSP are
   pre-reserved and = explicit=20 action is required to activate (i.e.
NEW
   working one. Here, the = recovery=20 resources for the protecting LSP are
   pre-reserved but = explicit=20 action is required to activate=20 (i.e. 
         &nbs= p;     =20 ^^^
=3D=3D=3D
Section 3
OLD
   requirements by allowing multiple protecting LSPs to = share=20 common
   link and node resources. The recovery resources = are=20 pre-reserved and
NEW
   requirements by allowing multiple protecting LSPs to = share=20 common
   link and node resources. The recovery resources = are=20 pre-reserved=20 but
           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;        ^^^=20
=3D=3D=3D
Section 3
   Note that in both=20
   cases, any lower priority LSP that would use the = pre-reserved=20
   resources for the protecting LSP(s) MUST be preempted = during=20 the
   activation of the protecting LSP.
This sentence = comes=20 out of the blue. The whole of the paragraph up to then has not even = mentioned=20 extra traffic. I suggest you insert a paragraph break and a sentence = explaining=20 how the pre-reserved resources may be used to support an extra-traffic=20 LSP...
Also, delete "would".
=3D=3D=3D
Section 3
   Full LSP re-routing (or = restoration)=20 switches normal traffic to an
   alternate LSP that is = fully=20 established only after working LSP
   failure = occurs.
This text does not read well in = English. In fact,=20 the same is true of pre-planned. What you mean is, I think, as=20 follows...
   Full LSP re-routing (or = restoration)=20 switches normal traffic to an
   alternate LSP that is not = even=20 partially established until after
   the working = LSP failure occurs.=20
=3D=3D=3D
Section 3
   Note that crankback = signaling (see=20 [CRANK]) and LSP segment recovery
   are further detailed = in=20 dedicated companion documents. Also, there
Need to add a citation = for LSP=20 segment recovery.
=3D=3D=3D
Section=20 4.2
OLD
   The=20 recovery attributes includes all the parameters that=20 determine 
NEW
   The recovery = attributes=20 include all the parameters that determine
=3D=3D=3D
Section 4.2.1
   - S (Secondary) bit: = enables=20 distinction between primary and 
     = secondary=20 LSPs. A primary LSP is a fully established LSP for =20
     which the resource allocation has been = committed at=20 the data plane 
     (i.e. full = cross-connection=20 has been performed). Both working and 
     = protecting LSPs can be primary LSPs. A secondary LSP is an LSP  =
I am=20 uneasy about this definition of "primary". In [TERM] the only mention of = "primary" is in section 2...
   Recovery typically = involves the=20 activation of a recovery (or
   alternate) LSP when a = failure is=20 encountered in the working (or
   primary) = LSP.
This implies that "primary" is a = synonym for=20 "working".
Further, RFC3471 has a subtly = different meaning=20 for "secondary" in section 7.
   Protection Information = also=20 indicates if the LSP is a primary or
   secondary = LSP.  A=20 secondary LSP is a backup to a primary LSP.  The
   = resources=20 of a secondary LSP are not used until the primary LSP
   fails.  The = resources allocated=20 for a secondary LSP MAY be used by
   other LSPs until the = primary=20 LSP fails over to the secondary LSP.  At
   that = point, any=20 LSP that is using the resources for the secondary LSP
   = MUST be=20 preempted.
Can we please not modify the interpretation of the=20 S-bit.
If you need to flag a new piece of = information=20 (to distinguish between resource allocated and not) then please = introduce a new=20 flag.
Note that the P-bit appears to=20 be slightly orthogonal because the text seems to describe = the=20 *current* role of the LSP. (The S-bit in RFC3471 describes the role at = the time=20 the LSP is set up, I think).
=3D=3D=3D
Section 4.3
OLD
   When used for the = working LSP=20 signaling, the Association ID of the
NEW
   When used for signaling = the working=20 LSP, the Association ID of the
=3D=3D=3D
Section 4.3
OLD
   When used for the = protecting LSP=20 signaling, this field identifies
NEW
   When used for signaling = the=20 protecting LSP, this field identifies
=3D=3D=3D
Section 5
   When a failure occurs = (say at node=20 B) and is detected at end-node D,
   the receiver at D = selects the=20 normal traffic from the other LSP.
   From this = perspective, 1+1=20 unidirectional protection can be seen as
   an = uncoordinated=20 protection switching mechanism acting independently
   at = both=20 end-points. Also, for the protected LSP under failure
  =20 condition, the Path_State_Removed Flag of the ERROR_SPEC object (see=20
   [RFC3473]) SHOULD NOT be set upon PathErr message = generation.=20
So, what you are saying is that in 1+1 protection the network may = *never*=20 know that the error is so bad that the LSP is dead, but MUST leave that = choice=20 to the ingress. While this is the operational practice in many transport = networks, I don't see why you make this as strong as a SHOULD=20 NOT.
=3D=3D=3D
Section 5
   Note: one should assume = that both=20 paths are SRLG disjoint otherwise,
   a failure would = impact both=20 working and protecting LSPs.
What is this supposed to tell the = reader? That=20 he should make the assumption or that he should ensure SRLG diversity?=20 ;-)
Actually, I think you want to say = that the=20 quality of 1+1 protection may vary. Allowing link diverse, node diverse = or SRLG=20 diverse 1+1 protection.
(ditto section 6 and 7)
=3D=3D=3D
Section 5.1
   Since both LSPs belong = to the same=20 session, the SESSION object MUST
   be the same for both = LSPs.=20
An undisputable conclusion drawn from = an unproven=20 premise.
Why must both LSPs belong to the same = session? A=20 one line explanation would start the section off nicely.
=3D=3D=3D
Section 5.1
   A new PROTECTION object = is included=20 in the Path message. This object
What is the implication of "new"? I = guess=20 you mean the new type defined in this draft.
=3D=3D=3D
Section 5.1
   A new PROTECTION object = is included=20 in the Path message. This object
   carries the desired = end-to-end=20 LSP Protection Type (in this case,
   "1+1 = Unidirectional"). This=20 LSP Protection Type value is applicable
   to both uni- = and=20 bi-directional LSPs.
This is unclear. In section 14.1 you have =
          &nbs= p;    =20 0x08    1+1 Unidirectional Protection =20
           &nb= sp;   =20 0x10    1+1 Bi-directional Protection =
=3D=3D=3D
Section 5.1
Your description of the use of the = P-bit for 1+1=20 protection isn't clear. You mean to say that the P-bit indicates which = LSP the=20 ingress would *prefer* to be the protecting LSP if all other things are = equal,=20 but your text (and the description of the P-bit in sections 4.2.1 and = 14) don't=20 make this clear.
=3D=3D=3D
Section 6.2
   directions. This is done = using the=20 Notify message with a new Error 
   Code indicating "Working LSP Failure (Switchover = Request)".=20 The
I don't see this in the IANA section, and I wonder if you also = mean=20 Error Value?
=3D=3D=3D
Section 6.2
   directions. This is done = using the=20 Notify message with a new Error
   Code indicating = "Working LSP=20 Failure (Switchover Request)". The
   Notify Ack message = MUST be=20 sent to confirm the reception of the
   Notify message = (see=20 [RFC3473], Section 4.3).   
I see no definition of a "Notify Ack = message" in=20 RFC3473 (in any section).
I am worried that you are confusing = the Ack=20 message with a new procedure requiring a handshake of Notify=20 messages.
=3D=3D=3D
Section 6.2
        1. If=20 an end-node (A or D) detects the failure of the working =20
           LSP (or = a=20 degradation of signal quality over the working =20
           LSP) or = receives a Notify message including its SESSION =20
           object = within=20 the <upstream/downstream session list> (see =20
           = [RFC3473]), it=20 MUST begin receiving on the protecting LSP 
Note that the sender descriptor or = flow=20 descriptor is also present in the Notify and this will considerably help = resolve=20 ambiguities and race conditions since it identifies the = LSP.
=3D=3D=3D
Section 6.2
        1. If=20 an end-node (A or D) detects the failure of the working =20
           LSP (or = a=20 degradation of signal quality over the working =20
           LSP) or = receives a Notify message including its SESSION =20
           object = within=20 the <upstream/downstream session list> (see =20
           = [RFC3473]), it=20 MUST begin receiving on the protecting LSP 
I don't think the = receipt=20 of a Notify message is sufficient, per se. I think the error code and = value need=20 to indicate a problem with the LSP.
=3D=3D=3D
Section 6.2
        1. If=20 an end-node (A or D) detects the failure of the working =20
           LSP (or = a=20 degradation of signal quality over the working =20
           LSP) or = receives a Notify message including its SESSION =20
           object = within=20 the <upstream/downstream session list> (see =20
           = [RFC3473]), it=20 MUST begin receiving on the protecting LSP =20
           and = send a=20 Notify message reliably to the other end-node (D =20
           or A,=20 respectively).
"...send a Notify message reliably" = will=20 certainly be misunderstood.
You presumably mean "...send a Notify = message=20 including the Message_ID object".
=3D=3D=3D
Section 6.2
        2.=20 Upon receipt of the switchover message, the end-node =20
           (D or = A,=20 respectively) MUST begin receiving from the =20
           = protection LSP=20 and send a (Notify) Ack message to the other =20
           = end-node (A or=20 D, respectively) using reliable message =20
           = delivery (see=20 [RFC2961]).
While this clarifies the use of Ack rather than Notify = Ack (not=20 sure why you need to include "(Notify)") it is now confused about the = delivery=20 of the Ack message. How do we achieve reliable delivery of an Ack=20 message?!
=3D=3D=3D
Section 7
   Although the resources = for the=20 protecting LSP are pre-allocated,
   preemptable traffic = may be=20 carried end-to-end using this LSP (i.e.
   the protecting = LSP is=20 capable of carrying extra-traffic) with the
   caveat that = this=20 traffic will be preempted if the working LSP fails.
Do you mean that the extra traffic is = carried=20 "using this LSP" or "using some or all of the resources assigned to this = LSP"?
=3D=3D=3D
Section 7
   Also, if extra-traffic = is carried=20 over the protecting LSP, the
   corresponding end-nodes = may be=20 notified of the failure in order to
   complete the=20 switchover. 
I think this is "end-nodes may need to be=20 notified"
=3D=3D=3D
Section 7.2
   To co-ordinate the = switchover=20 between end-points, an end-to-end
   switchover request is = needed=20 such that the affected LSP(s) are moved
   to the = protecting=20 LSP.
In what way may there be more than = one affected=20 LSP moved to a single protecting LSP?
=3D=3D=3D
Section 7.2
   This operation may be = done using a=20 Notify message exchange with a
   new Error Code = indicating=20 "(Working) LSP Failure (Switchover
   Request)". The = Notify Ack=20 message MUST be sent to confirm the
   reception of the = Notify=20 message. 
All of the same comments as for section = 6.2.
Also:
- Why do you say "may be = done"?
- Is this the same error code as in = 6.2? (the=20 text is slightly different)
=3D=3D=3D 
Section = 7.3
OLD
   provisioned protecting = LSP is=20 resource-disjoint LSP from the N
NEW
   provisioned protecting = LSP=20 is resource-disjoint from the N
=3D=3D=3D
Section 7.3
Can you highlight that the N working = LSPs are all=20 between the same pair of end points.
=3D=3D=3D
Section 8
OLD
   this does not mean that = the=20 corresponding resources can not used by
NEW
   this does not mean that = the=20 corresponding resources can not be used by
=3D=3D=3D
Section 8
   To make bandwidth = pre-reserved for a=20 protecting (but not activated)
   LSP, available for extra = traffic=20 this bandwidth could be included in
   the advertised = Unreserved=20 Bandwidth at priority lower (means
   numerically higher) = than the=20 Setup Priority of the protecting LSP.
This feels like it should be = the=20 Holding Priority. That is, the Setup Priority was only important for how = it=20 could displace pre-existing LSPs.
=3D=3D=3D
Section 8.3
OLD
   From [GMPLS-ARCH], the = secondary LSP=20 is setup with resource pre-
NEW
   From [RFC3945], the = secondary LSP is=20 setup with resource pre-
=3D=3D=3D
Section 9
OLD
   plane) a specific = protecting LSP=20 instantiated during the (pre-
   )provisioning phase. This = requires=20 restoration signaling along the 
NEW
   plane) a specific = protecting=20 LSP instantiated during the (pre-)
   provisioning phase. = This=20 requires restoration signaling along the
=3D=3D=3D
Section 9
   resource sharing), the = LSPs must=20 have the same Session Ids, but the
   Session Id includes = the=20 target (egress) IP address. These addresses
2xs/Id/ID/
Suggest a search for = "id"
=3D=3D=3D
Section 9.3
OLD
   From [GMPLS-ARCH], the = secondary LSP=20 is setup with resource pre-
NEW
   From [RFC3945], the = secondary LSP is=20 setup with resource pre-
=3D=3D=3D
Section 10
OLD
   activated. Additional = condition=20 raises from mis-connection avoidance
NEW
   activated. An additional = condition=20 arises from mis-connection avoidance
=3D=3D=3D
Section 10
OLD
   Note that step 1 may = cause alarms to=20 be raised for the pre-empted
   LSP. If alarm suppression = is=20 desired the pre-empting node MAY expand
   before applying = step 1=20 act as follows.
NEW
   Note that step 1 may = cause alarms to=20 be raised for the pre-empted
   LSP. If alarm suppression = is=20 desired the pre-empting node MAY insert
   the following steps = before step=20 1.
=3D=3D=3D
Section 10
   At the downstream node = (with respect=20 to the pre-empting LSP) the
   processing is RECOMMENDED = to be as=20 follows:
   
   1. Receive PathTear = (and/or=20 PathErr) message for the pre-empted  =
     =20 LSP(s).
   
   2a.Release the resources = associated with the LSP on the interface =
      to=20 the pre-empting LSP, remove any cross-connection and release =20
      all other resources associated with = the=20 pre-empted LSP.
   2b.Forward the PathTear (and/or = PathErr)=20 message per [RFC 3473].
   
   C. = Receive the=20 Path message for the pre-empting LSP and process as =20
      normal, forwarding it to the = downstream node.=20
   
   D. Receive the Resv for the = pre-empting=20 LSP and process as normal,
      forwarding = it to=20 the upstream node.
Cool numbering scheme :-)
Any chance of settling on something = more=20 conventional?
=3D=3D=3D
Section 11.2
   Note: when the = end-to-end LSP=20 Protection Type is set to
   "Unprotected", both S and P = bit MUST=20 be set to 0 and the LSP SHOULD
   NOT be re-routed at the = head-end=20 node after failure occurrence. The
   Association_ID value = MUST be=20 set to the LSP_ID value of the signaled
   LSP.
Please = explain=20 the difference between an attempt to "re-route" and an attempt to=20 "re-establish". presumably it could involve:
- a time difference
- the use of make-before-break for = failed=20 LSPs.
- the use of the ASSOCIATION = object.
I would like to make sure that you = are not=20 applying "SHOULD NOT" to LSP re-establishment.
=3D=3D=3D
Section 12
OLD
   allocated to the LSP = that was=20 originally routed over it even after a
NEW
   allocated to the LSP = that was=20 originally routed over them even after a
=3D=3D=3D
Section 12
   - then, apply the = reverse 1-phase=20 APS switchover request/response 
     (or = 2-phase=20 APS) described in Section 6.2 (or Section 7.2, 
This is the = first=20 mention of APS
=3D=3D=3D
Section 13
I think this section is going to give = us grief=20 during IESG review :-(
Why do we need to tie this so closely = with NMS=20 etc. And why describe it as external?
Can't we simply describe the function = by:
- dropping the first = para
- in C, D and E drop=20 "externally"
- in D and E replace "manual" with=20 "requested"
=3D=3D=3D
Section 13 TWICE
OLD
   Recovery signaling = operation is=20 initiated externally that switches
NEW
   Recovery = signaling is initiated=20 externally that switches
=3D=3D=3D
Section 13 (A and B)
   is set to either 0x04, = or 0x08 or=20 0x10.
I would prefer you to use the meanings rather than the=20 values.
=3D=3D=3D
Section 13 (D and E)
   This, unless a fault = condition=20 exists on
? "This is allowed"? "This is = possible"? "This is=20 successful"?
=3D=3D=3D
Section 14
OLD
   use so that the object = can be=20 included in the Notify message to act
   a switchover = request for=20 1+1 bi-directional and 1:1 protection. 
NEW
   use so that the object = can be=20 included in the Notify message to act
   as a switchover = request=20 for 1+1 bi-directional and 1:1 protection. 
=3D=3D=3D
Section 14.1
I believe we have had this discussion = before.
We don't introduce reserved fields = for future=20 extensibility. We only do it for padding.
If you are certain that we need to = extend in the=20 future then please use sub-objects or TLVs.
This means that you can:
a. Remove the last four bytes of the = Protection=20 object.
b. Retain the C-Type from = RFC3473
=3D=3D=3D
Section 15
   This object MUST be =
  =20 present in the Path message (for the pre-provisioning of the =
  =20 secondary protecting LSP) if and only if the LSP Protection Type=20
   value is set to "0x02".
"MUST if and only if" is not really = in=20 RFC2119.
Can we two statements. One with = "MUST" and one=20 with "MUST NOT".
=3D=3D=3D
Section 15
In the case where my protecting LSP = protects only=20 one working LSP and where the full path of the protecting LSP is known = by the=20 ingress (strict and explicit) and there is no resource sharing between = the=20 protected and protecting LSP, I can't see why I must include a=20 PPRO.
In other words, PPRO is an enabler of = function=20 (as stated in section 15.4 "The PPRO enables of sharing recovery = resources=20 between a given secondary protecting LSP and one or more secondary=20 protecting LSPs if their corresponding primary working LSPs have=20 mutually (link/node/SRLG)disjoint paths."), but that does not make = its=20 presence mandatory.
=3D=3D=3D
Section 15.1
   The contents of a = PRIMARY_PATH_ROUTE=20 object are a series of
   variable-length data items = called=20 subobjects. The subobjects are
   identical to those that = can=20 constitute an EXPLICIT/RECORD ROUTE
   object as defined = in=20 [RFC3209], [RFC3473] and [RFC3477].
This seems in contradiction with = section=20 15.3
=3D=3D=3D
Section 15.4
OLD
   The PPRO enables of = sharing recovery=20 resources between a given
NEW
   The PPRO = enables sharing of=20 recovery resources between a given
=3D=3D=3D
Section 16
   The ASSOCIATION object = is used to=20 associate LSPs with each other. In
   the context of = end-to-end=20 LSP recovery, the association MUST only
   identify LSPs = that=20 support the same Tunnel ID.
Hmmm. presumably same source and = destination is=20 relatively important too.
=3D=3D=3D
Section 16
   The ASSOCIATION object = is used to=20 associate LSPs with each other.  
You already said=20 this.
=3D=3D=3D
Section 16.1
      = Association ID: 16=20 bits
    =
        A=20 value that when combined with Association Type and =20
        Association Source = uniquely=20 identifies an association. 
It would be helpful to state who = assigns=20 this value.
=3D=3D=3D
Section 16.1
      = Association=20 Source: 4 or 16 bytes
   =20
        The IP address of the = node that=20 originated the association.
"The IP address"?
Question. Are two associations with = the same=20 Association ID equivalent if the Association Source addresses are = different but=20 identify the same node?
Answer (it transpires) is "no". =
You need to make this much clearer=20 here.
=3D=3D=3D
Section 17
Isn't Notify modified as = well?
And I thought Resv was, but I may = have been=20 sleeping.
=3D=3D=3D
Section 18
This is a bit poor.
If you don't modify the "external = commands"=20 section, you'll certainly have to discuss security for them. After all, = a forced=20 failover can be pretty disruptive.
But I think you need to discuss = misconnection=20 here. In particular when there is mesh protection going on.
=3D=3D=3D
Section 19
The IANA section needs some gardening = to make it=20 really easy for IANA to implement.
- Break it up into clearer=20 subsections.
- Make sure you have included all of = the=20 information needed in the registry
- Point back at the defining sections = of the=20 draft
- Only have suggested values in one = place in the=20 document
- Be consistend in using TBD or TBA = in the=20 document
=3D=3D=3D
Section 19
Should the IANA section also cover = the bits in=20 the ADMIN STATUS object?
=3D=3D=3D
Section 21
Missing references [CRANK], = [RFC2205]. Suspect=20 you need to check them all.
Will need to add a reference for LSP = segment=20 recovery.
=3D=3D=3D
Section 21.1
This seems a very long list of = normative=20 references. I hope you can split this so that most of the references are = informational.
=3D=3D=3D
Section 22
You might change this to "Editors'=20 Addresses"
 
 
------=_NextPart_000_01E5_01C529BF.63405520-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Mar 2005 18:59:59 +0000 Message-ID: From: "Stephen Shew" To: ccamp@ops.ietf.org Subject: RE: ASON Lexicography Date: Tue, 15 Mar 2005 13:58:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52990.E2C88F1F" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C52990.E2C88F1F Content-Type: text/plain I support this becoming a WG draft. > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Thursday, March 10, 2005 15:48 > To: ccamp@ops.ietf.org > Subject: ASON Lexicography > > > Dear CCAMP, > > In our meeting this week we heard about > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > There is some more discussion to be done on the content of > this draft but the chairs and the meeting thought that the > work is a very important part of CCAMP's job. > > Please indicate your opinion on whether this draft should be > made a working draft document by March 20, 2005. > > Thanks, > Kireeti. > ------- > > > ------_=_NextPart_001_01C52990.E2C88F1F Content-Type: text/html RE: ASON Lexicography

I support this becoming a WG draft.

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella
> Sent: Thursday, March 10, 2005 15:48
> To: ccamp@ops.ietf.org
> Subject: ASON Lexicography
>
>
> Dear CCAMP,
>
> In our meeting this week we heard about
> draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt
>
> There is some more discussion to be done on the content of
> this draft but the chairs and the meeting thought that the
> work is a very important part of CCAMP's job.
>
> Please indicate your opinion on whether this draft should be
> made a working draft document by March 20, 2005.
>
> Thanks,
> Kireeti.
> -------
>
>
>

------_=_NextPart_001_01C52990.E2C88F1F-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Mar 2005 14:53:09 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON Lexicography Date: Tue, 15 Mar 2005 08:53:02 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF093C91FF@OCCLUST04EVS1.ugd.att.com> Thread-Topic: ASON Lexicography Thread-Index: AcUlssurnnG1sm0fQtyjKS8N8axp5gDu9VIg From: "Brungard, Deborah A, ALABS" To: "Kireeti Kompella" , Yes- Deborah=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Mar 2005 14:51:24 +0000 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4A35979@zrtphxm2> From: "Don Fedyk" To: Kireeti Kompella , ccamp@ops.ietf.org Subject: RE: ASON Lexicography Date: Tue, 15 Mar 2005 09:48:34 -0500 Hi Kireeti Yes Valuable. It should be a WG draft. Don > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Thursday, March 10, 2005 3:48 PM > To: ccamp@ops.ietf.org > Subject: ASON Lexicography > > > Dear CCAMP, > > In our meeting this week we heard about > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > There is some more discussion to be done on the content of > this draft but the chairs and the meeting thought that the > work is a very important part of CCAMP's job. > > Please indicate your opinion on whether this draft should be > made a working draft document by March 20, 2005. > > Thanks, > Kireeti. > ------- > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Mar 2005 12:34:40 +0000 Message-ID: <031301c52952$85dae720$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , Subject: comments on draft-ietf-ccamp-gmpls-te-mib-08.txt Date: Tue, 15 Mar 2005 12:29:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A minor comment; this document has false (0), in several places; following RFC 2579, I think this should be false (2) A larger question,; this mib augments tables in the mpls mib (RFC3812); is there a reason why the AUGMENTS construct was not used? Tom Petch Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Mar 2005 12:06:02 +0000 Message-Id: <6.0.0.20.2.20050315210637.07d6c1e8@imb.m.ecl.ntt.co.jp> Date: Tue, 15 Mar 2005 21:07:18 +0900 To: "Kireeti Kompella" , From: "inoue.ichiro@lab.ntt.co.jp" Subject: RE: ASON Lexicography Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit I suppot it too. Ichiro Inoue Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Mar 2005 12:02:53 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: ASON Lexicography Date: Tue, 15 Mar 2005 06:01:20 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA060C8921@KCCLUST06EVS1.ugd.att.com> Thread-Topic: ASON Lexicography Thread-Index: AcUlssvSvweURWJyQ4uCzvl6ocGwkwDo4aRA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Kireeti Kompella" , Cc: "Ash, Gerald R \(Jerry\), ALABS" > Please indicate your opinion on whether this draft should be > made a working draft document by March 20, 2005. Yes. Thanks, Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Mar 2005 10:00:42 +0000 Message-ID: <017601c52945$d7aeda50$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tom Petch" , Subject: Re: comments on draft-ietf-ccamp-gmpls-lsr-mib-07.txt Date: Tue, 15 Mar 2005 09:53:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Good man, Tom. Thanks. Adrian ----- Original Message ----- From: "Tom Petch" To: "Adrian Farrel" ; Sent: Monday, March 14, 2005 2:19 PM Subject: comments on draft-ietf-ccamp-gmpls-lsr-mib-07.txt > I find the IANA Considerations section less than clear. I suggest that you > differentiate between xx and xx, eg by using yy for GMPLS-LABEL-STD-MIB > > I would also reword it slightly as follows. > > ** MPLS and GMPLS related standards track MIB modules are rooted under the > mplsStdMIB subtree. > > One of the MIB modules contained in this document extends tables > contained in MPLS MIB modules. > > ** The two MIB modules contained in this document, like that in > GMPLS-TC-STD-MIB [GMPLSTCMIB], should be placed in the mplsStdMIB subtree. > > ** New assignments in the mplsStdMIB subtree can only be made via a Standards > Action as specified in [RFC2434]. > > 11.1. IANA Considerations for GMPLS-LSR-STD-MIB > > The IANA is requested to assign { mplsStdMIB xx } to the > GMPLS-LSR-STD-MIB module specified in this document. > > 11.2. IANA Considerations for GMPLS-LABEL-STD-MIB > > ** The IANA is requested to assign { mplsStdMIB yy } to the > GMPLS-LABEL-STD-MIB module specified in this document. > > > Tom Petch > > draft-ietf-ccamp-gmpls-te-mib-08.txt > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Mar 2005 05:35:04 +0000 Message-ID: <423673C9.6030505@lab.ntt.co.jp> Date: Tue, 15 Mar 2005 14:34:01 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: ASON Lexicography Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes, it should be a WG draft. -- Kohei Shiomoto Kireeti Kompella wrote: > Dear CCAMP, > > In our meeting this week we heard about > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > There is some more discussion to be done on the content of this draft > but the chairs and the meeting thought that the work is a very > important part of CCAMP's job. > > Please indicate your opinion on whether this draft should be made a > working draft document by March 20, 2005. > > Thanks, > Kireeti. > ------- > > > -- Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan Phone +81 422 59 4402 Fax +81 422 59 3787 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Mar 2005 03:15:08 +0000 Date: Tue, 15 Mar 2005 11:10:13 +0800 From: Amit 70405 Subject: Query about recovery hierarchies To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline Hi All, I want to clarify some things about hiearchical classification of recovery mechanisms. In draft-ietf-ccamp-gmpls-recovery-analysis-04, there are two hierarchies being defined. I have below understanding of these hierarchies. Plz let me know if this correct. Horizontal & Vertical recovery hierachy are the hierarchies. Horizontal hierachy basically is about control plane recovery mechanism. This includes link, segment and e2e recovery mechanisms. Whereas Vertical Hierarchy is about utilising recovery mechanisms at different network layers. Suppose for e.g: MSP protection is supported at Layer 1. And control plane supports link, segmnent & e2e supports. Than the layer 1 & Control plane mechanisms should be independant of each other. Is this what the Recovery Hierarchy means? Plz correct me if I am wrong. Thanks in advance. Regards, Amit. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Mar 2005 15:26:54 +0000 Message-ID: <025a01c528a0$fc6ff040$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , Subject: comments on draft-ietf-ccamp-gmpls-lsr-mib-07.txt Date: Mon, 14 Mar 2005 15:19:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I find the IANA Considerations section less than clear. I suggest that you differentiate between xx and xx, eg by using yy for GMPLS-LABEL-STD-MIB I would also reword it slightly as follows. ** MPLS and GMPLS related standards track MIB modules are rooted under the mplsStdMIB subtree. One of the MIB modules contained in this document extends tables contained in MPLS MIB modules. ** The two MIB modules contained in this document, like that in GMPLS-TC-STD-MIB [GMPLSTCMIB], should be placed in the mplsStdMIB subtree. ** New assignments in the mplsStdMIB subtree can only be made via a Standards Action as specified in [RFC2434]. 11.1. IANA Considerations for GMPLS-LSR-STD-MIB The IANA is requested to assign { mplsStdMIB xx } to the GMPLS-LSR-STD-MIB module specified in this document. 11.2. IANA Considerations for GMPLS-LABEL-STD-MIB ** The IANA is requested to assign { mplsStdMIB yy } to the GMPLS-LABEL-STD-MIB module specified in this document. Tom Petch draft-ietf-ccamp-gmpls-te-mib-08.txt Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 13 Mar 2005 00:09:58 +0000 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8960b712d5442f3313fd967cb940c868@cisco.com> Content-Transfer-Encoding: 7bit Cc: ccamp@ops.ietf.org From: JP Vasseur Subject: Re: ASON Lexicography Date: Sat, 12 Mar 2005 11:04:49 -0500 To: Kireeti Kompella in favor. JP. On Mar 10, 2005, at 3:48 PM, Kireeti Kompella wrote: > Dear CCAMP, > > In our meeting this week we heard about > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > There is some more discussion to be done on the content of this draft > but the chairs and the meeting thought that the work is a very > important part of CCAMP's job. > > Please indicate your opinion on whether this draft should be made a > working draft document by March 20, 2005. > > Thanks, > Kireeti. > ------- > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 12 Mar 2005 16:32:21 +0000 Message-ID: <42331977.9050104@cisco.com> Date: Sat, 12 Mar 2005 11:31:51 -0500 From: Scott W Brim User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) MIME-Version: 1.0 To: Adrian Farrel CC: Kireeti Kompella , ccamp@ops.ietf.org Subject: Re: ASON Lexicography Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 3/12/2005 11:26, Adrian Farrel allegedly wrote: > Hi Scott, > > Thanks for you input. Obviously we have been discussing the content of the > draft with people in Q14/15 and in CCAMP and have received quite a lot of > input. We plan to bring out a new version as soon as we can cut the > bandwidth. Looking forward to it. > In the mean time, are there specific terms that you have an issue with, or > is it a matter of style. Concepts, as you saw in my exchange a month ago. I'll wait for the new version. Thanks ... Scott Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 12 Mar 2005 16:27:10 +0000 Message-ID: <004c01c5271f$65f52040$09cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Last call on protection signaling drafts Date: Sat, 12 Mar 2005 15:59:33 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This email begins a two week working group last call on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt and http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-01.txt Last call will end on Sunday 27th March at 12 noon GMT. Please send you comments to the list. The chairs can provide an annonymizing function if you require. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 12 Mar 2005 16:27:03 +0000 Message-ID: <007b01c52720$4d931a10$09cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Scott W Brim" , "Kireeti Kompella" Cc: Subject: Re: ASON Lexicography Date: Sat, 12 Mar 2005 16:26:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Scott, Thanks for you input. Obviously we have been discussing the content of the draft with people in Q14/15 and in CCAMP and have received quite a lot of input. We plan to bring out a new version as soon as we can cut the bandwidth. In the mean time, are there specific terms that you have an issue with, or is it a matter of style. Thanks, Adrian ----- Original Message ----- From: "Scott W Brim" To: "Kireeti Kompella" Cc: Sent: Friday, March 11, 2005 1:45 AM Subject: Re: ASON Lexicography > On Thu, Mar 10, 2005 12:48:29PM -0800, Kireeti Kompella allegedly wrote: > > Dear CCAMP, > > > > In our meeting this week we heard about > > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > > > There is some more discussion to be done on the content of this draft > > but the chairs and the meeting thought that the work is a very > > important part of CCAMP's job. > > > > Please indicate your opinion on whether this draft should be made a > > working draft document by March 20, 2005. > > Yes it's a good goal, but the draft is going to need a large amount of > work. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 11 Mar 2005 09:41:45 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : ASON Lexicography Date: Fri, 11 Mar 2005 10:39:33 +0100 Message-ID: Thread-Topic: ASON Lexicography Thread-Index: AcUlszjabAotRAeTTiSrYKXLl/r2NgAatbNQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Kireeti Kompella" , Hi, This is a highly useful draft. It should become a WG ID. Regards, JL >-----Message d'origine----- >De : owner-ccamp@ops.ietf.org=20 >[mailto:owner-ccamp@ops.ietf.org] De la part de Kireeti Kompella >Envoy=E9 : jeudi 10 mars 2005 21:48 >=C0 : ccamp@ops.ietf.org >Objet : ASON Lexicography > > >Dear CCAMP, > >In our meeting this week we heard about=20 >draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > >There is some more discussion to be done on the content of=20 >this draft but the chairs and the meeting thought that the=20 >work is a very important part of CCAMP's job. > >Please indicate your opinion on whether this draft should be=20 >made a working draft document by March 20, 2005. > >Thanks, >Kireeti. >------- > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 11 Mar 2005 01:48:34 +0000 Date: Thu, 10 Mar 2005 20:45:46 -0500 From: Scott W Brim To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: ASON Lexicography Message-ID: <20050311014546.GA3896@sbrim-w2k02> Mail-Followup-To: Scott W Brim , Kireeti Kompella , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i On Thu, Mar 10, 2005 12:48:29PM -0800, Kireeti Kompella allegedly wrote: > Dear CCAMP, > > In our meeting this week we heard about > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > There is some more discussion to be done on the content of this draft > but the chairs and the meeting thought that the work is a very > important part of CCAMP's job. > > Please indicate your opinion on whether this draft should be made a > working draft document by March 20, 2005. Yes it's a good goal, but the draft is going to need a large amount of work. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Mar 2005 21:21:04 +0000 Message-Id: <200503102120.j2ALKbjI018527@rtp-core-2.cisco.com> From: "Zafar Ali" To: "'Kireeti Kompella'" , Subject: RE: ASON Lexicography Date: Thu, 10 Mar 2005 16:20:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcUltOjMaYubLmzAR8SZWOU+gd66FAAAgozQ > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Thursday, March 10, 2005 3:48 PM > To: ccamp@ops.ietf.org > Subject: ASON Lexicography > > Dear CCAMP, > > In our meeting this week we heard about > draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt > > There is some more discussion to be done on the content of > this draft but the chairs and the meeting thought that the > work is a very important part of CCAMP's job. > > Please indicate your opinion on whether this draft should be > made a working draft document by March 20, 2005. In Favor. > > Thanks, > Kireeti. > ------- > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Mar 2005 20:49:50 +0000 Date: Thu, 10 Mar 2005 12:48:29 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: ASON Lexicography Message-ID: <20050310124529.L97363@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear CCAMP, In our meeting this week we heard about draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt There is some more discussion to be done on the content of this draft but the chairs and the meeting thought that the work is a very important part of CCAMP's job. Please indicate your opinion on whether this draft should be made a working draft document by March 20, 2005. Thanks, Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Mar 2005 06:17:33 +0000 Message-Id: <6.1.0.6.2.20050310151357.063ce1f0@mail.jp.nec.com> Date: Thu, 10 Mar 2005 15:14:17 +0900 To: "Ash, Gerald R \(Jerry\), ALABS" From: Atsushi Iwata Subject: RE: Liaison from ITU-T Q14/15 on crankback Cc: "Adrian Farrel" , , "Ash, Gerald R \(Jerry\), ALABS" , "Kireeti Kompella" , "Scott Bradner" , "Scott W Brim" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Adrian I also agree with this. Thanks. At 04:40 05/03/10, Ash, Gerald R \(Jerry\), ALABS wrote: >Adrian, > >> However, I propose that we should respond asking to be >> involved in the review of the proposed additions of >> crankback function to the referenced recommendations >> before that material is consented (last-called) by the >> ITU-T. This would allow us to correct any >> misunderstandings about our draft. >> >> Please comment on this proposal on the mail list. > >Definitely agree. > >Thanks, >Jerry *--------------------------------------------------------* Atsushi Iwata, Ph.D. / Senior Manager System Platforms Research Labs, NEC Corporation 1753 Shimonumabe Nakahara-ku, Kawasaki, 211-8666, Japan TEL: +81-44-396-2744 (Direct), Fax: +81-44-431-7612 (Direct) NEC-internal TEL: 8-22-72634, NEC-internal FAX: 8-22-60469 NEC-mail: 8-22-60440, E-mail: a-iwata@ah.jp.nec.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Mar 2005 23:05:36 +0000 Message-ID: <040a01c524fc$3f4656a0$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Jean Philippe Vasseur'" Subject: Slides and agenda updated Date: Wed, 9 Mar 2005 23:00:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I've uploaded all of the slides to http://www.olddog.co.uk/ccamp.htm except for JP's slides on draft-vasseur-ccamp-automesh-00.txt which are still giving my copy of PowerPoint significant indigestion. JP, can you check that you can send me a copy saved with all PowerPoint options deleted? Thanks Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Mar 2005 19:40:58 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Liaison from ITU-T Q14/15 on crankback Date: Wed, 9 Mar 2005 13:40:07 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA060C88F4@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Liaison from ITU-T Q14/15 on crankback Thread-Index: AcUk1zNT05BSpbiyTOigN342BKTmjwACE/HA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , Cc: "Ash, Gerald R \(Jerry\), ALABS" , "Kireeti Kompella" , "Scott Bradner" , "Scott W Brim" Adrian, > However, I propose that we should respond asking to be=20 > involved in the review of the proposed additions of > crankback function to the referenced recommendations > before that material is consented (last-called) by the > ITU-T. This would allow us to correct any > misunderstandings about our draft. > > Please comment on this proposal on the mail list. Definitely agree. Thanks, Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Mar 2005 18:38:16 +0000 Message-ID: <037e01c524d7$0a7a8f60$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" , "Scott Bradner" , "Scott W Brim" Subject: Liaison from ITU-T Q14/15 on Transport use of LMP Date: Wed, 9 Mar 2005 18:37:00 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0379_01C524D6.FB0E0B10" This is a multi-part message in MIME format. ------=_NextPart_000_0379_01C524D6.FB0E0B10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This is the second of the two liaisons form an ITU-T meeting held in = January that arrived today. It is an informational liaison and no action is required. However, the liaison suggests that two items are considered within the = Transport LMP draft. I would appreciate it if the editor and authors of = that draft sent some thoughts on this to the ccamp list. I can then = judge consensus on these thoughts and respond to the liaison as = appropriate. Thanks, Adrian ---- The content of the liaison is as follows: Subject: Liaison Statement to IETF CCAMP WG on the Comparison of LMP and = ASON Discovery To: Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs From: Alex Zinin and Bill Fenner, IETF Routing Area Directors Scott Bradner, IETF liaison to ITU-T Thank you for your response to our liaison on this topic. As noted in = your liaison some experts from the IETF were able to attend the Q14/15 = meeting. As a result of the discussion of terminology we have the = following observations that we suggest should be incorporated into = draft-ietf-ccamp-transport-lmp-00.txt to provide some additional context = that will aid the members of the IETF in understanding the terminology = used by the ITU-T. =20 In your liaison you state that an SNPP link could easily be mapped to a = TE link. However, discussion at the meeting revealed some subtle but = important differences: - The SNPP link construct is defined to support hierarchical = containment. However, since the IETF has not yet addressed hierarchical routing the current description of a TE link does not (explicitly) include the=20 notion of hierarchical containment. - In the ITU the properties of a node are described explicitly in terms = of=20 adaptation/termination functions and the binding of these functions to = subnetworks (within the node) and links (which are attached to the = node). In the IETF the capabilities and properties of a node are inferred = from=20 the description of the properties of the link ends that terminate on = node. =20 An electronic copy of this liaison statement can be found at = ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICAT= IONS/index.html ------=_NextPart_000_0379_01C524D6.FB0E0B10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

This is the second of the = two liaisons=20 form an ITU-T meeting held in January that arrived today.
It is an=20 informational liaison and no action is required.
 
However, the liaison suggests that = two items are=20 considered within the Transport LMP draft. I would appreciate it if the = editor=20 and authors of that draft sent some thoughts on this to the ccamp list. = I can=20 then judge consensus on these thoughts and respond to the liaison as=20 appropriate.
 
Thanks,
Adrian
 
----

The content of the liaison is as = follows:

Subject:=20 Liaison Statement to IETF CCAMP WG on the Comparison of LMP and ASON=20 Discovery
To: Adrian Farrel and Kireeti Kompella, IETF CCAMP=20 co-chairs
From: Alex Zinin and Bill Fenner, IETF Routing Area=20 Directors
        Scott Bradner, = IETF=20 liaison to ITU-T

Thank you for your response to our liaison on = this=20 topic.  As noted in your liaison some experts from the IETF were = able to=20 attend the Q14/15 meeting.  As a result of the discussion of = terminology we=20 have the following observations that we suggest should be incorporated = into=20 draft-ietf-ccamp-transport-lmp-00.txt to provide some additional context = that=20 will aid the members of the IETF in understanding the terminology used = by the=20 ITU-T. 

In your=20 liaison you state that an SNPP link could easily be mapped to a TE = link. =20 However, discussion at the meeting revealed some subtle but important=20 differences:

- The SNPP=20 link construct is defined to support hierarchical = containment.
  However, since the IETF has = not yet=20 addressed hierarchical routing the
  current description of a = TE link does=20 not (explicitly) include the
  notion of hierarchical=20 containment.

- In the ITU the properties of a node are described explicitly = in terms=20 of
  adaptation/termination functions and the binding of these = functions=20 to
  subnetworks (within the node) and links (which are attached = to the=20 node).
  In the IETF the capabilities and properties of a node are = inferred=20 from
  the description of the properties of the link ends that = terminate on=20 node.
 
An electronic copy of this liaison statement can be = found at=20 ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICAT= IONS/index.html
------=_NextPart_000_0379_01C524D6.FB0E0B10-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Mar 2005 18:38:08 +0000 Message-ID: <037801c524d6$39035c50$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" , "Scott Bradner" , "Scott W Brim" Subject: Liaison from ITU-T Q14/15 on crankback Date: Wed, 9 Mar 2005 18:28:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, This is the first of the two liaisons form an ITU-T meeting held in January that arrived today. It is an informational liaison and no action is required. However, I propose that we should respond asking to be involved in the review of the proposed additions of crankback function to the referenced recommendations before that material is consented (last-called) by the ITU-T. This would allow us to correct any misunderstandings about our draft. Please comment on this proposal on the mail list. Thanks, Adrian ==== The content of this liaison is as follows: Subject: Liaison Statement to IETF CCAMP WG on Crankback in GMPLS Systems To: Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs Cc: Alex Zinin and Bill Fenner, IETF Routing Area Directors Scott Bradner, IETF liaison to ITU-T Thank you for your response to our liaison regarding crankback as described in . Q14/15 appreciates the clarifications and will use this to develop protocol requirements for the next revision of G.7713 ("Distributed call and connection management"). In particular, we need to incorporate crankback into the call model. After that, the protocol details from can be incorporated into G.7713.2. An electronic copy of this liaison statement can be found at ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Mar 2005 18:27:53 +0000 Message-ID: <037201c524d5$12786040$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" Subject: Two LSs from ITU-T SG15's Q14/15 to IETF CCAMP WG Date: Wed, 9 Mar 2005 18:20:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, We have received two liaison statements from ITU-T Study Group 15 Question 14. I have put these on the alternate ccamp web site at http://www.olddog.co.uk/incoming.htm I will send separate emails to include the text of the liaisons and propose actions. Adrian ----- Original Message ----- From: To: ; ; ; ; ; ; Cc: ; ; ; Sent: Wednesday, March 09, 2005 3:45 PM Subject: Two LSs from ITU-T SG15's Q14/15 to IETF CCAMP WG Dear Sirs, On behalf of the Chairman of ITU-T Study Group 15, I am pleased to send you two Liaison Statements agreed at the SG15 Q.14/15 Interim Meeting, 24 - 28 January 2005: 1) To IETF CCAMP WG on Crankback in GMPLS Systems 2) To IETF CCAMP WG on the Comparison of LMP and ASON Discovery Best regards, Greg Jones Counsellor, ITU-T Study Group 15 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Mar 2005 15:41:26 +0000 Date: Tue, 8 Mar 2005 10:40:44 -0500 From: Ashok Narayanan To: benjamin.niven-jenkins@bt.com Cc: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Message-ID: <20050308154044.GA1098@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i On Tue, Mar 08, 2005 at 03:20:43PM -0000, benjamin.niven-jenkins@bt.com wrote: > Ashok, > > I think one of the key points that needs highlighting explicitly which is not clear in the draft or your text below is that there are two separate control networks: > 1) One control network for the non-PSC core. > 2) One control network for the PSC edge nodes. Maybe that division is not as clear as it needs to be. Which network of those two do the following belong to?: 1) Path message for an optical LSP generated by a PSC edge node. 2) NOTIFY message from a PSC edge node to the other PSC edge node for an optical LSP. 3) Path message for a frame LSP going over an optical LSP generated by a PSC edge node. 4) LDP messages exchanged between PSC edge nodes. 5) SIP messages transiting the PSC edge nodes. There are plenty of different control plane levels here, so rather than talk about two specific ones, I would like to differentiate between a) "Messages for GMPLS/TE routing/signalling of optical LSPs between the PSC edge devices and the optical core devices" b) "everything else". I want to say that if we use a separated control network for "a)", then any and all traffic for "b)" MUST NOT go over that control network. Everything else is to clarify (and may insert additional ambiguities of its own :-() > > Network (1) has to be OOB as a forced requirement of the co-cs mode. Not necessarily OOB, but "separated". I think this is the point that Dimitri was making. DCC is not necessarily considered OOB, but it is a separated control plane. > Network (2) does not have to be OOB but it may be (it's down to operator choice/policy etc.). Yes, and the specific statement is that traffic in network 2 cannot transit the separated control plane used for network 1. Whether it is separated or not is not relevant as you correctly point out. > > If you look at the whole network stack you have trails in the non-PSC core layer network supporting link connections in the PSC layer network. These non-PSC layer network trails may be used to support link connections in the PSC layer network that may be assigned to carry only 'PSC data traffic' (for the PSC data plane), only 'PSC control traffic' (for the PSC control plane when it's taken OOB) or both 'PSC data and control plane traffic' (when the PSC control plane is inband wrt the PSC data plane). > > In other words, the non-PSC layer network has it's own data & > control plane networks that are (or should be) decoupled from the > PSC layer network (which has its own data & control plane networks). > non-PSC layer network data plane trails can be used to support PSC > layer network data (and/or control) plane link connections, but > non-PSC layer network control plane trails MUST NOT be used to > support PSC layer network data (and/or control) plane link > connections. I agree. I would phrase this as a "clarification" of b) above; clarifying that PSC layer network control traffic falls in the "everything else" category w.r.t the optical network. > This behaviour should be recursive from the lowest to > the highest layer in the network stack. That's not necessarily what I'm saying but it's not bad. > > Ben > > > -----Original Message----- > > From: Ashok Narayanan [mailto:ashokn@cisco.com] > > Sent: 08 March 2005 14:52 > > To: Adrian Farrel > > Cc: Niven-jenkins,B,Ben,XDE73 R; ccamp@ops.ietf.org > > Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt > > > > > > On Tue, Mar 08, 2005 at 02:12:54PM -0000, Adrian Farrel wrote: > > > Hi, > > > > > > Ben summarized... > > > > > > > Thanks for the explanation. If I understand correctly > > what you are > > > > saying is that the best current practice is to use an OOB > > control plane > > > > for the non-PSC layer networks and an in-band control > > plane for the > > > > PSC layer networks. > > > > > > If that is the intention of the authors of this draft, they > > will have to > > > fight me :-) > > > > I better check out this website: > > http://www.all-karate.com/how_to_learn_karate.php > > > > > I do not see why an in-band control channel for a PSC > > network would be > > > made a RECOMMEND, SHOULD or MUST. > > > > That is certainly not the recommendation (phew). > > > > I clarified in a separate email, but basically the point we are making > > is that in an optical GMPLS/TE network with optical switches in the > > core and PSC devices on the edge, edge-to-edge protocols not used for > > GMPLS/TE signalling within the core must be kept off the separated > > control network. I think the text needs to be tightened up to say > > this; I sent out an alternative formulation just now, let's see how > > that goes. > > > > > > > > > So one must avoid using the control plane network (of a non-PSC > > > > layer network) for the transfer of data (or control) > > plane packets from > > > > the PSC layer network's control & data planes. > > > > > > Yes. But more precisely, one must avoid using the control > > channels for > > > data traffic. Even in-band control channel may use a > > different address > > > space, and those addresses must not be used for data. > > > > Which is fine, but then raises the question: what is "data"? Bearer > > traffic? SIP messages transiting through a number of hops to get here? > > IPv4 RSVP for QoS? BGP or LDP running between the PSCs? I claim that > > for the aforementioned "GMPLS/TE-optical-core-PSC-edge" network, *all* > > of the aforementioned must be kept off the separated control plane > > *used for GMPLS within the optical core*. Nothing prevents these other > > protocols from having their own separated control plane, just as long > > as that other control plane also goes over a GMPLS/TE LSP or via some > > other "data" path. > > > > What I'm trying to say is that the optical switches in the core should > > basically not have to ever see any signalling or data packets that > > don't pertain to GMPLS/TE signalling within the optical core. > > > > In summary: (is this a better way to write this in the draft?) > > > > 1) A core of optical switches with PSC edge devices running GMPLS may > > use a separated control network (DCC, OOB Ethernet, or some other) to > > carry GMPLS/TE signalling messages. Further, this control network may > > be low-bandwidth and may pass through devices that are not well suited > > for IP routing. > > > > 2) Bearer data traffic transiting this network MUST NOT be carried on > > this separated control network. > > > > 3) Further, given the nature of the control network and the devices > > that maintain it, protocols running between the PSC edge devices that > > are not used for GMPLS/TE signalling within the core MUST NOT be > > carried over this control network. (N.B. should this be relaxed to a > > "SHOULD"?) This does not preclude these other protocols from running > > separated control planes of their own, as long as the protocol > > signalling messages do not transit the separated control network used > > within the GMPLS/TE core. > > > > -Ashok > > > > > > > > > > > > > > > > --- Asok the Intern ---------------------------------------- > > Ashok Narayanan > > IOS Network Protocols, Cisco Systems > > 1414 Mass Ave, Boxborough MA 01719 > > Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) > > -- --- Asok the Intern ---------------------------------------- Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Mar 2005 15:21:47 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Date: Tue, 8 Mar 2005 15:20:43 -0000 Message-ID: Thread-Topic: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Thread-Index: AcUj7mJ60OKsLVUhR2OZjc+ClTML9wAAe5dQ From: To: , Cc: Ashok, I think one of the key points that needs highlighting explicitly which = is not clear in the draft or your text below is that there are two = separate control networks: 1) One control network for the non-PSC core.=20 2) One control network for the PSC edge nodes. Network (1) has to be OOB as a forced requirement of the co-cs mode. Network (2) does not have to be OOB but it may be (it's down to operator = choice/policy etc.). If you look at the whole network stack you have trails in the non-PSC = core layer network supporting link connections in the PSC layer network. = These non-PSC layer network trails may be used to support link = connections in the PSC layer network that may be assigned to carry only = 'PSC data traffic' (for the PSC data plane), only 'PSC control traffic' = (for the PSC control plane when it's taken OOB) or both 'PSC data and = control plane traffic' (when the PSC control plane is inband wrt the PSC = data plane). =20 In other words, the non-PSC layer network has it's own data & control = plane networks that are (or should be) decoupled from the PSC layer = network (which has its own data & control plane networks). non-PSC = layer network data plane trails can be used to support PSC layer network = data (and/or control) plane link connections, but non-PSC layer network = control plane trails MUST NOT be used to support PSC layer network data = (and/or control) plane link connections. This behaviour should be = recursive from the lowest to the highest layer in the network stack.=20 Ben > -----Original Message----- > From: Ashok Narayanan [mailto:ashokn@cisco.com] > Sent: 08 March 2005 14:52 > To: Adrian Farrel > Cc: Niven-jenkins,B,Ben,XDE73 R; ccamp@ops.ietf.org > Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt >=20 >=20 > On Tue, Mar 08, 2005 at 02:12:54PM -0000, Adrian Farrel wrote: > > Hi, > >=20 > > Ben summarized... > >=20 > > > Thanks for the explanation. If I understand correctly=20 > what you are > > > saying is that the best current practice is to use an OOB=20 > control plane > > > for the non-PSC layer networks and an in-band control=20 > plane for the > > > PSC layer networks. > >=20 > > If that is the intention of the authors of this draft, they=20 > will have to > > fight me :-) >=20 > I better check out this website: > http://www.all-karate.com/how_to_learn_karate.php >=20 > > I do not see why an in-band control channel for a PSC=20 > network would be > > made a RECOMMEND, SHOULD or MUST. >=20 > That is certainly not the recommendation (phew).=20 >=20 > I clarified in a separate email, but basically the point we are making > is that in an optical GMPLS/TE network with optical switches in the > core and PSC devices on the edge, edge-to-edge protocols not used for > GMPLS/TE signalling within the core must be kept off the separated > control network. I think the text needs to be tightened up to say > this; I sent out an alternative formulation just now, let's see how > that goes. >=20 > >=20 > > > So one must avoid using the control plane network (of a non-PSC > > > layer network) for the transfer of data (or control)=20 > plane packets from > > > the PSC layer network's control & data planes. > >=20 > > Yes. But more precisely, one must avoid using the control=20 > channels for > > data traffic. Even in-band control channel may use a=20 > different address > > space, and those addresses must not be used for data. >=20 > Which is fine, but then raises the question: what is "data"? Bearer > traffic? SIP messages transiting through a number of hops to get here? > IPv4 RSVP for QoS? BGP or LDP running between the PSCs? I claim that > for the aforementioned "GMPLS/TE-optical-core-PSC-edge" network, *all* > of the aforementioned must be kept off the separated control plane > *used for GMPLS within the optical core*. Nothing prevents these other > protocols from having their own separated control plane, just as long > as that other control plane also goes over a GMPLS/TE LSP or via some > other "data" path. >=20 > What I'm trying to say is that the optical switches in the core should > basically not have to ever see any signalling or data packets that > don't pertain to GMPLS/TE signalling within the optical core. >=20 > In summary: (is this a better way to write this in the draft?) >=20 > 1) A core of optical switches with PSC edge devices running GMPLS may > use a separated control network (DCC, OOB Ethernet, or some other) to > carry GMPLS/TE signalling messages. Further, this control network may > be low-bandwidth and may pass through devices that are not well suited > for IP routing. >=20 > 2) Bearer data traffic transiting this network MUST NOT be carried on > this separated control network. >=20 > 3) Further, given the nature of the control network and the devices > that maintain it, protocols running between the PSC edge devices that > are not used for GMPLS/TE signalling within the core MUST NOT be > carried over this control network. (N.B. should this be relaxed to a > "SHOULD"?) This does not preclude these other protocols from running > separated control planes of their own, as long as the protocol > signalling messages do not transit the separated control network used > within the GMPLS/TE core. >=20 > -Ashok >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --- Asok the Intern ---------------------------------------- > Ashok Narayanan > IOS Network Protocols, Cisco Systems > 1414 Mass Ave, Boxborough MA 01719 > Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Mar 2005 14:52:29 +0000 Date: Tue, 8 Mar 2005 09:51:50 -0500 From: Ashok Narayanan To: Adrian Farrel Cc: benjamin.niven-jenkins@bt.com, ccamp@ops.ietf.org Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Message-ID: <20050308145150.GA28982@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i On Tue, Mar 08, 2005 at 02:12:54PM -0000, Adrian Farrel wrote: > Hi, > > Ben summarized... > > > Thanks for the explanation. If I understand correctly what you are > > saying is that the best current practice is to use an OOB control plane > > for the non-PSC layer networks and an in-band control plane for the > > PSC layer networks. > > If that is the intention of the authors of this draft, they will have to > fight me :-) I better check out this website: http://www.all-karate.com/how_to_learn_karate.php > I do not see why an in-band control channel for a PSC network would be > made a RECOMMEND, SHOULD or MUST. That is certainly not the recommendation (phew). I clarified in a separate email, but basically the point we are making is that in an optical GMPLS/TE network with optical switches in the core and PSC devices on the edge, edge-to-edge protocols not used for GMPLS/TE signalling within the core must be kept off the separated control network. I think the text needs to be tightened up to say this; I sent out an alternative formulation just now, let's see how that goes. > > > So one must avoid using the control plane network (of a non-PSC > > layer network) for the transfer of data (or control) plane packets from > > the PSC layer network's control & data planes. > > Yes. But more precisely, one must avoid using the control channels for > data traffic. Even in-band control channel may use a different address > space, and those addresses must not be used for data. Which is fine, but then raises the question: what is "data"? Bearer traffic? SIP messages transiting through a number of hops to get here? IPv4 RSVP for QoS? BGP or LDP running between the PSCs? I claim that for the aforementioned "GMPLS/TE-optical-core-PSC-edge" network, *all* of the aforementioned must be kept off the separated control plane *used for GMPLS within the optical core*. Nothing prevents these other protocols from having their own separated control plane, just as long as that other control plane also goes over a GMPLS/TE LSP or via some other "data" path. What I'm trying to say is that the optical switches in the core should basically not have to ever see any signalling or data packets that don't pertain to GMPLS/TE signalling within the optical core. In summary: (is this a better way to write this in the draft?) 1) A core of optical switches with PSC edge devices running GMPLS may use a separated control network (DCC, OOB Ethernet, or some other) to carry GMPLS/TE signalling messages. Further, this control network may be low-bandwidth and may pass through devices that are not well suited for IP routing. 2) Bearer data traffic transiting this network MUST NOT be carried on this separated control network. 3) Further, given the nature of the control network and the devices that maintain it, protocols running between the PSC edge devices that are not used for GMPLS/TE signalling within the core MUST NOT be carried over this control network. (N.B. should this be relaxed to a "SHOULD"?) This does not preclude these other protocols from running separated control planes of their own, as long as the protocol signalling messages do not transit the separated control network used within the GMPLS/TE core. -Ashok --- Asok the Intern ---------------------------------------- Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Mar 2005 14:30:32 +0000 Date: Tue, 8 Mar 2005 09:29:59 -0500 From: Ashok Narayanan To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Cc: benjamin.niven-jenkins@bt.com, ccamp@ops.ietf.org Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Message-ID: <20050308142959.GE32112@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Dimitri, Thanks for the comments. Hopefully this text will get beaten into shape with the attention you folks are paying to it. On Tue, Mar 08, 2005 at 02:56:05PM +0100, dimitri papadimitriou wrote: > ashok - this section is indeed to be clarified > > 1. for non-PSC it should distinguish the logical from the physical > control channel separation with respect to the data plane channels, i do > not see for instance why DCC channels could not be used to exchange > control plane traffic and still keep a logical separation Sure; of course we are not saying that. DCC channels although travelling on the same fiber are logically separated from the data channel on the same fiber. I don't think there is any statement to the contrary. > > 2. for PSC - why is there something different in terms of "practice" > than what is currently used in MPLS networks ? We aren't recommending any. The separated L3 control plane idea I had mentioned was my attempt to understand the kind of application that Ben was getting at when he asked "why must control protocols (such as LDP) NOT form adjacencies over the control plane interfaces". See below. > > or > > 3. do you assume that the interconnection of a PSC with non-PSC network > (both driven by GMPLS) could indeed introduce change from the current > practices operators used to use for their packet networks ? that in case > could be further applied to PSC-only networks ? I'd say the first part of this is slightly true. Let me try and reformulate; please tell me if this is better: "Consider a GMPLS/TE network with optical switches in the core and PSC devices at the edge, with a separated control plane (either OOB or via DCC). The edge PSC devices have IP reachability with each other via both the separated control plane network and via any optical GMPLS/TE LSPs that may be configured between them (the "data traffic network"). For the reasons mentioned below, traffic on the separated control network MUST be limited to GMPLS/TE signalling traffic solely for the purpose of established optical LSPs within the core of optical switches. All bearer traffic carried through this network MUST be carried over GMPLS/TE LSPs and MUST NOT be carried over the separated control network. Further, any protocols that run purely between the PSC devices that are not used for GMPLS/TE signalling within the optical switch core (e.g. protocols for carrying bearer traffic like LDP and BGP) MUST communicate over GMPLS/TE LSPs and MUST NOT form adjacencies or exchange messages over the separated control network." So there is in fact a change from the current practice of a PSC network *only* at the edge of a cloud of optical switches running GMPLS. If this was a regular cloud of routers then we could say "if you have IP reachability over link X, use it". But in the case of an optical switch network we may well have IP reachability through the separated control network but we don't want to use it. Regarding the second part of that question: we are not suggesting any techniques to be applied in PSC-only networks. The separated PSC control plane I alluded to earlier may be a useful idea, but it merits separate treatment and is beyond the scope of this section IMHO. -Ashok > > thanks, > - dimitri. > > Ashok Narayanan wrote: > > >Ben, > > > >Thanks for the comment. We'll try to clarify this in the next > >version. > > > >-Ashok > > > >On Tue, Mar 08, 2005 at 01:14:08PM -0000, > >benjamin.niven-jenkins@bt.com wrote: > > > >>Ashok, > >> > >>Thanks for the explanation. If I understand correctly what you are > >>saying is that the best current practice is to use an OOB control > >>plane for the non-PSC layer networks and an in-band control plane > >>for the PSC layer networks. So one must avoid using the control > >>plane network (of a non-PSC layer network) for the transfer of data > >>(or control) plane packets from the PSC layer network's control & > >>data planes. Fine, I agree that is the BCP, but I don't believe > >>the current draft articulates that intent very well and section 7.4 > >>probably needs expanding (IMO one or two paragraphs is probably not > >>enough to discuss/address/detail OOB Vs in-band properly and > >>unambiguously), for example it is not IMO clear from the current > >>text that you are talking about 2 separate control plane networks - > >>one OOB (for non-PSC layer networks/nodes) and one inband (for PSC > >>layer networks/nodes). > >> > >>Thanks Ben > >> > >> > >>>-----Original Message----- From: Ashok Narayanan > >>>[mailto:ashokn@cisco.com] Sent: 08 March 2005 12:59 To: > >>>Niven-jenkins,B,Ben,XDE73 R Cc: ccamp@ops.ietf.org Subject: Re: > >>>Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt > >>> > >>> > >>> > >>>>I am trying to understand section 7.4 (Separation of > >>> > >>>Control and Data Plane Traffic) of > >>>draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > >>> > >>>>The draft states: "PSC-capable nodes implementing an OOB > >>>>control plane (perhaps to communicate with an optical switch) > >>>>MUST NOT use the OOB control plane for data traffic. For > >>>>example, in the case of MPLS service running on top of a GMPLS > >>>>LSP, if the peer PSC device is reachable via both the control > >>>>plane and the data plane, control protocols such as LDP MUST > >>>>NOT form adjacencies over the control plane interfaces. This > >>>>may be provided by a combination of implementation features and > >>>>deployment guidelines." > >>>> > >>>>So, if the control plane is OOB why must control protocols > >>>>(such as LDP) NOT form adjacencies over the control plane > >>>>interfaces? This implies that LDP (for e.g.) MUST form its > >>>>adjacencies over the data plane interfaces and therefore LDP is > >>>>not running OOB (and therefore the control plane is not > >>>>entirely OOB). > >>>> > >>> > >>>That's an interesting question. The draft focuses on GMPLS/TE > >>>deployments and the use of an out-of-band control channel as a > >>>matter of necessity (i.e. because optical switches are not > >>>capable of handling in-band control traffic). Consider the > >>>general deployment of a core of optical switches surrounded by > >>>GMPLS/TE routers at the edge. From the perspective of this > >>>network (optical switches, edge routers, and the links in > >>>between), that statement translates to: > >>> > >>>_ The GMPLS/TE control plane between the edge routers and the > >>>optical switches in the core is entirely out-of-band > >>> > >>>- All other protocols between the edge routers MUST be entirely > >>>in-band. > >>> > >>>The control plane network may well be a series of point-to-point > >>>GRE tunnels overlaid on some other low-bandwidth network > >>>(actually this is what the draft recommends). Ordinarily one > >>>would establish a GRE tunnel between each pair of neighbors so > >>>they can talk to each other. But this means that signalling > >>>messages going from edge router to edge router actually have to > >>>be routed through the control planes of intermediate switches. > >>>The two alternatives to avoid this (to create a full mesh of GRE > >>>tunnels - at least between all the edge routers - or to not use > >>>GRE at all if the control plane is switched Ethernet, and > >>>therefore to essentially permit a full mesh of OSPF peers) are > >>>not really palatable (and in the case of SDCC, not usable). The > >>>optical switches in the core should not be in the business of > >>>routing packets. Sometimes they have to (e.g. Notify messages), > >>>but they are not designed for this purpose and should not be > >>>deployed as such. > >>> > >>>And practically speaking the control network is expected to be a > >>>low-bandwidth network that can "just get the job done". A single > >>>10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle > >>>the control traffic for a GMPLS/TE network, but will probably > >>>fail if we want to use it to peer LDP or BGP for 10,000 > >>>prefixes/labels between the edge routers. > >>> > >>>The best current practice is therefore to use the low-bandwidth > >>>control network between routers and switches for GMPLS/TE > >>>signaling (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical > >>>TE LSPs signalled between edge routers to do other L3 protocols > >>>between them. > >>> > >>>The issue of a separated control plane between PSC edge routers > >>>for different L3 protocols for administrative reasons is an > >>>interesting one. Nothing precludes you from creating multiple > >>>parallel LSPs between edge routers and using one of them to carry > >>>control traffic between the two edge routers on behalf of all the > >>>others; that would still satisfy this requirement. Alternatively, > >>>one could engineer a more beefy control plane network so that it > >>>can in fact carry all the control plane traffic (BGP, LDP etc.) > >>>but that is not the BCP today based on available implementations. > >>> > >>> > >>>-Ashok > >>> > >>>On Tue, Mar 08, 2005 at 10:33:54AM -0000, > >>>benjamin.niven-jenkins@bt.com wrote: > >>> > >>>>Colleagues, > >>>> > >>>>I am trying to understand section 7.4 (Separation of > >>> > >>>Control and Data Plane Traffic) of > >>>draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > >>> > >>>>The draft states: "PSC-capable nodes implementing an OOB > >>>>control plane > >>> > >>>(perhaps to communicate with an optical switch) MUST NOT use the > >>>OOB control plane for data traffic. For example, in the case of > >>>MPLS service running on top of a GMPLS LSP, if the peer PSC > >>>device is reachable via both the control plane and the data > >>>plane, control protocols such as LDP MUST NOT form adjacencies > >>>over the control plane interfaces. This may be provided by a > >>>combination of implementation features and deployment > >>>guidelines." > >>> > >>>>So, if the control plane is OOB why must control protocols > >>> > >>>(such as LDP) NOT form adjacencies over the control plane > >>>interfaces? This implies that LDP (for e.g.) MUST form its > >>>adjacencies over the data plane interfaces and therefore LDP is > >>>not running OOB (and therefore the control plane is not entirely > >>>OOB). > >>> > >>>>Thanks Ben > >>>> > >>>> > >>>>-- Ben Niven-Jenkins Networking Specialist, BT Exact > >>>> > >>>>e-mail: benjamin.niven-jenkins@bt.com tel: +44(0) 1473 648225 > >>>>mob: +44(0) 7918 077205 > >>>> > >>>>pp34/161 B81 Callisto House, Adastral Park, Martlesham, > >>> > >>>Ipswich IP5 3RE, UK > >>> > >>>>BT Exact is a trademark of British Telecommunications plc > >>>>Registered office: 81 Newgate Street London EC1A 7AJ Registered > >>>>in England no. 1800000 > >>>> > >>>>This electronic message contains information from British > >>> > >>>Telecommunications which may be privileged or confidential. The > >>>information is intended to be for the use of the individual(s) or > >>>the entity named above. If you are not the intended recipient be > >>>aware that any disclosure, copying, distribution or use of the > >>>contents of this information is prohibited. If you have received > >>>this electronic message in error, please notify us by telephone > >>>or email (to the numbers or address above) immediately. > >>> > >>>>Activity and use of the British Telecommunications plc > >>> > >>>email system is monitored to secure its effective operation and > >>>for other lawful business purposes. Communications using this > >>>system will also be monitored and may be recorded to secure > >>>effective operation and for other lawful business purposes. > >>> > >>>-- > >>> > >>> > >>> > >>>--- Asok the Intern ---------------------------------------- > >>>Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass > >>>Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 > >>>(Attn: Ashok Narayanan) > >>> > > > > -- --- Asok the Intern ---------------------------------------- Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Mar 2005 14:17:27 +0000 Message-ID: <01b601c523e9$0152c180$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Date: Tue, 8 Mar 2005 14:12:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Ben summarized... > Thanks for the explanation. If I understand correctly what you are > saying is that the best current practice is to use an OOB control plane > for the non-PSC layer networks and an in-band control plane for the > PSC layer networks. If that is the intention of the authors of this draft, they will have to fight me :-) I do not see why an in-band control channel for a PSC network would be made a RECOMMEND, SHOULD or MUST. > So one must avoid using the control plane network (of a non-PSC > layer network) for the transfer of data (or control) plane packets from > the PSC layer network's control & data planes. Yes. But more precisely, one must avoid using the control channels for data traffic. Even in-band control channel may use a different address space, and those addresses must not be used for data. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Mar 2005 13:56:07 +0000 Message-ID: <422DAEF5.6070803@psg.com> Date: Tue, 08 Mar 2005 14:56:05 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 MIME-Version: 1.0 To: Ashok Narayanan CC: benjamin.niven-jenkins@bt.com, ccamp@ops.ietf.org Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ashok - this section is indeed to be clarified 1. for non-PSC it should distinguish the logical from the physical control channel separation with respect to the data plane channels, i do not see for instance why DCC channels could not be used to exchange control plane traffic and still keep a logical separation 2. for PSC - why is there something different in terms of "practice" than what is currently used in MPLS networks ? or 3. do you assume that the interconnection of a PSC with non-PSC network (both driven by GMPLS) could indeed introduce change from the current practices operators used to use for their packet networks ? that in case could be further applied to PSC-only networks ? thanks, - dimitri. Ashok Narayanan wrote: > Ben, > > Thanks for the comment. We'll try to clarify this in the next > version. > > -Ashok > > On Tue, Mar 08, 2005 at 01:14:08PM -0000, > benjamin.niven-jenkins@bt.com wrote: > >> Ashok, >> >> Thanks for the explanation. If I understand correctly what you are >> saying is that the best current practice is to use an OOB control >> plane for the non-PSC layer networks and an in-band control plane >> for the PSC layer networks. So one must avoid using the control >> plane network (of a non-PSC layer network) for the transfer of data >> (or control) plane packets from the PSC layer network's control & >> data planes. Fine, I agree that is the BCP, but I don't believe >> the current draft articulates that intent very well and section 7.4 >> probably needs expanding (IMO one or two paragraphs is probably not >> enough to discuss/address/detail OOB Vs in-band properly and >> unambiguously), for example it is not IMO clear from the current >> text that you are talking about 2 separate control plane networks - >> one OOB (for non-PSC layer networks/nodes) and one inband (for PSC >> layer networks/nodes). >> >> Thanks Ben >> >> >>> -----Original Message----- From: Ashok Narayanan >>> [mailto:ashokn@cisco.com] Sent: 08 March 2005 12:59 To: >>> Niven-jenkins,B,Ben,XDE73 R Cc: ccamp@ops.ietf.org Subject: Re: >>> Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt >>> >>> >>> >>>> I am trying to understand section 7.4 (Separation of >>> >>> Control and Data Plane Traffic) of >>> draft-shiomoto-ccamp-gmpls-addressing-00.txt better. >>> >>>> The draft states: "PSC-capable nodes implementing an OOB >>>> control plane (perhaps to communicate with an optical switch) >>>> MUST NOT use the OOB control plane for data traffic. For >>>> example, in the case of MPLS service running on top of a GMPLS >>>> LSP, if the peer PSC device is reachable via both the control >>>> plane and the data plane, control protocols such as LDP MUST >>>> NOT form adjacencies over the control plane interfaces. This >>>> may be provided by a combination of implementation features and >>>> deployment guidelines." >>>> >>>> So, if the control plane is OOB why must control protocols >>>> (such as LDP) NOT form adjacencies over the control plane >>>> interfaces? This implies that LDP (for e.g.) MUST form its >>>> adjacencies over the data plane interfaces and therefore LDP is >>>> not running OOB (and therefore the control plane is not >>>> entirely OOB). >>>> >>> >>> That's an interesting question. The draft focuses on GMPLS/TE >>> deployments and the use of an out-of-band control channel as a >>> matter of necessity (i.e. because optical switches are not >>> capable of handling in-band control traffic). Consider the >>> general deployment of a core of optical switches surrounded by >>> GMPLS/TE routers at the edge. From the perspective of this >>> network (optical switches, edge routers, and the links in >>> between), that statement translates to: >>> >>> _ The GMPLS/TE control plane between the edge routers and the >>> optical switches in the core is entirely out-of-band >>> >>> - All other protocols between the edge routers MUST be entirely >>> in-band. >>> >>> The control plane network may well be a series of point-to-point >>> GRE tunnels overlaid on some other low-bandwidth network >>> (actually this is what the draft recommends). Ordinarily one >>> would establish a GRE tunnel between each pair of neighbors so >>> they can talk to each other. But this means that signalling >>> messages going from edge router to edge router actually have to >>> be routed through the control planes of intermediate switches. >>> The two alternatives to avoid this (to create a full mesh of GRE >>> tunnels - at least between all the edge routers - or to not use >>> GRE at all if the control plane is switched Ethernet, and >>> therefore to essentially permit a full mesh of OSPF peers) are >>> not really palatable (and in the case of SDCC, not usable). The >>> optical switches in the core should not be in the business of >>> routing packets. Sometimes they have to (e.g. Notify messages), >>> but they are not designed for this purpose and should not be >>> deployed as such. >>> >>> And practically speaking the control network is expected to be a >>> low-bandwidth network that can "just get the job done". A single >>> 10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle >>> the control traffic for a GMPLS/TE network, but will probably >>> fail if we want to use it to peer LDP or BGP for 10,000 >>> prefixes/labels between the edge routers. >>> >>> The best current practice is therefore to use the low-bandwidth >>> control network between routers and switches for GMPLS/TE >>> signaling (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical >>> TE LSPs signalled between edge routers to do other L3 protocols >>> between them. >>> >>> The issue of a separated control plane between PSC edge routers >>> for different L3 protocols for administrative reasons is an >>> interesting one. Nothing precludes you from creating multiple >>> parallel LSPs between edge routers and using one of them to carry >>> control traffic between the two edge routers on behalf of all the >>> others; that would still satisfy this requirement. Alternatively, >>> one could engineer a more beefy control plane network so that it >>> can in fact carry all the control plane traffic (BGP, LDP etc.) >>> but that is not the BCP today based on available implementations. >>> >>> >>> -Ashok >>> >>> On Tue, Mar 08, 2005 at 10:33:54AM -0000, >>> benjamin.niven-jenkins@bt.com wrote: >>> >>>> Colleagues, >>>> >>>> I am trying to understand section 7.4 (Separation of >>> >>> Control and Data Plane Traffic) of >>> draft-shiomoto-ccamp-gmpls-addressing-00.txt better. >>> >>>> The draft states: "PSC-capable nodes implementing an OOB >>>> control plane >>> >>> (perhaps to communicate with an optical switch) MUST NOT use the >>> OOB control plane for data traffic. For example, in the case of >>> MPLS service running on top of a GMPLS LSP, if the peer PSC >>> device is reachable via both the control plane and the data >>> plane, control protocols such as LDP MUST NOT form adjacencies >>> over the control plane interfaces. This may be provided by a >>> combination of implementation features and deployment >>> guidelines." >>> >>>> So, if the control plane is OOB why must control protocols >>> >>> (such as LDP) NOT form adjacencies over the control plane >>> interfaces? This implies that LDP (for e.g.) MUST form its >>> adjacencies over the data plane interfaces and therefore LDP is >>> not running OOB (and therefore the control plane is not entirely >>> OOB). >>> >>>> Thanks Ben >>>> >>>> >>>> -- Ben Niven-Jenkins Networking Specialist, BT Exact >>>> >>>> e-mail: benjamin.niven-jenkins@bt.com tel: +44(0) 1473 648225 >>>> mob: +44(0) 7918 077205 >>>> >>>> pp34/161 B81 Callisto House, Adastral Park, Martlesham, >>> >>> Ipswich IP5 3RE, UK >>> >>>> BT Exact is a trademark of British Telecommunications plc >>>> Registered office: 81 Newgate Street London EC1A 7AJ Registered >>>> in England no. 1800000 >>>> >>>> This electronic message contains information from British >>> >>> Telecommunications which may be privileged or confidential. The >>> information is intended to be for the use of the individual(s) or >>> the entity named above. If you are not the intended recipient be >>> aware that any disclosure, copying, distribution or use of the >>> contents of this information is prohibited. If you have received >>> this electronic message in error, please notify us by telephone >>> or email (to the numbers or address above) immediately. >>> >>>> Activity and use of the British Telecommunications plc >>> >>> email system is monitored to secure its effective operation and >>> for other lawful business purposes. Communications using this >>> system will also be monitored and may be recorded to secure >>> effective operation and for other lawful business purposes. >>> >>> -- >>> >>> >>> >>> --- Asok the Intern ---------------------------------------- >>> Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass >>> Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 >>> (Attn: Ashok Narayanan) >>> > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Mar 2005 13:55:29 +0000 From: "Rajiv Papneja" To: "'Ashok Narayanan'" , Cc: Subject: RE: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Date: Tue, 8 Mar 2005 08:54:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcUj39SDCZvsFny6SgaEx790Tq5i2wABSDfQ Message-Id: See below: -----Original Message----- From: Ashok Narayanan [mailto:ashokn@cisco.com] Sent: Tuesday, March 08, 2005 7:59 AM To: benjamin.niven-jenkins@bt.com Cc: ccamp@ops.ietf.org Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt > > I am trying to understand section 7.4 (Separation of Control and Data Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > > The draft states: > "PSC-capable nodes implementing an OOB control plane (perhaps to > communicate with an optical switch) MUST NOT use the OOB control > plane for data traffic. For example, in the case of MPLS service > running on top of a GMPLS LSP, if the peer PSC device is reachable > via both the control plane and the data plane, control protocols > such as LDP MUST NOT form adjacencies over the control plane > interfaces. This may be provided by a combination of implementation > features and deployment guidelines." > > So, if the control plane is OOB why must control protocols (such as > LDP) NOT form adjacencies over the control plane interfaces? This > implies that LDP (for e.g.) MUST form its adjacencies over the data > plane interfaces and therefore LDP is not running OOB (and therefore > the control plane is not entirely OOB). > That's an interesting question. The draft focuses on GMPLS/TE deployments and the use of an out-of-band control channel as a matter of necessity (i.e. because optical switches are not capable of handling in-band control traffic). Consider the general deployment of a core of optical switches surrounded by GMPLS/TE routers at the edge. From the perspective of this network (optical switches, edge routers, and the links in between), that statement translates to: _ The GMPLS/TE control plane between the edge routers and the optical switches in the core is entirely out-of-band - All other protocols between the edge routers MUST be entirely in-band. The control plane network may well be a series of point-to-point GRE tunnels overlaid on some other low-bandwidth network (actually this is what the draft recommends). Ordinarily one would establish a GRE tunnel between each pair of neighbors so they can talk to each other. But this means that signalling messages going from edge router to edge router actually have to be routed through the control planes of intermediate switches. The two alternatives to avoid this (to create a full mesh of GRE tunnels - at least between all the edge routers - or to not use GRE at all if the control plane is switched Ethernet, and therefore to essentially permit a full mesh of OSPF peers) are not really palatable (and in the case of SDCC, not usable). The optical switches in the core should not be in the business of routing packets. Sometimes they have to (e.g. Notify messages), but they are not designed for this purpose and should not be deployed as such. And practically speaking the control network is expected to be a low-bandwidth network that can "just get the job done". A single 10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle the control traffic for a GMPLS/TE network, but will probably fail if we want to use it to peer LDP or BGP for 10,000 prefixes/labels between the edge routers. [rp] Furthermore - If LDP adjacencies are formed over the control plane, and since the LDP forwarding is based on the IP routing and metrics, the PSC devices will try to forward the IP traffic on the interfaces with the lowest metric (control interface in this case), and since all the edge nodes in the GMPLS control plane are adjacent from control plane traffic perspective, one has to change the metrics of the control plane interface on the PSC devices to avoid the best path through the control plane (OOB). The best current practice is therefore to use the low-bandwidth control network between routers and switches for GMPLS/TE signaling (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical TE LSPs signalled between edge routers to do other L3 protocols between them. The issue of a separated control plane between PSC edge routers for different L3 protocols for administrative reasons is an interesting one. Nothing precludes you from creating multiple parallel LSPs between edge routers and using one of them to carry control traffic between the two edge routers on behalf of all the others; that would still satisfy this requirement. Alternatively, one could engineer a more beefy control plane network so that it can in fact carry all the control plane traffic (BGP, LDP etc.) but that is not the BCP today based on available implementations. -Ashok On Tue, Mar 08, 2005 at 10:33:54AM -0000, benjamin.niven-jenkins@bt.com wrote: > Colleagues, > > I am trying to understand section 7.4 (Separation of Control and Data Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > > The draft states: > "PSC-capable nodes implementing an OOB control plane (perhaps to communicate with an optical switch) MUST NOT use the OOB control plane for data traffic. For example, in the case of MPLS service running on top of a GMPLS LSP, if the peer PSC device is reachable via both the control plane and the data plane, control protocols such as LDP MUST NOT form adjacencies over the control plane interfaces. This may be provided by a combination of implementation features and deployment guidelines." > > So, if the control plane is OOB why must control protocols (such as LDP) NOT form adjacencies over the control plane interfaces? This implies that LDP (for e.g.) MUST form its adjacencies over the data plane interfaces and therefore LDP is not running OOB (and therefore the control plane is not entirely OOB). > > Thanks > Ben > > > -- > Ben Niven-Jenkins > Networking Specialist, BT Exact > > e-mail: benjamin.niven-jenkins@bt.com > tel: +44(0) 1473 648225 > mob: +44(0) 7918 077205 > > pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, UK > > BT Exact is a trademark of British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > > This electronic message contains information from British Telecommunications which may be privileged or confidential. The information is intended to be for the use of the individual(s) or the entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. > > Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. -- --- Asok the Intern ---------------------------------------- Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Mar 2005 13:21:35 +0000 Date: Tue, 8 Mar 2005 08:21:22 -0500 From: Ashok Narayanan To: benjamin.niven-jenkins@bt.com Cc: ccamp@ops.ietf.org Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Message-ID: <20050308132122.GB32112@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Ben, Thanks for the comment. We'll try to clarify this in the next version. -Ashok On Tue, Mar 08, 2005 at 01:14:08PM -0000, benjamin.niven-jenkins@bt.com wrote: > Ashok, > > Thanks for the explanation. If I understand correctly what you are saying is that the best current practice is to use an OOB control plane for the non-PSC layer networks and an in-band control plane for the PSC layer networks. So one must avoid using the control plane network (of a non-PSC layer network) for the transfer of data (or control) plane packets from the PSC layer network's control & data planes. Fine, I agree that is the BCP, but I don't believe the current draft articulates that intent very well and section 7.4 probably needs expanding (IMO one or two paragraphs is probably not enough to discuss/address/detail OOB Vs in-band properly and unambiguously), for example it is not IMO clear from the current text that you are talking about 2 separate control plane networks - one OOB (for non-PSC layer networks/nodes) and one inband (for PSC layer networks/nodes). > > Thanks > Ben > > > -----Original Message----- > > From: Ashok Narayanan [mailto:ashokn@cisco.com] > > Sent: 08 March 2005 12:59 > > To: Niven-jenkins,B,Ben,XDE73 R > > Cc: ccamp@ops.ietf.org > > Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt > > > > > > > > > > I am trying to understand section 7.4 (Separation of > > Control and Data Plane Traffic) of > > draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > > > > > > The draft states: > > > "PSC-capable nodes implementing an OOB control plane (perhaps to > > > communicate with an optical switch) MUST NOT use the OOB control > > > plane for data traffic. For example, in the case of MPLS service > > > running on top of a GMPLS LSP, if the peer PSC device is reachable > > > via both the control plane and the data plane, control protocols > > > such as LDP MUST NOT form adjacencies over the control plane > > > interfaces. This may be provided by a combination of implementation > > > features and deployment guidelines." > > > > > > So, if the control plane is OOB why must control protocols (such as > > > LDP) NOT form adjacencies over the control plane interfaces? This > > > implies that LDP (for e.g.) MUST form its adjacencies over the data > > > plane interfaces and therefore LDP is not running OOB (and therefore > > > the control plane is not entirely OOB). > > > > > > > That's an interesting question. The draft focuses on GMPLS/TE > > deployments and the use of an out-of-band control channel as a matter > > of necessity (i.e. because optical switches are not capable of > > handling in-band control traffic). Consider the general deployment of > > a core of optical switches surrounded by GMPLS/TE routers at the > > edge. From the perspective of this network (optical switches, edge > > routers, and the links in between), that statement translates to: > > > > _ The GMPLS/TE control plane between the edge routers and the optical > > switches in the core is entirely out-of-band > > > > - All other protocols between the edge routers MUST be > > entirely in-band. > > > > The control plane network may well be a series of point-to-point GRE > > tunnels overlaid on some other low-bandwidth network (actually this is > > what the draft recommends). Ordinarily one would establish a GRE > > tunnel between each pair of neighbors so they can talk to each other. > > But this means that signalling messages going from edge router to edge > > router actually have to be routed through the control planes of > > intermediate switches. The two alternatives to avoid this (to create a > > full mesh of GRE tunnels - at least between all the edge routers - or > > to not use GRE at all if the control plane is switched Ethernet, and > > therefore to essentially permit a full mesh of OSPF peers) are not > > really palatable (and in the case of SDCC, not usable). The optical > > switches in the core should not be in the business of routing > > packets. Sometimes they have to (e.g. Notify messages), but they are > > not designed for this purpose and should not be deployed as such. > > > > And practically speaking the control network is expected to be a > > low-bandwidth network that can "just get the job done". A single > > 10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle the > > control traffic for a GMPLS/TE network, but will probably fail if we > > want to use it to peer LDP or BGP for 10,000 prefixes/labels between > > the edge routers. > > > > The best current practice is therefore to use the low-bandwidth > > control network between routers and switches for GMPLS/TE signaling > > (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical TE LSPs > > signalled between edge routers to do other L3 protocols between them. > > > > The issue of a separated control plane between PSC edge routers for > > different L3 protocols for administrative reasons is an interesting > > one. Nothing precludes you from creating multiple parallel LSPs > > between edge routers and using one of them to carry control traffic > > between the two edge routers on behalf of all the others; that would > > still satisfy this requirement. Alternatively, one could engineer a > > more beefy control plane network so that it can in fact carry all the > > control plane traffic (BGP, LDP etc.) but that is not the BCP today > > based on available implementations. > > > > -Ashok > > > > On Tue, Mar 08, 2005 at 10:33:54AM -0000, > > benjamin.niven-jenkins@bt.com wrote: > > > Colleagues, > > > > > > I am trying to understand section 7.4 (Separation of > > Control and Data Plane Traffic) of > > draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > > > > > > The draft states: > > > "PSC-capable nodes implementing an OOB control plane > > (perhaps to communicate with an optical switch) MUST NOT use > > the OOB control plane for data traffic. For example, in the > > case of MPLS service running on top of a GMPLS LSP, if the > > peer PSC device is reachable via both the control plane and > > the data plane, control protocols such as LDP MUST NOT form > > adjacencies over the control plane interfaces. This may be > > provided by a combination of implementation features and > > deployment guidelines." > > > > > > So, if the control plane is OOB why must control protocols > > (such as LDP) NOT form adjacencies over the control plane > > interfaces? This implies that LDP (for e.g.) MUST form its > > adjacencies over the data plane interfaces and therefore LDP > > is not running OOB (and therefore the control plane is not > > entirely OOB). > > > > > > Thanks > > > Ben > > > > > > > > > -- > > > Ben Niven-Jenkins > > > Networking Specialist, BT Exact > > > > > > e-mail: benjamin.niven-jenkins@bt.com > > > tel: +44(0) 1473 648225 > > > mob: +44(0) 7918 077205 > > > > > > pp34/161 B81 Callisto House, Adastral Park, Martlesham, > > Ipswich IP5 3RE, UK > > > > > > BT Exact is a trademark of British Telecommunications plc > > > Registered office: 81 Newgate Street London EC1A 7AJ > > > Registered in England no. 1800000 > > > > > > This electronic message contains information from British > > Telecommunications which may be privileged or confidential. > > The information is intended to be for the use of the > > individual(s) or the entity named above. If you are not the > > intended recipient be aware that any disclosure, copying, > > distribution or use of the contents of this information is > > prohibited. If you have received this electronic message in > > error, please notify us by telephone or email (to the numbers > > or address above) immediately. > > > > > > Activity and use of the British Telecommunications plc > > email system is monitored to secure its effective operation > > and for other lawful business purposes. Communications using > > this system will also be monitored and may be recorded to > > secure effective operation and for other lawful business purposes. > > > > -- > > > > > > > > --- Asok the Intern ---------------------------------------- > > Ashok Narayanan > > IOS Network Protocols, Cisco Systems > > 1414 Mass Ave, Boxborough MA 01719 > > Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) > > -- --- Asok the Intern ---------------------------------------- Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Mar 2005 13:19:38 +0000 Subject: [WARNING: A/V UNSCANNABLE] Re: Agenda and slides on line Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/mixed; boundary=Apple-Mail-2-984250060 Message-Id: <2e7a83c89f2b8b8b4c498eb31a1be32c@cisco.com> Cc: From: JP Vasseur Date: Tue, 8 Mar 2005 07:19:12 -0600 To: "Adrian Farrel" --Apple-Mail-2-984250060 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Mar 8, 2005, at 2:31 AM, Adrian Farrel wrote: > Agenda and slides on line at http://www.olddog.co.uk/62/ccamp.htm > > All there except... > > Status and plans for CCAMP re-charter > Alex Zinin. No slides received. > > draft-vasseur-ccamp-automesh-00.txt > JP Vasseur. Slides received but corrupt > => --Apple-Mail-2-984250060 Content-Transfer-Encoding: base64 Content-Type: application/vnd.ms-powerpoint; x-mac-type=534C4438; x-unix-mode=0644; x-mac-creator=50505433; name="IETF-62-draft-vasseur-ccamp-automesh-00.ppt" Content-Disposition: attachment; filename=IETF-62-draft-vasseur-ccamp-automesh-00.ppt 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAPwAAAAAAAAAA EAAAQgAAAAEAAAD+////AAAAAEAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////PQAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAD+/////v///zsAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAA/v///zwAAAA+AAAA/v////7///////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////wBS AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAACAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAAA2tC6nI8UB IwAAAEAGAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAA2D8AAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAABELAAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAFAAAAAAAADwDo Az4kAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAAkE vAEAAAAACgQEAAAAVAAAAA8A1w84AAAAAADTDwQAAAA8AAAAAAC6DyQAAABqAHYAYQBzAHMAZQB1 AHIAQABjAGkAcwBjAG8ALgBjAG8AbQAPANcPTgAAAAAA0w8EAAAAPwAAAAAAug86AAAAeQBhAHMA dQBrAGEAdwBhAC4AcwBlAGkAcwBoAG8AQABsAGEAYgAuAG4AdAB0AC4AYwBvAC4AagBwAA8A1w9Y AAAAAADTDwQAAABEAAAAAAC6D0QAAABqAGUAYQBuAGwAbwB1AGkAcwAuAGwAZQByAG8AdQB4AEAA ZgByAGEAbgBjAGUAdABlAGwAZQBjAG8AbQAuAGMAbwBtAA8A1w80AAAAAADTDwQAAABGAAAAAAC6 DyAAAABwAG0AYQBiAGUAeQBAAHEAdwBlAHMAdAAuAGMAbwBtAA8A1w82AAAAAADTDwQAAABHAAAA AAC6DyIAAABwAHAAcwBlAG4AYQBrAEAAYwBpAHMAYwBvAC4AYwBvAG0ADwDXDzgAAAAAANMPBAAA AEgAAAAAALoPJAAAAHMAcAByAGUAdgBpAGQAaQBAAGMAaQBzAGMAbwAuAGMAbwBtAA8A8gP6AQAA LwDIDwwAAAAwANIPBAAAAAEAAAAPANUHMAEAAAAAtw9EAAAAQQByAGkAYQBsAAAAbgBnAHMAAABv AGQAZQAgAP+/CNz/vzDYAAAQAAkBEEn/vwjc/78w2AEAF7ZAAVxQVpFsIwAABAAQALcPRAAAAEEA cgBpAGEAbAAgAFUAbgBpAGMAbwBkAGUAIABNAFMAAAAw2AAAEAAJARBJ/78I3P+/MNgBABe2QAFc UFaRbCOAAAYiIAC3D0QAAABXAGkAbgBnAGQAaQBuAGcAcwAAAG8AZABlACAATQBTAAAAMNgAABAA CQEQSf+/CNz/vzDYAQAXtkABXFBWkWwjAgAEADAAtw9EAAAAVABpAG0AZQBzAAAAbgBnAHMAAABv AGQAZQAgAE0AUwAAADDYAAAQAAkBEEn/vwjc/78w2AEAF7ZAAVxQVpFsIwAABAAAAKQPCgAAAIAA YAAAAP////8AAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD/ /T8AAAAiIAAAZAAAAAD/AABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA////////EgAAAAAB AAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsE4AAA AA8AAPDYAAAAAAAG8IAAAAACPAAADwAAABUAAAAFAAAAAQAAAAcAAAADAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAFAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAADAAAAAAAAAAEAAAABAAAAAkAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAACAAAABAAAAIMAC/AwAAAAgQEEAAAIgwEAAAAIhkEAAAAA vwEQABAAwAEBAAAIxUEAAAAA/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDw DxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQBxsQAAAfABQEHAAAAAAAFQQUAAAA upOw9gDKmjutB5THAMqaOwEBAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABnAAAAZAAAAGcA AABkAAAAALBuAQAAAAAAAAAAUNj/vwAAAACwDg8BkP7//5D///8BAAAAcAD7AwgAAAAAAAAAcAgA AHAA+wMIAAAAAQAAAEALAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAALDY/78CAAAA AKUGAQAAAABnAAAAAMqaOwAAAAAAAAAAAAEAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAf AAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAALDY/78CAAAAAKUGAQAAAAAUAAAAAMqaOwAA AAAAAAAAAAEAAA8AiBPcDgAADwCKE7gAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTmAAA AA8Asw+QAAAAEACvDwgAAAAAAQAABQAAAAAAsQ8oAAAAAAAABAAAAAAAAAAEAQAAAAAAAAQCAAAA AAAABAMAAAAAAAAEBAAAABAArw8IAAAACQEAAAEAAAAAALEPOAAAAAAAAAQAAAAAAAAABAEAAAAA AAAEAgAAAAAAAAQDAAAAAAAABAQAAAAAAAAEBQAAAAAAAAQGAAAADwCKE6QBAAAAALoPDgAAAF8A XwBfAFAAUABUADkAAACLE4YBAAAPAK4PfgEAABAArw8IAAAAAAEAAAUAAAAAAKwPUAAAAAAAAAAA ABAAAAAAAAAAAAAAAAAAAAAQAAEAAAAAAAAAAAAAAAAAEAACAAAAAAAAAAAAAAAAABAAAwAAAAAA AAAAAAAAAAAQAAQAAAAAAAAAEACvDwgAAAAIAQAAAQAAAAAArA80AAAAAAAAAgAAAAAAAAAAAAAA AAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAArw8IAAAACQEAAAEAAAAAAKwP dAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAQAAEAAAAAAAAAAAAAAAAAEAACAAAAAAAAAAAAAAAA ABAAAwAAAAAAAAAAAAAAAAAQAAQAAAAAAAAAAACAAv//AAAAABAABQAAAAAAAAAAAAAAAAAQAAYA AAAAAAAAEACvDwgAAAADAQAAAQAAAAAArA8mAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAPAIoTaAAAAAAAug8UAAAAXwBfAF8AUABQAFQAMgAwADAAMQAAAIsTRAAAAA8A iBc8AAAAAACJFzQAAAAAAAAAAAAAAAAAAABYAgAAAAEBAAEBAAABAQEAAQAAAAAAAAAI3AAAAAAA AAAAAACAAgHgDwCKE/gLAAAAALoPFgAAAF8AXwBfAFAAUABUAE0AYQBjADEAMQAAAIsT0gsAAEAA GhBmBQAABQAAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgA AAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAA AAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEA cgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBn AHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEA AAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAA AAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAA AQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAA AAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgA eQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAA AAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAA AQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEF AAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAA AAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAA AAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAA AAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEB AAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQA AABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAA ACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAAB BwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAg AAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAA AAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAA AAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4A bwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAA AAAAAAAEAAAADgAJABEAAAAaAAEAABwQFAEAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAA AAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAA AQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAA BAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBv AHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAA AAAAAAQAAAAOAAkAEQAAABoAAQ8AGxBABQAAEACvDwgAAAAAAQAABQAAAAAAGRDEAQAAAAAAAAAA AAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAA AAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAAB AAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAA AAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBhAHAAaAB5 AAAAAAEGAAAABAAUAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAAAAAInAAA AAAAAAIAAACcAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAHgAAAAHAAAABAAAAAAAAAEA AAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAA AAEGAAAABAAUAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAQAK8PCAAAAAkB AAABAAAAAAAZEEwDAAAAAAAAAAAAAAAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAA AQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAAB AAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAA AAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBw AGUAIABUAHkAcABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQA AAAOAAkAEQAAABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAAB AAAA6AAAAAgAAAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMA AAABAAAAAAAAAQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAA AAoAQQByAGkAYQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkA cABvAGcAcgBhAHAAaAB5AAAAAAEGAAAABAAUAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAA ABoAAQAAAAgMAQAAAAAAAgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgA AAAEAAAAAAAAAQAAAAABAAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAA AQQAAAABAAAAAAAAAQUAAABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkA YQBsAAAAAAAIAAAAAAAAAAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAGcAcgBh AHAAaAB5AAAAAAEGAAAABAAYAAAAAAEHAAAABgAAAAAAAAAAAAQAAAAOAAkAEQAAABoAAQAAAAAA AAAAPwDZDwwAAAAAANoPBAAAAAAAJQAPAPAP9Q4AAAAA8wMUAAAAAwAAAAAAAAACAAAAAAEAAAAA AAAAAJ8PBAAAAAYAAAAAAKgPsQAAAFJvdXRpbmcgZXh0ZW5zaW9ucyBmb3IgZGlzY292ZXJ5IG9m IE11bHRpcHJvdG9jb2wgKE1QTFMpIExhYmVsIFN3aXRjaCALICAgICAgICAgICAgICAgUm91dGVy IChMU1IpIFRyYWZmaWMgRW5naW5lZXJpbmcgKFRFKSBtZXNoIG1lbWJlcnNoaXAgCwtkcmFmdC12 YXNzZXVyLWNjYW1wLWF1dG9tZXNoLTAwLnR4dAAAoQ86AAAAsgAAAAAAAAAAAIsAAAABAAIAAQAc AAEAAAAABAAAAAQCAAAAAAgCAAAIIAAkAAAAAAwDAAAMAQAYABAAnw8EAAAABQAAAAAAqA9lAQAA SmVhbi1QaGlsaXBwZSBWYXNzZXVyIChqdmFzc2V1ckBjaXNjby5jb20pDSAgICAgICAgICAgICAg ICAgICAgICAgICBKZWFuIExvdWlzIExlIFJvdXggKGplYW5sb3Vpcy5sZXJvdXhAZnJhbmNldGVs ZWNvbS5jb20pDSAgICAgICAgICAgICAgICAgICAgICAgICBQZXRlciBQc2VuYWsgKHBwc2VuYWtA Y2lzY28uY29tKQ0gICAgICAgICAgICAgICAgICAgICAgICAgU3RlZmFubyBQcmV2aWRpIChzcHJl dmlkaUBjaXNjby5jb20pIA0gICAgICAgIFNlaXNobyBZYXN1a2F3YSAoeWFzdWthd2Euc2Vpc2hv QGxhYi5udHQuY28uanApIA0gICAgICAgICAgICAgICAgICAgICAgICAgUGF1bCBNYWJleSAocG1h YmV5QHF3ZXN0LmNvbSkNAAChD3oAAAArAAAAAAAAEAAAUADKAAAAAAAAGAAAAABQADkAAAAAAAAQ AABQADcAAAAAAAAYAAAAAFAAAQAAAAAAABAAAFAAfAAAAAAAAgAUABkAAAAABAIAAAQUACEAAAAA CAIAAAgUAD0AAAAADAIAAAwUAHMAAAAAEAIAABAUAAAAqg86AQAAFwAAAAAAAAASAAAAAAAAAAEA AAAAAAAAGgAAAAEAAAAAABQAAAAAAAAACQAAAAEAAAABAAEAAAAAAAAAFAAAAAEAAAABAAQAAAAA AAAAAQAAAAAAAAAaAAAAAQAAAAAABgAAAAAAAAAHAAAAAQAAAAEAAQAAAAAAAAARAAAAAAAAAAEA AAAAAAAAGgAAAAEAAAAAABEAAAAAAAAAEgAAAAAAAAALAAAAAAAAAAcAAAABAAAAAQAKAAAAAAAA AAgAAAABAAAAAQABAAAAAAAAAAoAAAABAAAAAQABAAAAAAAAAAMAAAABAAAAAQAEAAAAAAAAAAIA AAABAAAAAQABAAAAAAAAABsAAAABAAAAAAAFAAAAAAAAAAYAAAABAAAAAQABAAAAAAAAABAAAAAA AAAAAwAAAAAAAAAPAPIPGAAAAAAA8w8QAAAAAAAAADwAAAAEAAAACAAA8wAA3w8IAAAAFwAAACkA AAAPAPIPGAAAAAAA8w8QAAAAAAAAAEQAAAAEAAAACAAA8wAA3w8IAAAAWAAAAHoAAAAPAPIPGAAA AAAA8w8QAAAAAAAAAEcAAAAEAAAACAAA8wAA3w8IAAAAowAAALQAAAAPAPIPGAAAAAAA8w8QAAAA AAAAAEgAAAAEAAAACAAA8wAA3w8IAAAA4AAAAPIAAAAPAPIPGAAAAAAA8w8QAAAAAAAAAD8AAAAE AAAACAAA8wAA3w8IAAAADgEAACsBAAAPAPIPGAAAAAAA8w8QAAAAAAAAAEYAAAAEAAAACAAA8wAA 3w8IAAAAUwEAAGMBAAAAAPMDFAAAAAsAAAAEAAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACo DwoAAABCYWNrZ3JvdW5kEACfDwQAAAABAAAAAACoD1wBAAANZHJhZnQtdmFzc2V1ci1jY2FtcC1y b3V0ZXItaW5mby0wMC50eHQgKENDQU1QKQ0gICAgIERlc2NyaWJlcyBleHRlbnNpb25zIHRvIE1Q TFMgVHJhZmZpYyBFbmdpbmVlcmluZyByb3V0aW5nIGZvciB0aGUgYWR2ZXJ0aXNlbWVudCBvZiBU cmFmZmljIEVuZ2luZWVyaW5nIFJvdXRlciBJbmZvcm1hdGlvbiBhbmQgY2FwYWJpbGl0aWVzLiBU aGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIGZ1bmN0aW9uYWwgZGVzY3JpcHRpb24gb2YgdGhlc2Ug ZXh0ZW5zaW9ucyB3aGVyZWFzIHByb3RvY29sIHNwZWNpZmljIGZvcm1hdHMgYW5kIG1lY2hhbmlz bXMgYXJlIGRlc2NyaWJlZCBpbiBzZXBhcmF0ZSBkb2N1bWVudHMuIAkAAKEPbgAAAAEAAAABAJMQ AAACAOAAAgBQAC8AAAAAALIQAAADAOAAAgAAAAABUAAtAQAAAAAhEAAAAAAAAAABUAABAAAAAAAC ABIANAAAAAAEggAABAIAFAAmAQAAAAiCAAAIAgAQAAIAAAAADIIAAAwCABQAAACqDxwAAAABAAAA AQAAAAAAWQEAAAAAAAADAAAAAQAAAAAAAADzAxQAAAAPAAAAAAAAAAIAAAAJAQAAAAAAAAAAnw8E AAAAAAAAAAAAqA8WAAAAUXVpY2sgb3ZlcnZpZXcvc3VtbWFyeRAAnw8EAAAAAQAAAAAAqA8cAwAA VGhlcmUgYXJlIG5vdyB0d28gZHJhZnRzOg1kcmFmdC12YXNzZXVyLWNjYW1wLWF1dG8tbWVzaC0w MC50eHQNZHJhZnQtdmFzc2V1ci1jY2FtcC10ZS1ub2RlLWNhcC0wMC50eHQNVGhlIFBDRSBkaXNj b3ZlcnkgYXNwZWN0cyB3aWxsIGJlIGRpc2N1c3NlZCBpbiB0aGUgUENFIFdHDQ1UaGUgc2V0IHVw IG9mIGEgZnVsbCBtZXNoIG9mIE1QTFMgVEUgTFNQcyBhbW9uZyBhIHNldCBvZiBMYWJlbCBTd2l0 Y2ggUm91dGVyIChMU1IpIGlzIGNvbW1vbiBkZXBsb3ltZW50IHNjZW5hcmlvIG9mIE1QTFMgVHJh ZmZpYyBFbmdpbmVlcmluZyBlaXRoZXIgZm9yIGJhbmR3aWR0aCBvcHRpbWl6YXRpb24sIGJhbmR3 aWR0aCBndWFyYW50ZWVzIG9yIGZhc3QgcmVyb3V0aW5nIHdpdGggTVBMUyBGYXN0IFJlcm91dGUu IFN1Y2ggZGVwbG95bWVudCByZXF1aXJlcyB0aGUgY29uZmlndXJhdGlvbiBvZiBwb3RlbnRpYWxs eSBhIGxhcmdlIG51bWJlciBvZiBURSBMU1BzIChvbiB0aGUgb3JkZXIgb2YgdGhlIHNxdWFyZSBv ZiB0aGUgbnVtYmVyIExTUnMpLiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBJR1AgICAgICAgICAg KE9TUEYgYW5kIElTLUlTKSB0cmFmZmljIGVuZ2luZWVyaW5nIGV4dGVuc2lvbnMgc28gYXMgdG8g cHJvdmlkZSBhbiBhdXRvbWF0aWMgZGlzY292ZXJ5IG9mIHRoZSBzZXQgb2YgTFNScyBtZW1iZXJz IG9mIGEgbWVzaCwgbGVhZGluZyB0byBhbiBhdXRvbWF0aWMgbWVjaGFuaXNtIHRvIHNldCB1cCBU RSBMU1AgbWVzaChlcykgKGFsc28gcmVmZXJyZWQgdG8gYXMgYSBURSBtZXNoLWdyb3VwKS4gDQAA oQ+MAAAAGgAAAAAAABAAAFoAhwAAAAEAABAAAFoAewIAAAAAshAAAAMAIiADAAAAAAFaAAEAAAAA AAAQAABaABoAAAAAAAIAGAAlAAAAAAQCAAAEFAAnAAAAAAgCAAAIFAA5AAAAAAwCAAAMFAACAAAA ABACAAAQFAB7AgAAAhQCAAIUGAABAAAAABgCAAAYGAAAAKoPqgAAAGUAAAAAAAAAAQAAAAEAAAAA AIAAAAAAAAAAAQAAAAEAAAAAADoAAAAAAAAAAQAAAAEAAAAAAEMAAAAAAAAAAQAAAAEAAAAAAEIA AAAAAAAAAQAAAAEAAAAAAEIAAAAAAAAAAQAAAAEAAAAAAEQAAAAAAAAAAQAAAAEAAAAAAEwAAAAA AAAAAQAAAAEAAAAAAHIAAAAAAAAAAgAAAAEAAAABACsAAAAAAAAAAADzAxQAAAAIAAAAAAAAAAIA AAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8TAAAAUHJvcG9zZWQgbmV4dCBzdGVwcwAAoQ8UAAAA FAAAAAAAAAAAABQAAAAAAAIAKAAQAJ8PBAAAAAEAAAAAAKAPnAEAAA0ARABlAGYAaQBuAGkAdABl AGwAeQAgAG4AbwB0ACAAYQAgAG4AZQB3ACAASQBEACAAIQANAFAAcgBlAHQAdAB5ACAAcwB0AHIA YQBpAGcAaAB0AGYAbwByAHcAYQByAGQAIABkAHIAYQBmAHQAIAAmICAAbgBvACAAbwB1AHQAcwB0 AGEAbgBkAGkAbgBnACAAaQBzAHMAdQBlAHMAIABhAHMAIABmAGEAcgAgAGEAcwAgAE8AUwBQAEYA LwBJAFMASQBTACAAaQBzACAAYwBvAG4AYwBlAHIAbgBlAGQALAANAEkAbQBwAGwAZQBtAGUAbgB0 AGEAdABpAG8AbgBzACAAZQB4AGkAcwB0AHMALAAgAHQAZQBjAGgAbgBvAGwAbwBnAHkAIABkAGUA cABsAG8AeQBlAGQALgANAE4AbwAgAE0AYQBqAG8AcgAgAHAAbABhAG4AbgBlAGQAIABjAGgAYQBu AGcAZQBzAA0ATQBhAGsAZQAgAGkAdAAgAGEAIABXAEcAIABkAG8AYwB1AG0AZQBuAHQAPwAAAKEP RAAAAAEAAAAAAAAAAAAaAAAAAACyAAAAAwAiIAMAAAAAAbQAAAAAAAAAAAABAAAAAAAAABoAAAAC BAAAAgS0AAAAAAgAAAAIAACqDxIAAAABAAAAAQAAAAAAzgAAAAAAAAAAAOoDAAAAAA8A+APaCQAA AgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAAA9MBgAPAHIAAAAP///wAAAAAAgICAAAAAAAC7 4OMAMzOZAACZmQCZzAAAYADwByAAAAD///8AAAAAAJaWlgAAAAAA+99TAP+ZZgDMMwAAmWYAAGAA 8AcgAAAA////AAAAAACAgIAAAAAAAJnM/wDMzP8AMzPMAK9n/wBgAPAHIAAAAN728QAAAAAAlpaW AAAAAAD///8Ajcb/AABmzAAAqAAAYADwByAAAAD//9kAAAAAAHd3dwAAAAAA///3ADPMzAD/UFAA /5kAAGAA8AcgAAAAAICAAP///wAAWlgA//+ZAABkYgBtb8cAAP//AAD/AABgAPAHIAAAAIAAAAD/ //8AXB8AAN/SkwDMMwAAvnlgAP//mQDTohkAYADwByAAAAAAAJkA////AAAzZgDM//8AM2bMAACw AABmzP8A/+cBAGAA8AcgAAAAAAAAAP///wAzZpkA4+vxAAAzmQBGiksAZsz/APDlAABgAPAHIAAA AGhrXQD///8Ad3d3ANHRywCQkIIAgJ6oAP/MZgDp3LkAYADwByAAAABmZpkA////AD4+XAD///8A YFl7AGZm/wCZzP8A//+ZAGAA8AcgAAAAUj4mAP///wAtIBUA38CNAIx7cACPXy8AzLQAAIyeoAAA AKMPPgAAAAEA//0/AAAAIiAAAGQAAAAA/wEAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP// /////ywAAAAAAwAAEACjD3wAAAAFAP/9PwABACIgAABkAAAAAP8AAGQAFAAAANgAAABAAgAAAAAH AAAA///vAAAAAAD///////8gAAAAAAEAAIAFAAATINQBIAEAAAIAHACABQAAIiDQAkACAAACABgA gAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAAIACjD24AAAAFAP/9PwAAACIgAABkAAAAAP8A AGQAHgAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8MAAAAAAEAAAAFAAAgASABAAAAAAAF AABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEJAAAAAAEAAAAA AAAAAQABCQAAAAABACABAAAAAAIAAQkAAAAAAQBAAgAAAAADAAEJAAAAAAEAYAMAAAAABAABCQAA AAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAFAAAAAAAAAAAAAgAcAAEAAAAA AAAAAgAYAAIAAAAAAAAAAgAUAAMAAAAAAAAAAgASAAQAAAAAAAAAAgASAIAAow8+AAAABQAAAAAA AAAAAAIAGAABAAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAAAAAAAAIAEAAEAAAAAAAAAAIAEAAP AAwEDAUAAA8AAvAEBQAAEAAI8AgAAAAGAAAABgQAAA8AA/CcBAAADwAE8CgAAAABAAnwEAAAAAAA AAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8NIAAAASAArwCAAAAAIEAAAACgAAkwAL 8DYAAAB/AAEABQCAAHBKewmHAAEAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIA AAgAABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAABANQADwAN8FQAAAAAAJ8PBAAA AAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxlAACiDwYAAAAhAAAA AAAAAKoPCgAAACEAAAABAAAAAAAPAATwFgEAABIACvAIAAAAAwQAAAAKAACDAAvwMAAAAH8AAQAF AIAAsE17CYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAA8AMgAWAV Ew8PABHwEAAAAAAAwwsIAAAAAQAAAAIA1AAPAA3wngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xp Y2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZv dXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAA AAQAAACqDwoAAABTAAAAAQAAAAAADwAE8LYAAAASAArwCAAAAAQEAAAACgAAgwAL8DAAAAB/AAEA BQCAAGBUewmBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAF4PIAFg BooQDwAR8BAAAAAAAMMLCAAAAAIAAAAHAdQADwAN8D4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoA AAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAOAAAA+A8EAAAAAAAAAA8ABPDuAAAAEgAK8AgAAAAF BAAAAAoAAIMAC/AwAAAAfwABAAUAgADwWXsJgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkA AQICAAAIAAAQ8AgAAABeD3cGNhCKEA8AEfAQAAAAAADDCwgAAAADAAAACQLUAA8ADfB2AAAAAACf DwQAAAAEAAAAAACoDyIAAAA2MnRoIElFVEYsIE1pbm5lYXBvbGlzLCBNYXJjaCAyMDA1AAChDxYA AAAjAAAAAAAACAAAAQAjAAAAAAACAA4AAACqDxoAAAAXAAAAAAAAAAEAAAABAAAAAAALAAAAAAAA AA8ABPC4AAAAEgAK8AgAAAAGBAAAAAoAAIMAC/AwAAAAfwABAAUAgABQX3sJgQEEAAAIgwEAAAAI vwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABeDyAQYBWKEA8AEfAQAAAAAADDCwgAAAAE AAAACALUAA8ADfBAAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAIA AgAAAAAAAgAOAAAA2A8EAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEA AAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8A AAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBf AFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAmKDDASBAIY8gALoPHAAAAEQAZQBmAGEAdQBsAHQA IABEAGUAcwBpAGcAbgAPAO4DJAIAAAIA7wMYAAAAAAAAAA8QAAAAAAAAAAAAgAAAAAAHAPdgDwAM BJQBAAAPAALwjAEAADAACPAIAAAAAwAAAAMIAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA AAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPByAAAAEgAK8AgAAAACCAAAIAIAAFMAC/Ae AAAAfwAAAAQAgADwIX0JvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAAB6A2AAgBYYBw8AEfAQAAAA AADDCwgAAAAAAAAADwDUAA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMIAAAg AgAAUwAL8B4AAAB/AAAABACAAPCMegm/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPAJAADwFUAO DwAR8BAAAAAAAMMLCAAAAAEAAAAQANQADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAI AAAAAQgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAA AA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAJigwwHAxiKP DwDuA5EKAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwD3YA8ADARBCgAADwAC8DkKAABA AAjwCAAAAAYAAAAIKAAADwAD8NEJAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIA CvAIAAAAACgAAAUAAAAPAATwcgAAABIACvAIAAAAAigAACACAABTAAvwHgAAAH8AAAAEAIAAAExu C78BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAAAAnAWcV0AIPABHwEAAAAAAAwwsIAAAAAAAAAA0A 1AAPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADKAAAIAIAAFMAC/AeAAAAfwAA AAQAgABgQWwLvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAAAQAgAAJhaHDw8AEfAQAAAAAADDCwgA AAABAAAADgDUAA8ADfAMAAAAAACeDwQAAAABAAAADwAE8JEDAAASAArwCAAAAAYoAAAACgAAgwAL 8DAAAAB/AAAABQCAALBdawuBAQQAAAiDAQAAAAi/AQAAEQDAAQEAAAj/AQAACQABAgIAAAgAABDw CAAAANAFAABACzAPDwAR8KAAAAAPAIgTmAAAAA8AihOQAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5 AAAAixNyAAAAAACsD2oAAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAIA AAAAAAAAAAAADwAN8IkCAAAAAJ8PBAAAAAEAAAAAAKgPfwEAAA1kcmFmdC12YXNzZXVyLW9zcGYt dGUtY2Fwcy0wMC50eHQgKE9TUEYpDQlUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBPU1BGIHRyYWZm aWMgZW5naW5lZXJpbmcgY2FwYWJpbGl0eSBUTFZzIHJlbGF0ZWQgdG8gdmFyaW91cyBNUExTIFRy YWZmaWMgRW5naW5lZXJpbmcgY2FwYWJpbGl0aWVzLiBUaGVzZSBPU1BGIFRFIGNhcGFiaWxpdHkg VExWcyBhcmUgY2FycmllZCB3aXRoaW4gdGhlIE9TUEYgcm91dGVyIGluZm9ybWF0aW9uIExTQSAo b3BhcXVlIHR5cGUgb2YgNCwgb3BhcXVlIElEIG9mIDApIHNwZWNpZmllZCBpbiBkcmFmdC1pZXRm LW9zcGYtY2FwLTAyLnR4dC4NZHJhZnQtdmFzc2V1ci1pc2lzLXRlLWNhcHMtMDAudHh0IChJUy1J UykNCUlTLUlTIHNwZWNpZmljcw0JAAChD9QAAAABAAAAAQCTEAAAAgDgAAIAUAApAAAAAACyEAAA AwDgAAIAAAAAAVAAGQEAAAAAIRAAAAAAAAAAAVAAKgAAAAAAshAAAAMA4AACAAAAAAFQABMAAAAA ALMQAAACAOAAAgAAAAABUAABAAAAAACCAAIADgApAAAAAASCAAAEAgAUAP0AAAAACIIAAAgCABAA GgAAAAEMggABDAIAEAACAAAAABCCAAAQAgAQACsAAAAAFIIAABQCABQAEAAAAAAYggAAGAIADwAC AAAAAByCAAAcAgAUAAAAqg8SAAAAAQAAAAEAAAAAAH8BAAAAAAAADwAE8GQAAABCAQrwCAAAAAco AACACgAAowAL8DwAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADAAYAAAADLAdSUAADR AQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAGAJ4ArADGAJDwAE8KAEAAASAArwCAAAAAgoAAAACgAA gwAL8DAAAAB/AAAABQCAAMC2aguBAQQAAAiDAQAAAAi/AQAAEQDAAQEAAAj/AQAACQABAgIAAAgA ABDwCAAAAMAGcAuAFjcODwAR8G4AAAAPAIgTZgAAAA8AihNeAAAAAAC6Dw4AAABfAF8AXwBQAFAA VAA5AAAAixNAAAAAAACsDzgAAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAgAAAAAA AAAAAAAAAAACAAAAAAAAAAAAAA8ADfDKAwAAAACfDwQAAAABAAAAAACgDxoDAAAgACAAIAAgACAA IABUAEUAIABUAEwAVgAgAHIAZQBsAGEAdABlAGQAIAB0AG8AIAB2AGEAcgBpAG8AdQBzACAAYwBh AHAAYQBiAGkAbABpAHQAaQBlAHMAIABmAHUAbgBjAHQAaQBvAG4AYQBsAGkAdABpAGUAcwANAFAA QwBFACAAKABQAGEAdABoACAAQwBvAG0AcAB1AHQAYQB0AGkAbwBuACAARQBsAGUAbQBlAG4AdAAp ACAAZABpAHMAYwBvAHYAZQByAHkAOgAgAHUAcwBlAGQAIABpAG4AIAB2AGEAcgBpAG8AdQBzACAA YwBvAG4AdABlAHgAdABzACAAcwB1AGMAaAAgAGEAcwAgAEkAbgB0AGUAcgAtAGQAbwBtAGEAaQBu ACwAIABDAFAAVQAgAGkAbgB0AGUAbgBzAGkAdgBlACAAVABFACAATABTAFAAIABwAGEAdABoACAA YwBvAG0AcAB1AHQAYQB0AGkAbwBuACAAKABOAFAALQBjAG8AbQBwAGwAZQB0AGUAIABwAGIAcwAs ACAAJiApACwAIABHAE0AUABMAFMALAAgACYgIAANAFQARQAtAE0ARQBTAEgALQBHAFIATwBVAFAA OgAgAGEAbABsAG8AdwBzACAAZgBvAHIAIABhAHUAdABvAC0AZABpAHMAYwBvAHYAZQByAHkAIABv AGYAIABUAEUAIABtAGUAcwBoACAAZwByAG8AdQBwACAAbQBlAG0AYgBlAHIAcwANAFQARQAtAE4A TwBEAEUALQBDAEEAUAA6ACAAdQBzAGUAZAAgAG8AZgAgAHQAaABlACAAYQBkAHYAZQByAHQAaQBz AGUAbQBlAG4AdAAgAG8AZgAgAGMAbwBuAHQAcgBvAGwAIABhAG4AZAAgAGQAYQB0AGEAIABwAGwA YQBuAGUAIABuAG8AZABlACAAYwBhAHAAYQBiAGkAbABpAHQAaQBlAHMAIAAoAGUALgBnAC4AIABQ ADIATQBQACAAVABFACAAYwBhAHAAYQBiAGwAZQAgAG4AbwBkAGUAKQANAAAAoQ9oAAAAPQAAAAEA kxAAAAIA4AACAFAAUAEAAAEAkgAAAAMA4AACAAEAAAABAJMQAAACAOAAAgBQAAYAAAAAAIIAAgAO ADcAAAABBIIAAQQCAA4AnwAAAAAIggAACAIADgCyAAAAAAwCAAAMDgAAAKoPJAAAAAYAAAABAAAA AADDAAAAAAAAAAMAAAABAAAAAQDCAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABKAAAAAwAAIMAC/Aw AAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAA AAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8A7gPwAQAAAgDvAxgAAAABAAAADQ4A AAAAAAAAAACAAAAAAAcA92APAAwEoAEAAA8AAvCYAQAAIAAI8AgAAAADAAAAAzgAAA8AA/AwAQAA DwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAA4AAAFAAAADwAE8HgAAAAS AArwCAAAAAI4AAAgAgAAYwAL8CQAAAB/AAAABACAAJAefAm/AQAAAQD/AQAAAQABAwIEAACIAwAA AAAAABDwCAAAAAAAJwFnFdACDwAR8BAAAAAAAMMLCAAAAAAAAAANANQADwAN8AwAAAAAAJ4PBAAA AAAAAAAPAATweAAAABIACvAIAAAAAzgAACACAABjAAvwJAAAAH8AAAAEAIAAICB8Cb8BAAABAP8B AAABAAEDAwQAAIgDAAAAAAAAEPAIAAAAcAIWAIAWXw8PABHwEAAAAAAAwwsIAAAAAQAAAA4A1AAP AA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABOAAAAAwAAIMAC/AwAAAAgQEAAAAI gwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAA AICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8A7gMkAgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACA AAAAAAcA92APAAwElAEAAA8AAvCMAQAAUAAI8AgAAAADAAAAAxQAAA8AA/AkAQAADwAE8CgAAAAB AAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAUAAAFAAAADwAE8HIAAAASAArwCAAAAAIU AAAgAgAAUwAL8B4AAAB/AAAABACAAGBnbgu/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAK0AAABg FZcCDwAR8BAAAAAAAMMLCAAAAAAAAAANANQADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIA CvAIAAAAAxQAACACAABTAAvwHgAAAH8AAAAEAIAA0DNuC78BAAABAP8BAAABAAEDAwQAAAAAEPAI AAAAcAJgAOIVdg4PABHwEAAAAAAAwwsIAAAAAQAAAA4A1AAPAA3wDAAAAAAAng8EAAAAAQAAAA8A BPBIAAAAEgAK8AgAAAABFAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwES ABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkA mcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4I AAAAnKDDAaA8vrIQABEQYwAAAAAGAAB4nLtwXvDBwo1SDxnQgB0DM8O//5wMbEhijFAMBgIMQPn/ /0FMGA0C/0fBkAJ/gfjfQDtiFAwYYAhCz/mkASYGVpQ8j1ex2Ra95cpHGf8RUkciINp+GoGhbD8A 0NTyeQAAchcwAAAAAQAwAAAAAABGJAAAKC4AAAgAEADlPAAACwAQAFQwAAAPABAA7ToAABIAEAAR PwAAAAD1DxwAAAAAAQAA6RUAAwAAAAB8PwAAAQAAABIAAAABANwwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAA AAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAA /v////7///////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////v8AAAMKAQAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQ k5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rgADAAC8AgAAEAAAAAEAAACIAAAAAwAAAJAAAAAP AAAAqAAAAAQAAAC4AAAABgAAAMAAAAAHAAAAyAAAAAgAAADQAAAACQAAANgAAAAKAAAA4AAAABcA AADoAAAACwAAAPAAAAAQAAAA+AAAABMAAAAAAQAAFgAAAAgBAAANAAAAEAEAAAwAAABaAgAAAgAA ABAnAAAeAAAADwAAAE9uLXNjcmVlbiBTaG93AAAeAAAABwAAAE9sZGRvZwABAwAAANg/AAADAAAA IwAAAAMAAAAEAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAABCwALAAAAAAAAAAsAAAAA AAAACwAAAAAAAAALAAAAAAAAAB4QAAAJAAAABgAAAEFyaWFsABEAAABBcmlhbCBVbmljb2RlIE1T AAoAAABXaW5nZGluZ3MABgAAAFRpbWVzAA8AAABEZWZhdWx0IERlc2lnbgCyAAAAUm91dGluZyBl eHRlbnNpb25zIGZvciBkaXNjb3Zlcnkgb2YgTXVsdGlwcm90b2NvbCAoTVBMUykgTGFiZWwgU3dp dGNoICAgICAgICAgICAgICAgICD+/wAAAwoBAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCr kQgAKyez2TAAAAAULAAACwAAAAEAAABgAAAAAgAAAGgAAAAEAAAAeAAAAAgAAACIAAAACQAAAJwA AAASAAAAqAAAAAoAAADIAAAADAAAANQAAAANAAAA4AAAAA8AAADsAAAAEQAAAPQAAAACAAAAECcA AB4AAAAIAAAAU2xpZGUgMQAeAAAACAAAACBBZHJpYW4AHgAAAAsAAABKUCBWYXNzZXVyAHseAAAA BAAAADEyOAAeAAAAFQAAAE1pY3Jvc29mdCBQb3dlclBvaW50AAAAAkAAAABAcxaK3AEAAEAAAACA P1GRmKDDAUAAAAAApk552SPFAQMAAABjAQAARwAAABgrAAD+////UElDVCsQAAAAAACHALQAEQL/ DAD//gAAAEgAAABIAAAAAAAAAIcAtAAAAAAAHgABAAoAAAAAAIcAtACaAAAA/4LQAAAAAACHALQA AAAEAAAAAABIAAAASAAAABAAIAAEAAgAAAAgAAgRcAAveiwAAAAAAIcAtAAAAAAAhwC0AAAADIH/ gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B /4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/ gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B /4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/ gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wCdgf/D//4A9/8BAADx/wAA9/8AAPT/ AAD3/wEAAOb/BgD/AAD//wD9/wMA/wAA9v8AAPb/AADU//4A9/8BAADx/wAA9/8AAPT/AAD3/wEA AOb/BgD/AAD//wD9/wMA/wAA9v8AAPb/AADU//4A9/8BAADx/wAA9/8AAPT/AAD3/wEAAOb/BgD/ AAD//wD9/wMA/wAA9v8AAPb/AADe/wGNgf/D/woA//8A/wAA/wD///wAA/8A///+AAH///4ABP// AAD//gAD/wD///4AFf8AAP8A/wD//wAA/wAA/wAA/wD/AP/9AAz/AAD/AAD/AAD/AP///QAO/wD/ /wD/AAD/AAD/AAD//gAB///7AAT/AP8A//4ADv8AAP8AAP//AAD/AAD/ANT/CgD//wD/AAD/AP// /AAD/wD///4AAf///gAE//8AAP/+AAP/AP///gAV/wAA/wD/AP//AAD/AAD/AAD/AP8A//0ADP8A AP8AAP8AAP8A///9AA7/AP//AP8AAP8AAP8AAP/+AAH///sABP8A/wD//gAO/wAA/wAA//8AAP8A AP8A1P8KAP//AP8AAP8A///8AAP/AP///gAB///+AAT//wAA//4AA/8A///+ABX/AAD/AP8A//8A AP8AAP8AAP8A/wD//QAM/wAA/wAA/wAA/wD///0ADv8A//8A/wAA/wAA/wAA//4AAf//+wAE/wD/ AP/+AA7/AAD/AAD//wAA/wAA/wDe/wGQgf/D//4ACf8A//8AAP//AP/9AAn/AAD//wD/AP///gAP /wAA//8AAP8AAP//AAD///4AAv8AAP3/AwAA///+AAP/AP///gAO//8A//8A//8AAP8AAP///gAL /wD/AP//AP8A/wD//QAE//8AAP/9AAD//QAQ//8A/wAA//8AAP//AP//AADU//4ACf8A//8AAP// AP/9AAn/AAD//wD/AP///gAP/wAA//8AAP8AAP//AAD///4AAv8AAP3/AwAA///+AAP/AP///gAO //8A//8A//8AAP8AAP///gAL/wD/AP//AP8A/wD//QAE//8AAP/9AAD//QAQ//8A/wAA//8AAP// AP//AADU//4ACf8A//8AAP//AP/9AAn/AAD//wD/AP///gAP/wAA//8AAP8AAP//AAD///4AAv8A AP3/AwAA///+AAP/AP///gAO//8A//8A//8AAP8AAP///gAL/wD/AP//AP8A/wD//QAE//8AAP/9 AAD//QAQ//8A/wAA//8AAP//AP//AADe/wGNgf/D/wwA/wD/AP//AAD//wD//gAH//8AAP//AP/+ AAP/AAD//AAD//8A//0AGf//AAD//wD/AAD//wAA//8AAP//AP//AAD//gAG//8A//8A//sADf// AAD/AP//AP8A/wD//QAE//8AAP/+ABb//wAA/wD//wD/AAD//wAA//8A//8AANT/DAD/AP8A//8A AP//AP/+AAf//wAA//8A//4AA/8AAP/8AAP//wD//QAZ//8AAP//AP8AAP//AAD//wAA//8A//8A AP/+AAb//wD//wD/+wAN//8AAP8A//8A/wD/AP/9AAT//wAA//4AFv//AAD/AP//AP8AAP//AAD/ /wD//wAA1P8MAP8A/wD//wAA//8A//4AB///AAD//wD//gAD/wAA//wAA///AP/9ABn//wAA//8A /wAA//8AAP//AAD//wD//wAA//4ABv//AP//AP/7AA3//wAA/wD//wD/AP8A//0ABP//AAD//gAW //8AAP8A//8A/wAA//8AAP//AP//AADe/wFsgf/D/wQA/wAA//4AAP/+AAD//gAD//8A//4AAf// /gAE/wD/AP/+AAH///wAAP/9AAH///0AA///AP/9AP7/+gAD/wAA//4AA/8AAP/+AAX//wAA///+ AAT/AP8A//4AAP/9AAD/+gAB///+AAL/AP/+AAP/AAD//QDU/wQA/wAA//4AAP/+AAD//gAD//8A //4AAf///gAE/wD/AP/+AAH///wAAP/9AAH///0AA///AP/9AP7/+gAD/wAA//4AA/8AAP/+AAX/ /wAA///+AAT/AP8A//4AAP/9AAD/+gAB///+AAL/AP/+AAP/AAD//QDU/wQA/wAA//4AAP/+AAD/ /gAD//8A//4AAf///gAE/wD/AP/+AAH///wAAP/9AAH///0AA///AP/9AP7/+gAD/wAA//4AA/8A AP/+AAX//wAA///+AAT/AP8A//4AAP/9AAD/+gAB///+AAL/AP/+AAP/AAD//QDe/wAogf+w//0A wP8AAOv/AACq//0AwP8AAOv/AACq//0AwP8AAOv/AADH/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B /4H/sf8AiIH/k//+AAP//wD//gAB/wD+//0A/v8AAPz/AAD7/wIA///+APz/AgD/AP7/AACC//4A A///AP/+AAH/AP7//QD+/wAA/P8AAPv/AgD///4A/P8CAP8A/v8AAIL//gAD//8A//4AAf8A/v/9 AP7/AAD8/wAA+/8CAP///gD8/wIA/wD+/wAAvP8AqYH/k//+AAz/AAD/AP8A/wD//wAA/v8DAP// AP7//gAD/wD///4ACP8AAP//AP8A//0AAP/+AAH/AIT//gAM/wAA/wD/AP8A//8AAP7/AwD//wD+ //4AA/8A///+AAj/AAD//wD/AP/9AAD//gAB/wCE//4ADP8AAP8A/wD/AP//AAD+/wMA//8A/v/+ AAP/AP///gAI/wAA//8A/wD//QAA//4AAf8Avv8ArIH/lP8DAP8A//4AAP/+AAH/AP7//gAE/wD/ /wD9//4AB/8AAP//AP///QAN/wD/AAD/AAD//wAA/wCG/wMA/wD//gAA//4AAf8A/v/+AAT/AP// AP3//gAH/wAA//8A///9AA3/AP8AAP8AAP//AAD/AIb/AwD/AP/+AAD//gAB/wD+//4ABP8A//8A /f/+AAf/AAD//wD///0ADf8A/wAA/wAA//8AAP8Av/8AqYH/lP8DAP8A//4AAf8A/v8NAP//AP// AP8A//8A///9AAH///wABf8A//8A//wACP8AAP//AP//AIb/AwD/AP/+AAH/AP7/DQD//wD//wD/ AP//AP///QAB///8AAX/AP//AP/8AAj/AAD//wD//wCG/wMA/wD//gAB/wD+/w0A//8A//8A/wD/ /wD///0AAf///AAF/wD//wD//AAI/wAA//8A//8Av/8AoIH/lP8DAP8A//4AAf8A/v/+AAD//gAD /wD///cAAP/+AAH///4ACP8A/wD/AP8A//4AAv//AIb/AwD/AP/+AAH/AP7//gAA//4AA/8A///3 AAD//gAB///+AAj/AP8A/wD/AP/+AAL//wCG/wMA/wD//gAB/wD+//4AAP/+AAP/AP//9wAA//4A Af///gAI/wD/AP8A/wD//gAC//8Av/8AIIH/k/8AAPD/AACB/+D/AADw/wAAgf/g/wAA8P8AAJr/ AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AKyB/67//gD3/wAA+v8C AP8A/v/+AAD//gAD/wD///0A+/8DAP8AAPz//gD5/wAA9f8AAPf//AAA//0As//+APf/AAD6/wIA /wD+//4AAP/+AAP/AP///QD7/wMA/wAA/P/+APn/AAD1/wAA9//8AAD//QCz//4A9/8AAPr/AgD/ AP7//gAA//4AA/8A///9APv/AwD/AAD8//4A+f8AAPX/AAD3//wAAP/9ANL/AS2B/67/CgD//wD/ AAD/AP///gAA//4ACf8A/wD/AP//AAD+/wUA//8A/wD+/wMA/wD/+QAM/wAA//8A//8A/wD///wA Bv8A//8AAP/+AAb/AAD/AP///gAI//8A//8A//8A/v8AALT/CgD//wD/AAD/AP///gAA//4ACf8A /wD/AP//AAD+/wUA//8A/wD+/wMA/wD/+QAM/wAA//8A//8A/wD///wABv8A//8AAP/+AAb/AAD/ AP///gAI//8A//8A//8A/v8AALT/CgD//wD/AAD/AP///gAA//4ACf8A/wD/AP//AAD+/wUA//8A /wD+/wMA/wD/+QAM/wAA//8A//8A/wD///wABv8A//8AAP/+AAb/AAD/AP///gAI//8A//8A//8A /v8AANP/ASSB/67//gAU/wD//wAA//8A/wAA//8AAP8A//8A/v/+AAD//gAC//8A/v8JAP8AAP// AP8A//4A/f/8AAT/AAD///0AB/8AAP//AP///AAH/wAA//8A/wD+/wIA///+AAH/ALT//gAU/wD/ /wAA//8A/wAA//8AAP8A//8A/v/+AAD//gAC//8A/v8JAP8AAP//AP8A//4A/f/8AAT/AAD///0A B/8AAP//AP///AAH/wAA//8A/wD+/wIA///+AAH/ALT//gAU/wD//wAA//8A/wAA//8AAP8A//8A /v/+AAD//gAC//8A/v8JAP8AAP//AP8A//4A/f/8AAT/AAD///0AB/8AAP//AP///AAH/wAA//8A /wD+/wIA///+AAH/ANP/ASeB/67/DAD/AP8A//8AAP//AP/8ABL//wD//wD//wD//wD/AP8A//8A /v8DAP8A//4AAv8A//4A/f8JAP//AP//AAD///4AAf//+QAL/wAA//8AAP//AP8A/v8DAP//AP7/ AAC0/wwA/wD/AP//AAD//wD//AAS//8A//8A//8A//8A/wD/AP//AP7/AwD/AP/+AAL/AP/+AP3/ CQD//wD//wAA///+AAH///kAC/8AAP//AAD//wD/AP7/AwD//wD+/wAAtP8MAP8A/wD//wAA//8A //wAEv//AP//AP//AP//AP8A/wD//wD+/wMA/wD//gAC/wD//gD9/wkA//8A//8AAP///gAB///5 AAv/AAD//wAA//8A/wD+/wMA//8A/v8AANP/ATmB/67/BAD/AAD//gAA//4AAv8A//4ABP//AP// /gAA//4ABv8A/wAA/wD+/wMA/wD//gAJ/wD/AAD/AAD///0AA///AP/8AAb//wD/AAD//gAG/wAA //8A//4AAf8A/v8CAP///gAB/wC0/wQA/wAA//4AAP/+AAL/AP/+AAT//wD///4AAP/+AAb/AP8A AP8A/v8DAP8A//4ACf8A/wAA/wAA///9AAP//wD//AAG//8A/wAA//4ABv8AAP//AP/+AAH/AP7/ AgD///4AAf8AtP8EAP8AAP/+AAD//gAC/wD//gAE//8A///+AAD//gAG/wD/AAD/AP7/AwD/AP/+ AAn/AP8AAP8AAP///QAD//8A//wABv//AP8AAP/+AAb/AAD//wD//gAB/wD+/wIA///+AAH/ANP/ AEyB/5n/AAD0/wAA5f/9AO///QAC//8A+f8AAJ7/AAD0/wAA5f/9AO///QAC//8A+f8AAJ7/AAD0 /wAA5f/9AO///QAC//8A+f8AANL/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wA4gf+E/wAA 7v8AAPb/AAD+/wAAgf/y/wAA7v8AAPb/AAD+/wAAgf/y/wAA7v8AAPb/AAD+/wAAu/8ApoH/kP8J AP8A/wD//wAA//4ACv8A//8A/wD/AP///gAJ/wD/AP8A/wD///4AAP/9AAb/AP8AAP8Agf8JAP8A /wD//wAA//4ACv8A//8A/wD/AP///gAJ/wD/AP8A/wD///4AAP/9AAb/AP8AAP8Agf8JAP8A/wD/ /wAA//4ACv8A//8A/wD/AP///gAJ/wD/AP8A/wD///4AAP/9AAb/AP8AAP8Avv8AqYH/kP8eAAD/ AP8AAP//AP//AAD/AP8AAP8A/wAA//8AAP8A//4ABP8AAP///gAE//8AAP/9AAH/AIL/HgAA/wD/ AAD//wD//wAA/wD/AAD/AP8AAP//AAD/AP/+AAT/AAD///4ABP//AAD//QAB/wCC/x4AAP8A/wAA //8A//8AAP8A/wAA/wD/AAD//wAA/wD//gAE/wAA///+AAT//wAA//0AAf8Av/8AnYH/kP8EAP// AP/9AAD//gAI//8A/wD//wD//AAH//8A/wAA///8AAH///4AAf///gAC//8Agv8EAP//AP/9AAD/ /gAI//8A/wD//wD//AAH//8A/wAA///8AAH///4AAf///gAC//8Agv8EAP//AP/9AAD//gAI//8A /wD//wD//AAH//8A/wAA///8AAH///4AAf///gAC//8Av/8AjoH/kP8GAP//AP8A//sACv//AP8A //8A/wD//gAD//8A//wAAP/+AAD//QAB///7AIL/BgD//wD/AP/7AAr//wD/AP//AP8A//4AA/// AP/8AAD//gAA//0AAf//+wCC/wYA//8A/wD/+wAK//8A/wD//wD/AP/+AAP//wD//AAA//4AAP/9 AAH///sAv/8AFoH/gf/f/wAAgf/O/wAAgf/O/wAAvP8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B /7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/ sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x /wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ANIH/p/8AAP7/AADF/wAA/P/7AJr/AAD+/wAA xf8AAPz/+wCa/wAA/v8AAMX/AAD8//sAwP8A5YH/qP/+AAD//QD+/wwA/wAA/wD/AP8A/wD//gD9 /wUA//8A///+AAD//gD9/wIAAP/+AAr/AP8AAP8A/wD///4A/f8GAP8AAP8A//sAov/+AAD//QD+ /wwA/wAA/wD/AP8A/wD//gD9/wUA//8A///+AAD//gD9/wIAAP/+AAr/AP8AAP8A/wD///4A/f8G AP8AAP8A//sAov/+AAD//QD+/wwA/wAA/wD/AP8A/wD//gD9/wUA//8A///+AAD//gD9/wIAAP/+ AAr/AP8AAP8A/wD///4A/f8GAP8AAP8A//sAx/8A3IH/qf8EAP8A///+AAD//AAE/wD/AP/8AAP/ AAD//QAC//8A/v/7AAD//gAI/wAA/wAA/wD/+QAD/wAA//wACv8AAP8A/wD//wAAov8EAP8A///+ AAD//AAE/wD/AP/8AAP/AAD//QAC//8A/v/7AAD//gAI/wAA/wAA/wD/+QAD/wAA//wACv8AAP8A /wD//wAAov8EAP8A///+AAD//AAE/wD/AP/8AAP/AAD//QAC//8A/v/7AAD//gAI/wAA/wAA/wD/ +QAD/wAA//wACv8AAP8A/wD//wAAxv8AlIH/qf/+AAX/AAD/AAD9//MA/f/4AP7/AQAA/v/4AAH/ AP7/+wAB/wD9/wQA//8A//oAo//+AAX/AAD/AAD9//MA/f/4AP7/AQAA/v/4AAH/AP7/+wAB/wD9 /wQA//8A//oAo//+AAX/AAD/AAD9//MA/f/4AP7/AQAA/v/4AAH/AP7/+wAB/wD9/wQA//8A//oA x/8AFoH/gf/+/wAAgf/O/wAAgf/O/wAAnf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB /4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/ gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B /4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wBhgf+e/wQAAP8A//4A+v8AAOX/ AADy/wEAAP7/AADp/wAAqP8EAAD/AP/+APr/AADl/wCZ8v8BmZn+/wCZ6f8AAKj/BAAA/wD//gD6 /wAA5f8AmfL/AZmZ/v8Amen/AADX/wDlgf+m/wMA/wD//gAC/wD/9wAP/wD/AP8A/wD/AP8A/wAA //4A9P8MAAD//wD/AP8A/wAA//sADP8AAP8A/wD/AP//AP/+AAH/APj/AACw/wMA/wD//gAC/wD/ 9wAP/wD/AP8A/wD/AP8A/wAA//4A9P8MmZn//5n/mf+Z/5mZ//uZDP+Zmf+Z/5n/mf//mf/+mQH/ mfj/AACw/wMA/wD//gAC/wD/9wAP/wD/AP8A/wD/AP8A/wAA//4A9P8MmZn//5n/mf+Z/5mZ//uZ DP+Zmf+Z/5n/mf//mf/+mQH/mfj/AADX/wCggf+m//cAAP/7AAL/AP/8AAH///cAAf8A9P/+AAD/ 9AAD/wAA//0AB/8A/wAA/wD//QD4/wAAsP/3AAD/+wAC/wD//AAB///3AAH/APT//pkA//SZA/+Z mf/9mQf/mf+Zmf+Z//2Z+P8AALD/9wAA//sAAv8A//wAAf//9wAB/wD0//6ZAP/0mQP/mZn//ZkH /5n/mZn/mf/9mfj/AADX/wBcgf+n//oABv//AP//AP/4AAP//wD/9gAB/wD0/9IAsf/6AAb//wD/ /wD/+AAD//8A//YAAf8A9P/TmQAAsf/6AAb//wD//wD/+AAD//8A//YAAf8A9P/TmQAA1/8AJoH/ lv8CAP8A4P/SAKD/AgD/AOD/05kAAKD/AgD/AOD/05kAANf/AAyB/4H/gf+B/4H/sf8AlIH/n/8A APz/AAD+/wAA/f/+AOz/AAD7/wAA/f8AAPf/AAD2/wQAAP//APb/AADh/wAAyf8AAPz/AAD+/wAA /f/+AOz/AJn7/wCZ/f8Amff/AJn2/wSZmf//mfb/AJnh/wAAyf8AAPz/AAD+/wAA/f/+AOz/AJn7 /wCZ/f8Amff/AJn2/wSZmf//mfb/AJnh/wAA9/8BLYH/p/8DAP8A//4AGv8A//8AAP8A/wD/AP// AP8A/wD/AAD/AP//APT/AwD/AP/9AAb/AAD/AP8A+f8BAP/8AAL/AP/2AAz/AP8AAP8AAP8A/wD/ /gAB/wD0/wEA//4ABP8A//8A0f8DAP8A//4AGv8A//8AAP8A/wD/AP//AP8A/wD/AAD/AP//APT/ A5n/mf/9mQb/mZn/mf+Z+f8Bmf/8mQL/mf/2mQz/mf+Zmf+Zmf+Z/5n//pkB/5n0/wGZ//6ZBP+Z //8A0f8DAP8A//4AGv8A//8AAP8A/wD/AP//AP8A/wD/AAD/AP//APT/A5n/mf/9mQb/mZn/mf+Z +f8Bmf/8mQL/mf/2mQz/mf+Zmf+Zmf+Z/5n//pkB/5n0/wGZ//6ZBP+Z//8A9/8A7oH/p//6AAT/ AP8A//wAAv8A//wACP8A/wAA/wD/APT/+AAA//wA+f/8AAP/AAD//QAA//4AAP/9AAD/+AAC/wD/ /QD1/wMA/wD//QAC//8A0f/6AAT/AP8A//wAAv8A//wACP8A/wAA/wD/APT/+JkA//yZ+f/8mQP/ mZn//ZkA//6ZAP/9mQD/+JkC/5n//Zn1/wOZ/5n//ZkC//8A0f/6AAT/AP8A//wAAv8A//wACP8A /wAA/wD/APT/+JkA//yZ+f/8mQP/mZn//ZkA//6ZAP/9mQD/+JkC/5n//Zn1/wOZ/5n//ZkC//8A 9/8AWYH/qP/6AAH///gAAP/9AAL/AP/7AAL//wD0/6wA0v/6AAH///gAAP/9AAL/AP/7AAL//wD0 /62ZAADS//oAAf//+AAA//0AAv8A//sAAv//APT/rZkAAPf/ABaB/4H/+P+sAKL/rZkAAKL/rZkA APf/AAyB/4H/gf+B/4H/sf8AYYH/qP8BAAD1/wEAAPj/AADt/wAA/v8BAAD+/wAA6P8AAJ//AQAA 9f8BAAD4/wAA7f8Amf7/AZmZ/v8Amej/AACf/wEAAPX/AQAA+P8AAO3/AJn+/wGZmf7/AJno/wAA xP8A1oH/qP8GAP8A/wAA//4A/f8FAP8A/wD//gAC/wAA+/8BAP/9AAL/AP/+AAP/AAD//AAM/wAA /wD/AP8A//8A//4AAf8A9/8AAJ//BgD/AP8AAP/+AP3/BQD/AP8A//4AAv8AAPv/AQD//ZkC/5n/ /pkD/5mZ//yZDP+Zmf+Z/5n/mf//mf/+mQH/mff/AACf/wYA/wD/AAD//gD9/wUA/wD/AP/+AAL/ AAD7/wEA//2ZAv+Z//6ZA/+Zmf/8mQz/mZn/mf+Z/5n//5n//pkB/5n3/wAAxP8Ar4H/qP8CAAD/ +wD8/wIAAP/7AAD//gD8/wUA/wD/AP/7AAD/+wAD/wAA//0AB/8A/wAA/wD//QD3/wAAn/8CAAD/ +wD8/wIAAP/7AAD//gD8/wUA/5n/mf/7mQD/+5kD/5mZ//2ZB/+Z/5mZ/5n//Zn3/wAAn/8CAAD/ +wD8/wIAAP/7AAD//gD8/wUA/5n/mf/7mQD/+5kD/5mZ//2ZB/+Z/5mZ/5n//Zn3/wAAxP8AWYH/ qP8CAP//+wD8/wIA///8AAD//QD8/wEA/9EAn/8CAP//+wD8/wIA///8AAD//QD8/wEA/9KZAACf /wIA///7APz/AgD///wAAP/9APz/AQD/0pkAAMT/ABiB/4b/0QCB//3/0pkAAIH//f/SmQAAxP8A DIH/gf+B/4H/gf+x/wB5gf+n/wAA/P8AAPv/AQAA+/8DAP//AOz/BwD//wD//wAA/v8AAOn/AACg /wAA/P8AAPv/AQAA+/8DAP//AOz/B5n//5n//5mZ/v8Amen/AACg/wAA/P8AAPv/AQAA+/8DAP// AOz/B5n//5n//5mZ/v8Amen/AADG/wC+gf+o/wcA//8A/wAA//4ABP8A/wD//AAG/wD/AAD/APb/ +gAC/wD/+gAM/wAA/wD/AP8A//8A//4AAf8A+P8AAKH/BwD//wD/AAD//gAE/wD/AP/8AAb/AP8A AP8A9v/6mQL/mf/6mQz/mZn/mf+Z/5n//5n//pkB/5n4/wAAof8HAP//AP8AAP/+AAT/AP8A//wA Bv8A/wAA/wD2//qZAv+Z//qZDP+Zmf+Z/5n/mf//mf/+mQH/mfj/AADG/wCXgf+n//sAAP/9AAD/ /gAA//gAAf8A9//+AAD/9QAD/wAA//0AB/8A/wAA/wD//QD4/wAAoP/7AAD//QAA//4AAP/4AAH/ APf//pkA//WZA/+Zmf/9mQf/mf+Zmf+Z//2Z+P8AAKD/+wAA//0AAP/+AAD/+AAB/wD3//6ZAP/1 mQP/mZn//ZkH/5n/mZn/mf/9mfj/AADG/wBTgf+o//cABv8AAP8A///+AAD//AAB/wD3/9MAof/3 AAb/AAD/AP///gAA//wAAf8A9//UmQAAof/3AAb/AAD/AP///gAA//wAAf8A9//UmQAAxv8AGIH/ gv/TAIH/+//UmQAAgf/7/9SZAADG/wAMgf+B/4H/gf+B/7H/AJSB/6f/AAD+/wMA//8A+f8AAPn/ AADo/wAA7f8DAP//APz/BgAA/wD//wDp/wAA/f8AAMP/AAD+/wMA//8A+f8AAPn/AADo/wCZ7f8D mf//mfz/BpmZ/5n//5np/wCZ/f8AAMP/AAD+/wMA//8A+f8AAPn/AADo/wCZ7f8Dmf//mfz/BpmZ /5n//5np/wCZ/f8AAOn/AR6B/6j/AAD+/wIAAP/+AAH/APz/DAD/AP8A/wAA/wD//wD+/wMAAP8A +v8LAP//AP8AAP8A//8A/v8BAAD4/wQA/wAA//4AAP/6AAD//gD5//0A/f8CAP8A/f/+AAL//wDE /wAA/v8CAAD//gAB/wD8/wwA/wD/AP8AAP8A//8A/v8DAAD/APr/C5n//5n/mZn/mf//mf7/AZmZ +P8Emf+Zmf/+mQD/+pkA//6Z+f/9mf3/Apn/mf3//pkC//8AxP8AAP7/AgAA//4AAf8A/P8MAP8A /wD/AAD/AP//AP7/AwAA/wD6/wuZ//+Z/5mZ/5n//5n+/wGZmfj/BJn/mZn//pkA//qZAP/+mfn/ /Zn9/wKZ/5n9//6ZAv//AOn/AOuB/6f/9wAB/wD8/wIA///6AAD//QAD/wD/APr/AgAA//oAAP/9 AAH/APn/9wAA//4AB/8AAP8AAP8A+v/9AP7/BAD/AP8A/v8FAAD/AP8Aw//3AAH/APz/AgD///oA AP/9AAP/AP8A+v8CmZn/+pkA//2ZAf+Z+f/3mQD//pkH/5mZ/5mZ/5n6//2Z/v8Emf+Z/5n+/wWZ mf+Z/wDD//cAAf8A/P8CAP//+gAA//0AA/8A/wD6/wKZmf/6mQD//ZkB/5n5//eZAP/+mQf/mZn/ mZn/mfr//Zn+/wSZ/5n/mf7/BZmZ/5n/AOn/AFmB/6j/+AAC/wAA+/8BAP/3AAH///4AAf8A+v+2 AMT/+AAC/wAA+/8BAP/3AAH///4AAf8A+v+3mQAAxP/4AAL/AAD7/wEA//cAAf///gAB/wD6/7eZ AADp/wAWgf+B//z/tgCY/7eZAACY/7eZAADp/wAMgf+B/4H/gf+B/7H/AGSB/6j/AQAA/P8AAP3/ BgD//wD//wDt/wAA+v8BAADk/wAAnP8BAAD8/wAA/f8GAP//AP//AO3/AJn6/wGZmeT/AACc/wEA APz/AAD9/wYA//8A//8A7f8Amfr/AZmZ5P8AAMH/ANOB/6j/BwD/AP8AAP8A/f8EAP//AP/+AAL/ AAD7/wEA//0AAv8A//4AA/8AAP/8AAH/AP7/CAAA/wAA//8A//4AAf8A+P8AAJz/BwD/AP8AAP8A /f8EAP//AP/+AAL/AAD7/wEA//2ZAv+Z//6ZA/+Zmf/8mQH/mf7/CJmZ/5mZ//+Z//6ZAf+Z+P8A AJz/BwD/AP8AAP8A/f8EAP//AP/+AAL/AAD7/wEA//2ZAv+Z//6ZA/+Zmf/8mQH/mf7/CJmZ/5mZ //+Z//6ZAf+Z+P8AAMH/AKCB/6j/AwAA///9AP3//QAD/wAA//0A/P8DAP8A//0AA/8AAP/6AAD/ 9gAE/wD/AP/9APj/AACc/wMAAP///QD9//0AA/8AAP/9APz/AwD/mf/9mQP/mZn/+pkA//aZBP+Z /5n//Zn4/wAAnP8DAAD///0A/f/9AAP/AAD//QD8/wMA/5n//ZkD/5mZ//qZAP/2mQT/mf+Z//2Z +P8AAMH/AFaB/6j/AgD///wA/f8CAP//+gAB/wD8/wEA/9EAnP8CAP///AD9/wIA///6AAH/APz/ AQD/0pkAAJz/AgD///wA/f8CAP//+gAB/wD8/wEA/9KZAADB/wAggf+S/wAA+f/RAIb/AAD5/9KZ AACG/wAA+f/SmQAAwf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8A DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8AdoH/jv/7AAf//wAA/wD/AP7/AwD/AAD2/wAA+/8C AP8A/P8CAP//+QCH//sAB///AAD/AP8A/v8DAP8AAPb/AAD7/wIA/wD8/wIA///5AIf/+wAH//8A AP8A/wD+/wMA/wAA9v8AAPv/AgD/APz/AgD///kAxv8AW4H/jv8CAAD//QAA//0ABP8AAP//8QD7 //cAAf//+gCH/wIAAP/9AAD//QAE/wAA///xAPv/9wAB///6AIf/AgAA//0AAP/9AAT/AAD///EA +//3AAH///oAxv8AhYH/jv/+AAb/AAD//wAA/v8AAP7/BgAA/wD/AP/3APz/AgAA//sAA///AP/7 AIf//gAG/wAA//8AAP7/AAD+/wYAAP8A/wD/9wD8/wIAAP/7AAP//wD/+wCH//4ABv8AAP//AAD+ /wAA/v8GAAD/AP8A//cA/P8CAAD/+wAD//8A//sAxv8ALoH/gf8C//8A9f8AAPz/AACB/+H/AAD1 /wAA/P8AAIH/4f8AAPX/AAD8/wAAr/8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/ gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B /4H/gf+x/wD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUm91 dGVyIChMU1IpIFRyYWZmaWMgRW5naW5lZXJpbmcgKFRFKSBtZXNoIG1lbWJlcnNoaXAgICBkcmFm dC12YXNzZXVyLWNjYW1wLWF1dG9tZXNoLTAwLnR4dAALAAAAQmFja2dyb3VuZAAXAAAAUXVpY2sg b3ZlcnZpZXcvc3VtbWFyeQAUAAAAUHJvcG9zZWQgbmV4dCBzdGVwcwAMEAAABgAAAB4AAAALAAAA Rm9udHMgVXNlZAADAAAABAAAAB4AAAAQAAAARGVzaWduIFRlbXBsYXRlAAMAAAABAAAAHgAAAA0A AABTbGlkZSBUaXRsZXMAAwAAAAQAAAAAAPACAAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAA AQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAAABAnAABBAAAAqAIAACQAAAADAAAABwAAAAMAAAAG AAAAAwAAAAAAAAADAAAABwAAAB8AAAAaAAAAbQBhAGkAbAB0AG8AOgBqAHYAYQBzAHMAZQB1AHIA QABjAGkAcwBjAG8ALgBjAG8AbQAAAB8AAAABAAAAAAAAAAMAAAAHAAAAAwAAAAYAAAADAAAAAAAA AAMAAAAHAAAAHwAAACUAAABtAGEAaQBsAHQAbwA6AHkAYQBzAHUAawBhAHcAYQAuAHMAZQBpAHMA aABvAEAAbABhAGIALgBuAHQAdAAuAGMAbwAuAGoAcAAAAAAAHwAAAAEAAAAAAAAAAwAAAAcAAAAD AAAABgAAAAMAAAAAAAAAAwAAAAcAAAAfAAAAKgAAAG0AYQBpAGwAdABvADoAagBlAGEAbgBsAG8A dQBpAHMALgBsAGUAcgBvAHUAeABAAGYAcgBhAG4AYwBlAHQAZQBsAGUAYwBvAG0ALgBjAG8AbQAA AB8AAAABAAAAAAAAAAMAAAAHAAAAAwAAAAYAAAADAAAAAAAAAAMAAAAHAAAAHwAAABgAAABtAGEA aQBsAHQAbwA6AHAAbQBhAGIAZQB5AEAAcQB3AGUAcwB0AC4AYwBvAG0AAAAfAAAAAQAAAAAAAAAD AAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8AAAAZAAAAbQBhAGkAbAB0AG8AOgBwAHAA cwBlAG4AYQBrAEAAYwBpAHMAYwBvAC4AYwBvAG0AAAAAAB8AAAABAAAAAAAAAAMAAAAHAAAAAwAA AAYAAAADAAAAAAAAAAMAAAAHAAAAHwAAABoAAABtAGEAaQBsAHQAbwA6AHMAcAByAGUAdgBpAGQA aQBAAGMAaQBzAGMAbwAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMAdQBy AHIAZQBuAHQAIABVAHMAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAaAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAA AD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2DyIA AAAUAAAAX8CR47Q/AAAKAPQDAwAiJEpQIFZhc3NldXIIAAAASgBQACAAVgBhAHMAcwBlAHUAcgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --Apple-Mail-2-984250060 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Thanks. > draft-ietf-ccamp-rsvp-restart-ext-01.txt > Arun Satyanarayana. No slides received > > draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt > Dimitri Papdimitriou. No slides received > > Presenters listed above must use their own laptops. > > Cheers, > Adrian > --Apple-Mail-2-984250060-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Mar 2005 13:14:34 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Date: Tue, 8 Mar 2005 13:14:08 -0000 Message-ID: Thread-Topic: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Thread-Index: AcUj3pQ6K1Bv7p0MQvGsa0GkGiUFAgAAPyaw From: To: Ashok, Thanks for the explanation. If I understand correctly what you are = saying is that the best current practice is to use an OOB control plane = for the non-PSC layer networks and an in-band control plane for the PSC = layer networks. So one must avoid using the control plane network (of a = non-PSC layer network) for the transfer of data (or control) plane = packets from the PSC layer network's control & data planes. Fine, I = agree that is the BCP, but I don't believe the current draft articulates = that intent very well and section 7.4 probably needs expanding (IMO one = or two paragraphs is probably not enough to discuss/address/detail OOB = Vs in-band properly and unambiguously), for example it is not IMO clear = from the current text that you are talking about 2 separate control = plane networks - one OOB (for non-PSC layer networks/nodes) and one = inband (for PSC layer networks/nodes). Thanks Ben > -----Original Message----- > From: Ashok Narayanan [mailto:ashokn@cisco.com] > Sent: 08 March 2005 12:59 > To: Niven-jenkins,B,Ben,XDE73 R > Cc: ccamp@ops.ietf.org > Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt >=20 >=20 > >=20 > > I am trying to understand section 7.4 (Separation of=20 > Control and Data Plane Traffic) of=20 > draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > >=20 > > The draft states: > > "PSC-capable nodes implementing an OOB control plane (perhaps to > > communicate with an optical switch) MUST NOT use the OOB control > > plane for data traffic. For example, in the case of MPLS service > > running on top of a GMPLS LSP, if the peer PSC device is reachable > > via both the control plane and the data plane, control protocols > > such as LDP MUST NOT form adjacencies over the control plane > > interfaces. This may be provided by a combination of implementation > > features and deployment guidelines." > >=20 > > So, if the control plane is OOB why must control protocols (such as > > LDP) NOT form adjacencies over the control plane interfaces? This > > implies that LDP (for e.g.) MUST form its adjacencies over the data > > plane interfaces and therefore LDP is not running OOB (and therefore > > the control plane is not entirely OOB). > >=20 >=20 > That's an interesting question. The draft focuses on GMPLS/TE > deployments and the use of an out-of-band control channel as a matter > of necessity (i.e. because optical switches are not capable of > handling in-band control traffic). Consider the general deployment of > a core of optical switches surrounded by GMPLS/TE routers at the > edge. From the perspective of this network (optical switches, edge > routers, and the links in between), that statement translates to: >=20 > _ The GMPLS/TE control plane between the edge routers and the optical > switches in the core is entirely out-of-band >=20 > - All other protocols between the edge routers MUST be=20 > entirely in-band. >=20 > The control plane network may well be a series of point-to-point GRE > tunnels overlaid on some other low-bandwidth network (actually this is > what the draft recommends). Ordinarily one would establish a GRE > tunnel between each pair of neighbors so they can talk to each other. > But this means that signalling messages going from edge router to edge > router actually have to be routed through the control planes of > intermediate switches. The two alternatives to avoid this (to create a > full mesh of GRE tunnels - at least between all the edge routers - or > to not use GRE at all if the control plane is switched Ethernet, and > therefore to essentially permit a full mesh of OSPF peers) are not > really palatable (and in the case of SDCC, not usable). The optical > switches in the core should not be in the business of routing > packets. Sometimes they have to (e.g. Notify messages), but they are > not designed for this purpose and should not be deployed as such. >=20 > And practically speaking the control network is expected to be a > low-bandwidth network that can "just get the job done". A single > 10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle the > control traffic for a GMPLS/TE network, but will probably fail if we > want to use it to peer LDP or BGP for 10,000 prefixes/labels between > the edge routers. >=20 > The best current practice is therefore to use the low-bandwidth > control network between routers and switches for GMPLS/TE signaling > (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical TE LSPs > signalled between edge routers to do other L3 protocols between them. >=20 > The issue of a separated control plane between PSC edge routers for > different L3 protocols for administrative reasons is an interesting > one. Nothing precludes you from creating multiple parallel LSPs > between edge routers and using one of them to carry control traffic > between the two edge routers on behalf of all the others; that would > still satisfy this requirement. Alternatively, one could engineer a > more beefy control plane network so that it can in fact carry all the > control plane traffic (BGP, LDP etc.) but that is not the BCP today > based on available implementations. >=20 > -Ashok >=20 > On Tue, Mar 08, 2005 at 10:33:54AM -0000,=20 > benjamin.niven-jenkins@bt.com wrote: > > Colleagues, > >=20 > > I am trying to understand section 7.4 (Separation of=20 > Control and Data Plane Traffic) of=20 > draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > >=20 > > The draft states: > > "PSC-capable nodes implementing an OOB control plane=20 > (perhaps to communicate with an optical switch) MUST NOT use=20 > the OOB control plane for data traffic. For example, in the=20 > case of MPLS service running on top of a GMPLS LSP, if the=20 > peer PSC device is reachable via both the control plane and=20 > the data plane, control protocols such as LDP MUST NOT form=20 > adjacencies over the control plane interfaces. This may be=20 > provided by a combination of implementation features and=20 > deployment guidelines." > >=20 > > So, if the control plane is OOB why must control protocols=20 > (such as LDP) NOT form adjacencies over the control plane=20 > interfaces? This implies that LDP (for e.g.) MUST form its=20 > adjacencies over the data plane interfaces and therefore LDP=20 > is not running OOB (and therefore the control plane is not=20 > entirely OOB). > >=20 > > Thanks > > Ben > >=20 > >=20 > > --=20 > > Ben Niven-Jenkins > > Networking Specialist, BT Exact > >=20 > > e-mail: benjamin.niven-jenkins@bt.com > > tel: +44(0) 1473 648225 > > mob: +44(0) 7918 077205 > >=20 > > pp34/161 B81 Callisto House, Adastral Park, Martlesham,=20 > Ipswich IP5 3RE, UK > >=20 > > BT Exact is a trademark of British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ > > Registered in England no. 1800000 > >=20 > > This electronic message contains information from British=20 > Telecommunications which may be privileged or confidential.=20 > The information is intended to be for the use of the=20 > individual(s) or the entity named above. If you are not the=20 > intended recipient be aware that any disclosure, copying,=20 > distribution or use of the contents of this information is=20 > prohibited. If you have received this electronic message in=20 > error, please notify us by telephone or email (to the numbers=20 > or address above) immediately.=20 > >=20 > > Activity and use of the British Telecommunications plc=20 > email system is monitored to secure its effective operation=20 > and for other lawful business purposes. Communications using=20 > this system will also be monitored and may be recorded to=20 > secure effective operation and for other lawful business purposes. >=20 > --=20 >=20 >=20 >=20 > --- Asok the Intern ---------------------------------------- > Ashok Narayanan > IOS Network Protocols, Cisco Systems > 1414 Mass Ave, Boxborough MA 01719 > Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Mar 2005 13:00:07 +0000 Date: Tue, 8 Mar 2005 07:58:33 -0500 From: Ashok Narayanan To: benjamin.niven-jenkins@bt.com Cc: ccamp@ops.ietf.org Subject: Re: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Message-ID: <20050308125833.GA32112@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i > > I am trying to understand section 7.4 (Separation of Control and Data Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > > The draft states: > "PSC-capable nodes implementing an OOB control plane (perhaps to > communicate with an optical switch) MUST NOT use the OOB control > plane for data traffic. For example, in the case of MPLS service > running on top of a GMPLS LSP, if the peer PSC device is reachable > via both the control plane and the data plane, control protocols > such as LDP MUST NOT form adjacencies over the control plane > interfaces. This may be provided by a combination of implementation > features and deployment guidelines." > > So, if the control plane is OOB why must control protocols (such as > LDP) NOT form adjacencies over the control plane interfaces? This > implies that LDP (for e.g.) MUST form its adjacencies over the data > plane interfaces and therefore LDP is not running OOB (and therefore > the control plane is not entirely OOB). > That's an interesting question. The draft focuses on GMPLS/TE deployments and the use of an out-of-band control channel as a matter of necessity (i.e. because optical switches are not capable of handling in-band control traffic). Consider the general deployment of a core of optical switches surrounded by GMPLS/TE routers at the edge. From the perspective of this network (optical switches, edge routers, and the links in between), that statement translates to: _ The GMPLS/TE control plane between the edge routers and the optical switches in the core is entirely out-of-band - All other protocols between the edge routers MUST be entirely in-band. The control plane network may well be a series of point-to-point GRE tunnels overlaid on some other low-bandwidth network (actually this is what the draft recommends). Ordinarily one would establish a GRE tunnel between each pair of neighbors so they can talk to each other. But this means that signalling messages going from edge router to edge router actually have to be routed through the control planes of intermediate switches. The two alternatives to avoid this (to create a full mesh of GRE tunnels - at least between all the edge routers - or to not use GRE at all if the control plane is switched Ethernet, and therefore to essentially permit a full mesh of OSPF peers) are not really palatable (and in the case of SDCC, not usable). The optical switches in the core should not be in the business of routing packets. Sometimes they have to (e.g. Notify messages), but they are not designed for this purpose and should not be deployed as such. And practically speaking the control network is expected to be a low-bandwidth network that can "just get the job done". A single 10/100 Ethernet (or, worse, 192kbps SDCCs) can probably handle the control traffic for a GMPLS/TE network, but will probably fail if we want to use it to peer LDP or BGP for 10,000 prefixes/labels between the edge routers. The best current practice is therefore to use the low-bandwidth control network between routers and switches for GMPLS/TE signaling (RSVP-TE, OSPF, LMP) and use the high-bandwidth optical TE LSPs signalled between edge routers to do other L3 protocols between them. The issue of a separated control plane between PSC edge routers for different L3 protocols for administrative reasons is an interesting one. Nothing precludes you from creating multiple parallel LSPs between edge routers and using one of them to carry control traffic between the two edge routers on behalf of all the others; that would still satisfy this requirement. Alternatively, one could engineer a more beefy control plane network so that it can in fact carry all the control plane traffic (BGP, LDP etc.) but that is not the BCP today based on available implementations. -Ashok On Tue, Mar 08, 2005 at 10:33:54AM -0000, benjamin.niven-jenkins@bt.com wrote: > Colleagues, > > I am trying to understand section 7.4 (Separation of Control and Data Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better. > > The draft states: > "PSC-capable nodes implementing an OOB control plane (perhaps to communicate with an optical switch) MUST NOT use the OOB control plane for data traffic. For example, in the case of MPLS service running on top of a GMPLS LSP, if the peer PSC device is reachable via both the control plane and the data plane, control protocols such as LDP MUST NOT form adjacencies over the control plane interfaces. This may be provided by a combination of implementation features and deployment guidelines." > > So, if the control plane is OOB why must control protocols (such as LDP) NOT form adjacencies over the control plane interfaces? This implies that LDP (for e.g.) MUST form its adjacencies over the data plane interfaces and therefore LDP is not running OOB (and therefore the control plane is not entirely OOB). > > Thanks > Ben > > > -- > Ben Niven-Jenkins > Networking Specialist, BT Exact > > e-mail: benjamin.niven-jenkins@bt.com > tel: +44(0) 1473 648225 > mob: +44(0) 7918 077205 > > pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, UK > > BT Exact is a trademark of British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > > This electronic message contains information from British Telecommunications which may be privileged or confidential. The information is intended to be for the use of the individual(s) or the entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. > > Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. -- --- Asok the Intern ---------------------------------------- Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Mar 2005 10:34:59 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Date: Tue, 8 Mar 2005 10:33:54 -0000 Message-ID: Thread-Topic: Question on draft-shiomoto-ccamp-gmpls-addressing-00.txt Thread-Index: AcUjylMWrzJFN4+1Edm5TAAwBQ7M6w== From: To: Colleagues, I am trying to understand section 7.4 (Separation of Control and Data = Plane Traffic) of draft-shiomoto-ccamp-gmpls-addressing-00.txt better. The draft states: "PSC-capable nodes implementing an OOB control plane (perhaps to = communicate with an optical switch) MUST NOT use the OOB control plane = for data traffic. For example, in the case of MPLS service running on = top of a GMPLS LSP, if the peer PSC device is reachable via both the = control plane and the data plane, control protocols such as LDP MUST NOT = form adjacencies over the control plane interfaces. This may be = provided by a combination of implementation features and deployment = guidelines." So, if the control plane is OOB why must control protocols (such as LDP) = NOT form adjacencies over the control plane interfaces? This implies = that LDP (for e.g.) MUST form its adjacencies over the data plane = interfaces and therefore LDP is not running OOB (and therefore the = control plane is not entirely OOB). Thanks Ben --=20 Ben Niven-Jenkins Networking Specialist, BT Exact e-mail: benjamin.niven-jenkins@bt.com tel: +44(0) 1473 648225 mob: +44(0) 7918 077205 pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, = UK BT Exact is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British = Telecommunications which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or the = entity named above. If you are not the intended recipient be aware that = any disclosure, copying, distribution or use of the contents of this = information is prohibited. If you have received this electronic message = in error, please notify us by telephone or email (to the numbers or = address above) immediately.=20 Activity and use of the British Telecommunications plc email system is = monitored to secure its effective operation and for other lawful = business purposes. Communications using this system will also be = monitored and may be recorded to secure effective operation and for = other lawful business purposes. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Mar 2005 08:45:39 +0000 Message-ID: <012c01c523b9$517e70d0$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Agenda and slides on line Date: Tue, 8 Mar 2005 08:31:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Agenda and slides on line at http://www.olddog.co.uk/62/ccamp.htm All there except... Status and plans for CCAMP re-charter Alex Zinin. No slides received. draft-vasseur-ccamp-automesh-00.txt JP Vasseur. Slides received but corrupt draft-ietf-ccamp-rsvp-restart-ext-01.txt Arun Satyanarayana. No slides received draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt Dimitri Papdimitriou. No slides received Presenters listed above must use their own laptops. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Mar 2005 01:03:16 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt Date: Tue, 8 Mar 2005 01:59:29 +0100 Message-ID: Thread-Topic: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt Thread-Index: AcUik9dvC+GJY5kCSi+DcYbYzFCuDwA5G+Lg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , Cc: , Hi dimitri Thanks for these comments Please see inline Regards JL >-----Message d'origine----- >De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20 >Envoy=E9 : dimanche 6 mars 2005 22:31 >=C0 : LE ROUX Jean-Louis RD-CORE-LAN >Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org >Objet : Re: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt > > >hi jean-louis > >the below discussion raises the issue that the decoupling of=20 >the control=20 >from the (data plane) resource admission control (driven by=20 >the Min/Max=20 >LSP bandwidith) raises the issue of the control plane=20 >saturation due to=20 >LSPs that do not reserve any bandwith/or allow for bandwidth=20 >reuse such=20 >low priority LSPs and therefore the #LSPs actually processed by the=20 >control plane can become much higher than the number of LSPs=20 >that could=20 >result from the Min LSP bandwidth parameter - this is a nice=20 >side effect=20 >of part of bunch of other control plane processing issues such=20 >prioritized treatment of control messages, concurrent requests, etc. > >i think the problem statement is rather scoped, however the solution=20 >scope seems to me to be raising correlation issue and further=20 >relationship with the data plane resource re-optimization=20 >issues we were=20 >discussing on this list a couple of times - i could sum'up this in one=20 >sentence is it suitable to flood the state of the signaling control=20 >engine using flooding or is the intention to consider this as an=20 >additional constraint -=20 Yes, in a way, this can be seen as an additional constraint. A head-end should avoid a saturated LSR when computing a path of a new = LSP. >note that in the former case flooding provides=20 >you a notification mechanism after occurrence but does not deliver any=20 >avoidance mechanism - Yes it does.=20 An LSR could anticipate the saturation, by setting the Saturation bit = once a threshold is reached. This is a local decision. > >this said is that really a "router capability" or do you mean here the=20 >capability to provide "control plane saturation tracking" ? No this is not a router capability, this is a control plane status. > >therefore, it would be probably advisable to be a bit less=20 >expeditive in=20 >terms of solution This a light and simple solution that IMHO solves the problem... Thanks JL > >thanks, >- dimitri. > >LE ROUX Jean-Louis RD-CORE-LAN wrote: > >> Hi Adrian, >>=20 >> Thanks a lot for these comments >>=20 >> Please see inline >>=20 >> Regards >>=20 >> JL >>=20 >>=20 >>=20 >>=20 >>> -----Message d'origine----- De : Adrian Farrel=20 >>> [mailto:adrian@olddog.co.uk] Envoy=E9 : mardi 1 f=E9vrier 2005 19:41 = =C0 >>> : LE ROUX Jean-Louis RD-CORE-LAN Cc : ccamp@ops.ietf.org Objet : >>> Re: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt >>>=20 >>>=20 >>> Jean-Louis, >>>=20 >>> Thanks for this draft. >>>=20 >>> A couple of immediate thoughts. >>>=20 >>> 1. What is wrong with using Error Code 23? >>=20 >>=20 >> Error code 23 is used for "System Errors". IMHO the saturation=20 >> semantic defined here is quite different. >>=20 >>=20 >>=20 >>> 2. Will implementations really want to confess to the reason that=20 >>> they are unable to handle more LSPs? It seems to me that it=20 >would be=20 >>> a remarkably honest implementation that implemented this draft. >>>=20 >>=20 >>=20 >> Bascially the draft proposes to handle properly control plane=20 >> saturation cases. If you want to handle these cases you need a=20 >> dedicated error code, this would allow Head-end LSRs to take=20 >> appropriate actions. >>=20 >>=20 >>> Isn't it more likely that the LSR would claim an admission control=20 >>> error? 3. >>=20 >>=20 >> Saturation is not and admission control problem >>=20 >>=20 >>> "The head-end should not reroute already established LSPs passing=20 >>> through the saturated node." Why ever not? Surely this is local=20 >>> policy, and the ingress may know that the only way to route its new=20 >>> and projected LSPs is to move some of the existing ones. >>=20 >>=20 >> Stability is better, the LSR is already supporting a set of TE-LSPs,=20 >> it is saturated, why would you want to move these LSPs? >>=20 >> 4. Why is saturation a good thing to advertise in the >>=20 >>> IGP? If an LSR wishes to prevent new LSPs being routed=20 >through it, it=20 >>> should withdraw bandwidth just as it would if the signaling=20 >elements=20 >>> of the control plane had failed. 5. >>=20 >>=20 >> But what about 0 bandwidth LSPs? A head-end may select a node with 0=20 >> bandwidth available, when computing the path of a 0=20 >bandwidth LSP. So=20 >> withdrawing bandwidth is not sufficient to handle properly control=20 >> plane saturations >>=20 >>=20 >>=20 >>> Much of the draft restates default behavior (e.g. what to=20 >do when you=20 >>> receive a Path message). This is interesting information for the=20 >>> reader, but I am not sure that it is right to present it here. >>>=20 >>=20 >>=20 >> Agree >>=20 >> 6. Why does the new Error Codes have three Error Values, >>=20 >>> but the Saturation TLV only have one bit defined? >>=20 >>=20 >> Good point, we need to define 3 flags >>=20 >>=20 >>> 7. Section 5.2. All "MUST" should be "SHOULD" I think. >>=20 >>=20 >> Why? This is IMHO a mandatory behavior for an implementation=20 >compliant=20 >> with this draft. >>=20 >>=20 >>> My main question is why you need this draft. It seems that you can=20 >>> already achieve all of these features using existing protocol=20 >>> elements. >>=20 >>=20 >> I think that this would be cleaner with these light signaling and=20 >> routing extensions. >>=20 >>=20 >>> At most you might want to write a one page BCP to say what=20 >a transit=20 >>> or egress LSP should do when it cannot handle a new LSP because of=20 >>> some internal resource shortage other than an admission control=20 >>> problem. >>=20 >>=20 >> But the problem is that we consider that when a transit or=20 >egress LSR=20 >> cannot handle a new LSP because of some internal resource shortage=20 >> other than an admission control problem, it should notify=20 >the head end=20 >> about its saturation, and if you want proper reaction you need a=20 >> specific notification...thus dedicated error code points are required >>=20 >>=20 >> Again thanks a lot for these comments >>=20 >> Regards >>=20 >> JL >>=20 >>=20 >>=20 >>> Cheers, Adrian >>>=20 >>>=20 >>> ----- Original Message ----- From: "LE ROUX Jean-Louis=20 >RD-CORE-LAN" =20 >>> To: >>> Sent: Tuesday, February 01, 2005 7:21 AM Subject: TR: I-D=20 >>> ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt >>>=20 >>>=20 >>> Hi all, >>>=20 >>> We just posted a new draft related to (G)MPLS-TE control plane >>> resource shortages. Your comments/feedbacks on this draft are >>> welcome. >>>=20 >>> Regards, >>>=20 >>> JL >>>=20 >>>=20 >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>> directories. >>>=20 >>>=20 >>> Title : Procedure to handle (G)MPLS-TE control plane saturation >>> Author(s) : J. Le Roux, et al. Filename : >>> draft-leroux-ccamp-ctrl-saturation-00.txt Pages : 10 Date : >>> 2005-1-31 >>>=20 >>> This document defines extensions to RSVP-TE (Resource Reservation >>> Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to >>> signal control plane resources saturation, when an LSR runs out of >>> control plane resources available to support a new LSP. Such=20 >>> notification may serve as trigger for the impacted Head-end LSR to=20 >>> take appropriate actions. >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-sat >>=20 >> uration-0 0.txt >>=20 >> To remove yourself from the I-D Announcement list, send a message to=20 >> i-d-announce-request at ietf.org with the word unsubscribe=20 >in the body=20 >> of the message. You can also visit=20 >> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your=20 >> subscription settings. >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP. Login with the=20 >> username "anonymous" and a password of your e-mail address. After=20 >> logging in, type "cd internet-drafts" and then "get=20 >> draft-leroux-ccamp-ctrl-saturation-00.txt". >>=20 >> A list of Internet-Drafts directories can be found in=20 >> http://www.ietf.org/shadow.html or=20 >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >>=20 >> Internet-Drafts can also be obtained by e-mail. >>=20 >> Send a message to: mailserv at ietf.org. In the body type: "FILE=20 >> /internet-drafts/draft-leroux-ccamp-ctrl-saturation-00.txt". >>=20 >> NOTE: The mail server at ietf.org can return the document in=20 >> MIME-encoded form by using the "mpack" utility. To use this=20 >feature,=20 >> insert the command "ENCODING mime" before the "FILE" command. To=20 >> decode the response(s), you will need "munpack" or a MIME-compliant=20 >> mail reader. Different MIME-compliant mail readers exhibit=20 >different=20 >> behavior, especially when dealing with "multipart" MIME=20 >messages (i.e.=20 >> documents which have been split up into multiple messages), so check=20 >> your local documentation on how to manipulate these messages. >>=20 >>=20 >> Below is the data which will enable a MIME compliant mail reader=20 >> implementation to automatically retrieve the ASCII version of the=20 >> Internet-Draft.=20 >>=20 >> -0 >> 0.txt> >>=20 > 0.txt> >=20 >=20 >=20 >=20 > . >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Mar 2005 20:55:58 +0000 Message-ID: <016101c52357$c29c0960$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: CCAMP Draft status page Date: Mon, 7 Mar 2005 20:50:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have had a go at updating this. http://www.olddog.co.uk/ccamp.htm If there are errors please shout, but not until after this week because I will simply not find your message in all the rest of the noise! Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Mar 2005 04:56:18 +0000 Message-ID: <006801c522b4$c7517830$a4858182@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Kireeti Kompella" , "Tomonori TAKEDA" , Cc: "Igor Bryskin" , Subject: Re: What is happenning to CCAMP WG recharter ? Date: Sun, 6 Mar 2005 18:34:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Alex has been press-ganged into coming to the CCAMP meeting. He will be able to explain where we stand and what the next steps are. Thanks for pursuing this. Adrian ----- Original Message ----- From: "Kireeti Kompella" To: "Tomonori TAKEDA" Cc: "Igor Bryskin" ; ; Sent: Monday, February 28, 2005 12:04 AM Subject: Re: What is happenning to CCAMP WG recharter ? > On Wed, 23 Feb 2005, Tomonori TAKEDA wrote: > > > The same question arises to me. I thought we had good amount of discussion > > about new charter items. Is there any open issue? > > It's on the ADs' plate. > > Alex? Bill? > > Kireeti. > ------- > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 06 Mar 2005 22:58:45 +0000 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <606d83edd8741dc6ef3e2b32627907ac@cisco.com> Content-Transfer-Encoding: quoted-printable Cc: adrian@olddog.co.uk, LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org From: JP Vasseur Subject: Re: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt Date: Sun, 6 Mar 2005 17:58:07 -0500 To: dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com Hi Dimitri, On Mar 6, 2005, at 4:31 PM, dimitri papadimitriou wrote: > hi jean-louis > > the below discussion raises the issue that the decoupling of the =20 > control from the (data plane) resource admission control (driven by =20= > the Min/Max LSP bandwidith) raises the issue of the control plane =20 > saturation due to LSPs that do not reserve any bandwith/or allow for =20= > bandwidth reuse such low priority LSPs and therefore the #LSPs =20 > actually processed by the control plane can become much higher than =20= > the number of LSPs that could result from the Min LSP bandwidth =20 > parameter - this is a nice side effect of part of bunch of other =20 > control plane processing issues such prioritized treatment of control =20= > messages, concurrent requests, etc. > > i think the problem statement is rather scoped, however the solution =20= > scope seems to me to be raising correlation issue and further =20 > relationship with the data plane resource re-optimization issues we =20= > were discussing on this list a couple of times - i could sum'up this =20= > in one sentence is it suitable to flood the state of the signaling =20 > control engine using flooding or is the intention to consider this as =20= > an additional constraint - note that in the former case flooding =20 > provides you a notification mechanism after occurrence but does not =20= > deliver any avoidance mechanism - > it provides a notification mechanism that a head-end should consider as =20= a constraint. > this said is that really a "router capability" or do you mean here the = =20 > capability to provide "control plane saturation tracking" ? > the later. > therefore, it would be probably advisable to be a bit less expeditive =20= > in terms of solution > "expeditive" ? Thanks. JP. > thanks, > - dimitri. > > LE ROUX Jean-Louis RD-CORE-LAN wrote: > >> Hi Adrian, >> Thanks a lot for these comments >> Please see inline >> Regards >> JL >>> -----Message d'origine----- De : Adrian Farrel >>> [mailto:adrian@olddog.co.uk] Envoy=E9 : mardi 1 f=E9vrier 2005 19:41 = =C0 >>> : LE ROUX Jean-Louis RD-CORE-LAN Cc : ccamp@ops.ietf.org Objet : >>> Re: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt >>> Jean-Louis, >>> Thanks for this draft. >>> A couple of immediate thoughts. >>> 1. What is wrong with using Error Code 23? >> Error code 23 is used for "System Errors". IMHO the saturation >> semantic defined here is quite different. >>> 2. Will implementations really want to confess to the reason that >>> they are unable to handle more LSPs? It seems to me that it would >>> be a remarkably honest implementation that implemented this draft. >> Bascially the draft proposes to handle properly control plane >> saturation cases. If you want to handle these cases you need a >> dedicated error code, this would allow Head-end LSRs to take >> appropriate actions. >>> Isn't it more likely that the LSR would claim an admission control >>> error? 3. >> Saturation is not and admission control problem >>> "The head-end should not reroute already established LSPs passing >>> through the saturated node." Why ever not? Surely this is local =20 >>> policy, and the ingress may know that the only way to route its new >>> and projected LSPs is to move some of the existing ones. >> Stability is better, the LSR is already supporting a set of TE-LSPs, >> it is saturated, why would you want to move these LSPs? >> 4. Why is saturation a good thing to advertise in the >>> IGP? If an LSR wishes to prevent new LSPs being routed through it, >>> it should withdraw bandwidth just as it would if the signaling >>> elements of the control plane had failed. 5. >> But what about 0 bandwidth LSPs? A head-end may select a node with 0 >> bandwidth available, when computing the path of a 0 bandwidth LSP. So >> withdrawing bandwidth is not sufficient to handle properly control >> plane saturations >>> Much of the draft restates default behavior (e.g. what to do when >>> you receive a Path message). This is interesting information for the = =20 >>> reader, but I am not sure that it is right to present it here. >> Agree >> 6. Why does the new Error Codes have three Error Values, >>> but the Saturation TLV only have one bit defined? >> Good point, we need to define 3 flags >>> 7. Section 5.2. All "MUST" should be "SHOULD" I think. >> Why? This is IMHO a mandatory behavior for an implementation >> compliant with this draft. >>> My main question is why you need this draft. It seems that you can >>> already achieve all of these features using existing protocol >>> elements. >> I think that this would be cleaner with these light signaling and >> routing extensions. >>> At most you might want to write a one page BCP to say what a >>> transit or egress LSP should do when it cannot handle a new LSP >>> because of some internal resource shortage other than an admission >>> control problem. >> But the problem is that we consider that when a transit or egress LSR >> cannot handle a new LSP because of some internal resource shortage >> other than an admission control problem, it should notify the head >> end about its saturation, and if you want proper reaction you need a >> specific notification...thus dedicated error code points are required >> Again thanks a lot for these comments >> Regards >> JL >>> Cheers, Adrian >>> ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN" >>> To: Sent: = =20 >>> Tuesday, February 01, 2005 7:21 AM Subject: TR: I-D >>> ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt >>> Hi all, >>> We just posted a new draft related to (G)MPLS-TE control plane =20 >>> resource shortages. Your comments/feedbacks on this draft are >>> welcome. >>> Regards, >>> JL >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> Title : Procedure to handle (G)MPLS-TE control plane saturation =20 >>> Author(s) : J. Le Roux, et al. Filename : >>> draft-leroux-ccamp-ctrl-saturation-00.txt Pages : 10 Date : >>> 2005-1-31 >>> This document defines extensions to RSVP-TE (Resource Reservation =20= >>> Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to >>> signal control plane resources saturation, when an LSR runs out of >>> control plane resources available to support a new LSP. Such =20 >>> notification may serve as trigger for the impacted Head-end LSR to =20= >>> take appropriate actions. >>> A URL for this Internet-Draft is: =20 >>> http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-sat >> uration-0 0.txt >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request at ietf.org with the word unsubscribe in the >> body of the message. You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your >> subscription settings. >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then "get >> draft-leroux-ccamp-ctrl-saturation-00.txt". >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> Internet-Drafts can also be obtained by e-mail. >> Send a message to: mailserv at ietf.org. In the body type: "FILE >> /internet-drafts/draft-leroux-ccamp-ctrl-saturation-00.txt". >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this feature, >> insert the command "ENCODING mime" before the "FILE" command. To >> decode the response(s), you will need "munpack" or a MIME-compliant >> mail reader. Different MIME-compliant mail readers exhibit different >> behavior, especially when dealing with "multipart" MIME messages >> (i.e. documents which have been split up into multiple messages), so >> check your local documentation on how to manipulate these messages. >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > saturation-0 >> 0.txt> >> > saturation-0 >> 0.txt> >> . > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 06 Mar 2005 21:33:15 +0000 Message-ID: <422B7697.9010600@psg.com> Date: Sun, 06 Mar 2005 22:31:03 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN CC: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit hi jean-louis the below discussion raises the issue that the decoupling of the control from the (data plane) resource admission control (driven by the Min/Max LSP bandwidith) raises the issue of the control plane saturation due to LSPs that do not reserve any bandwith/or allow for bandwidth reuse such low priority LSPs and therefore the #LSPs actually processed by the control plane can become much higher than the number of LSPs that could result from the Min LSP bandwidth parameter - this is a nice side effect of part of bunch of other control plane processing issues such prioritized treatment of control messages, concurrent requests, etc. i think the problem statement is rather scoped, however the solution scope seems to me to be raising correlation issue and further relationship with the data plane resource re-optimization issues we were discussing on this list a couple of times - i could sum'up this in one sentence is it suitable to flood the state of the signaling control engine using flooding or is the intention to consider this as an additional constraint - note that in the former case flooding provides you a notification mechanism after occurrence but does not deliver any avoidance mechanism - this said is that really a "router capability" or do you mean here the capability to provide "control plane saturation tracking" ? therefore, it would be probably advisable to be a bit less expeditive in terms of solution thanks, - dimitri. LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Adrian, > > Thanks a lot for these comments > > Please see inline > > Regards > > JL > > > > >> -----Message d'origine----- De : Adrian Farrel >> [mailto:adrian@olddog.co.uk] Envoyé : mardi 1 février 2005 19:41 À >> : LE ROUX Jean-Louis RD-CORE-LAN Cc : ccamp@ops.ietf.org Objet : >> Re: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt >> >> >> Jean-Louis, >> >> Thanks for this draft. >> >> A couple of immediate thoughts. >> >> 1. What is wrong with using Error Code 23? > > > Error code 23 is used for "System Errors". IMHO the saturation > semantic defined here is quite different. > > > >> 2. Will implementations really want to confess to the reason that >> they are unable to handle more LSPs? It seems to me that it would >> be a remarkably honest implementation that implemented this draft. >> > > > Bascially the draft proposes to handle properly control plane > saturation cases. If you want to handle these cases you need a > dedicated error code, this would allow Head-end LSRs to take > appropriate actions. > > >> Isn't it more likely that the LSR would claim an admission control >> error? 3. > > > Saturation is not and admission control problem > > >> "The head-end should not reroute already established LSPs passing >> through the saturated node." Why ever not? Surely this is local >> policy, and the ingress may know that the only way to route its new >> and projected LSPs is to move some of the existing ones. > > > Stability is better, the LSR is already supporting a set of TE-LSPs, > it is saturated, why would you want to move these LSPs? > > 4. Why is saturation a good thing to advertise in the > >> IGP? If an LSR wishes to prevent new LSPs being routed through it, >> it should withdraw bandwidth just as it would if the signaling >> elements of the control plane had failed. 5. > > > But what about 0 bandwidth LSPs? A head-end may select a node with 0 > bandwidth available, when computing the path of a 0 bandwidth LSP. So > withdrawing bandwidth is not sufficient to handle properly control > plane saturations > > > >> Much of the draft restates default behavior (e.g. what to do when >> you receive a Path message). This is interesting information for >> the reader, but I am not sure that it is right to present it here. >> > > > Agree > > 6. Why does the new Error Codes have three Error Values, > >> but the Saturation TLV only have one bit defined? > > > Good point, we need to define 3 flags > > >> 7. Section 5.2. All "MUST" should be "SHOULD" I think. > > > Why? This is IMHO a mandatory behavior for an implementation > compliant with this draft. > > >> My main question is why you need this draft. It seems that you can >> already achieve all of these features using existing protocol >> elements. > > > I think that this would be cleaner with these light signaling and > routing extensions. > > >> At most you might want to write a one page BCP to say what a >> transit or egress LSP should do when it cannot handle a new LSP >> because of some internal resource shortage other than an admission >> control problem. > > > But the problem is that we consider that when a transit or egress LSR > cannot handle a new LSP because of some internal resource shortage > other than an admission control problem, it should notify the head > end about its saturation, and if you want proper reaction you need a > specific notification...thus dedicated error code points are required > > > Again thanks a lot for these comments > > Regards > > JL > > > >> Cheers, Adrian >> >> >> ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN" >> To: >> Sent: Tuesday, February 01, 2005 7:21 AM Subject: TR: I-D >> ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt >> >> >> Hi all, >> >> We just posted a new draft related to (G)MPLS-TE control plane >> resource shortages. Your comments/feedbacks on this draft are >> welcome. >> >> Regards, >> >> JL >> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Procedure to handle (G)MPLS-TE control plane saturation >> Author(s) : J. Le Roux, et al. Filename : >> draft-leroux-ccamp-ctrl-saturation-00.txt Pages : 10 Date : >> 2005-1-31 >> >> This document defines extensions to RSVP-TE (Resource Reservation >> Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to >> signal control plane resources saturation, when an LSR runs out of >> control plane resources available to support a new LSP. Such >> notification may serve as trigger for the impacted Head-end LSR to >> take appropriate actions. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-sat > > uration-0 0.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the > body of the message. You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce to change your > subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then "get > draft-leroux-ccamp-ctrl-saturation-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: mailserv at ietf.org. In the body type: "FILE > /internet-drafts/draft-leroux-ccamp-ctrl-saturation-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this feature, > insert the command "ENCODING mime" before the "FILE" command. To > decode the response(s), you will need "munpack" or a MIME-compliant > mail reader. Different MIME-compliant mail readers exhibit different > behavior, especially when dealing with "multipart" MIME messages > (i.e. documents which have been split up into multiple messages), so > check your local documentation on how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > 0.txt> > 0.txt> > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 06 Mar 2005 18:29:42 +0000 Message-ID: <422B4BA7.3090300@psg.com> Date: Sun, 06 Mar 2005 19:27:51 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 MIME-Version: 1.0 To: Kireeti Kompella CC: dimitri.papadimitriou@alcatel.be, Igor Bryskin , yakov@juniper.net, ccamp@ops.ietf.org Subject: Re: A philosophical question about FA and FA-LSP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi - see in-line: Kireeti Kompella wrote: > On Sat, 5 Mar 2005, dimitri papadimitriou wrote: > > >>>What's special? Nothing really. A "normal" TE link usually has a >>>(single) physical interface associated with it; an FA TE link is >>>usually multi-hop. A "normal" TE link usually is accompanied by an >>>IGP adjacency (at least, in the packet domain); an FA TE link usually >>>doesn't. >> >>but if a couple this with your answer "Correct -- LSPs created in IGP A >>can be advertised as TE links in IGP B. This can be used (say) for >>inter-area signaling." don't you have now an adjacency accompanying the >>TE link advertisement in IGP B > > > Not necessarily. Say you have: > > IGP B - X == IGP A == Y - IGP B > > X and Y participate in both IGPs; X has an LSP to Y, and advertises it > into IGP B. All's fine. > > I'm guessing you are referring to the fact that IGP B appears > partitioned? Well, to connect up the piece on the right with the > piece on the left, one can: > a) create an adjacency over the FA LSP (only possible if LSP is PSC) ok but is that not another adjacency accompanying the TE link advertisement for (or in) IGP B as stated in my previous reply ? > b) have a virtual link (OSPF) from X to Y > c) have some other "backdoor" connection between the two parts. the same applying for the other cases >>- therefore why is there a need to rename >>the canonical inheritance i.e. why not just speak in that case about a >>TE link or a "hierarchical TE link" as it was the case in one of the >>earlier versions of the LSP-HIER document and keep the FA concept when >>dealing with a unique instance ? > > You can call it what you like :-) "FA" in particular refers to the > idea that the "adjacency" is primarily for forwarding, and not > necessarily for the control plane. However, the latter is not ruled > out (as in case (a) above.) initially the term has been introduced to implicitly allow for the creation of a forwarding adjacency *without introducing a control plane adjacency* solving the facto scaling of the control plane both in terms of routing (creation of a data plane adjacency does not trigger creation of a routing adjacency therefore the number of routing adjacencies remains constant independently of the number of data plane adjacencies) and signaling (resulting from the LSP nesting operations), and the inherent problem associated to the so-called "unknown adjacency" problem that was also the achille heel of the IPoverATM approach where one had to create a full-mesh of VCs to determine the reachable end-points from the IP level i do believe we are in agreement on this point - if not please let me know - now on the issue concerning not ruling out case a) as described here above how do you position this with the following paragraph in the LSP-Hierarchy document " It is expected that FAs will not be used for establishing ISIS/OSPF peering relation between the routers at the ends of the adjacency." probably we do not have to preclude this but it would be advisable to consider a self-consistent terminology to describe the sub-cases we are dealing with thanks, - dimitri. > Kireeti. > ------- > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 05 Mar 2005 21:56:38 +0000 Message-ID: <0e6501c521cd$9d8e05f0$19cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , "Igor Bryskin" Cc: , "Igor Bryskin" , "LE ROUX Jean-Louis RD-CORE-LAN" , Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Date: Sat, 5 Mar 2005 16:30:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Why are we talking about signaling virtual FA LSPs? I thought the point of a virtual FA was that it was entirely putative. Seems like you are talking about something more solid than a virtual FA LSP. Adrian ----- Original Message ----- From: "dimitri papadimitriou" To: "Igor Bryskin" Cc: ; "Igor Bryskin" ; "LE ROUX Jean-Louis RD-CORE-LAN" ; Sent: Saturday, March 05, 2005 3:03 PM Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt > igor - i will provide a detailed answer concerning a clean method to > deal with "virtual FAs" that does not rely on the use of the protection > object (and therefore would deliver a clean method to provide signaling > for protected "virtual FAs" > > hopefully we can discuss this during this IETF meeting, > > thanks, > - dimitri. > > Igor Bryskin wrote: > > > Dimitri, > > > > See at the bottom > > > > > >>>IB>>Well, are they? They give you a way to signal a > >>>requirement not to commit resources for an LSP > > > > until > > > >>>further notice and also to require their commitment > >>>when it becomes necessary. Why not to allow working > >>>LSP to be signaled as Secondary according to the > >>>mentioned draft? Then it would be possible even to > >>>signal protected virtual FAs, which is not as > > > > stupid > > > >>>as it may sound :=) > >> > >>Sorry but this sounds really bad... > >>Please let me know then how do you signal protected > > > > virtual FAs? > > > >>IB>> You signal both working and protection LSPs of > > > > the FA as Secondary. > > At > > > >>the time when you decide to make FA "real" you > > > > re-signal working or both > > > >>LSPs (depending on protection type) as Primary. > > > > Don't see why this > > wouldn't > > > >>work. > >> > >>DP> because what do you do in case the primary > > > > (virtual) FA-LSP fails ? > > you > > > >>are simply going to activate the secondary (virtual) > > > > FA-LSP which is in > > > >>clear > >>opposition with the notion of virtual-FA - the > > > > reason is again because you > > > >>are trying to use one bit i.e. S to say something in > > > > a context (protection > > > >>object) for which it has not been designed for > >> > > > > > > IB>> Oh-Oh, what do you mean by "primary (virtual) > > FA-LSP fails" and "you > > are simply going to activate the secondary (virtual) > > FA-LSP "? I activate > > protection LSP if I have a failure in the *data plane* > > of the working LSP. > > But working LSP of the virtual FA does not have any > > data plane yet, there is > > nothing that can trigger the protection LSP activation > > and switchover. > > > > DP> but they are associated to resources they do not > > use - and the control plane role is to ensure that > > when they need to be activated resources can be used - > > the question JL raises is the problem of "how do i > > protect a virtual FA" and the response is if you are > > using the S bit for telling i am a virtual FA you can > > not use it anymore to ensure protection of a primary > > (and even less a secondary !) - this said an secondary > > LSP exists only within the context of its primary > > > > IB>>Here is what I have in mind. > > > > A network operator configures a mesh of virtual FAs. > > Working FA LSPs are signaled as Secondary. Once they > > are established the FA TE link ends are advertised. > > Resources for these LSPs are allocated on the links > > the LSPs are going through, however, they are not > > committed (not bound into cross-connects). Two or more > > virtual FA LSPs may share the resources on common > > links. This is especially true for those of them that > > are unlikely to become real at the same time. > > Furthermore, polices could be such that virtual FA LSP > > resources could be allowed to get pre-empted by real > > (not necessarily FA-) LSPs. The mentioned resources > > also could be involved in mesh restoration schemes and > > even be bound into extra traffic LSPs. > > > > When a virtual FA transforms into real FA, its working > > FA-LSP is re-signaled as Primary. At this time, the > > allocated resources are bound into FA-LSP > > cross-connects. Naturally, all other LSPs – virtual or > > real – that share resources with the FA-LSP in > > question are notified and need to be recomputed and/or > > re-signaled. > > > > A virtual FA could be provisioned as protected in a > > sense that when it becomes real it will have a certain > > protection scheme already in place. Path computation > > for backup LSPs of virtual FAs is performed just like > > of real FAs, that is, by assuming that associated > > working LSPs are Primary (fully built) LSPs. > > Regardless of the protection type backup LSPs of > > virtual FAs are always signaled as Secondary. At the > > time when a virtual FA is transformed into real one > > (that is, when its working LSP becomes Primary) its > > backup LSP(s) may be activated as well (e.g. 1+1 > > protection) or may be left Secondary until the working > > LSP data plane failure is detected (e.g. shared > > protection). > > > > Igor > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > > > . > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 05 Mar 2005 18:51:54 +0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=y4CYz/xM+wVfrTxVflmwKoigseGLCu509ypm9ibzfdfdhXRr6rk2euW3HFD94AVuWddaqc2EGm430rKJQEG3YIiLcgIviWlSn2kz6iO9v9T/fkX0UvKwqpjuMqos8UHo6dJn4Mou9oJIabNX2dtGD0t6FMR0G7BKl7UvD6Oge3Q= ; Message-ID: <20050305185054.87306.qmail@web30810.mail.mud.yahoo.com> Date: Sat, 5 Mar 2005 10:50:54 -0800 (PST) From: Igor Bryskin Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Cc: Dimitri.Papadimitriou@alcatel.be, Igor Bryskin , LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Excellent. Looking forward to the discussion. Hopefully, I’ll get to understand what is not clean about the mechanism I suggested. Before we start the discussion, I’d like to make clear that all I am asking is a capability to provision working LSPs as Secondary LSPs. Note that this is a generic mechanism, and signaling of virtual FAs is one of possibly many applications that can make use of it. For example, on many occasions I hear a requirement from service providers to provide a way of provisioning a service when part of network resources are not in place yet with actual service activation after all resources are installed. This is necessary to make sure that resources that are in place are not “grabbed” by other dynamically provisioned services. This problem could be easily solved by the suggested mechanism. Lastly, despite what you and JL are saying, provisioning of virtual FAs has a lot to do with recovery. It is usually a MUST requirement for FAs to be protected. In this case if you provision virtual FA as unprotected, and, while it is transformed into real FA, try to compute/provision protection LSP, the computation may fail despite that two disjoint paths do exist and could be determined if they were computed at the same time. Therefore, it should be possible to compute working and protection (possibly multiple as in case of segment protection) path(s) for virtual FA and signal them, associating them together, without committing network resource for neither of them. See you in Minneapolis, Igor --- dimitri papadimitriou wrote: > igor - i will provide a detailed answer concerning a > clean method to > deal with "virtual FAs" that does not rely on the > use of the protection > object (and therefore would deliver a clean method > to provide signaling > for protected "virtual FAs" > > hopefully we can discuss this during this IETF > meeting, > > thanks, > - dimitri. > > Igor Bryskin wrote: > > > Dimitri, > > > > See at the bottom > > > > > >>>IB>>Well, are they? They give you a way to signal > a > >>>requirement not to commit resources for an LSP > > > > until > > > >>>further notice and also to require their > commitment > >>>when it becomes necessary. Why not to allow > working > >>>LSP to be signaled as Secondary according to the > >>>mentioned draft? Then it would be possible even > to > >>>signal protected virtual FAs, which is not as > > > > stupid > > > >>>as it may sound :=) > >> > >>Sorry but this sounds really bad... > >>Please let me know then how do you signal > protected > > > > virtual FAs? > > > >>IB>> You signal both working and protection LSPs > of > > > > the FA as Secondary. > > At > > > >>the time when you decide to make FA "real" you > > > > re-signal working or both > > > >>LSPs (depending on protection type) as Primary. > > > > Don't see why this > > wouldn't > > > >>work. > >> > >>DP> because what do you do in case the primary > > > > (virtual) FA-LSP fails ? > > you > > > >>are simply going to activate the secondary > (virtual) > > > > FA-LSP which is in > > > >>clear > >>opposition with the notion of virtual-FA - the > > > > reason is again because you > > > >>are trying to use one bit i.e. S to say something > in > > > > a context (protection > > > >>object) for which it has not been designed for > >> > > > > > > IB>> Oh-Oh, what do you mean by "primary (virtual) > > FA-LSP fails" and "you > > are simply going to activate the secondary > (virtual) > > FA-LSP "? I activate > > protection LSP if I have a failure in the *data > plane* > > of the working LSP. > > But working LSP of the virtual FA does not have > any > > data plane yet, there is > > nothing that can trigger the protection LSP > activation > > and switchover. > > > > DP> but they are associated to resources they do > not > > use - and the control plane role is to ensure that > > when they need to be activated resources can be > used - > > the question JL raises is the problem of "how do i > > protect a virtual FA" and the response is if you > are > > using the S bit for telling i am a virtual FA you > can > > not use it anymore to ensure protection of a > primary > > (and even less a secondary !) - this said an > secondary > > LSP exists only within the context of its primary > > > > IB>>Here is what I have in mind. > > > > A network operator configures a mesh of virtual > FAs. > > Working FA LSPs are signaled as Secondary. Once > they > > are established the FA TE link ends are > advertised. > > Resources for these LSPs are allocated on the > links > > the LSPs are going through, however, they are not > > committed (not bound into cross-connects). Two or > more > > virtual FA LSPs may share the resources on common > > links. This is especially true for those of them > that > > are unlikely to become real at the same time. > > Furthermore, polices could be such that virtual FA > LSP > > resources could be allowed to get pre-empted by > real > > (not necessarily FA-) LSPs. The mentioned > resources > > also could be involved in mesh restoration schemes > and > > even be bound into extra traffic LSPs. > > > > When a virtual FA transforms into real FA, its > working > > FA-LSP is re-signaled as Primary. At this time, > the > > allocated resources are bound into FA-LSP > > cross-connects. Naturally, all other LSPs – > virtual or > > real – that share resources with the FA-LSP in > > question are notified and need to be recomputed > and/or > > re-signaled. > > > > A virtual FA could be provisioned as protected in > a > > sense that when it becomes real it will have a > certain > > protection scheme already in place. Path > computation > > for backup LSPs of virtual FAs is performed just > like > > of real FAs, that is, by assuming that associated > > working LSPs are Primary (fully built) LSPs. > > Regardless of the protection type backup LSPs of > > virtual FAs are always signaled as Secondary. At > the > > time when a virtual FA is transformed into real > one > > (that is, when its working LSP becomes Primary) > its > > backup LSP(s) may be activated as well (e.g. 1+1 > > protection) or may be left Secondary until the > working > > LSP data plane failure is detected (e.g. shared > > protection). > > > > Igor > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > > > . > > > > __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 05 Mar 2005 17:47:18 +0000 Date: Sat, 5 Mar 2005 09:45:55 -0800 (PST) From: Kireeti Kompella To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be cc: Igor Bryskin , yakov@juniper.net, ccamp@ops.ietf.org Subject: Re: A philosophical question about FA and FA-LSP Message-ID: <20050305093157.A79191@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 5 Mar 2005, dimitri papadimitriou wrote: > > What's special? Nothing really. A "normal" TE link usually has a > > (single) physical interface associated with it; an FA TE link is > > usually multi-hop. A "normal" TE link usually is accompanied by an > > IGP adjacency (at least, in the packet domain); an FA TE link usually > > doesn't. > > but if a couple this with your answer "Correct -- LSPs created in IGP A > can be advertised as TE links in IGP B. This can be used (say) for > inter-area signaling." don't you have now an adjacency accompanying the > TE link advertisement in IGP B Not necessarily. Say you have: IGP B - X == IGP A == Y - IGP B X and Y participate in both IGPs; X has an LSP to Y, and advertises it into IGP B. All's fine. I'm guessing you are referring to the fact that IGP B appears partitioned? Well, to connect up the piece on the right with the piece on the left, one can: a) create an adjacency over the FA LSP (only possible if LSP is PSC) b) have a virtual link (OSPF) from X to Y c) have some other "backdoor" connection between the two parts. > - therefore why is there a need to rename > the canonical inheritance i.e. why not just speak in that case about a > TE link or a "hierarchical TE link" as it was the case in one of the > earlier versions of the LSP-HIER document and keep the FA concept when > dealing with a unique instance ? You can call it what you like :-) "FA" in particular refers to the idea that the "adjacency" is primarily for forwarding, and not necessarily for the control plane. However, the latter is not ruled out (as in case (a) above.) Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 05 Mar 2005 16:23:41 +0000 Message-ID: <0de601c5219f$988f1e00$19cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" , "Tove Madsen" Subject: Agenda on-line Date: Sat, 5 Mar 2005 16:22:49 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Kireeti has submitted the agenda to the Secretariat so you should be able to see it on their web site. I have placed an HTML version on the alternative CCAMP pages at http://www.olddog.co.uk/ccamp.htm You'll also find a template for your slides there in case you need something to start with and some reminders of what you should be talking about. Would the presenters please send me their slides before midnight on Monday. (No slides, no presentation :-) Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 05 Mar 2005 15:03:27 +0000 Message-ID: <4229CA36.6000505@psg.com> Date: Sat, 05 Mar 2005 16:03:18 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 MIME-Version: 1.0 To: Igor Bryskin CC: Dimitri.Papadimitriou@alcatel.be, Igor Bryskin , LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit igor - i will provide a detailed answer concerning a clean method to deal with "virtual FAs" that does not rely on the use of the protection object (and therefore would deliver a clean method to provide signaling for protected "virtual FAs" hopefully we can discuss this during this IETF meeting, thanks, - dimitri. Igor Bryskin wrote: > Dimitri, > > See at the bottom > > >>>IB>>Well, are they? They give you a way to signal a >>>requirement not to commit resources for an LSP > > until > >>>further notice and also to require their commitment >>>when it becomes necessary. Why not to allow working >>>LSP to be signaled as Secondary according to the >>>mentioned draft? Then it would be possible even to >>>signal protected virtual FAs, which is not as > > stupid > >>>as it may sound :=) >> >>Sorry but this sounds really bad... >>Please let me know then how do you signal protected > > virtual FAs? > >>IB>> You signal both working and protection LSPs of > > the FA as Secondary. > At > >>the time when you decide to make FA "real" you > > re-signal working or both > >>LSPs (depending on protection type) as Primary. > > Don't see why this > wouldn't > >>work. >> >>DP> because what do you do in case the primary > > (virtual) FA-LSP fails ? > you > >>are simply going to activate the secondary (virtual) > > FA-LSP which is in > >>clear >>opposition with the notion of virtual-FA - the > > reason is again because you > >>are trying to use one bit i.e. S to say something in > > a context (protection > >>object) for which it has not been designed for >> > > > IB>> Oh-Oh, what do you mean by "primary (virtual) > FA-LSP fails" and "you > are simply going to activate the secondary (virtual) > FA-LSP "? I activate > protection LSP if I have a failure in the *data plane* > of the working LSP. > But working LSP of the virtual FA does not have any > data plane yet, there is > nothing that can trigger the protection LSP activation > and switchover. > > DP> but they are associated to resources they do not > use - and the control plane role is to ensure that > when they need to be activated resources can be used - > the question JL raises is the problem of "how do i > protect a virtual FA" and the response is if you are > using the S bit for telling i am a virtual FA you can > not use it anymore to ensure protection of a primary > (and even less a secondary !) - this said an secondary > LSP exists only within the context of its primary > > IB>>Here is what I have in mind. > > A network operator configures a mesh of virtual FAs. > Working FA LSPs are signaled as Secondary. Once they > are established the FA TE link ends are advertised. > Resources for these LSPs are allocated on the links > the LSPs are going through, however, they are not > committed (not bound into cross-connects). Two or more > virtual FA LSPs may share the resources on common > links. This is especially true for those of them that > are unlikely to become real at the same time. > Furthermore, polices could be such that virtual FA LSP > resources could be allowed to get pre-empted by real > (not necessarily FA-) LSPs. The mentioned resources > also could be involved in mesh restoration schemes and > even be bound into extra traffic LSPs. > > When a virtual FA transforms into real FA, its working > FA-LSP is re-signaled as Primary. At this time, the > allocated resources are bound into FA-LSP > cross-connects. Naturally, all other LSPs – virtual or > real – that share resources with the FA-LSP in > question are notified and need to be recomputed and/or > re-signaled. > > A virtual FA could be provisioned as protected in a > sense that when it becomes real it will have a certain > protection scheme already in place. Path computation > for backup LSPs of virtual FAs is performed just like > of real FAs, that is, by assuming that associated > working LSPs are Primary (fully built) LSPs. > Regardless of the protection type backup LSPs of > virtual FAs are always signaled as Secondary. At the > time when a virtual FA is transformed into real one > (that is, when its working LSP becomes Primary) its > backup LSP(s) may be activated as well (e.g. 1+1 > protection) or may be left Secondary until the working > LSP data plane failure is detected (e.g. shared > protection). > > Igor > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 05 Mar 2005 14:58:56 +0000 Message-ID: <4229C915.7030308@psg.com> Date: Sat, 05 Mar 2005 15:58:29 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 MIME-Version: 1.0 To: Kireeti Kompella CC: Igor Bryskin , yakov@juniper.net, ccamp@ops.ietf.org Subject: Re: A philosophical question about FA and FA-LSP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi kireeti, >>My question was what is (if any) special about FA TE link apart from >>the fact that it is dynamically created/destroyed? > > > Actually, an FA TE link doesn't have to be dynamically > created/destroyed. > > What's special? Nothing really. A "normal" TE link usually has a > (single) physical interface associated with it; an FA TE link is > usually multi-hop. A "normal" TE link usually is accompanied by an > IGP adjacency (at least, in the packet domain); an FA TE link usually > doesn't. but if a couple this with your answer "Correct -- LSPs created in IGP A can be advertised as TE links in IGP B. This can be used (say) for inter-area signaling." don't you have now an adjacency accompanying the TE link advertisement in IGP B - therefore why is there a need to rename the canonical inheritance i.e. why not just speak in that case about a TE link or a "hierarchical TE link" as it was the case in one of the earlier versions of the LSP-HIER document and keep the FA concept when dealing with a unique instance ? thanks, - dimitri > But from the point of view of the IGP, or an LSR in that IGP, they > can't tell an FA TE link from any other TE link. > > Kireeti. > ------- > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 05 Mar 2005 14:32:22 +0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=LAuZJwcYhl7fZX7+DoPjENXM5HaUk0reCo2tH3S1OXRfEtpuyThe5HSF4zZ8pOYKNMjo/FtqL1vRlpyY7h1sBc1huoxgDhp2wfAa5IcclsbgOAG5fvxCADvNx0odLuAUsZLaLHuyfZ0VcmTarclpbF28IDr/Qks5db0CzRvSx2g= ; Message-ID: <20050305143158.15452.qmail@web30806.mail.mud.yahoo.com> Date: Sat, 5 Mar 2005 06:31:57 -0800 (PST) From: Igor Bryskin Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt To: Dimitri.Papadimitriou@alcatel.be, Igor Bryskin Cc: Igor Bryskin , Dimitri.Papadimitriou@alcatel.be, LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Dimitri, See at the bottom > > > >IB>>Well, are they? They give you a way to signal a > >requirement not to commit resources for an LSP until > >further notice and also to require their commitment > >when it becomes necessary. Why not to allow working > >LSP to be signaled as Secondary according to the > >mentioned draft? Then it would be possible even to > >signal protected virtual FAs, which is not as stupid > >as it may sound :=) > > Sorry but this sounds really bad... > Please let me know then how do you signal protected virtual FAs? > > IB>> You signal both working and protection LSPs of the FA as Secondary. At > the time when you decide to make FA "real" you re-signal working or both > LSPs (depending on protection type) as Primary. Don't see why this wouldn't > work. > > DP> because what do you do in case the primary (virtual) FA-LSP fails ? you > are simply going to activate the secondary (virtual) FA-LSP which is in > clear > opposition with the notion of virtual-FA - the reason is again because you > are trying to use one bit i.e. S to say something in a context (protection > object) for which it has not been designed for > IB>> Oh-Oh, what do you mean by "primary (virtual) FA-LSP fails" and "you are simply going to activate the secondary (virtual) FA-LSP "? I activate protection LSP if I have a failure in the *data plane* of the working LSP. But working LSP of the virtual FA does not have any data plane yet, there is nothing that can trigger the protection LSP activation and switchover. DP> but they are associated to resources they do not use - and the control plane role is to ensure that when they need to be activated resources can be used - the question JL raises is the problem of "how do i protect a virtual FA" and the response is if you are using the S bit for telling i am a virtual FA you can not use it anymore to ensure protection of a primary (and even less a secondary !) - this said an secondary LSP exists only within the context of its primary IB>>Here is what I have in mind. A network operator configures a mesh of virtual FAs. Working FA LSPs are signaled as Secondary. Once they are established the FA TE link ends are advertised. Resources for these LSPs are allocated on the links the LSPs are going through, however, they are not committed (not bound into cross-connects). Two or more virtual FA LSPs may share the resources on common links. This is especially true for those of them that are unlikely to become real at the same time. Furthermore, polices could be such that virtual FA LSP resources could be allowed to get pre-empted by real (not necessarily FA-) LSPs. The mentioned resources also could be involved in mesh restoration schemes and even be bound into extra traffic LSPs. When a virtual FA transforms into real FA, its working FA-LSP is re-signaled as Primary. At this time, the allocated resources are bound into FA-LSP cross-connects. Naturally, all other LSPs – virtual or real – that share resources with the FA-LSP in question are notified and need to be recomputed and/or re-signaled. A virtual FA could be provisioned as protected in a sense that when it becomes real it will have a certain protection scheme already in place. Path computation for backup LSPs of virtual FAs is performed just like of real FAs, that is, by assuming that associated working LSPs are Primary (fully built) LSPs. Regardless of the protection type backup LSPs of virtual FAs are always signaled as Secondary. At the time when a virtual FA is transformed into real one (that is, when its working LSP becomes Primary) its backup LSP(s) may be activated as well (e.g. 1+1 protection) or may be left Secondary until the working LSP data plane failure is detected (e.g. shared protection). Igor __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 05 Mar 2005 14:13:27 +0000 Message-ID: <4229BE41.50004@psg.com> Date: Sat, 05 Mar 2005 15:12:17 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Status of draft-ietf-ccamp-transport-lmp Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi adrian - i did ask a question concerning the introduction of the term "unidirectional" for which i did not receive any clear answer - but this is an "internal comment" unrelated to comments/questions from the previous last call/liaisons/etc. thanks, - dimitri. Adrian Farrel wrote: > Authors, > > Can you tell me: Does this version of the draft address all of the issues > raised in the WG last call and the IETF liaison? > Or do you plan a further revision? > > Thanks, > Adrian > ----- Original Message ----- > From: > To: > Cc: > Sent: Monday, February 21, 2005 8:26 PM > Subject: I-D ACTION:draft-ietf-ccamp-transport-lmp-01.txt > > > >>A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >>This draft is a work item of the Common Control and Measurement Plane > > Working Group of the IETF. > >>Title : A Transport Network View of LMP >>Author(s) : D. Fedyk, et al. >>Filename : draft-ietf-ccamp-transport-lmp-01.txt >>Pages : 17 >>Date : 2005-2-21 >> >>The Link Management Protocol (LMP) has been developed as part of the >> Generalized MPLS (GMPLS) protocol suite to manage Traffic >> Engineering (TE) resources and links. The GMPLS control plane >> (routing and signaling) uses TE links for establishing Label >> Switched Paths (LSPs). This memo describes the relationship of the >> LMP procedures to 'discovery' as defined in the International >> Telecommunication Union (ITU-T), and on-going ITU-T work. This >> document provides an overview of LMP in the context of the ITU-T >> Automatically Switched Optical Networks (ASON) and transport network >> terminology and relates it to the ITU-T discovery work to promote a >> common understanding for progressing the work of IETF and ITU-T. >> >>A URL for this Internet-Draft is: >> > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-01.txt > >>To remove yourself from the I-D Announcement list, send a message to >>i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > >>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>to change your subscription settings. >> >> >>Internet-Drafts are also available by anonymous FTP. Login with the > > username > >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >>"get draft-ietf-ccamp-transport-lmp-01.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >>mailserv@ietf.org. >>In the body type: >>"FILE /internet-drafts/draft-ietf-ccamp-transport-lmp-01.txt". >> >>NOTE: The mail server at ietf.org can return the document in >>MIME-encoded form by using the "mpack" utility. To use this >>feature, insert the command "ENCODING mime" before the "FILE" >>command. To decode the response(s), you will need "munpack" or >>a MIME-compliant mail reader. Different MIME-compliant mail readers >>exhibit different behavior, especially when dealing with >>"multipart" MIME messages (i.e. documents which have been split >>up into multiple messages), so check your local documentation on >>how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 05 Mar 2005 12:05:51 +0000 Message-ID: <0b6c01c5217b$4dfb3550$19cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Status of draft-ietf-ccamp-transport-lmp Date: Sat, 5 Mar 2005 11:59:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Authors, Can you tell me: Does this version of the draft address all of the issues raised in the WG last call and the IETF liaison? Or do you plan a further revision? Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Monday, February 21, 2005 8:26 PM Subject: I-D ACTION:draft-ietf-ccamp-transport-lmp-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : A Transport Network View of LMP > Author(s) : D. Fedyk, et al. > Filename : draft-ietf-ccamp-transport-lmp-01.txt > Pages : 17 > Date : 2005-2-21 > > The Link Management Protocol (LMP) has been developed as part of the > Generalized MPLS (GMPLS) protocol suite to manage Traffic > Engineering (TE) resources and links. The GMPLS control plane > (routing and signaling) uses TE links for establishing Label > Switched Paths (LSPs). This memo describes the relationship of the > LMP procedures to 'discovery' as defined in the International > Telecommunication Union (ITU-T), and on-going ITU-T work. This > document provides an overview of LMP in the context of the ITU-T > Automatically Switched Optical Networks (ASON) and transport network > terminology and relates it to the ITU-T discovery work to promote a > common understanding for progressing the work of IETF and ITU-T. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ccamp-transport-lmp-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-transport-lmp-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 05 Mar 2005 10:45:45 +0000 Message-ID: <0a6001c5216f$81cdecd0$19cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Nortel folk on this list Date: Sat, 5 Mar 2005 10:38:31 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit If there are any Nortel folk out there you might want to notify everyone else you know in Nortel that a large number of Nortel addresses are failing to receive CCAMP email because the company has changed its email address. You are kindly requested to remove your old addresses and add yourself using the the new ones. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 05 Mar 2005 10:33:27 +0000 Message-ID: <0a3701c5216e$2c2c0a10$19cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lam, Hing-Kam \(Kam\)" Cc: "'Kireeti Kompella'" , "Scott Bradner" , , "Bill Fenner" , , Subject: GMPLS Signaling Procedure for Egress Control Date: Sat, 5 Mar 2005 09:57:24 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit To: Mr. Kam Lam, rapporteur ITU-T Question 14/15 Cc: Mr. Scott Bradner, IETF liaison coordinator with the ITU-T Alex Zinin and Bill Fenner, IETF Routing Area Directors From: Adrian Farrel and Kireeti Kompella, IETF CCAMP working group chairs Subject: GMPLS Signaling Procedure for Egress Control For: Information Dear Mr. Lam We would like to inform Question 14/15 of the publication of a new GMPLS RFC. RFC 4003 (ftp://ftp.rfc-editor.org/in-notes/rfc4003.txt) "GMPLS Signaling Procedure for Egress Control" describes the procedures for control of egress ports and labels such as might be used to establish soft permanent LSPs. The abstract is as follows. This document clarifies the procedures for the control of the label used on an output/downstream interface of the egress node of a Label Switched Path (LSP). This control is also known as "Egress Control". Support for Egress Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Signaling. This document clarifies the specification of GMPLS Signaling and does not modify GMPLS signaling mechanisms and procedures. The need for clarification of these procedures was first raised by your Question, and CCAMP is grateful for the questions and discussion that led to the production of this RFC. Best regards, Adrian Farrel and Kireeti Kompella Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 23:26:51 +0000 To: "Igor Bryskin" Cc: "Igor Bryskin" , , "LE ROUX Jean-Louis RD-CORE-LAN" , MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Date: Sat, 5 Mar 2005 00:25:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 PFA+Jm5ic3A7PEJSPjxCUj48Rk9OVCBTSVpFPTI+PEI+JnF1b3Q7SWdvciBCcnlza2luJnF1b3Q7 ICZsdDtpYnJ5c2tpbkBtb3Zhei5jb20mZ3Q7PC9CPjwvRk9OVD48QlI+PEZPTlQgU0laRT0yPlNl bnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+PEZPTlQgU0laRT0yPjAz LzA0LzIwMDUgMTg6MDUgRVNUPC9GT05UPjxCUj48QlI+IDxGT05UIFNJWkU9Mj5Ubzo8L0ZPTlQ+ IDxGT05UIFNJWkU9Mj4mcXVvdDtJZ29yIEJyeXNraW4mcXVvdDsgJmx0O2lfYnJ5c2tpbkB5YWhv by5jb20mZ3Q7LCBEaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENBVEVMPC9GT05U PjxCUj4gPEZPTlQgU0laRT0yPmNjOjwvRk9OVD4gPEZPTlQgU0laRT0yPiZxdW90O0xFIFJPVVgg SmVhbi1Mb3VpcyBSRC1DT1JFLUxBTiZxdW90OyAmbHQ7amVhbmxvdWlzLmxlcm91eEBmcmFuY2V0 ZWxlY29tLmNvbSZndDssICZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PC9GT05UPjxCUj4gPEZP TlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPlN1YmplY3Q6PC9GT05UPiA8 Rk9OVCBTSVpFPTI+UmU6IFJFIDogUkUgOiBUUiA6IEktRCBBQ1RJT046ZHJhZnQtbGVyb3V4LWNj YW1wLWdtcGxzLW1ybi1ldmFsLTAwLnR4dDwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQPjxGT05U IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7SUImZ3Q7Jmd0 O1dlbGwsIGFyZSB0aGV5PyBUaGV5IGdpdmUgeW91IGEgd2F5IHRvIHNpZ25hbCBhPEJSPiZndDsg Jmd0O3JlcXVpcmVtZW50IG5vdCB0byBjb21taXQgcmVzb3VyY2VzIGZvciBhbiBMU1AgdW50aWw8 QlI+Jmd0OyAmZ3Q7ZnVydGhlciBub3RpY2UgYW5kIGFsc28gdG8gcmVxdWlyZSB0aGVpciBjb21t aXRtZW50PEJSPiZndDsgJmd0O3doZW4gaXQgYmVjb21lcyBuZWNlc3NhcnkuIFdoeSBub3QgdG8g YWxsb3cgd29ya2luZzxCUj4mZ3Q7ICZndDtMU1AgdG8gYmUgc2lnbmFsZWQgYXMgU2Vjb25kYXJ5 IGFjY29yZGluZyB0byB0aGU8QlI+Jmd0OyAmZ3Q7bWVudGlvbmVkIGRyYWZ0PyBUaGVuIGl0IHdv dWxkIGJlIHBvc3NpYmxlIGV2ZW4gdG88QlI+Jmd0OyAmZ3Q7c2lnbmFsIHByb3RlY3RlZCB2aXJ0 dWFsIEZBcywgd2hpY2ggaXMgbm90IGFzIHN0dXBpZDxCUj4mZ3Q7ICZndDthcyBpdCBtYXkgc291 bmQgOj0pPEJSPiZndDs8QlI+Jmd0OyBTb3JyeSBidXQgdGhpcyBzb3VuZHMgcmVhbGx5IGJhZC4u LjxCUj4mZ3Q7IFBsZWFzZSBsZXQgbWUga25vdyB0aGVuIGhvdyBkbyB5b3Ugc2lnbmFsIHByb3Rl Y3RlZCB2aXJ0dWFsIEZBcz88QlI+Jmd0OzxCUj4mZ3Q7IElCJmd0OyZndDsgWW91IHNpZ25hbCBi b3RoIHdvcmtpbmcgYW5kIHByb3RlY3Rpb24gTFNQcyBvZiB0aGUgRkEgYXMgU2Vjb25kYXJ5LjxC Uj5BdDxCUj4mZ3Q7IHRoZSB0aW1lIHdoZW4geW91IGRlY2lkZSB0byBtYWtlIEZBICZxdW90O3Jl YWwmcXVvdDsgeW91IHJlLXNpZ25hbCB3b3JraW5nIG9yIGJvdGg8QlI+Jmd0OyBMU1BzIChkZXBl bmRpbmcgb24gcHJvdGVjdGlvbiB0eXBlKSBhcyBQcmltYXJ5LiBEb24ndCBzZWUgd2h5IHRoaXM8 QlI+d291bGRuJ3Q8QlI+Jmd0OyB3b3JrLjxCUj4mZ3Q7PEJSPiZndDsgRFAmZ3Q7IGJlY2F1c2Ug d2hhdCBkbyB5b3UgZG8gaW4gY2FzZSB0aGUgcHJpbWFyeSAodmlydHVhbCkgRkEtTFNQIGZhaWxz ID88QlI+eW91PEJSPiZndDsgYXJlIHNpbXBseSBnb2luZyB0byBhY3RpdmF0ZSB0aGUgc2Vjb25k YXJ5ICh2aXJ0dWFsKSBGQS1MU1Agd2hpY2ggaXMgaW48QlI+Jmd0OyBjbGVhcjxCUj4mZ3Q7IG9w cG9zaXRpb24gd2l0aCB0aGUgbm90aW9uIG9mIHZpcnR1YWwtRkEgLSB0aGUgcmVhc29uIGlzIGFn YWluIGJlY2F1c2UgeW91PEJSPiZndDsgYXJlIHRyeWluZyB0byB1c2Ugb25lIGJpdCBpLmUuIFMg dG8gc2F5IHNvbWV0aGluZyBpbiBhIGNvbnRleHQgKHByb3RlY3Rpb248QlI+Jmd0OyBvYmplY3Qp IGZvciB3aGljaCBpdCBoYXMgbm90IGJlZW4gZGVzaWduZWQgZm9yPEJSPiZndDs8QlI+PC9GT05U PjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SUImZ3Q7Jmd0OyBPaC1PaCwgd2hh dCBkbyB5b3UgbWVhbiBieSAmcXVvdDtwcmltYXJ5ICh2aXJ0dWFsKSBGQS1MU1AgZmFpbHMmcXVv dDsgYW5kICZuYnNwOyZxdW90O3lvdTxCUj5hcmUgc2ltcGx5IGdvaW5nIHRvIGFjdGl2YXRlIHRo ZSBzZWNvbmRhcnkgKHZpcnR1YWwpIEZBLUxTUCAmcXVvdDs/ICZuYnNwO0kgYWN0aXZhdGU8QlI+ cHJvdGVjdGlvbiBMU1AgaWYgSSBoYXZlIGEgZmFpbHVyZSBpbiB0aGUgKmRhdGEgcGxhbmUqIG9m IHRoZSB3b3JraW5nIExTUC48QlI+QnV0IHdvcmtpbmcgTFNQIG9mIHRoZSB2aXJ0dWFsIEZBIGRv ZXMgbm90IGhhdmUgYW55IGRhdGEgcGxhbmUgeWV0LCB0aGVyZSBpczxCUj5ub3RoaW5nIHRoYXQg Y2FuIHRyaWdnZXIgdGhlIHByb3RlY3Rpb24gTFNQIGFjdGl2YXRpb24gYW5kIHN3aXRjaG92ZXIu PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkRQJmd0OyBidXQg dGhleSBhcmUgYXNzb2NpYXRlZCB0byByZXNvdXJjZXMgdGhleSBkbyBub3QgdXNlIC0gYW5kIHRo ZSBjb250cm9sIHBsYW5lIHJvbGUgaXMgdG8gZW5zdXJlIHRoYXQgd2hlbiB0aGV5IG5lZWQgdG8g YmUgYWN0aXZhdGVkIHJlc291cmNlcyBjYW4gYmUgdXNlZCAtIHRoZSBxdWVzdGlvbiBKTCByYWlz ZXMgaXMgdGhlIHByb2JsZW0gb2YgJnF1b3Q7aG93IGRvIGkgcHJvdGVjdCBhIHZpcnR1YWwgRkEm cXVvdDsgYW5kIHRoZSByZXNwb25zZSBpcyBpZiB5b3UgYXJlIHVzaW5nIHRoZSBTIGJpdCBmb3Ig dGVsbGluZyBpIGFtIGEgdmlydHVhbCBGQSB5b3UgY2FuIG5vdCB1c2UgaXQgYW55bW9yZSB0byBl bnN1cmUgcHJvdGVjdGlvbiBvZiBhIHByaW1hcnkgKGFuZCBldmVuIGxlc3MgYSBzZWNvbmRhcnkg ISkgLSB0aGlzIHNhaWQgYW4gc2Vjb25kYXJ5IExTUCBleGlzdHMgb25seSB3aXRoaW4gdGhlIGNv bnRleHQgb2YgaXRzIHByaW1hcnk8L0ZPTlQ+PC9QPjxQPiZuYnNwOzwvUD48UD48Rk9OVCBGQUNF PSJNb25vc3BhY2UsQ291cmllciI+PEJSPjwvRk9OVD48L1A+ Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 23:05:34 +0000 Message-ID: <002101c5210e$a1a2d8b0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Igor Bryskin" , Cc: "LE ROUX Jean-Louis RD-CORE-LAN" , Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Date: Fri, 4 Mar 2005 18:05:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > > > >IB>>Well, are they? They give you a way to signal a > >requirement not to commit resources for an LSP until > >further notice and also to require their commitment > >when it becomes necessary. Why not to allow working > >LSP to be signaled as Secondary according to the > >mentioned draft? Then it would be possible even to > >signal protected virtual FAs, which is not as stupid > >as it may sound :=) > > Sorry but this sounds really bad... > Please let me know then how do you signal protected virtual FAs? > > IB>> You signal both working and protection LSPs of the FA as Secondary. At > the time when you decide to make FA "real" you re-signal working or both > LSPs (depending on protection type) as Primary. Don't see why this wouldn't > work. > > DP> because what do you do in case the primary (virtual) FA-LSP fails ? you > are simply going to activate the secondary (virtual) FA-LSP which is in > clear > opposition with the notion of virtual-FA - the reason is again because you > are trying to use one bit i.e. S to say something in a context (protection > object) for which it has not been designed for > IB>> Oh-Oh, what do you mean by "primary (virtual) FA-LSP fails" and "you are simply going to activate the secondary (virtual) FA-LSP "? I activate protection LSP if I have a failure in the *data plane* of the working LSP. But working LSP of the virtual FA does not have any data plane yet, there is nothing that can trigger the protection LSP activation and switchover. Igor Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 22:51:41 +0000 To: Igor Bryskin Cc: LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org From: Dimitri.Papadimitriou@alcatel.be Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt MIME-Version: 1.0 Date: Fri, 4 Mar 2005 23:51:02 +0100 Message-ID: Content-type: text/plain; charset=us-ascii >> I wouldn't be so expeditious... >> Actually we could use a similar mechanism but >> definitely not the same. >> Secondary LSP are dedicated to Shared Meshed >> Restoration. >> IMHO this would be bad to use the Protection object >> for soft-FAs. Semantics >> are pretty different... >> > >IB>>Well, are they? They give you a way to signal a >requirement not to commit resources for an LSP until >further notice and also to require their commitment >when it becomes necessary. Why not to allow working >LSP to be signaled as Secondary according to the >mentioned draft? Then it would be possible even to >signal protected virtual FAs, which is not as stupid >as it may sound :=) Sorry but this sounds really bad... Please let me know then how do you signal protected virtual FAs? IB>> You signal both working and protection LSPs of the FA as Secondary. At the time when you decide to make FA "real" you re-signal working or both LSPs (depending on protection type) as Primary. Don't see why this wouldn't work. DP> because what do you do in case the primary (virtual) FA-LSP fails ? you are simply going to activate the secondary (virtual) FA-LSP which is in clear opposition with the notion of virtual-FA - the reason is again because you are trying to use one bit i.e. S to say something in a context (protection object) for which it has not been designed for Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 22:20:14 +0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=DtxrKT8R6VQU9aRPkJ0XphvKDtZZDdct/0+9EdNXHYtQoZ8b3zIs4KdZ83ZmqZtmOVITo/+gCPtVyfj0RfSN8dNFzPjZ/GN/bmdf06yum5KO1YuodHxGXCmVVdMphWtO5aH2seBEHEilwUJa39j7AhvSHRgtwkEbKb3j4GScNaE= ; Message-ID: <20050304221920.69508.qmail@web30806.mail.mud.yahoo.com> Date: Fri, 4 Mar 2005 14:19:20 -0800 (PST) From: Igor Bryskin Subject: Re: A philosophical question about FA and FA-LSP To: Kireeti Kompella , Igor Bryskin Cc: yakov@juniper.net, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-154085893-1109974760=:69340" --0-154085893-1109974760=:69340 Content-Type: text/plain; charset=us-ascii Thanks, Kireeti Kireeti Kompella wrote: On Fri, 4 Mar 2005, Kireeti Kompella wrote: > But from the point of view of the IGP, or an LSR in that IGP, they > can't tell an FA TE link from any other TE link. Correction: it has been pointed out that the above statement about LSRs applies to all LSRs except those at the two ends of the FA LSP. Kireeti. ------- --------------------------------- Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web --0-154085893-1109974760=:69340 Content-Type: text/html; charset=us-ascii
Thanks, Kireeti
 

Kireeti Kompella <kireeti@juniper.net> wrote:
On Fri, 4 Mar 2005, Kireeti Kompella wrote:

> But from the point of view of the IGP, or an LSR in that IGP, they
> can't tell an FA TE link from any other TE link.

Correction: it has been pointed out that the above statement about
LSRs applies to all LSRs except those at the two ends of the FA LSP.

Kireeti.
-------

Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web --0-154085893-1109974760=:69340-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 21:26:21 +0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=v5G7BiV3M0/ttfSBJZRNwKMjgDqMF4T9KKWTYkcSQ+9e7T8MfRvm1q7pqCFTjiURMCoM23Z+Cd8wrYzcNw8spuR7uJ6Mu2KdDk3EdXerHbyFIamkGl4wQlH6sLUWHmz0w/3m55lhXQYrbf9bO22VbLg819qR1/kxaNNZfGlbDZo= ; Message-ID: <20050304212544.3559.qmail@web30807.mail.mud.yahoo.com> Date: Fri, 4 Mar 2005 13:25:44 -0800 (PST) From: Igor Bryskin Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt To: LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1320231352-1109971544=:2579" --0-1320231352-1109971544=:2579 Content-Type: text/plain; charset=us-ascii >> >> I wouldn't be so expeditious... >> Actually we could use a similar mechanism but >> definitely not the same. >> Secondary LSP are dedicated to Shared Meshed >> Restoration. >> IMHO this would be bad to use the Protection object >> for soft-FAs. Semantics >> are pretty different... >> > >IB>>Well, are they? They give you a way to signal a >requirement not to commit resources for an LSP until >further notice and also to require their commitment >when it becomes necessary. Why not to allow working >LSP to be signaled as Secondary according to the >mentioned draft? Then it would be possible even to >signal protected virtual FAs, which is not as stupid >as it may sound :=) Sorry but this sounds really bad... Please let me know then how do you signal protected virtual FAs? IB>> You signal both working and protection LSPs of the FA as Secondary. At the time when you decide to make FA “real” you re-signal working or both LSPs (depending on protection type) as Primary. Don’t see why this wouldn’t work. Igor --------------------------------- Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web --0-1320231352-1109971544=:2579 Content-Type: text/html; charset=us-ascii

>>
>> I wouldn't be so expeditious...
>> Actually we could use a similar mechanism but
>> definitely not the same.
>> Secondary LSP are dedicated to Shared Meshed
>> Restoration.
>> IMHO this would be bad to use the Protection object
>> for soft-FAs. Semantics
>> are pretty different...
>>
>
>IB>>Well, are they? They give you a way to signal a
>requirement not to commit resources for an LSP until
>further notice and also to require their commitment
>when it becomes necessary. Why not to allow working
>LSP to be signaled as Secondary according to the
>mentioned draft? Then it would be possible even to
>signal protected virtual FAs, which is not as stupid
>as it may sound :=)

Sorry but this sounds really bad...
Please let me know then how do you signal protected virtual FAs?

IB>> You signal both working and protection LSPs of the FA as Secondary. At the time when you decide to make FA “real” you re-signal working or both LSPs (depending on protection type) as Primary. Don’t see why this wouldn’t work.

Igor

Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web --0-1320231352-1109971544=:2579-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 20:29:18 +0000 Message-ID: <058e01c520f7$26698e30$19cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Richard Rabbat" , Cc: , , "'Sadler, Jonathan B.'" , "'Ong, Lyndon'" , "'Richard Rabbat'" , , "'Greg Bernstein'" Subject: Re: question about RFC 3946 Date: Fri, 4 Mar 2005 19:26:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Whatever technical answer we end up with, can we stick with the phrases "strictly greater" and "greater or equal" as appropriate, and avoid the (apparently) ambiguous "greater". Thanks, Adrian ----- Original Message ----- From: To: "Richard Rabbat" Cc: ; ; "'Sadler, Jonathan B.'" ; "'Ong, Lyndon'" ; "'Adrian Farrel'" ; "'Richard Rabbat'" ; ; "'Greg Bernstein'" Sent: Tuesday, March 01, 2005 6:57 PM Subject: Re: question about RFC 3946 > > richard: > > "greater" does not mean "strictly greater" it means "greater or equal" > > So, what values of NCC and RCC should one use for STS-3c/VC-4? > > for STS-3c: > An STS-3c SPE signal is formed by the application of RCC with > value 1 (standard contiguous concatenation), NCC with value 1, > NVC with value 0, MT with value 1 and T with value 0 to an STS- > 3c SPE Elementary Signal. > > for VC-4: > A VC-4 signal is formed by the application of RCC with value 0, > NCC with value 0, NVC with value 0, MT with value 1 and T with > value 0 to a VC-4 Elementary Signal. > > do not know if this clarifies - > > hint: Note 2 refers to transparent STS-N/STM-N signals (signal type 7->12) > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 19:23:03 +0000 Date: Fri, 4 Mar 2005 11:22:43 -0800 (PST) From: Kireeti Kompella To: Igor Bryskin cc: yakov@juniper.net, ccamp@ops.ietf.org Subject: Re: A philosophical question about FA and FA-LSP Message-ID: <20050304112107.F72451@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 4 Mar 2005, Kireeti Kompella wrote: > But from the point of view of the IGP, or an LSR in that IGP, they > can't tell an FA TE link from any other TE link. Correction: it has been pointed out that the above statement about LSRs applies to all LSRs except those at the two ends of the FA LSP. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 18:58:54 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Date: Fri, 4 Mar 2005 19:56:22 +0100 Message-ID: Thread-Topic: RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Thread-Index: AcUgvc80KlMsDPzJSDi5II1t1/lYvgAKySNw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" , Igor, Please see inline Regards, JL >-----Message d'origine----- >De : Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 >Envoy=E9 : vendredi 4 mars 2005 14:26 >=C0 : LE ROUX Jean-Louis RD-CORE-LAN; ccamp@ops.ietf.org >Objet : Re: RE : TR : I-D=20 >ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt=20 > > >JL, > >Please, see my comments in-line > >Igor > >--- LE ROUX Jean-Louis RD-CORE-LAN=20 > wrote: > >> Hi Igor, >>=20 >> Thanks for these comments >>=20 >> Please see inline >>=20 >>=20 >> >-----Message d'origine----- >> >De : Igor Bryskin [mailto:i_bryskin@yahoo.com] >> >Envoy=E9 : jeudi 3 mars 2005 20:45 >> >=C0 : LE ROUX Jean-Louis RD-CORE-LAN; >> ccamp@ops.ietf.org >> >Objet : Re: TR : I-D >> ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt >> > >> > >> >JL, >> > >> >I have a couple of comments/suggestions. >> > >> >1. The draft says that currently GMPLS does not >> have a >> >mechanism to provision virtual FAs. I don't think >> this >> >is correct - I believe we could use the same >> mechanism >> >as was suggested in >> >draft-ietf-ccamp-gmpls-recovery-e2e-signaling >> (section >> >9.3) for signaling of Secondary LSPs >>=20 >> I wouldn't be so expeditious... >> Actually we could use a similar mechanism but >> definitely not the same. >> Secondary LSP are dedicated to Shared Meshed >> Restoration. >> IMHO this would be bad to use the Protection object >> for soft-FAs. Semantics >> are pretty different... >>=20 > >IB>>Well, are they? They give you a way to signal a >requirement not to commit resources for an LSP until >further notice and also to require their commitment >when it becomes necessary. Why not to allow working >LSP to be signaled as Secondary according to the >mentioned draft? Then it would be possible even to >signal protected virtual FAs, which is not as stupid >as it may sound :=3D) Sorry but this sounds really bad... Please let me know then how do you signal protected virtual FAs? > >>=20 >> >2. I agree that we need TE link adaptation >> >capabilities to be advertised along with other TE >> link >> >attributes such as switching capabilities, >> protection >> >capabilities, etc. I suggest also adding TE link >> termination >> >capabilities to this list, i.e. decoupling of these >>=20 >> >capabilities from adaptation capabilities: >> >to terminate LSP in a particular layer and to adopt >> >into it LSPs of one or more higher layers are >> separate >> >resources and could be considered separately in the >>=20 >> >inter-layer path computations; >>=20 >> I agree that our curent terminology may be confusing >> What we call Internal Adapatation Capability >> actually refers to Termination capabilities. >> See the MRN requirement draft (version 01) for an >=D8 example. > >IB>> My point is that termination and adaptation >capabilities are separate things. For instance, the >fact that a link can terminate lambdas means the it >has certain number of available transceivers, while >the fact whether these lambdas can carry particular >tributary signals depends, say, on whether SIM cards >of appropriate type could be cross-connected to the=20 >transceivers. In fact, link termination bandwidth is shared=20 >between multiple adaptation functions. The bottom line is I=20 >think it would be good idea to advertise them separately. > IMHO all what is missing in GMPLS-RTG is the advertisement of the = internal termination capabilities (a.k.a internal adaptation capability = in our draft...).=20 This is useful only when doing inter-region path computation.=20 IMHO we just need to find an appropriate terminology. >>=20 >>=20 >> >3. Everything that is said about regions, region >> >boundaries, etc. is also applicable for layers >> >contained within regions. I suggest to do what we >> have >> >already done in the PCE WG documents and >> >presentations: replace word region with word layer everywhere apart=20 >> >from where signaling specific >> aspects >> >are discussed. >>=20 >> See section 3 of the requirement draft. >> Actually what we define for region also applies to >> layers, but we prefer to >=D8 keep the term region here at the time being. > >IB>> And my question is why to do so, if FAs and >everything to do with VNT is about layers, including >those that start and stop in the middle of the region, >that is, far away from region boundaries? Furthermore, >when you say things like creating FA in the lower >region to carry LSP for the higher region, it is not >clear what do you mean by that in the case when the >lower region contains multiple layers. You are right this applies also to multi-layers. We will clarify in next revision, but note that this is already = clarified in the=20 MRN req draft (see section 3). Thanks again, JL > >Igor > >>=20 >> Again, thanks a lot for these comments, >>=20 >> Regards, >>=20 >> JL >>=20 >> > >> >Thanks, >> >Igor >> > =20 >> > >> > >> >--- LE ROUX Jean-Louis RD-CORE-LAN >> > wrote: >> > >> > >> > >> >>=20 >> >> Hi all, >> >>=20 >> >> Here is a new draft evaluating current GMPLS >> >> protocols wrt MRN >> >> requirements. >> >> Your comments on this new draft would be highly appreciated. >> >>=20 >> >> Best Regards, >> >>=20 >> >> JL >> >>=20 >> >> To: i-d-announce at ietf.org >> >> Subject: I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt >> >> From: Internet-Drafts at ietf.org=20 >> >> Date: Tue, 15 Feb 2005 10:14:38 -0500=20 >> >>=20 >> >> A New Internet-Draft is available from the >> on-line Internet-Drafts >> >> directories. >> >>=20 >> >>=20 >> >> Title : Evaluation of existing GMPLS Protocols >> >> against >> >> Multi Region Networks >> >> Author(s) : J. Le Roux, et al. >> >> Filename : >> draft-leroux-ccamp-gmpls-mrn-eval-00.txt >> >> Pages : 11 >> >> Date : 2005-2-14 >> >> =09 >> >> This document provides an evaluation of >> Generalized Multi-Protocol >> >> Label Switching (GMPLS) protocols and >> mechanisms >> >> against the=20 >> >> requirements for Multi Region Networks (MRN). >> =20 >> >> In addition, this document identifies areas >> where >> >> additional=20 >> >> protocol extensions or procedures are needed >> to >> >> satisfy the=20 >> >> requirements of Multi Region Networks, and >> >> provides guidelines for=20 >> >> potential extensions. >> >>=20 >> >> A URL for this Internet-Draft is: >> >> >> >>http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mr >> n-eval-00 >> > .txt >> >=20 >> >=20 >> >=20 >> >=20 >> > >>=20 >>=20 >>=20 >> =09 >> =09 >> __________________________________ >> Celebrate Yahoo!'s 10th Birthday!=20 >> Yahoo! Netrospective: 100 Moments of the Web=20 >> http://birthday.yahoo.com/netrospective/ >> > > > >=09 > =09 >__________________________________=20 >Celebrate Yahoo!'s 10th Birthday!=20 >Yahoo! Netrospective: 100 Moments of the Web=20 >http://birthday.yahoo.com/netrospective/ > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 18:41:08 +0000 Date: Fri, 4 Mar 2005 10:40:45 -0800 (PST) From: Kireeti Kompella To: Igor Bryskin cc: yakov@juniper.net, ccamp@ops.ietf.org Subject: Re: A philosophical question about FA and FA-LSP Message-ID: <20050304100910.R72177@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 4 Mar 2005, Igor Bryskin wrote: > My question was what is (if any) special about FA TE link apart from > the fact that it is dynamically created/destroyed? Actually, an FA TE link doesn't have to be dynamically created/destroyed. What's special? Nothing really. A "normal" TE link usually has a (single) physical interface associated with it; an FA TE link is usually multi-hop. A "normal" TE link usually is accompanied by an IGP adjacency (at least, in the packet domain); an FA TE link usually doesn't. But from the point of view of the IGP, or an LSR in that IGP, they can't tell an FA TE link from any other TE link. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 18:07:50 +0000 Message-ID: <00ad01c520e5$013fdf90$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Kireeti Kompella" Cc: , Subject: Re: A philosophical question about FA and FA-LSP Date: Fri, 4 Mar 2005 13:07:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, My question was what is (if any) special about FA TE link apart from the fact that it is dynamically created/destroyed? Igor ----- Original Message ----- From: "Kireeti Kompella" To: "Igor Bryskin" Cc: ; Sent: Friday, March 04, 2005 12:53 PM Subject: Re: A philosophical question about FA and FA-LSP > On Fri, 4 Mar 2005, Igor Bryskin wrote: > > > I have a question to Kireti and Yakov. > ... > > My question is: can I draw a conclusion from the above that it is > > not required anymore for an FA to be advertised into the same > > instance of IGP-TE as was used for the advertising of the FA-LSP > > constituent TE links. > > Correct -- LSPs created in IGP A can be advertised as TE links in IGP B. > This can be used (say) for inter-area signaling. > > > In other words, if an LSP created by one instance of the control > > plane (say, L1VPN Provider) and advertised as a TE link into another > > instance of the control plane (say, VPN), would/should such TE link > > be treated anyhow different from the LSP advertised into the same > > instance of control plane. > > The advertisement into the VPN control plane is just a TE link for the > VPN IGP-TE. > > Kireeti. > ------- > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 17:54:43 +0000 Date: Fri, 4 Mar 2005 09:53:29 -0800 (PST) From: Kireeti Kompella To: Igor Bryskin cc: yakov@juniper.net, ccamp@ops.ietf.org Subject: Re: A philosophical question about FA and FA-LSP Message-ID: <20050304094707.A72012@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 4 Mar 2005, Igor Bryskin wrote: > I have a question to Kireti and Yakov. ... > My question is: can I draw a conclusion from the above that it is > not required anymore for an FA to be advertised into the same > instance of IGP-TE as was used for the advertising of the FA-LSP > constituent TE links. Correct -- LSPs created in IGP A can be advertised as TE links in IGP B. This can be used (say) for inter-area signaling. > In other words, if an LSP created by one instance of the control > plane (say, L1VPN Provider) and advertised as a TE link into another > instance of the control plane (say, VPN), would/should such TE link > be treated anyhow different from the LSP advertised into the same > instance of control plane. The advertisement into the VPN control plane is just a TE link for the VPN IGP-TE. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 16:43:33 +0000 Message-ID: <00a201c520d9$290913e0$7a1810ac@movaz.com> Reply-To: "Igor Bryskin" From: "Igor Bryskin" To: , "Kireeti Kompella" Cc: Subject: A philosophical question about FA and FA-LSP Date: Fri, 4 Mar 2005 11:42:31 -0500 Organization: Movaz Networks MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009F_01C520AF.4003BE80" This is a multi-part message in MIME format. ------=_NextPart_000_009F_01C520AF.4003BE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 I have a question to Kireti and Yakov. =20 This is from draft-ietf-ccamp-gmpls-routing-09.txt:=20 =20 Traditionally, a TE link is advertised as an adjunct to a "regular" = link, i.e., a routing adjacency is brought up on the link, and when = the link is up, both the properties of the link used for Shortest Path = First (SPF) computations (basically, the SPF metric) and the TE = properties of the link are then advertised. GMPLS challenges this = notion in three ways. First, links that are not capable of sending = and receiving on a packet-by-packet basis may yet have TE properties; = however, a routing adjacency cannot be brought up on such links. = Second, a Label Switched Path can be advertised as a point-to-point TE = link (see [LSP-HIER]); thus, an advertised TE link may be between a = pair of nodes that don't have a routing adjacency with each other. = Finally, a number of links may be advertised as a single TE link = (perhaps for improved scalability), so again, there is no longer a = one-to-one association of a regular routing adjacency and a TE link. = Thus we have a more general notion of a TE link. A TE link is a = "logical" link that has TE properties. . My question is: can I draw a = conclusion from the above that it is not required anymore for an FA to = be advertised into the same instance of IGP-TE as was used for the = advertising of the FA-LSP constituent TE links. In other words, if an = LSP created by one instance of the control plane (say, L1VPN Provider) = and advertised as a TE link into another instance of the control plane = (say, VPN), would/should such TE link be treated anyhow different from = the LSP advertised into the same instance of control plane. Thanks,Igor=20 =20 =20 ------=_NextPart_000_009F_01C520AF.4003BE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

I have a question to = Kireti and=20 Yakov.

 

This is from =
draft-ietf-ccamp-gmpls-routing-09.txt:

 

 

Traditionally, a TE link is advertised as an adjunct to a =
"regular"
   link, i.e., a routing =
adjacency is brought up on the link, and =
when
   the link is up, both the =
properties of the link used for =
Shortest
   Path First (SPF) =
computations (basically, the SPF metric) and the =
TE
   properties of the link =
are then advertised.
 
   GMPLS challenges this notion in three =
ways.  First, links that =
are
   not capable of sending =
and receiving on a packet-by-packet basis =
may
   yet have TE properties; =
however, a routing adjacency cannot =
be
   brought up on such =
links.  Second, a Label =
Switched Path can be
   advertised as a point-to-point TE link (see =
[LSP-HIER]); thus, an
   advertised TE link may be between a pair of =
nodes that don't have a
   routing adjacency with each other.  Finally, a number of links may =
be
   advertised as a single =
TE link (perhaps for improved scalability), =
so
   again, there is no =
longer a one-to-one association of a =
regular
   routing adjacency and a =
TE link.
 
   Thus we have a more general notion of a TE =
link.  A TE link is =
a
   "logical" link that has =
TE properties. =85
 
My =
question is:  can I draw a conclusion from the above that it is not =
required anymore for an FA to be advertised into the same instance of =
IGP-TE as was used for the advertising of the FA-LSP constituent TE =
links.
 In other words, if an =
LSP created by one instance of the control plane (say, L1VPN Provider) =
and advertised as a TE link into another instance of the control plane =
(say, VPN), would/should such TE link be treated 
anyhow different from the LSP advertised =
into the same instance of control =
plane.
 
Thanks,
Igor

 

 

 

------=_NextPart_000_009F_01C520AF.4003BE80-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 16:03:57 +0000 Message-ID: <007501c520d3$b9d8f940$19cb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Zafar Ali" , "'Richard Rabbat'" , Subject: Re: Draft status updated on alternate CCAMP web page Date: Fri, 4 Mar 2005 15:40:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, When something is left entirely undone, no-one objects. When something is half done, everyone demands perfection. Contrary to popular opinion, I am only human. I hope to complete this task before Minneapolis. Adrian ----- Original Message ----- From: "Zafar Ali" To: "'Richard Rabbat'" ; "'Adrian Farrel'" ; Sent: Tuesday, March 01, 2005 8:08 PM Subject: RE: Draft status updated on alternate CCAMP web page > Hi Richard, > > Re: the ID (draft-shiomoto-ccamp-gmpls-addressing-00), I did find it quite > useful and IMO we should pursue this further in CCAMP. > > Having said that, I would like to point that there are a number of ID-es > that are currently NOT in Adrian's list and I think this has to do with his > comment in the original email (quoting Adrian): "I have yet to update the > section that covers personal drafts related to CCAMP." Adrian, please > correct me/ add/ del. > > Thanks > > Regards... Zafar > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Richard Rabbat > > Sent: Thursday, February 24, 2005 1:52 PM > > To: 'Adrian Farrel'; ccamp@ops.ietf.org > > Subject: RE: Draft status updated on alternate CCAMP web page > > > > Adrian, > > Can you add > > http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls > > -addressing-00 > > .txt > > to your draft tracker? > > > > We sent out email about it and have received feedback > > off-list. We're planning on discussing this draft in > > Minneapolis and would love to have more on-list discussions. > > As you can see from the list of contributors, there is > > enormous interest in this draft and we hope it serves as a > > basis for thoughtful discussions. > > Best, > > Richard, Rajiv and Kohei. > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > > Sent: Monday, February 21, 2005 10:35 AM > > > To: Adrian Farrel; ccamp@ops.ietf.org > > > Subject: Re: Draft status updated on alternate CCAMP web page > > > > > > > > > So, I can't type. > > > Want to make something of it? > > > http://www.olddog.co.uk/ccamp-drafts.htm > > > > > > (Thanks Jean-Louis) > > > > > > Adrian > > > > > > ----- Original Message ----- > > > From: "Adrian Farrel" > > > To: > > > Sent: Monday, February 21, 2005 12:32 PM > > > Subject: Draft status updated on alternate CCAMP web page > > > > > > > > > > I have updated http://www.oldog.co.uk/ccamp-drafts.htm to > > > indicate the > > > > current status of all CCAMP drafts. I have yet to update > > the section > > > that > > > > covers personal drafts related to CCAMP. > > > > > > > > Adrian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 14:00:20 +0000 To: Igor Bryskin Cc: LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Date: Fri, 4 Mar 2005 14:59:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 PFA+aWdvciAtIGEgc2hvcnQgaGludCBjb25jZXJuaW5nIHRoZSBmaXJzdCBwb2ludDxCUj48QlI+ PEZPTlQgU0laRT0yPjxCPklnb3IgQnJ5c2tpbiAmbHQ7aV9icnlza2luQHlhaG9vLmNvbSZndDs8 L0I+PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+U2VudCBieTogb3duZXItY2NhbXBAb3BzLmlldGYu b3JnPC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+MDMvMDQvMjAwNSAwNToyNiBQU1Q8L0ZPTlQ+PEJS PjxCUj4gPEZPTlQgU0laRT0yPlRvOjwvRk9OVD4gPEZPTlQgU0laRT0yPkxFIFJPVVggSmVhbi1M b3VpcyBSRC1DT1JFLUxBTiAmbHQ7amVhbmxvdWlzLmxlcm91eEBmcmFuY2V0ZWxlY29tLmNvbSZn dDssIGNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZPTlQ+ IDxCUj4gPEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPlN1YmplY3Q6 PC9GT05UPiA8Rk9OVCBTSVpFPTI+UmU6IFJFIDogVFIgOiBJLUQgQUNUSU9OOmRyYWZ0LWxlcm91 eC1jY2FtcC1nbXBscy1tcm4tZXZhbC0wMC50eHQ8L0ZPTlQ+PEJSPiA8QlI+PEJSPjwvUD48UD48 Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SkwsPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFD RT0iTW9ub3NwYWNlLENvdXJpZXIiPlBsZWFzZSwgc2VlIG15IGNvbW1lbnRzIGluLWxpbmU8QlI+ PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SWdvcjxCUj48L0ZPTlQ+ PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4tLS0gTEUgUk9VWCBKZWFuLUxvdWlz IFJELUNPUkUtTEFOPEJSPiZsdDtqZWFubG91aXMubGVyb3V4QGZyYW5jZXRlbGVjb20uY29tJmd0 OyB3cm90ZTo8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0 OyBIaSBJZ29yLDxCUj4mZ3Q7PEJSPiZndDsgVGhhbmtzIGZvciB0aGVzZSBjb21tZW50czxCUj4m Z3Q7PEJSPiZndDsgUGxlYXNlIHNlZSBpbmxpbmU8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgJmd0 Oy0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxCUj4mZ3Q7ICZndDtEZSA6IElnb3IgQnJ5c2tp biBbbWFpbHRvOmlfYnJ5c2tpbkB5YWhvby5jb21dPEJSPiZndDsgJmd0O0Vudm95JmVhY3V0ZTsg OiBqZXVkaSAzIG1hcnMgMjAwNSAyMDo0NTxCUj4mZ3Q7ICZndDsmQWdyYXZlOyA6IExFIFJPVVgg SmVhbi1Mb3VpcyBSRC1DT1JFLUxBTjs8QlI+Jmd0OyBjY2FtcEBvcHMuaWV0Zi5vcmc8QlI+Jmd0 OyAmZ3Q7T2JqZXQgOiBSZTogVFIgOiBJLUQ8QlI+Jmd0OyBBQ1RJT046ZHJhZnQtbGVyb3V4LWNj YW1wLWdtcGxzLW1ybi1ldmFsLTAwLnR4dDxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZn dDsgJmd0O0pMLDxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7SSBoYXZlIGEgY291cGxlIG9mIGNv bW1lbnRzL3N1Z2dlc3Rpb25zLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7MS5UaGUgZHJhZnQg c2F5cyB0aGF0IGN1cnJlbnRseSBHTVBMUyBkb2VzIG5vdDxCUj4mZ3Q7IGhhdmUgYTxCUj4mZ3Q7 ICZndDttZWNoYW5pc20gdG8gcHJvdmlzaW9uIHZpcnR1YWwgRkFzLiBJIGRvbid0IHRoaW5rPEJS PiZndDsgdGhpczxCUj4mZ3Q7ICZndDtpcyBjb3JyZWN0IC0gSSBiZWxpZXZlIHdlIGNvdWxkIHVz ZSB0aGUgc2FtZTxCUj4mZ3Q7IG1lY2hhbmlzbTxCUj4mZ3Q7ICZndDthcyB3YXMgc3VnZ2VzdGVk IGluPEJSPiZndDsgJmd0O2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtcmVjb3ZlcnktZTJlLXNpZ25h bGluZzxCUj4mZ3Q7IChzZWN0aW9uPEJSPiZndDsgJmd0OzkuMykgZm9yIHNpZ25hbGluZyBvZiBT ZWNvbmRhcnkgTFNQczxCUj4mZ3Q7PEJSPiZndDsgSSB3b3VsZG4ndCBiZSBzbyBleHBlZGl0aW91 cy4uLjxCUj4mZ3Q7IEFjdHVhbGx5IHdlIGNvdWxkIHVzZSBhIHNpbWlsYXIgbWVjaGFuaXNtIGJ1 dDxCUj4mZ3Q7IGRlZmluaXRlbHkgbm90IHRoZSBzYW1lLjxCUj4mZ3Q7IFNlY29uZGFyeSBMU1Ag YXJlIGRlZGljYXRlZCB0byBTaGFyZWQgTWVzaGVkPEJSPiZndDsgUmVzdG9yYXRpb24uPEJSPiZn dDsgSU1ITyB0aGlzIHdvdWxkIGJlIGJhZCB0byB1c2UgdGhlIFByb3RlY3Rpb24gb2JqZWN0PEJS PiZndDsgZm9yIHNvZnQtRkFzLiBTZW1hbnRpY3M8QlI+Jmd0OyBhcmUgcHJldHR5IGRpZmZlcmVu dC4uLjxCUj4mZ3Q7PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi PklCJmd0OyZndDtXZWxsLCBhcmUgdGhleT8gVGhleSBnaXZlIHlvdSBhIHdheSB0byBzaWduYWwg YTxCUj5yZXF1aXJlbWVudCBub3QgdG8gY29tbWl0IHJlc291cmNlcyBmb3IgYW4gTFNQIHVudGls PEJSPmZ1cnRoZXIgbm90aWNlIGFuZCBhbHNvIHRvIHJlcXVpcmUgdGhlaXIgY29tbWl0bWVudDxC Uj53aGVuIGl0IGJlY29tZXMgbmVjZXNzYXJ5LiBXaHkgbm90IHRvIGFsbG93IHdvcmtpbmc8QlI+ TFNQIHRvIGJlIHNpZ25hbGVkIGFzIFNlY29uZGFyeSBhY2NvcmRpbmcgdG8gdGhlPEJSPm1lbnRp b25lZCBkcmFmdD8gVGhlbiBpdCB3b3VsZCBiZSBwb3NzaWJsZSBldmVuIHRvPEJSPnNpZ25hbCBw cm90ZWN0ZWQgdmlydHVhbCBGQXMsIHdoaWNoIGlzIG5vdCBhcyBzdHVwaWQ8QlI+YXMgaXQgbWF5 IHNvdW5kIDo9KTxCUj48L0ZPTlQ+PEJSPkRQJmd0OyBiZWNhdXNlIGl0IHdvdWxkIHJlcXVpcmUg Y29uc2lkZXJpbmcgd29ya2luZyBzZWNvbmRhcmllcyAtIHRoaXMgY29tYmluYXRpb24gaXMgcHJl Y2x1ZGVkIGFzIGl0IGRvZXMgbm90IG1ha2UgYW55IHNlbnNlIChzZWUgdGhlIGRvY3VtZW50LCBh IGJpdCBhIHNpbmdsZSBzZW1hbnRpYykgd2hpbGUgdGhlIGNvbWJpbmF0aW9uIHByb3RlY3Rpbmcg c2Vjb25kYXJ5IGlzIGFscmVhZHkgZGV0ZXJtaW5lZCBhcyBzYWlkIGJ5IEpMICh0aGlzIGlzIHN0 cmljdGx5IHJlbGF0ZWQgdG8gYSBwcm90ZWN0aW9uIG9iamVjdCkgLSBhbnkgb3RoZXIgc2VtYW50 aWMgb3ZlcmxvYWQgd291bGQgYmUgY29uc2lkZXJlZCBoZXJlIGFzIGEgYmFkIHByb3RvY29sIGRl c2lnbiBwcmFjdGljZSAtIHRoZXJlZm9yZSBpdCBpcyBtdWNoIGFwcHJvcHJpYXRlIHRvIGNvbnNp ZGVyIGEgc3BlY2lmaWMgZm9yIGRpc3Rpbmd1aXNoaW5nIGJvdGggdmlydHVhbCBmcm9tIG5vbi12 aXJ0dWFsIEZBcyBhbmQgbWFrZSB1c2Ugb2YgdGhlIHByb3RlY3Rpb24gb2JqZWN0IGFzIGRlZmlu ZWQgaW4gdGhlIGVuZC10by1lbmQgcmVjb3ZlcnkgZG9jdW1lbnQgYXMgcmVxdWlyZWQgaS5lLiBw cm90ZWN0ZWQgb3Igbm90IHZpcnR1YWwgRkFzLCBwcm90ZWN0ZWQgb3Igbm90IEZBLUxTUHMsIGV0 Yy4gPC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj48QlI+Jmd0OyAmZ3Q7Mi5J IGFncmVlIHRoYXQgd2UgbmVlZCBURSBsaW5rIGFkYXB0YXRpb248QlI+Jmd0OyAmZ3Q7Y2FwYWJp bGl0aWVzIHRvIGJlIGFkdmVydGlzZWQgYWxvbmcgd2l0aCBvdGhlciBURTxCUj4mZ3Q7IGxpbms8 QlI+Jmd0OyAmZ3Q7YXR0cmlidXRlcyBzdWNoIGFzIHN3aXRjaGluZyBjYXBhYmlsaXRpZXMsPEJS PiZndDsgcHJvdGVjdGlvbjxCUj4mZ3Q7ICZndDtjYXBhYmlsaXRpZXMsIGV0Yy4gSSBzdWdnZXN0 IGFsc28gYWRkaW5nIFRFIGxpbms8QlI+Jmd0OyB0ZXJtaW5hdGlvbjxCUj4mZ3Q7ICZndDtjYXBh YmlsaXRpZXMgdG8gdGhpcyBsaXN0LCBpLmUuIGRlY291cGxpbmcgb2YgdGhlc2U8QlI+Jmd0OzxC Uj4mZ3Q7ICZndDtjYXBhYmlsaXRpZXMgZnJvbSBhZGFwdGF0aW9uIGNhcGFiaWxpdGllczo8QlI+ Jmd0OyAmZ3Q7dG8gdGVybWluYXRlIExTUCBpbiBhIHBhcnRpY3VsYXIgbGF5ZXIgYW5kIHRvIGFk b3B0PEJSPiZndDsgJmd0O2ludG8gaXQgTFNQcyBvZiBvbmUgb3IgbW9yZSBoaWdoZXIgbGF5ZXJz IGFyZTxCUj4mZ3Q7IHNlcGFyYXRlPEJSPiZndDsgJmd0O3Jlc291cmNlcyBhbmQgY291bGQgYmUg Y29uc2lkZXJlZCBzZXBhcmF0ZWx5IGluIHRoZTxCUj4mZ3Q7PEJSPiZndDsgJmd0O2ludGVyLWxh eWVyIHBhdGggY29tcHV0YXRpb25zOzxCUj4mZ3Q7PEJSPiZndDsgSSBhZ3JlZSB0aGF0IG91ciBj dXJlbnQgdGVybWlub2xvZ3kgbWF5IGJlIGNvbmZ1c2luZzxCUj4mZ3Q7IFdoYXQgd2UgY2FsbCBJ bnRlcm5hbCBBZGFwYXRhdGlvbiBDYXBhYmlsaXR5PEJSPiZndDsgYWN0dWFsbHkgcmVmZXJzIHRv IFRlcm1pbmF0aW9uIGNhcGFiaWxpdGllcy48QlI+Jmd0OyBTZWUgdGhlIE1STiByZXF1aXJlbWVu dCBkcmFmdCAodmVyc2lvbiAwMSkgZm9yIGFuPEJSPiZPc2xhc2g7ZXhhbXBsZS48QlI+PC9GT05U PjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SUImZ3Q7Jmd0OyBNeSBwb2ludCBp cyB0aGF0IHRlcm1pbmF0aW9uIGFuZCBhZGFwdGF0aW9uPEJSPmNhcGFiaWxpdGllcyBhcmUgc2Vw YXJhdGUgdGhpbmdzLiBGb3IgaW5zdGFuY2UsIHRoZTxCUj5mYWN0IHRoYXQgYSBsaW5rIGNhbiB0 ZXJtaW5hdGUgbGFtYmRhcyBtZWFucyB0aGUgaXQ8QlI+aGFzIGNlcnRhaW4gbnVtYmVyIG9mIGF2 YWlsYWJsZSB0cmFuc2NlaXZlcnMsIHdoaWxlPEJSPnRoZSBmYWN0IHdoZXRoZXIgdGhlc2UgbGFt YmRhcyBjYW4gY2FycnkgcGFydGljdWxhcjxCUj50cmlidXRhcnkgc2lnbmFscyBkZXBlbmRzLCBz YXksIG9uIHdoZXRoZXIgU0lNIGNhcmRzPEJSPm9mIGFwcHJvcHJpYXRlIHR5cGUgY291bGQgYmUg Y3Jvc3MtY29ubmVjdGVkIHRvIHRoZTxCUj50cmFuc2NlaXZlcnMuIEluIGZhY3QsIGxpbmsgdGVy bWluYXRpb24gYmFuZHdpZHRoIGlzPEJSPnNoYXJlZCBiZXR3ZWVuIG11bHRpcGxlIGFkYXB0YXRp b24gZnVuY3Rpb25zLiBUaGU8QlI+Ym90dG9tIGxpbmUgaXMgSSB0aGluayBpdCB3b3VsZCBiZSBn b29kIGlkZWEgdG88QlI+YWR2ZXJ0aXNlIHRoZW0gc2VwYXJhdGVseS48QlI+PC9GT05UPjxCUj48 Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgJmd0OzMu RXZlcnl0aGluZyB0aGF0IGlzIHNhaWQgYWJvdXQgcmVnaW9ucywgcmVnaW9uPEJSPiZndDsgJmd0 O2JvdW5kYXJpZXMsIGV0Yy4gaXMgYWxzbyBhcHBsaWNhYmxlIGZvciBsYXllcnM8QlI+Jmd0OyAm Z3Q7Y29udGFpbmVkIHdpdGhpbiByZWdpb25zLiBJIHN1Z2dlc3QgdG8gZG8gd2hhdCB3ZTxCUj4m Z3Q7IGhhdmU8QlI+Jmd0OyAmZ3Q7YWxyZWFkeSBkb25lIGluIHRoZSBQQ0UgV0cgZG9jdW1lbnRz IGFuZDxCUj4mZ3Q7ICZndDtwcmVzZW50YXRpb25zOiByZXBsYWNlIHdvcmQgcmVnaW9uIHdpdGgg d29yZCBsYXllcjxCUj4mZ3Q7ICZndDtldmVyeXdoZXJlIGFwYXJ0IGZyb20gd2hlcmUgc2lnbmFs aW5nIHNwZWNpZmljPEJSPiZndDsgYXNwZWN0czxCUj4mZ3Q7ICZndDthcmUgZGlzY3Vzc2VkLjxC Uj4mZ3Q7PEJSPiZndDsgU2VlIHNlY3Rpb24gMyBvZiB0aGUgcmVxdWlyZW1lbnQgZHJhZnQuPEJS PiZndDsgQWN0dWFsbHkgd2hhdCB3ZSBkZWZpbmUgZm9yIHJlZ2lvbiBhbHNvIGFwcGxpZXMgdG88 QlI+Jmd0OyBsYXllcnMsIGJ1dCB3ZSBwcmVmZXIgdG88QlI+Jk9zbGFzaDtrZWVwIHRoZSB0ZXJt IHJlZ2lvbiBoZXJlIGF0IHRoZSB0aW1lIGJlaW5nLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9 Ik1vbm9zcGFjZSxDb3VyaWVyIj5JQiZndDsmZ3Q7IEFuZCBteSBxdWVzdGlvbiBpcyB3aHkgdG8g ZG8gc28sIGlmIEZBcyBhbmQ8QlI+ZXZlcnl0aGluZyB0byBkbyB3aXRoIFZOVCBpcyBhYm91dCBs YXllcnMsIGluY2x1ZGluZzxCUj50aG9zZSB0aGF0IHN0YXJ0IGFuZCBzdG9wIGluIHRoZSBtaWRk bGUgb2YgdGhlIHJlZ2lvbiw8QlI+dGhhdCBpcywgZmFyIGF3YXkgZnJvbSByZWdpb24gYm91bmRh cmllcz8gRnVydGhlcm1vcmUsPEJSPndoZW4geW91IHNheSB0aGluZ3MgbGlrZSBjcmVhdGluZyBG QSBpbiB0aGUgbG93ZXI8QlI+cmVnaW9uIHRvIGNhcnJ5IExTUCBmb3IgdGhlIGhpZ2hlciByZWdp b24sIGl0IGlzIG5vdDxCUj5jbGVhciB3aGF0IGRvIHlvdSBtZWFuIGJ5IHRoYXQgaW4gdGhlIGNh c2Ugd2hlbiB0aGU8QlI+bG93ZXIgcmVnaW9uIGNvbnRhaW5zIG11bHRpcGxlIGxheWVycy48QlI+ PC9GT05UPjwvUD48UD4mbmJzcDs8L1A+PFA+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy aWVyIj5JZ29yPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPiZn dDs8QlI+Jmd0OyBBZ2FpbiwgdGhhbmtzIGEgbG90IGZvciB0aGVzZSBjb21tZW50cyw8QlI+Jmd0 OzxCUj4mZ3Q7IFJlZ2FyZHMsPEJSPiZndDs8QlI+Jmd0OyBKTDxCUj4mZ3Q7PEJSPiZndDsgJmd0 OzxCUj4mZ3Q7ICZndDtUaGFua3MsPEJSPiZndDsgJmd0O0lnb3I8QlI+Jmd0OyAmZ3Q7PEJSPiZn dDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7LS0tIExFIFJPVVggSmVhbi1Mb3VpcyBS RC1DT1JFLUxBTjxCUj4mZ3Q7ICZndDsmbHQ7amVhbmxvdWlzLmxlcm91eEBmcmFuY2V0ZWxlY29t LmNvbSZndDsgd3JvdGU6PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJS PiZndDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7Jmd0OyBIaSBhbGwsPEJSPiZndDsgJmd0OyZndDs8 QlI+Jmd0OyAmZ3Q7Jmd0OyBIZXJlIGlzIGEgbmV3IGRyYWZ0IGV2YWx1YXRpbmcgY3VycmVudCBH TVBMUzxCUj4mZ3Q7ICZndDsmZ3Q7IHByb3RvY29scyB3cnQgTVJOPEJSPiZndDsgJmd0OyZndDsg cmVxdWlyZW1lbnRzLjxCUj4mZ3Q7ICZndDsmZ3Q7IFlvdXIgY29tbWVudHMgb24gdGhpcyBuZXcg ZHJhZnQgd291bGQgYmUgaGlnaGx5PEJSPiZndDsgJmd0OyZndDsgYXBwcmVjaWF0ZWQuPEJSPiZn dDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7Jmd0OyBCZXN0IFJlZ2FyZHMsPEJSPiZndDsgJmd0OyZn dDs8QlI+Jmd0OyAmZ3Q7Jmd0OyBKTDxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0OyZndDsg VG86IGktZC1hbm5vdW5jZSBhdCBpZXRmLm9yZzxCUj4mZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IEkt RDxCUj4mZ3Q7ICZndDsmZ3Q7IEFDVElPTjpkcmFmdC1sZXJvdXgtY2NhbXAtZ21wbHMtbXJuLWV2 YWwtMDAudHh0PEJSPiZndDsgJmd0OyZndDsgRnJvbTogSW50ZXJuZXQtRHJhZnRzIGF0IGlldGYu b3JnPEJSPiZndDsgJmd0OyZndDsgRGF0ZTogVHVlLCAxNSBGZWIgMjAwNSAxMDoxNDozOCAtMDUw MDxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0OyZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlPEJSPiZndDsgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8QlI+ Jmd0OyAmZ3Q7Jmd0OyBkaXJlY3Rvcmllcy48QlI+Jmd0OyAmZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDsm Z3Q7PEJSPiZndDsgJmd0OyZndDsgVGl0bGU6IEV2YWx1YXRpb24gb2YgZXhpc3RpbmcgR01QTFMg UHJvdG9jb2xzPEJSPiZndDsgJmd0OyZndDsgYWdhaW5zdDxCUj4mZ3Q7ICZndDsmZ3Q7IE11bHRp IFJlZ2lvbiBOZXR3b3JrczxCUj4mZ3Q7ICZndDsmZ3Q7IEF1dGhvcihzKTogSi4gTGUgUm91eCwg ZXQgYWwuPEJSPiZndDsgJmd0OyZndDsgRmlsZW5hbWU6PEJSPiZndDsgZHJhZnQtbGVyb3V4LWNj YW1wLWdtcGxzLW1ybi1ldmFsLTAwLnR4dDxCUj4mZ3Q7ICZndDsmZ3Q7IFBhZ2VzOiAxMTxCUj4m Z3Q7ICZndDsmZ3Q7IERhdGU6IDIwMDUtMi0xNDxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0 OyZndDsgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhbiBldmFsdWF0aW9uIG9mPEJSPiZndDsgR2Vu ZXJhbGl6ZWQgTXVsdGktUHJvdG9jb2w8QlI+Jmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7TGFi ZWwgU3dpdGNoaW5nIChHTVBMUykgcHJvdG9jb2xzIGFuZDxCUj4mZ3Q7IG1lY2hhbmlzbXM8QlI+ Jmd0OyAmZ3Q7Jmd0OyBhZ2FpbnN0IHRoZTxCUj4mZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDty ZXF1aXJlbWVudHMgZm9yIE11bHRpIFJlZ2lvbiBOZXR3b3JrcyAoTVJOKS48QlI+Jmd0OzxCUj4m Z3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtJbiBhZGRpdGlvbiwgdGhpcyBkb2N1bWVudCBpZGVu dGlmaWVzIGFyZWFzPEJSPiZndDsgd2hlcmU8QlI+Jmd0OyAmZ3Q7Jmd0OyBhZGRpdGlvbmFsPEJS PiZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwO3Byb3RvY29sIGV4dGVuc2lvbnMgb3IgcHJvY2Vk dXJlcyBhcmUgbmVlZGVkPEJSPiZndDsgdG88QlI+Jmd0OyAmZ3Q7Jmd0OyBzYXRpc2Z5IHRoZTxC Uj4mZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtyZXF1aXJlbWVudHMgb2YgTXVsdGkgUmVnaW9u IE5ldHdvcmtzLCBhbmQ8QlI+Jmd0OyAmZ3Q7Jmd0OyBwcm92aWRlcyBndWlkZWxpbmVzIGZvcjxC Uj4mZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtwb3RlbnRpYWwgZXh0ZW5zaW9ucy48QlI+Jmd0 OyAmZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDsmZ3Q7IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0 IGlzOjxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDs8QlI+Jmd0O2h0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxlcm91eC1jY2FtcC1nbXBscy1tcjxCUj4mZ3Q7IG4tZXZh bC0wMDxCUj4mZ3Q7ICZndDsgLnR4dDxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsg Jmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJS PiZndDs8QlI+Jmd0OzxCUj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 QlI+Jmd0OyBDZWxlYnJhdGUgWWFob28hJ3MgMTB0aCBCaXJ0aGRheSE8QlI+Jmd0OyBZYWhvbyEg TmV0cm9zcGVjdGl2ZTogMTAwIE1vbWVudHMgb2YgdGhlIFdlYjxCUj4mZ3Q7IDxBIEhSRUY9aHR0 cDovL2JpcnRoZGF5LnlhaG9vLmNvbS9uZXRyb3NwZWN0aXZlLz5odHRwOi8vYmlydGhkYXkueWFo b28uY29tL25ldHJvc3BlY3RpdmUvPC9BPjxCUj4mZ3Q7PEJSPjwvRk9OVD48QlI+PEJSPjxCUj48 QlI+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPEJSPkNlbGVicmF0ZSBZYWhvbyEncyAxMHRoIEJpcnRoZGF5ITxCUj5Z YWhvbyEgTmV0cm9zcGVjdGl2ZTogMTAwIE1vbWVudHMgb2YgdGhlIFdlYjxCUj48QSBIUkVGPWh0 dHA6Ly9iaXJ0aGRheS55YWhvby5jb20vbmV0cm9zcGVjdGl2ZS8+aHR0cDovL2JpcnRoZGF5Lnlh aG9vLmNvbS9uZXRyb3NwZWN0aXZlLzwvQT48L0ZPTlQ+PC9QPg== Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 13:27:43 +0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=l9Aw2FKYoriDOx2y5pEGlsqaU7LHcHLEnIIxrllwOH1Ld5S1ts7XRFdOF94ta00r5rFsoGtD1ZnoHwbnouwgx6xWa53xuvMnnWwFpDqFxYqq3+weOXKfXtGkUsTKsQ3eh3DZy0UCymEw2UU7NZkzu41kmd/AvDzS+HsQddW2Pdc= ; Message-ID: <20050304132624.8409.qmail@web30805.mail.mud.yahoo.com> Date: Fri, 4 Mar 2005 05:26:24 -0800 (PST) From: Igor Bryskin Subject: Re: RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt To: LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii JL, Please, see my comments in-line Igor --- LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Igor, > > Thanks for these comments > > Please see inline > > > >-----Message d'origine----- > >De : Igor Bryskin [mailto:i_bryskin@yahoo.com] > >Envoyé : jeudi 3 mars 2005 20:45 > >À : LE ROUX Jean-Louis RD-CORE-LAN; > ccamp@ops.ietf.org > >Objet : Re: TR : I-D > ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt > > > > > >JL, > > > >I have a couple of comments/suggestions. > > > >1. The draft says that currently GMPLS does not > have a > >mechanism to provision virtual FAs. I don't think > this > >is correct - I believe we could use the same > mechanism > >as was suggested in > >draft-ietf-ccamp-gmpls-recovery-e2e-signaling > (section > >9.3) for signaling of Secondary LSPs > > I wouldn't be so expeditious... > Actually we could use a similar mechanism but > definitely not the same. > Secondary LSP are dedicated to Shared Meshed > Restoration. > IMHO this would be bad to use the Protection object > for soft-FAs. Semantics > are pretty different... > IB>>Well, are they? They give you a way to signal a requirement not to commit resources for an LSP until further notice and also to require their commitment when it becomes necessary. Why not to allow working LSP to be signaled as Secondary according to the mentioned draft? Then it would be possible even to signal protected virtual FAs, which is not as stupid as it may sound :=) > > >2. I agree that we need TE link adaptation > >capabilities to be advertised along with other TE > link > >attributes such as switching capabilities, > protection > >capabilities, etc. I suggest also adding TE link > termination > >capabilities to this list, i.e. decoupling of these > > >capabilities from adaptation capabilities: > >to terminate LSP in a particular layer and to adopt > >into it LSPs of one or more higher layers are > separate > >resources and could be considered separately in the > > >inter-layer path computations; > > I agree that our curent terminology may be confusing > What we call Internal Adapatation Capability > actually refers to Termination capabilities. > See the MRN requirement draft (version 01) for an Ø example. IB>> My point is that termination and adaptation capabilities are separate things. For instance, the fact that a link can terminate lambdas means the it has certain number of available transceivers, while the fact whether these lambdas can carry particular tributary signals depends, say, on whether SIM cards of appropriate type could be cross-connected to the transceivers. In fact, link termination bandwidth is shared between multiple adaptation functions. The bottom line is I think it would be good idea to advertise them separately. > > > >3. Everything that is said about regions, region > >boundaries, etc. is also applicable for layers > >contained within regions. I suggest to do what we > have > >already done in the PCE WG documents and > >presentations: replace word region with word layer > >everywhere apart from where signaling specific > aspects > >are discussed. > > See section 3 of the requirement draft. > Actually what we define for region also applies to > layers, but we prefer to Ø keep the term region here at the time being. IB>> And my question is why to do so, if FAs and everything to do with VNT is about layers, including those that start and stop in the middle of the region, that is, far away from region boundaries? Furthermore, when you say things like creating FA in the lower region to carry LSP for the higher region, it is not clear what do you mean by that in the case when the lower region contains multiple layers. Igor > > Again, thanks a lot for these comments, > > Regards, > > JL > > > > >Thanks, > >Igor > > > > > > > >--- LE ROUX Jean-Louis RD-CORE-LAN > > wrote: > > > > > > > >> > >> Hi all, > >> > >> Here is a new draft evaluating current GMPLS > >> protocols wrt MRN > >> requirements. > >> Your comments on this new draft would be highly > >> appreciated. > >> > >> Best Regards, > >> > >> JL > >> > >> To: i-d-announce at ietf.org > >> Subject: I-D > >> ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt > >> From: Internet-Drafts at ietf.org > >> Date: Tue, 15 Feb 2005 10:14:38 -0500 > >> > >> A New Internet-Draft is available from the > on-line Internet-Drafts > >> directories. > >> > >> > >> Title : Evaluation of existing GMPLS Protocols > >> against > >> Multi Region Networks > >> Author(s) : J. Le Roux, et al. > >> Filename : > draft-leroux-ccamp-gmpls-mrn-eval-00.txt > >> Pages : 11 > >> Date : 2005-2-14 > >> > >> This document provides an evaluation of > Generalized Multi-Protocol > >> Label Switching (GMPLS) protocols and > mechanisms > >> against the > >> requirements for Multi Region Networks (MRN). > > >> In addition, this document identifies areas > where > >> additional > >> protocol extensions or procedures are needed > to > >> satisfy the > >> requirements of Multi Region Networks, and > >> provides guidelines for > >> potential extensions. > >> > >> A URL for this Internet-Draft is: > >> > >http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mr > n-eval-00 > > .txt > > > > > > > > > > > > > > > > __________________________________ > Celebrate Yahoo!'s 10th Birthday! > Yahoo! Netrospective: 100 Moments of the Web > http://birthday.yahoo.com/netrospective/ > __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 09:36:35 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Date: Fri, 4 Mar 2005 10:35:10 +0100 Message-ID: Thread-Topic: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Thread-Index: AcUgKYHELyJ/qyG8QG2tPdoiCwZ9BAAaRajw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Igor Bryskin" , Hi Igor,=20 Thanks for these comments Please see inline >-----Message d'origine----- >De : Igor Bryskin [mailto:i_bryskin@yahoo.com]=20 >Envoy=E9 : jeudi 3 mars 2005 20:45 >=C0 : LE ROUX Jean-Louis RD-CORE-LAN; ccamp@ops.ietf.org >Objet : Re: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt=20 > > >JL, > >I have a couple of comments/suggestions. > >1. The draft says that currently GMPLS does not have a >mechanism to provision virtual FAs. I don't think this >is correct - I believe we could use the same mechanism >as was suggested in=20 >draft-ietf-ccamp-gmpls-recovery-e2e-signaling (section >9.3) for signaling of Secondary LSPs I wouldn't be so expeditious... Actually we could use a similar mechanism but definitely not the same. Secondary LSP are dedicated to Shared Meshed Restoration. IMHO this would be bad to use the Protection object for soft-FAs. = Semantics are pretty different... >2. I agree that we need TE link adaptation >capabilities to be advertised along with other TE link=20 >attributes such as switching capabilities, protection=20 >capabilities, etc. I suggest also adding TE link termination=20 >capabilities to this list, i.e. decoupling of these=20 >capabilities from adaptation capabilities:=20 >to terminate LSP in a particular layer and to adopt >into it LSPs of one or more higher layers are separate=20 >resources and could be considered separately in the=20 >inter-layer path computations; I agree that our curent terminology may be confusing What we call Internal Adapatation Capability actually refers to = Termination capabilities. See the MRN requirement draft (version 01) for an example. >3. Everything that is said about regions, region >boundaries, etc. is also applicable for layers >contained within regions. I suggest to do what we have >already done in the PCE WG documents and >presentations: replace word region with word layer >everywhere apart from where signaling specific aspects >are discussed. See section 3 of the requirement draft. Actually what we define for region also applies to layers, but we prefer = to keep the term region here at the time being. Again, thanks a lot for these comments, Regards, JL > >Thanks, >Igor > =20 > > >--- LE ROUX Jean-Louis RD-CORE-LAN=20 > wrote: > > > >>=20 >> Hi all, >>=20 >> Here is a new draft evaluating current GMPLS >> protocols wrt MRN >> requirements. >> Your comments on this new draft would be highly >> appreciated. >>=20 >> Best Regards, >>=20 >> JL >>=20 >> To: i-d-announce at ietf.org >> Subject: I-D >> ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt=20 >> From: Internet-Drafts at ietf.org=20 >> Date: Tue, 15 Feb 2005 10:14:38 -0500=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>=20 >>=20 >> Title : Evaluation of existing GMPLS Protocols >> against >> Multi Region Networks >> Author(s) : J. Le Roux, et al. >> Filename : draft-leroux-ccamp-gmpls-mrn-eval-00.txt >> Pages : 11 >> Date : 2005-2-14 >> =09 >> This document provides an evaluation of Generalized Multi-Protocol >> Label Switching (GMPLS) protocols and mechanisms >> against the=20 >> requirements for Multi Region Networks (MRN). =20 >> In addition, this document identifies areas where >> additional=20 >> protocol extensions or procedures are needed to >> satisfy the=20 >> requirements of Multi Region Networks, and >> provides guidelines for=20 >> potential extensions. >>=20 >> A URL for this Internet-Draft is: >> >http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mr n-eval-00 > .txt >=20 >=20 >=20 >=20 > =09 =09 __________________________________=20 Celebrate Yahoo!'s 10th Birthday!=20 Yahoo! Netrospective: 100 Moments of the Web=20 http://birthday.yahoo.com/netrospective/ Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Mar 2005 02:23:25 +0000 Message-ID: <4227C61E.2000205@psg.com> Date: Fri, 04 Mar 2005 03:21:18 +0100 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 MIME-Version: 1.0 To: Igor Bryskin CC: LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org Subject: Re: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit igor - i let to jl the opportunit to respond in much more in details but here below some hints: > I have a couple of comments/suggestions. > > 1. The draft says that currently GMPLS does not have a > mechanism to provision virtual FAs. I don’t think this > is correct – I believe we could use the same mechanism > as was suggested in > draft-ietf-ccamp-gmpls-recovery-e2e-signaling (section > 9.3) for signaling of Secondary LSPs there is no mechanism to setup/delete "virtual FAs" as part of GMPLS signaling protocol today the secondary LSP concept, even if the latter may look similar to the virtual FA concept - note: this is explicitly mentioned as part of the recovery document however, the advertisement of the corr. TE link must be identical to what currently exist for fully provisioned FAs > 2. I agree that we need TE link adaptation > capabilities to be advertised along with other TE link > attributes such as switching capabilities, protection > capabilities, etc. I suggest also adding TE link > termination capabilities to this list, i.e. decoupling > of these capabilities from adaptation capabilities: > to terminate LSP in a particular layer and to adopt > into it LSPs of one or more higher layers are separate > resources and could be considered separately in the > inter-layer path computations; would you let us know what is missing in terms of termination capabilities - before we expand on this ? > 3. Everything that is said about regions, region > boundaries, etc. is also applicable for layers > contained within regions. I suggest to do what we have > already done in the PCE WG documents and > presentations: replace word region with word layer > everywhere apart from where signaling specific aspects > are discussed. i suggest you take a look at section 3.1 of it may help in understand the region vs layer concepts > Thanks, > Igor > > > > --- LE ROUX Jean-Louis RD-CORE-LAN > wrote: > > > > >>Hi all, >> >>Here is a new draft evaluating current GMPLS >>protocols wrt MRN >>requirements. >>Your comments on this new draft would be highly >>appreciated. >> >>Best Regards, >> >>JL >> >>To: i-d-announce at ietf.org >>Subject: I-D >>ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt >>From: Internet-Drafts at ietf.org >>Date: Tue, 15 Feb 2005 10:14:38 -0500 >> >>A New Internet-Draft is available from the on-line >>Internet-Drafts >>directories. >> >> >> Title : Evaluation of existing GMPLS Protocols >>against >>Multi Region Networks >> Author(s) : J. Le Roux, et al. >> Filename : draft-leroux-ccamp-gmpls-mrn-eval-00.txt >> Pages : 11 >> Date : 2005-2-14 >> >>This document provides an evaluation of Generalized >>Multi-Protocol >> Label Switching (GMPLS) protocols and mechanisms >>against the >> requirements for Multi Region Networks (MRN). >> In addition, this document identifies areas where >>additional >> protocol extensions or procedures are needed to >>satisfy the >> requirements of Multi Region Networks, and >>provides guidelines for >> potential extensions. >> >>A URL for this Internet-Draft is: >> > > http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mrn-eval-00 > >>.txt >> >> >> >> >> > > > > > > > __________________________________ > Celebrate Yahoo!'s 10th Birthday! > Yahoo! Netrospective: 100 Moments of the Web > http://birthday.yahoo.com/netrospective/ > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 03 Mar 2005 19:46:40 +0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=whz4O0VjfNchE7E6GgZw3683yEuAYRgyM6ER/RcFpsO51lUigqpmkiq7/02/XZ8LFI1HshXWRKNkeGqdmWVVpcaLWFdgqXTz5Z5d3GuTNX2ASqFVfSyB3xI4d3h2mFHQCTK0F1RTIIJjvVbaiw8lvgnOQHAkxifhnhRMqwiqKgI= ; Message-ID: <20050303194504.53945.qmail@web30805.mail.mud.yahoo.com> Date: Thu, 3 Mar 2005 11:45:03 -0800 (PST) From: Igor Bryskin Subject: Re: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt To: LE ROUX Jean-Louis RD-CORE-LAN , ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii JL, I have a couple of comments/suggestions. 1. The draft says that currently GMPLS does not have a mechanism to provision virtual FAs. I don’t think this is correct – I believe we could use the same mechanism as was suggested in draft-ietf-ccamp-gmpls-recovery-e2e-signaling (section 9.3) for signaling of Secondary LSPs 2. I agree that we need TE link adaptation capabilities to be advertised along with other TE link attributes such as switching capabilities, protection capabilities, etc. I suggest also adding TE link termination capabilities to this list, i.e. decoupling of these capabilities from adaptation capabilities: to terminate LSP in a particular layer and to adopt into it LSPs of one or more higher layers are separate resources and could be considered separately in the inter-layer path computations; 3. Everything that is said about regions, region boundaries, etc. is also applicable for layers contained within regions. I suggest to do what we have already done in the PCE WG documents and presentations: replace word region with word layer everywhere apart from where signaling specific aspects are discussed. Thanks, Igor --- LE ROUX Jean-Louis RD-CORE-LAN wrote: > > Hi all, > > Here is a new draft evaluating current GMPLS > protocols wrt MRN > requirements. > Your comments on this new draft would be highly > appreciated. > > Best Regards, > > JL > > To: i-d-announce at ietf.org > Subject: I-D > ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt > From: Internet-Drafts at ietf.org > Date: Tue, 15 Feb 2005 10:14:38 -0500 > > A New Internet-Draft is available from the on-line > Internet-Drafts > directories. > > > Title : Evaluation of existing GMPLS Protocols > against > Multi Region Networks > Author(s) : J. Le Roux, et al. > Filename : draft-leroux-ccamp-gmpls-mrn-eval-00.txt > Pages : 11 > Date : 2005-2-14 > > This document provides an evaluation of Generalized > Multi-Protocol > Label Switching (GMPLS) protocols and mechanisms > against the > requirements for Multi Region Networks (MRN). > In addition, this document identifies areas where > additional > protocol extensions or procedures are needed to > satisfy the > requirements of Multi Region Networks, and > provides guidelines for > potential extensions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mrn-eval-00 > .txt > > > > > __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 02 Mar 2005 21:53:44 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Date: Wed, 2 Mar 2005 22:51:40 +0100 Message-ID: Thread-Topic: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt Thread-Index: AcUfcYD///LTML9cQJ2kXP1XFm9NVwAACgAg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: Hi all, Here is a new draft evaluating current GMPLS protocols wrt MRN requirements. Your comments on this new draft would be highly appreciated. Best Regards, JL To: i-d-announce at ietf.org=20 Subject: I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt=20 From: Internet-Drafts at ietf.org=20 Date: Tue, 15 Feb 2005 10:14:38 -0500=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Evaluation of existing GMPLS Protocols against Multi Region Networks Author(s) : J. Le Roux, et al. Filename : draft-leroux-ccamp-gmpls-mrn-eval-00.txt Pages : 11 Date : 2005-2-14 =09 This document provides an evaluation of Generalized Multi-Protocol=20 Label Switching (GMPLS) protocols and mechanisms against the=20 requirements for Multi Region Networks (MRN). =20 In addition, this document identifies areas where additional=20 protocol extensions or procedures are needed to satisfy the=20 requirements of Multi Region Networks, and provides guidelines for=20 potential extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mrn-eval-00 .txt Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Mar 2005 20:09:13 +0000 Message-Id: <200503012008.j21K8S1j006643@rtp-core-1.cisco.com> From: "Zafar Ali" To: "'Richard Rabbat'" , "'Adrian Farrel'" , Subject: RE: Draft status updated on alternate CCAMP web page Date: Tue, 1 Mar 2005 15:08:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcUaovD8B+NmdnguQaCdiCl+oOdUdQD9lc3w Hi Richard, Re: the ID (draft-shiomoto-ccamp-gmpls-addressing-00), I did find it quite useful and IMO we should pursue this further in CCAMP. Having said that, I would like to point that there are a number of ID-es that are currently NOT in Adrian's list and I think this has to do with his comment in the original email (quoting Adrian): "I have yet to update the section that covers personal drafts related to CCAMP." Adrian, please correct me/ add/ del. Thanks Regards... Zafar > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Richard Rabbat > Sent: Thursday, February 24, 2005 1:52 PM > To: 'Adrian Farrel'; ccamp@ops.ietf.org > Subject: RE: Draft status updated on alternate CCAMP web page > > Adrian, > Can you add > http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls > -addressing-00 > .txt > to your draft tracker? > > We sent out email about it and have received feedback > off-list. We're planning on discussing this draft in > Minneapolis and would love to have more on-list discussions. > As you can see from the list of contributors, there is > enormous interest in this draft and we hope it serves as a > basis for thoughtful discussions. > Best, > Richard, Rajiv and Kohei. > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > > Sent: Monday, February 21, 2005 10:35 AM > > To: Adrian Farrel; ccamp@ops.ietf.org > > Subject: Re: Draft status updated on alternate CCAMP web page > > > > > > So, I can't type. > > Want to make something of it? > > http://www.olddog.co.uk/ccamp-drafts.htm > > > > (Thanks Jean-Louis) > > > > Adrian > > > > ----- Original Message ----- > > From: "Adrian Farrel" > > To: > > Sent: Monday, February 21, 2005 12:32 PM > > Subject: Draft status updated on alternate CCAMP web page > > > > > > > I have updated http://www.oldog.co.uk/ccamp-drafts.htm to > > indicate the > > > current status of all CCAMP drafts. I have yet to update > the section > > that > > > covers personal drafts related to CCAMP. > > > > > > Adrian > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Mar 2005 19:51:02 +0000 From: "Richard Rabbat" To: Cc: , "'Sadler, Jonathan B.'" , "'Ong, Lyndon'" , "'Adrian Farrel'" , , "'Greg Bernstein'" Subject: RE: question about RFC 3946 Date: Tue, 1 Mar 2005 11:46:02 -0800 Message-ID: <005901c51e97$537cf400$473ba485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dimitri, Thanks for the answer. Now, STS-3c and VC-4 share the same signal type. Should they still be formed differently? Richard. > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Tuesday, March 01, 2005 10:58 AM > To: Richard Rabbat > Cc: Dimitri.Papadimitriou@alcatel.be; > eric_mannie@hotmail.com; 'Sadler, Jonathan B.'; 'Ong, > Lyndon'; 'Adrian Farrel'; 'Richard Rabbat'; > ccamp@ops.ietf.org; 'Greg Bernstein' > Subject: Re: question about RFC 3946 > > > > richard: > > "greater" does not mean "strictly greater" it means "greater or equal" > > So, what values of NCC and RCC should one use for STS-3c/VC-4? > > for STS-3c: > An STS-3c SPE signal is formed by the application of RCC with > value 1 (standard contiguous concatenation), NCC with value 1, > NVC with value 0, MT with value 1 and T with value 0 > to an STS- > 3c SPE Elementary Signal. > > for VC-4: > A VC-4 signal is formed by the application of RCC > with value 0, > NCC with value 0, NVC with value 0, MT with value 1 and T with > value 0 to a VC-4 Elementary Signal. > > do not know if this clarifies - > > hint: Note 2 refers to transparent STS-N/STM-N signals > (signal type 7->12) > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Mar 2005 18:59:45 +0000 To: "Richard Rabbat" Cc: , , "'Sadler, Jonathan B.'" , "'Ong, Lyndon'" , "'Adrian Farrel'" , "'Richard Rabbat'" , , "'Greg Bernstein'" From: Dimitri.Papadimitriou@alcatel.be Subject: Re: question about RFC 3946 MIME-Version: 1.0 Date: Tue, 1 Mar 2005 19:57:32 +0100 Message-ID: Content-type: text/plain; charset=us-ascii richard: "greater" does not mean "strictly greater" it means "greater or equal" So, what values of NCC and RCC should one use for STS-3c/VC-4? for STS-3c: An STS-3c SPE signal is formed by the application of RCC with value 1 (standard contiguous concatenation), NCC with value 1, NVC with value 0, MT with value 1 and T with value 0 to an STS- 3c SPE Elementary Signal. for VC-4: A VC-4 signal is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1 and T with value 0 to a VC-4 Elementary Signal. do not know if this clarifies - hint: Note 2 refers to transparent STS-N/STM-N signals (signal type 7->12) Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Mar 2005 18:46:06 +0000 From: "Richard Rabbat" To: , , "'Sadler, Jonathan B.'" Cc: "'Ong, Lyndon'" , "'Adrian Farrel'" , "'Richard Rabbat'" , , "'Greg Bernstein'" Subject: question about RFC 3946 Date: Tue, 1 Mar 2005 10:36:16 -0800 Message-ID: <004701c51e8d$91e6a100$473ba485@PHOENIX> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01C51E4A.83C36100" This is a multi-part message in MIME format. ------=_NextPart_000_0048_01C51E4A.83C36100 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Dimitri, Eric, Jonathan,=20 I have a question about RFC 3946. =20 I'm trying to figure out how to understand text about setting NCC and = RCC=20 values for STS-3c and VC-4. Here's the context: =20 Quoting from RFC 3946: =20 Note 1: when requesting a SONET STS-Nc SPE with N=3D3*X, the Elementary Signal to use must always be an STS-3c_SPE signal type and the value of NCC must always be equal to X. This allows also facilitating the interworking between SONET and SDH. In particular, it means that the contiguous concatenation of three STS-1 SPEs can not be requested because according to this specification, this type of signal must be coded using the STS-3c SPE signal type. =20 Note 1 implies that for SONET STS-3c SPE, NCC =3D1 =20 Note 2: when requesting a transparent STS-N/STM-N signal limited to a single contiguously concatenated STS-Nc_SPE/VC-4-Nc, the signal type must be STS-N/STM-N, RCC with flag 1 and NCC set to 1. =20 Note 2 seems to imply that for STS-3c_SPE/VC-4-1c, RCC =3D NCC =3D 1 =20 Then later on: =20 The NCC value must be consistent with the type of contiguous concatenation being requested in the RCC field. In particular, this field is irrelevant if no contiguous concatenation is requested (RCC =3D 0), in that case it must be set to zero when sent, and should be ignored when received. A RCC value different from 0 must imply a number of contiguous components greater than 1. =20 Given that RCC must be different from 0, the last sentence literally=20 says that an RCC value of 1 (thus different from 0) must imply that NCC = > 1. =20 Going on to the examples of Annex 1: 1. A VC-4 signal is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1 and T with value 0 to a VC-4 Elementary Signal. ... 8. An STS-3c SPE signal is formed by the application of RCC with value 1 (standard contiguous concatenation), NCC with value 1, NVC with value 0, MT with value 1 and T with value 0 to an STS- 3c SPE Elementary Signal. =20 So, what values of NCC and RCC should one use for STS-3c/VC-4? -- Option 1-a: Set NCC =3D RCC =3D 1 for STS-3c and VC-4. Example 1 of the annex is not = the RFC text and should not be followed. =20 Option 1-b: Set NCC =3D RCC =3D 0 for STS-3c and VC-4. Example 8 of the annex is not = the RFC text and should not be followed. =20 Option 2: Set NCC =3D RCC =3D 0 for VC-4 and NCC =3D RCC =3D 1 for STS-3c AND = convert these values when moving between SDH and SONET domains =20 Option 3: Find some NCC-RCC combination that satisfies: " A RCC value different from 0 must imply a number of contiguous components greater than 1." =20 I sent email to Greg Bernstein, and he is of the opinion that options = 1-a or 1-b are best. If you also agree, we may need an errata along the lines: =20 Those would be the suggested changes. =20 FROM: The NCC value must be consistent with the type of contiguous concatenation being requested in the RCC field. In particular, this field is irrelevant if no contiguous concatenation is requested (RCC =3D 0), in that case it must be set to zero when sent, and should be ignored when received. A RCC value different from 0 must imply a number of contiguous components greater than 1. TO: The NCC value must be consistent with the type of contiguous concatenation being requested in the RCC field. In particular, this field is irrelevant if no contiguous concatenation is requested (RCC =3D 0), in that case it must be set to zero when sent, and should be ignored when received. A RCC value different from 0 must imply a number of contiguous components greater than or equal to 1. ^^^^^^^^^^^^<- for = option 1.a FROM: 1. A VC-4 signal is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1 and T with value 0 to a VC-4 Elementary Signal. =20 8. An STS-3c SPE signal is formed by the application of RCC with value 1 (standard contiguous concatenation), NCC with value 1, NVC with value 0, MT with value 1 and T with value 0 to an STS- 3c SPE Elementary Signal. TO: 1. A VC-4 signal and an STS-3c SPE signal are formed by the application of RCC with value i, NCC with value i, NVC with value 0, MT with value 1 and T with value 0 to a VC-4 Elementary Signal and an STS-3c SPE Elementary Signal respectively. (RR: To replace i with 0 if we choose option 1a and 1 for option = 1b) =20 8. An STS-3c SPE signal is formed as shown in example 1. RFC 3946's example 8 is now deprecated. In order to support earlier versions of the standard, a node should accept RFC 3946-compliant values of NCC =3D RCC =3D !i = when receiving them until all known implementations have updated their code to the Errata.=20 (RR: make sure we accept the other value) Looking forward to your answer. Richard. =20 =20 =20 =20 =20 ------=_NextPart_000_0048_01C51E4A.83C36100 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Hi Dimitri,=20 Eric, Jonathan,
I have a=20 question about RFC 3946.
 
I'm trying to figure out = how to=20 understand text about setting NCC and RCC 
values for STS-3c and VC-4. Here's=20 the context:
 
Quoting from RFC = 3946:
 
   Note 1: when = requesting a=20 SONET STS-Nc SPE with N=3D3*X, the
      = Elementary=20 Signal to use must always be an STS-3c_SPE signal=20 type
      and the value of NCC must always = be equal=20 to X.  This allows also
      = facilitating the=20 interworking between SONET and SDH.  = In
     =20 particular, it means that the contiguous concatenation of=20 three
      STS-1 SPEs can not be requested = because=20 according to this
      specification, this = type of=20 signal must be coded using the STS-3c
      = SPE=20 signal type.
 
Note 1 implies that for SONET = STS-3c SPE,=20 NCC =3D1
 
   Note 2: when = requesting a=20 transparent STS-N/STM-N signal
      limited = to a=20 single contiguously concatenated=20 STS-Nc_SPE/VC-4-Nc,
      the signal type = must be=20 STS-N/STM-N, RCC with flag 1 and NCC = set
      to=20 1.
 
Note 2 seems to imply that for=20 STS-3c_SPE/VC-4-1c, RCC =3D NCC =3D 1
 
Then later on:
 
   The NCC value must = be=20 consistent with the type of contiguous
   concatenation = being=20 requested in the RCC field.  In particular, this
   = field is=20 irrelevant if no contiguous concatenation is requested = (RCC
   =3D=20 0), in that case it must be set to zero when sent, and should = be
  =20 ignored when received.  A RCC value different from 0 must imply=20 a
   number of contiguous components greater than = 1.
 
Given=20 that RCC must be different from 0,=20 the last sentence literally
says that an RCC value of 1 = (thus different=20 from 0) must imply that NCC > 1.
 
Going on to the examples of = Annex=20 1:
   1.   A VC-4 signal is formed by the = application of=20 RCC with value 0,
        NCC with = value=20 0, NVC with value 0, MT with value 1 and T=20 with
        value 0 to a VC-4 = Elementary=20 Signal.
...
   8.   An STS-3c SPE signal is = formed by=20 the application of RCC = with
        value=20 1 (standard contiguous concatenation), NCC with value=20 1,
        NVC with value 0, MT = with value=20 1 and T with value 0 to an = STS-
        3c=20 SPE Elementary Signal.
 
So, what values of NCC and RCC = should one=20 use for STS-3c/VC-4?
--
Option 1-a:
Set NCC =3D RCC =3D 1 for = STS-3c and VC-4.=20 Example 1 of the annex is not the
RFC=20 text and should not be followed.
 
Option 1-b:
Set NCC =3D RCC =3D 0 for STS-3c and VC-4. = Example 8 of the annex is not the
RFC text and should not be = followed.
 
Option 2:
Set NCC =3D RCC = =3D 0 for VC-4 and=20 NCC =3D RCC =3D 1 for STS-3c AND convert these
values when moving = between SDH and=20 SONET domains
 
Option 3:
Find some NCC-RCC = combination=20 that satisfies:
"  A RCC value different from 0 must imply=20 a
   number of contiguous components greater than = 1."
 
I sent email=20 to Greg Bernstein, and he is of the opinion that options 1-a or 1-b are=20 best.
If you also=20 agree, we may need an errata along the lines:
 
Those would=20 be the suggested changes.
 
FROM:
   The NCC value must be = consistent=20 with the type of contiguous
   concatenation being = requested in the=20 RCC field.  In particular, this
   field is irrelevant = if no=20 contiguous concatenation is requested (RCC
   =3D 0), in = that case it=20 must be set to zero when sent, and should be
   ignored = when=20 received.  A RCC value different from 0 must imply = a
   number=20 of contiguous components greater than 1.
TO:
   The NCC = value=20 must be consistent with the type of contiguous
   = concatenation=20 being requested in the RCC field.  In particular, = this
  =20 field is irrelevant if no contiguous concatenation is requested=20 (RCC
   =3D 0), in that case it must be set to zero when = sent, and=20 should be
   ignored when received.  A RCC value = different=20 from 0 must imply a
   number of contiguous components = greater than=20 or equal to=20 1.
           &= nbsp;           &n= bsp;           &nb= sp;           =20 ^^^^^^^^^^^^<- for option 1.a
FROM:
   1.   = A VC-4=20 signal is formed by the application of RCC with value=20 0,
        NCC with value 0, NVC = with=20 value 0, MT with value 1 and T=20 with
        value 0 to a VC-4 = Elementary=20 Signal.
 
  =20 8.   An STS-3c SPE signal is formed by the application of RCC=20 with
        value 1 (standard = contiguous=20 concatenation), NCC with value = 1,
       =20 NVC with value 0, MT with value 1 and T with value 0 to an=20 STS-
        3c SPE Elementary=20 Signal.
TO:
   1.   A VC-4 signal and an = STS-3c SPE=20 signal are formed by the
       =20 application of RCC with value i, NCC with value i, NVC=20 with
        value 0, MT with = value 1 and=20 T with value 0 to a VC-4=20 Elementary
        Signal and an = STS-3c=20 SPE Elementary Signal respectively.
       &nbs= p;(RR: To=20 replace i with 0 if we choose option 1a and 1 for option=20 1b)
 
  =20 8.   An STS-3c SPE signal is formed as shown in example 1. RFC = 3946's
        example 8 is now=20 deprecated.
        In order to = support=20 earlier versions of the standard, a=20 node
        should accept RFC=20 3946-compliant values of NCC =3D RCC =3D !i=20 when
        receiving them until = all=20 known implementations have = updated
       =20 their code to the Errata.
        = (RR: make=20 sure we accept the other value)
Looking=20 forward to your answer.
Richard.
 
 
 
 
 
------=_NextPart_000_0048_01C51E4A.83C36100--