From blmorganjjjgs@resalehost.networksolutions.com Thu Dec 01 09:20:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhpIU-0000hA-3b for ccamp-archive@megatron.ietf.org; Thu, 01 Dec 2005 09:20:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25777 for ; Thu, 1 Dec 2005 09:19:42 -0500 (EST) Received: from [200.165.234.90] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ehpce-0007Ea-Sd for ccamp-archive@ietf.org; Thu, 01 Dec 2005 09:41:40 -0500 Message-ID: <000001c5f681$00872c80$0100007f@localhost> From: "Corbin Alexander" To: Subject: Corel Draw Date: Thu, 01 Dec 2005 12:19:51 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F681.00872C80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F681.00872C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 42 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F681.00872C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 42 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 43 reviews! )


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 32 reviews)


------=_NextPart_000_0001_01C5F681.00872C80-- From 364b5e33.af641f9c@automobiledumont.com Fri Dec 02 02:27:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei5KD-0005EO-RK for ccamp-archive@megatron.ietf.org; Fri, 02 Dec 2005 02:27:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17947 for ; Fri, 2 Dec 2005 02:26:34 -0500 (EST) Received: from [62.5.198.67] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ei5eq-0003Ld-5s for ccamp-archive@ietf.org; Fri, 02 Dec 2005 02:48:41 -0500 Message-ID: <000001c5f710$522ac800$0100007f@localhost> From: "Brody Edwards" <364b5e33.af641f9c@automobiledumont.com> To: Subject: cheap oem soft shipping //orldwide Date: Fri, 02 Dec 2005 10:26:51 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F710.522AC800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.4 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F710.522AC800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F710.522AC800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!
!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 32 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 32 reviews)!


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 31 reviews)


------=_NextPart_000_0001_01C5F710.522AC800-- From blitzkriegii@babylonandon-qaf.com Sat Dec 03 15:56:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EieQk-0002Wz-HH for ccamp-archive@megatron.ietf.org; Sat, 03 Dec 2005 15:56:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02806 for ; Sat, 3 Dec 2005 15:55:37 -0500 (EST) Received: from 12-207-199-58.client.mchsi.com ([12.207.199.58] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eield-0002zI-6F for ccamp-archive@ietf.org; Sat, 03 Dec 2005 16:18:06 -0500 Message-ID: <000001c5f84a$8e624380$0100007f@localhost> From: "Jorge Scott" To: Subject: Need S0ftware? Date: Sat, 03 Dec 2005 14:56:09 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F84A.8E624380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F84A.8E624380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F84A.8E624380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 47 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 34 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 46 reviews)


------=_NextPart_000_0001_01C5F84A.8E624380-- From rubenm2020@asaingenieria.com Sun Dec 04 00:54:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EimpE-0000cc-Ds for ccamp-archive@megatron.ietf.org; Sun, 04 Dec 2005 00:54:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07596 for ; Sun, 4 Dec 2005 00:53:26 -0500 (EST) Received: from [211.207.229.53] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EinAE-00080y-7f for ccamp-archive@ietf.org; Sun, 04 Dec 2005 01:16:00 -0500 Message-ID: <000001c5f895$867bc100$0100007f@localhost> From: "Seth Diaz" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Sun, 04 Dec 2005 14:53:47 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F895.867BC100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F895.867BC100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 44 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F895.867BC100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 40 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 48 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 34 reviews)


------=_NextPart_000_0001_01C5F895.867BC100-- From webbs@arvinsofmacon.com Mon Dec 05 01:37:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej9yP-0003w6-LD for ccamp-archive@megatron.ietf.org; Mon, 05 Dec 2005 01:37:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06092 for ; Mon, 5 Dec 2005 01:36:27 -0500 (EST) Received: from c-66-30-217-207.hsd1.ma.comcast.net ([66.30.217.207] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EjAJc-000401-Ks for ccamp-archive@ietf.org; Mon, 05 Dec 2005 01:59:15 -0500 Message-ID: <000001c5f964$cd84b780$0100007f@localhost> From: "Zander Long" To: Subject: Need S0ftware? Date: Mon, 05 Dec 2005 01:37:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F964.CD84B780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F964.CD84B780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 31 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F964.CD84B780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!

!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 38 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 35 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 31 reviews)


------=_NextPart_000_0001_01C5F964.CD84B780-- From enyajb123@877drbrain.com Tue Dec 06 01:40:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjWV6-0006mh-LF for ccamp-archive@megatron.ietf.org; Tue, 06 Dec 2005 01:40:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13151 for ; Tue, 6 Dec 2005 01:39:41 -0500 (EST) Received: from vengard.utnet.ru ([195.12.67.42] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EjWqW-0004Z4-8b for ccamp-archive@ietf.org; Tue, 06 Dec 2005 02:02:42 -0500 Message-ID: <000001c5fa2e$7b0fcd80$0100007f@localhost> From: "Asher Torres" To: Subject: cheap oem soft shipping //orldwide Date: Tue, 06 Dec 2005 11:40:17 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FA2E.7B0FCD80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FA2E.7B0FCD80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5FA2E.7B0FCD80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 36 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 44 reviews! )


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 37 reviews)


------=_NextPart_000_0001_01C5FA2E.7B0FCD80-- From bren@amazingmangosteen.com Tue Dec 06 06:36:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejb7o-0005Q3-U1 for ccamp-archive@megatron.ietf.org; Tue, 06 Dec 2005 06:36:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14542 for ; Tue, 6 Dec 2005 06:35:57 -0500 (EST) Received: from adsl-69-212-8-6.dsl.akrnoh.ameritech.net ([69.212.8.6] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EjbT2-00063e-8a for ccamp-archive@ietf.org; Tue, 06 Dec 2005 06:59:01 -0500 Message-ID: <000001c5fa57$cdb1af80$0100007f@localhost> From: "Keith Green" To: Subject: Need S0ftware? Date: Tue, 06 Dec 2005 06:36:16 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FA57.CDB1AF80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.5 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FA57.CDB1AF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5FA57.CDB1AF80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
  &! nbsp; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 38 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 31 rev! iews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 47 reviews)


------=_NextPart_000_0001_01C5FA57.CDB1AF80-- From owner-ccamp@ops.ietf.org Tue Dec 06 06:48:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjbIw-0008Q5-6B for ccamp-archive@megatron.ietf.org; Tue, 06 Dec 2005 06:48:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15846 for ; Tue, 6 Dec 2005 06:47:27 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjbeP-0006V6-My for ccamp-archive@ietf.org; Tue, 06 Dec 2005 07:10:31 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ejb5w-000E10-7n for ccamp-data@psg.com; Tue, 06 Dec 2005 11:34:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ejb5u-000E0i-4D for ccamp@ops.ietf.org; Tue, 06 Dec 2005 11:34:50 +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 jB6BYNQc021122 for ; Tue, 6 Dec 2005 11:34:43 GMT (envelope-from Diego.Caviglia@marconi.com) Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus To: "ccamp" X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Tue, 6 Dec 2005 12:34:47 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 06/12/2005 11:34:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Folks, a week has passed from the below e-mail, there has been only one replay from a carrier the answers were for yes for both question 2 and 3. Now I'll try to put the question in a different way. Do anyone think that the ID should not be moved to WG status? Regards Diego "Diego Caviglia" @ops.ietf.org on 29/11/2005 08.08.59 Sent by: owner-ccamp@ops.ietf.org To: ccamp@ops.ietf.org cc: "Dino Bramanti" , "Dan Li ; Tue, 6 Dec 2005 07:48:09 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjcbB-0000Ha-CE for ccamp-archive@ietf.org; Tue, 06 Dec 2005 08:11:13 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ejc5j-000K9z-Tg for ccamp-data@psg.com; Tue, 06 Dec 2005 12:38:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ejc5i-000K9k-G0 for ccamp@ops.ietf.org; Tue, 06 Dec 2005 12:38:42 +0000 Received: from du-069-0004.access.clara.net ([217.158.132.4] helo=Puppy) by relay2.mail.uk.clara.net with esmtp (Exim 4.50) id 1Ejc5f-000PzY-7B; Tue, 06 Dec 2005 12:38:41 +0000 Message-ID: <09e201c5fa62$7d025110$d9849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "ccamp" , "Diego Caviglia" References: Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus Date: Tue, 6 Dec 2005 12:40:34 -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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Hi Diego, Thanks for taking some of the burden of WG chair from my shoulders. Before pushing this any further, I would be interested in your response to the recent liaison from ITU-T SG15 (text below). I would also like to understand whether this type of function is really likely to be used repeatedly or whether we are describing a "one shot" solution to an in-service upgrade. Cheers, Adrian === Text of liaison from SG15 At the recent Q12/15 and Q14/15 Rapporteur meeting, it was reported that CCAMP is discussing the issue of migration of connections under the management plane to the control plane. This topic has been discussed in previous SG15 meetings and some of the conclusions are offered that may be helpful to CCAMP. The motivation for migrating calls and connections includes applying a control plane to an existing transport network, and/or combining a transport network whose connections are managed by an OSS and one whose connections are established by a control plane. Two broad issues with connection migration are dual views of a resource, and the preconditions before protocol state is created for a connection. Dual views of a resource concerns the need for a resource to be in both management and control plane view the same time. This is because although the control plane may have responsibility of allocating/releasing connections in subnetworks (a node is a smallest subnetwork), the management plane still has responsibility for other functions on the resource. Changing the responsibility of allocating/releasing connections requires more state for actions like rolling back a migration action due to failures. Preconditions for migrating from the management plane to control plane are extensive and may involve much planning because the context for the control plane has to be in place. This includes: - Naming of resources. Both node and link naming are required before signalling protocols can run. Without this, no explicit route can be formed to match the resources of the connection. Naming of multiple nodes and links has to be planned ahead of time. - Control plane component adjacencies must be established. In GMPLS the control adjacencies are separate from bearer adjacencies and do not have to coincide. Planning and establishing those adjacencies is needed before migration can be initiated. - Links must be pre-configured and made visible to control plane routing. - For each service and the associated connections to be migrated, the service name, connection names, and explicit resource lists (in the control plane name space) need to be passed from the management plane to the control plane. Once this is done, connection state in the control plane can be created for an existing connection and the resources placed under the view of the control plane. Taken together, the preparation for migrating even one connection suggests that a whole set of the transport resources be prepared at the same time. Finally, when connection state is being created to match an existing connection, the connection controllers (signalling entities) should not require awareness of why this is happening as the context could be migration or other operation. A mechanism to create control state without affecting transport plane state is needed in the connection controllers. It is important to ensure that the connections are not deleted when the management plane relinquishes control of the resources. Entities that initiate the connection (Call controllers) do need migration awareness as they need to obtain/derive service (call) identification from the management plane. This is because the identity of connections created by management planes are typically stored in OSS inventory systems, as well as the identity of the service to which the connection is associated with. The general conclusion is that the preparation for, and operational impacts of, connection migration are much larger and more complex than the actual control plane procedures to create signalling state for an existing connection. These procedures will only be invoked once in the life time of the network. For these reasons, Q12/15 and Q14/15 have decided not to pursue a solution to this problem. ----- Original Message ----- From: "Diego Caviglia" To: "ccamp" Sent: Tuesday, December 06, 2005 11:34 AM Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > Folks, > a week has passed from the below e-mail, there has been only one > replay from a carrier the answers were for yes for both question 2 and 3. > > Now I'll try to put the question in a different way. > > Do anyone think that the ID should not be moved to WG status? > > Regards > > Diego > > > > > > "Diego Caviglia" @ops.ietf.org on 29/11/2005 > 08.08.59 > > Sent by: owner-ccamp@ops.ietf.org > > > To: ccamp@ops.ietf.org > cc: "Dino Bramanti" , "Dan Li > Subject: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > > Hi all, > during the last IETF meeting unfortunaltely there was not enough > thime to present and discuss the ID in the subject, nevertheless I think > (but I'm an authour) the ID satisfy a real request from the Carries > community. > > I'd like to ask you some questions > > 1. Are there any comments on the ID? > > 2. Mainly for the carriers. Do you think the ID describes an useful > tool? > > 3. Should the ID moved to the WG status? > > Of course my answer for 2 and 3 are Yes and Yes ;-) > > Regards > > Diego > > > > > > > From owner-ccamp@ops.ietf.org Tue Dec 06 08:27:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejcr1-0006Eo-JA for ccamp-archive@megatron.ietf.org; Tue, 06 Dec 2005 08:27:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28705 for ; Tue, 6 Dec 2005 08:26:44 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjdCV-0001p9-HE for ccamp-archive@ietf.org; Tue, 06 Dec 2005 08:49:49 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ejcjr-000OKb-Us for ccamp-data@psg.com; Tue, 06 Dec 2005 13:20:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.10.152.20] (helo=oberon.imc.kth.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ejcjq-000OKC-5l for ccamp@ops.ietf.org; Tue, 06 Dec 2005 13:20:10 +0000 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id jB6DG2UF001622 for ; Tue, 6 Dec 2005 14:16:02 +0100 Received: from [127.0.0.1] ([172.16.2.233]) by mail1.imc.kth.se; Tue, 06 Dec 2005 14:19:23 +0100 Message-ID: <43958FD5.7040601@pi.se> Date: Tue, 06 Dec 2005 14:19:17 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Diego Caviglia CC: ccamp Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Diego, why did this consensus call not come from the wg chairs. I'm afraid that under the current circumstances you need to interpret non-responsiveness as non-interest. /Loa Diego Caviglia wrote: > Folks, > a week has passed from the below e-mail, there has been only one > replay from a carrier the answers were for yes for both question 2 and 3. > > Now I'll try to put the question in a different way. > > Do anyone think that the ID should not be moved to WG status? > > Regards > > Diego > > > > > > "Diego Caviglia" @ops.ietf.org on 29/11/2005 > 08.08.59 > > Sent by: owner-ccamp@ops.ietf.org > > > To: ccamp@ops.ietf.org > cc: "Dino Bramanti" , "Dan Li > Subject: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > > Hi all, > during the last IETF meeting unfortunaltely there was not enough > thime to present and discuss the ID in the subject, nevertheless I think > (but I'm an authour) the ID satisfy a real request from the Carries > community. > > I'd like to ask you some questions > > 1. Are there any comments on the ID? > > 2. Mainly for the carriers. Do you think the ID describes an useful > tool? > > 3. Should the ID moved to the WG status? > > Of course my answer for 2 and 3 are Yes and Yes ;-) > > Regards > > Diego > > > > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From owner-ccamp@ops.ietf.org Tue Dec 06 08:37:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejd0k-0000Zv-Po for ccamp-archive@megatron.ietf.org; Tue, 06 Dec 2005 08:37:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29720 for ; Tue, 6 Dec 2005 08:36:47 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjdME-000273-O6 for ccamp-archive@ietf.org; Tue, 06 Dec 2005 08:59:52 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjcvS-000Pai-N3 for ccamp-data@psg.com; Tue, 06 Dec 2005 13:32:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EjcvR-000PaL-9s for ccamp@ops.ietf.org; Tue, 06 Dec 2005 13:32:09 +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 jB6DW0CL003982; Tue, 6 Dec 2005 13:32:00 GMT (envelope-from Diego.Caviglia@marconi.com) Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus To: "Adrian Farrel" Cc: ccamp@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Tue, 6 Dec 2005 14:32:30 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 06/12/2005 13:32:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Hi Adrian, please find response/comments in line. Regards Diego "Adrian Farrel" @ops.ietf.org on 06/12/2005 13.40.34 Please respond to "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org To: "ccamp" , "Diego Caviglia" cc: Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus Hi Diego, Thanks for taking some of the burden of WG chair from my shoulders. [dc] Ouch touched ;-) I apologize if I gave the impression of playing your role, I was just trying to understand if there is interest in this ID or not. Before pushing this any further, I would be interested in your response to the recent liaison from ITU-T SG15 (text below). [dc] Ok I'll give an answer. I would also like to understand whether this type of function is really likely to be used repeatedly or whether we are describing a "one shot" solution to an in-service upgrade. [dc] This is a question that can be answered by Telco. My feeling is that it will be for sure used during the upgrade. Cheers, Adrian === Text of liaison from SG15 At the recent Q12/15 and Q14/15 Rapporteur meeting, it was reported that CCAMP is discussing the issue of migration of connections under the management plane to the control plane. This topic has been discussed in previous SG15 meetings and some of the conclusions are offered that may be helpful to CCAMP. The motivation for migrating calls and connections includes applying a control plane to an existing transport network, and/or combining a transport network whose connections are managed by an OSS and one whose connections are established by a control plane. [dc] Agreed. Two broad issues with connection migration are dual views of a resource, and the preconditions before protocol state is created for a connection. Dual views of a resource concerns the need for a resource to be in both management and control plane view the same time. This is because although the control plane may have responsibility of allocating/releasing connections in subnetworks (a node is a smallest subnetwork), the management plane still has responsibility for other functions on the resource. Changing the responsibility of allocating/releasing connections requires more state for actions like rolling back a migration action due to failures. Preconditions for migrating from the management plane to control plane are extensive and may involve much planning because the context for the control plane has to be in place. This includes: - Naming of resources. Both node and link naming are required before signalling protocols can run. Without this, no explicit route can be formed to match the resources of the connection. Naming of multiple nodes and links has to be planned ahead of time. [dc] Agreed. - Control plane component adjacencies must be established. In GMPLS the control adjacencies are separate from bearer adjacencies and do not have to coincide. Planning and establishing those adjacencies is needed before migration can be initiated. [dc] Agreed. - Links must be pre-configured and made visible to control plane routing. [dc] Agreed. - For each service and the associated connections to be migrated, the service name, connection names, and explicit resource lists (in the control plane name space) need to be passed from the management plane to the control plane. [dc] Agreed. Once this is done, connection state in the control plane can be created for an existing connection and the resources placed under the view of the control plane. Taken together, the preparation for migrating even one connection suggests that a whole set of the transport resources be prepared at the same time. [dc] Of course before migrate an LSP the control plane on the involved resourse needs to be up and running. Finally, when connection state is being created to match an existing connection, the connection controllers (signalling entities) should not require awareness of why this is happening as the context could be migration or other operation. [dc] The only thing that the SC needs to know is that the data plane is alredy configured, of course in case of failure of the signalling date plane resources are not deleted. A mechanism to create control state without affecting transport plane state is needed in the connection controllers. [dc] This is exatly, at least in our intention, what the ID proposes. It is important to ensure that the connections are not deleted when the management plane relinquishes control of the resources. [dc] Agreed Entities that initiate the connection (Call controllers) do need migration awareness as they need to obtain/derive service (call) identification from the management plane. [dc] Agreed, moreover also the intermediate TNEs do need migration awarness, in the ID this is done using an Admin Status flag. This is because the identity of connections created by management planes are typically stored in OSS inventory systems, as well as the identity of the service to which the connection is associated with. [dc] Yes usually it is like this. The general conclusion is that the preparation for, and operational impacts of, connection migration are much larger and more complex than the actual control plane procedures to create signalling state for an existing connection. [dc] Is that meaning that the CP impact is very low? If yes I agree on this and I'm also happy on this. Actually I don't see any significative difference between the impact of adding a control plane to an existing network and migrate the already created circuit under the CP domain. These procedures will only be invoked once in the life time of the network. For these reasons, Q12/15 and Q14/15 have decided not to pursue a solution to this problem. [dc] This may be is correct but that once in the life is when the CP is added to an alredy existing network. So may be is only once in the life but is during a very important and critic moment. ----- Original Message ----- From: "Diego Caviglia" To: "ccamp" Sent: Tuesday, December 06, 2005 11:34 AM Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > Folks, > a week has passed from the below e-mail, there has been only one > replay from a carrier the answers were for yes for both question 2 and 3. > > Now I'll try to put the question in a different way. > > Do anyone think that the ID should not be moved to WG status? > > Regards > > Diego > > > > > > "Diego Caviglia" @ops.ietf.org on 29/11/2005 > 08.08.59 > > Sent by: owner-ccamp@ops.ietf.org > > > To: ccamp@ops.ietf.org > cc: "Dino Bramanti" , "Dan Li > Subject: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > > Hi all, > during the last IETF meeting unfortunaltely there was not enough > thime to present and discuss the ID in the subject, nevertheless I think > (but I'm an authour) the ID satisfy a real request from the Carries > community. > > I'd like to ask you some questions > > 1. Are there any comments on the ID? > > 2. Mainly for the carriers. Do you think the ID describes an useful > tool? > > 3. Should the ID moved to the WG status? > > Of course my answer for 2 and 3 are Yes and Yes ;-) > > Regards > > Diego > > > > > > > From 141lorie@accel.net Tue Dec 06 11:51:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejg2j-0001IR-DP for ccamp-archive@megatron.ietf.org; Tue, 06 Dec 2005 11:51:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22846 for ; Tue, 6 Dec 2005 11:51:02 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjgOE-0000cp-24 for ccamp-archive@ietf.org; Tue, 06 Dec 2005 12:14:08 -0500 Received: from dynamic-ip-cr20011814110.cable.net.co ([200.118.14.110] helo=200.118.14.110) by mx2.foretec.com with smtp (Exim 4.24) id 1Ejg2W-0005HR-4k for ccamp-archive@ietf.org; Tue, 06 Dec 2005 11:51:46 -0500 Message-ID: From: "Steven A. Norman" <141lorie@accel.net> To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?U3dpc3Mgd2F0Y2hlcyAtIGNvcGllcw==?= Date: Tue, 06 Dec 2005 16:33:34 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_8997CF1C.5B30AA16" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0000_8997CF1C.5B30AA16 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_C59F7AB0.DEC4FC6F" ------=_NextPart_001_0001_C59F7AB0.DEC4FC6F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit TRUE COPIES OF SWISS WATCHES - exact copies of the original watches - perfect as a gift for your colleagues and friends - free gift box Rolex, Patek Philippe, Omega Cartier, Bvlgari, Franck Muller .. and 15 other most famous manufacturers. http://www.vipwatchesnow.com All copies are for only $239.95 - $279.95! ________________________________ To change your mail preferences, go here ________________________________ ------=_NextPart_001_0001_C59F7AB0.DEC4FC6F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
TRUE COPIES OF SWISS WATCHES

- exact copies of the original watches
- perfect as a gift for your colleagues and friends
- free gift box

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

.. and 15 other most famous manufacturers.

http://www.vipwatchesnow.com

All copies are for only $239.95 - $279.95!


________________________________
To change your mail preferences, go here
________________________________

------=_NextPart_001_0001_C59F7AB0.DEC4FC6F-- ------=_NextPart_000_0000_8997CF1C.5B30AA16-- From owner-ccamp@ops.ietf.org Wed Dec 07 09:24:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek0DZ-0000dD-Nt for ccamp-archive@megatron.ietf.org; Wed, 07 Dec 2005 09:24:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12107 for ; Wed, 7 Dec 2005 09:23:33 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek0ZF-0001r5-TP for ccamp-archive@ietf.org; Wed, 07 Dec 2005 09:46:52 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ek01p-000FfJ-T1 for ccamp-data@psg.com; Wed, 07 Dec 2005 14:12:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [12.129.211.51] (helo=huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ek01o-000Feu-CU for ccamp@ops.ietf.org; Wed, 07 Dec 2005 14:12:16 +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 <0IR400HM1SCHNX@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 07 Dec 2005 06:02:41 -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 <0IR4003U5SCF3R@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 07 Dec 2005 06:02:41 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [59.40.41.159]) by szxmc02-in.huawei.com (mshttpd); Wed, 07 Dec 2005 22:05:56 +0800 Date: Wed, 07 Dec 2005 22:05:56 +0800 From: lidan 37133 Subject: =?gb2312?B?u9i4tA==?=:Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus To: Adrian Farrel Cc: ccamp , Diego Caviglia Message-id: <168507e1688215.1688215168507e@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=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Content-Transfer-Encoding: quoted-printable Hi Adrian=2C Please see my comments below=2E Regards=2C Dan Li ----- =D4=AD=D3=CA=BC=FE ----- =B4=D3=3A Adrian Farrel =3Cadrian=40olddog=2Eco=2Euk=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =CA=AE=B6=FE=D4=C2 6=C8=D5=2C 2005 = =CF=C2=CE=E78=3A40 =D6=F7=CC=E2=3A Re=3A Consensus to move draft-caviglia-mp2cpcp2mp-03 to W= G satus =3E Hi Diego=2C =3E = =3E Thanks for taking some of the burden of WG chair from my shoulders=2E= =3E = =3E Before pushing this any further=2C I would be interested in your = =3E response to =3E the recent liaison from ITU-T SG15 (text below)=2E =3E = =3E I would also like to understand whether this type of function is = =3E reallylikely to be used repeatedly or whether we are describing a = =3E =22one shot=22 =3E solution to an in-service upgrade=2E MP2CP and CP2MP migration can be used for many scenarios=2C some cases ar= e given = here=3A 1) For control plane upgrade=2C after introduced the control plane=2C the= services = can be migrated from MP to CP=2E 2) For some reason=2C only partial functions of CP are used by the operat= ors=2C = like resource discovery=2C but services still provided by MP=2E Later the= y want = such services be migrated from MP to CP=2C and MP to CP is also needed ju= st in = case they want to roll back=2E 3) This feature also can be used for CP graceful shutdown=2E 4) For some serious CP failure cases=2C when CP session can not be recove= red in time=2C the connections under control of CP can be migrated to MP=2C s= o the service will not be interrupted=2E 5) More cases are welcome=2E=2E=2E So this is not one time use feature for the carriers=2E =3E = =3E Cheers=2C =3E Adrian =3E =3D=3D=3D =3E Text of liaison from SG15 =3E = =3E At the recent Q12/15 and Q14/15 Rapporteur meeting=2C it was = =3E reported that =3E CCAMP is discussing the issue of migration of connections under the =3E management plane to the control plane=2E This topic has been = =3E discussed in =3E previous SG15 meetings and some of the conclusions are offered = =3E that may be =3E helpful to CCAMP=2E =3E The motivation for migrating calls and connections includes = =3E applying a =3E control plane to an existing transport network=2C and/or combining a =3E transport network whose connections are managed by an OSS and one = =3E whoseconnections are established by a control plane=2E =3E Two broad issues with connection migration are dual views of a = =3E resource=2Cand the preconditions before protocol state is created = =3E for a connection=2E =3E Dual views of a resource concerns the need for a resource to be in = =3E bothmanagement and control plane view the same time=2E This is = =3E because although =3E the control plane may have responsibility of allocating/releasing =3E connections in subnetworks (a node is a smallest subnetwork)=2C the =3E management plane still has responsibility for other functions on the Dual views of resources is not the problem at all=2E When a resource is under the control of CP=2C the MP should still have the visibility of the= = resource=2C because CP is connection focused and *NOT* for all the functi= ons=2C = so MP should response for =22other functions=22 on the resource=2E If the= = resources under control of CP have dual visibility under both CP and MP=2C= = the resources under control of MP should also have dual visibility=2E =3E resource=2E Changing the responsibility of allocating/releasing = =3E connectionsrequires more state for actions like rolling back a = =3E migration action due to failures=2E This is the issue of concurrent access to resources under the control of both CP and MP=2C and it can be deal with some resource access locking scheme=2E But it is a implementation-related issue=2C so it=27s out of sc= ope of this I-D=2E =3E Preconditions for migrating from the management plane to control = =3E plane are =3E extensive and may involve much planning because the context for the =3E control plane has to be in place=2E This includes=3A =3E - Naming of resources=2E Both node and link naming are required befo= re =3E signalling protocols can run=2E Without this=2C no explicit route ca= n be =3E formed to match the resources of the connection=2E Naming of = =3E multiple nodes =3E and links has to be planned ahead of time=2E =3E - Control plane component adjacencies must be established=2E In = =3E GMPLS the =3E control adjacencies are separate from bearer adjacencies and do = =3E not have =3E to coincide=2E Planning and establishing those adjacencies is = =3E needed before =3E migration can be initiated=2E =3E - Links must be pre-configured and made visible to control plane = =3E routing=2E These preconditions assume the resource is either controlled by control plane or by management plane=2E But this is not true=2C as we mentioned b= efore=2C even the resource is under the control of control plane=2C the management= plane still has responsibility for many functions on the resource=2E So t= hese preconditions also can be applied to the resource which under the control= of management plane=2E The current GMPLS can support the resource discovery (naming of resource)= =2C the discovered resource also includes which under the control of MP=2E It=27s doesn=27t matter which plane use it=2EPlanning and establishing th= ose adjacencies are control plane bootstrap problem=2C so it=27s out of scope= of this I-D=2E =3E - For each service and the associated connections to be = =3E migrated=2C the =3E service name=2C connection names=2C and explicit resource lists (in t= he =3E control plane name space) need to be passed from the management = =3E plane to =3E the control plane=2E This already addressed in this I-D=2E =3E Once this is done=2C connection state in the control plane can be = =3E createdfor an existing connection and the resources placed under = =3E the view of the =3E control plane=2E Taken together=2C the preparation for migrating eve= n one =3E connection suggests that a whole set of the transport resources be =3E prepared at the same time=2E This already addressed in this I-D=2E =3E Finally=2C when connection state is being created to match an existin= g =3E connection=2C the connection controllers (signalling entities) = =3E should not =3E require awareness of why this is happening as the context could be =3E migration or other operation=2E A mechanism to create control state = No=2E The connection controllers should aware of this=2C because this action is directed by the management plane=2C it=27s different with other= operations like connection creation=2E =3E without affecting transport plane state is needed in the connection = =3E controllers=2EIt is important to ensure that the connections are not = =3E deleted when the =3E management plane relinquishes control of the resources=2E Entities th= at The transport plane should not be touched=2E Please see I-D for details=2E= =3E initiate the connection (Call controllers) do need migration = =3E awareness as =3E they need to obtain/derive service (call) identification from the =3E management plane=2E This is because the identity of connections = =3E created by =3E management planes are typically stored in OSS inventory systems=2C = =3E as well =3E as the identity of the service to which the connection is = =3E associated with=2E This should be done within the management plane before the migration action be taken=2E So it=27s also out of scope of this I-D=2E =3E The general conclusion is that the preparation for=2C and operational= =3E impacts of=2C connection migration are much larger and more complex = =3E than the =3E actual control plane procedures to create signalling state for an = =3E existingconnection=2E These procedures will only be invoked once in = =3E the life time of These problems actually are the issues of ASON architecture=2C not for GM= PLS=2E It is the time for these issues to be fixed in the ASON architecture=2E =3E the network=2E For these reasons=2C Q12/15 and Q14/15 have decided no= t to =3E pursue a solution to this problem=2E =3E = =3E = =3E ----- Original Message ----- = =3E From=3A =22Diego Caviglia=22 =3CDiego=2ECaviglia=40marconi=2Ecom=3E =3E To=3A =22ccamp=22 =3Cccamp=40ops=2Eietf=2Eorg=3E =3E Sent=3A Tuesday=2C December 06=2C 2005 11=3A34 AM =3E Subject=3A Re=3A Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG= = =3E satus =3E = =3E =3E =3E =3E Folks=2C =3E =3E a week has passed from the below e-mail=2C there has been = =3E only one =3E =3E replay from a carrier the answers were for yes for both question = =3E 2 and =3E 3=2E =3E =3E =3E =3E Now I=27ll try to put the question in a different way=2E =3E =3E =3E =3E Do anyone think that the ID should not be moved to WG status=3F =3E =3E =3E =3E Regards =3E =3E =3E =3E Diego =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =22Diego Caviglia=22 =3CDiego=2ECaviglia=40marconi=2Ecom=3E=40ops= =2Eietf=2Eorg on = =3E 29/11/2005=3E 08=2E08=2E59 =3E =3E =3E =3E Sent by=3A owner-ccamp=40ops=2Eietf=2Eorg =3E =3E =3E =3E =3E =3E To=3A ccamp=40ops=2Eietf=2Eorg =3E =3E cc=3A =22Dino Bramanti=22 =3CDino=2EBramanti=40marconi=2Ecom=3E= =2C =22Dan Li =3Cdanli=22 =3E =3E =3E =3E Subject=3A Consensus to move draft-caviglia-mp2cpcp2mp-03 to W= G = =3E satus=3E =3E =3E =3E =3E Hi all=2C =3E =3E during the last IETF meeting unfortunaltely there was = not =3E enough =3E =3E thime to present and discuss the ID in the subject=2C nevertheles= s = =3E I think =3E =3E (but I=27m an authour) the ID satisfy a real request from the Car= ries =3E =3E community=2E =3E =3E =3E =3E I=27d like to ask you some questions =3E =3E =3E =3E 1=2E Are there any comments on the ID=3F =3E =3E =3E =3E 2=2E Mainly for the carriers=2E Do you think the ID descri= bes an =3E useful =3E =3E tool=3F =3E =3E =3E =3E 3=2E Should the ID moved to the WG status=3F =3E =3E =3E =3E Of course my answer for 2 and 3 are Yes and Yes =3B-) =3E =3E =3E =3E Regards =3E =3E =3E =3E Diego =3E =3E From owner-ccamp@ops.ietf.org Wed Dec 07 16:03:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek6RW-000066-LA for ccamp-archive@megatron.ietf.org; Wed, 07 Dec 2005 16:03:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26563 for ; Wed, 7 Dec 2005 16:02:22 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek6nA-0007U4-7r for ccamp-archive@ietf.org; Wed, 07 Dec 2005 16:25:44 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ek6Hz-00080T-W1 for ccamp-data@psg.com; Wed, 07 Dec 2005 20:53:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ek6Hy-000806-O6 for ccamp@ops.ietf.org; Wed, 07 Dec 2005 20:53:22 +0000 Received: from du-069-0165.access.clara.net ([217.158.132.165] helo=Puppy) by relay3.mail.uk.clara.net with esmtp (Exim 4.46) id 1Ek6Hx-0004Qv-Dk; Wed, 07 Dec 2005 20:53:21 +0000 Message-ID: <016001c5fb70$bcd48380$9d849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Dimitri Papadimitriou" Cc: Subject: RFC 3946 bis Date: Wed, 7 Dec 2005 20:46:52 -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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Hi Dimitri, Since there has been no further comment on the list about this work, could you: - tidy up the draft (i.e. remove the editorial notes) - update the "Note 3." text as we discussed - re-submit Once that is done, we will last call and move on. Thanks, Adrian From owner-ccamp@ops.ietf.org Wed Dec 07 17:44:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek81Y-0007ty-63 for ccamp-archive@megatron.ietf.org; Wed, 07 Dec 2005 17:44:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12268 for ; Wed, 7 Dec 2005 17:43:39 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek8NJ-0004AH-2d for ccamp-archive@ietf.org; Wed, 07 Dec 2005 18:07:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ek7uC-000IBb-EG for ccamp-data@psg.com; Wed, 07 Dec 2005 22:36:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ek7uA-000IBN-Qj for ccamp@ops.ietf.org; Wed, 07 Dec 2005 22:36:55 +0000 Received: from du-069-0207.access.clara.net ([217.158.132.207] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1Ek7u8-000JaK-Ia for ccamp@ops.ietf.org; Wed, 07 Dec 2005 22:36:53 +0000 Message-ID: <01c401c5fb7f$3344ea60$9d849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Incoming liaisons from the ITU-T Date: Wed, 7 Dec 2005 22:37: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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Hi, There were four liaison statements sent to CCAMP by the recent meeting of Questions 12 and 14 of Study Group 15 of the ITU-T. These can be seen at http://www.olddog.co.uk/incoming.htm or through the IETF's liaison tracker pages. The subjects were: - Control plane resilience - Connection migration - ASON-related work - ASON lexicography The last two require a response from us by 27th January. Thanks, Adrian From webmaster@angelkingdom.com Thu Dec 08 00:13:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkE64-0008Dl-6B for ccamp-archive@megatron.ietf.org; Thu, 08 Dec 2005 00:13:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25373 for ; Thu, 8 Dec 2005 00:12:42 -0500 (EST) Received: from c-71-56-83-132.hsd1.ga.comcast.net ([71.56.83.132] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EkERs-0001U2-1E for ccamp-archive@ietf.org; Thu, 08 Dec 2005 00:36:10 -0500 Message-ID: <000001c5fbe0$3330a800$0100007f@localhost> From: "Alexander Price" To: Subject: What IS 0EM Software And Why D0 You Care? Date: Thu, 29 Dec 2005 00:15:03 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FBE0.3330A800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.5 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FBE0.3330A800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5FBE0.3330A800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   ! ; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 32 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 42 revi! ews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 47 reviews)


------=_NextPart_000_0001_01C5FBE0.3330A800-- From owner-ccamp@ops.ietf.org Thu Dec 08 05:44:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkJGN-0000ut-UU for ccamp-archive@megatron.ietf.org; Thu, 08 Dec 2005 05:44:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27263 for ; Thu, 8 Dec 2005 05:43:42 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkJcE-0002rg-2y for ccamp-archive@ietf.org; Thu, 08 Dec 2005 06:07:13 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkJ21-0003ED-IL for ccamp-data@psg.com; Thu, 08 Dec 2005 10:29:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkJ20-0003Dp-6S for ccamp@ops.ietf.org; Thu, 08 Dec 2005 10:29:44 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id jB8ATV8G018531; Thu, 8 Dec 2005 11:29:31 +0100 To: "Adrian Farrel" Cc: "ccamp" , "Diego Caviglia" From: Dimitri.Papadimitriou@alcatel.be Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus MIME-Version: 1.0 Date: Thu, 8 Dec 2005 11:29:30 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 12/08/2005 11:29:31 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 hi adrian, diego, all the scope of the mechanism should have been limited to create a control plane state when the corr. data plane resources have already been provisioned for the same connection by local config., MP, MPLS (for PSC LSP), whatever ... all the specifics in terms of migration from MP to CP and vice-versa are NOT to be standardized and falls outside the scope of the GMPLS protocol work per se; on the other side, if we need to initiate a work item on the migration to GMPLS *CONTROL PLANE* and come out with some operational guidelines, i strongly recommended to link this work with the item already started on this specific topic note: each time we include a bit in the ADMIN_STATUS object that refers to an operation which is not limited to a control plane related operation we should not "standardize" that behaviour; reason is because jumping in the bandwagon of standardizing usability and applications of the GMPLS control plane mechanism has as many profiles as users (we have had the same discussion during the p&r discussion loop); in the present case, we would be in a situation where we would be std'ing the usability of a CP mechanism assuming a that a) the MP <-> CP interaction is known (and hence also std'ized ?) but in a case where the following config is to considered we would also need to make assumptions about MP_1 <-> MP_2 MP_1 ---- MP_2 | | CP_1 ---- CP_2 --- Hi Diego, Thanks for taking some of the burden of WG chair from my shoulders. Before pushing this any further, I would be interested in your response to the recent liaison from ITU-T SG15 (text below). I would also like to understand whether this type of function is really likely to be used repeatedly or whether we are describing a "one shot" solution to an in-service upgrade. Cheers, Adrian === Text of liaison from SG15 At the recent Q12/15 and Q14/15 Rapporteur meeting, it was reported that CCAMP is discussing the issue of migration of connections under the management plane to the control plane. This topic has been discussed in previous SG15 meetings and some of the conclusions are offered that may be helpful to CCAMP. The motivation for migrating calls and connections includes applying a control plane to an existing transport network, and/or combining a transport network whose connections are managed by an OSS and one whose connections are established by a control plane. Two broad issues with connection migration are dual views of a resource, and the preconditions before protocol state is created for a connection. Dual views of a resource concerns the need for a resource to be in both management and control plane view the same time. This is because although the control plane may have responsibility of allocating/releasing connections in subnetworks (a node is a smallest subnetwork), the management plane still has responsibility for other functions on the resource. Changing the responsibility of allocating/releasing connections requires more state for actions like rolling back a migration action due to failures. Preconditions for migrating from the management plane to control plane are extensive and may involve much planning because the context for the control plane has to be in place. This includes: - Naming of resources. Both node and link naming are required before signalling protocols can run. Without this, no explicit route can be formed to match the resources of the connection. Naming of multiple nodes and links has to be planned ahead of time. - Control plane component adjacencies must be established. In GMPLS the control adjacencies are separate from bearer adjacencies and do not have to coincide. Planning and establishing those adjacencies is needed before migration can be initiated. - Links must be pre-configured and made visible to control plane routing. - For each service and the associated connections to be migrated, the service name, connection names, and explicit resource lists (in the control plane name space) need to be passed from the management plane to the control plane. Once this is done, connection state in the control plane can be created for an existing connection and the resources placed under the view of the control plane. Taken together, the preparation for migrating even one connection suggests that a whole set of the transport resources be prepared at the same time. Finally, when connection state is being created to match an existing connection, the connection controllers (signalling entities) should not require awareness of why this is happening as the context could be migration or other operation. A mechanism to create control state without affecting transport plane state is needed in the connection controllers. It is important to ensure that the connections are not deleted when the management plane relinquishes control of the resources. Entities that initiate the connection (Call controllers) do need migration awareness as they need to obtain/derive service (call) identification from the management plane. This is because the identity of connections created by management planes are typically stored in OSS inventory systems, as well as the identity of the service to which the connection is associated with. The general conclusion is that the preparation for, and operational impacts of, connection migration are much larger and more complex than the actual control plane procedures to create signalling state for an existing connection. These procedures will only be invoked once in the life time of the network. For these reasons, Q12/15 and Q14/15 have decided not to pursue a solution to this problem. ----- Original Message ----- From: "Diego Caviglia" To: "ccamp" Sent: Tuesday, December 06, 2005 11:34 AM Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > Folks, > a week has passed from the below e-mail, there has been only one > replay from a carrier the answers were for yes for both question 2 and 3. > > Now I'll try to put the question in a different way. > > Do anyone think that the ID should not be moved to WG status? > > Regards > > Diego > > > > > > "Diego Caviglia" @ops.ietf.org on 29/11/2005 > 08.08.59 > > Sent by: owner-ccamp@ops.ietf.org > > > To: ccamp@ops.ietf.org > cc: "Dino Bramanti" , "Dan Li > Subject: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > > Hi all, > during the last IETF meeting unfortunaltely there was not enough > thime to present and discuss the ID in the subject, nevertheless I think > (but I'm an authour) the ID satisfy a real request from the Carries > community. > > I'd like to ask you some questions > > 1. Are there any comments on the ID? > > 2. Mainly for the carriers. Do you think the ID describes an useful > tool? > > 3. Should the ID moved to the WG status? > > Of course my answer for 2 and 3 are Yes and Yes ;-) > > Regards > > Diego > > > > > > > From portfarm@aancel.com Fri Dec 09 06:06:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekg56-0005yH-A2 for ccamp-archive@megatron.ietf.org; Fri, 09 Dec 2005 06:06:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18002 for ; Fri, 9 Dec 2005 06:05:21 -0500 (EST) Received: from [211.48.241.61] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ekg4w-00072H-Qk for ccamp-archive@ietf.org; Fri, 09 Dec 2005 06:06:26 -0500 Message-ID: <000001c5fcda$9868c400$0100007f@localhost> From: "Mathew Morris" To: Subject: What IS 0EM Software And Why D0 You Care? Date: Fri, 09 Dec 2005 20:06:04 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FCDA.9868C400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FCDA.9868C400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5FCDA.9868C400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 42 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 42 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 34 reviews)


------=_NextPart_000_0001_01C5FCDA.9868C400-- From lonelord1@baldo22.com Fri Dec 09 09:40:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkjQa-0001gS-O1 for ccamp-archive@megatron.ietf.org; Fri, 09 Dec 2005 09:40:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12778 for ; Fri, 9 Dec 2005 09:39:49 -0500 (EST) Received: from 88-104-139-132.dynamic.dsl.as9105.com ([88.104.139.132] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EkjQZ-0005x6-NL for ccamp-archive@ietf.org; Fri, 09 Dec 2005 09:40:55 -0500 Message-ID: <000001c5fcf8$649c9700$0100007f@localhost> From: "Frank Henderson" To: Subject: 0EM Software Date: Fri, 09 Dec 2005 14:40:18 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FCF8.649C9700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FCF8.649C9700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5FCF8.649C9700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 32 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 44 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 36 reviews)


------=_NextPart_000_0001_01C5FCF8.649C9700-- From eliska.basti@acvz.com Fri Dec 09 12:21:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eklvf-0004zr-SR for ccamp-archive@megatron.ietf.org; Fri, 09 Dec 2005 12:21:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03202 for ; Fri, 9 Dec 2005 12:20:11 -0500 (EST) Received: from pool-71-244-241-115.chi01.dsl-w.verizon.net ([71.244.241.115] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eklvp-0003LI-AT for ccamp-archive@ietf.org; Fri, 09 Dec 2005 12:21:19 -0500 Message-ID: <000001c5fd0e$ed263200$0100007f@localhost> From: "Levi Gonzales" To: Subject: What IS 0EM Software And Why D0 You Care? Date: Fri, 09 Dec 2005 12:20:31 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FD0E.ED263200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FD0E.ED263200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5FD0E.ED263200 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 46 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 48 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 35 reviews)


------=_NextPart_000_0001_01C5FD0E.ED263200-- From owner-ccamp@ops.ietf.org Fri Dec 09 19:03:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EksD6-0007Qg-NV for ccamp-archive@megatron.ietf.org; Fri, 09 Dec 2005 19:03:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02563 for ; Fri, 9 Dec 2005 19:02:30 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EksDG-0004yt-7y for ccamp-archive@ietf.org; Fri, 09 Dec 2005 19:03:42 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eks07-000KLD-1n for ccamp-data@psg.com; Fri, 09 Dec 2005 23:50:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eks05-000KK5-HB for ccamp@ops.ietf.org; Fri, 09 Dec 2005 23:50:06 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Eks01-00086H-WE; Fri, 09 Dec 2005 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-04.txt Message-Id: Date: Fri, 09 Dec 2005 18:50:01 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 --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-04.txt Pages : 17 Date : 2005-12-9 Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. It is important to note that GMPLS is applicable in a wider contexts than ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply to allows the GMPLS terms to be applied within the ASON context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-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-ason-lexicography-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-ason-lexicography-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-12-9161905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-lexicography-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-9161905.I-D@ietf.org> --OtherAccess-- --NextPart-- From WilmaGutierrez@bestbuyair.com Sat Dec 10 00:59:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekxl5-0002x3-Vd for ccamp-archive@megatron.ietf.org; Sat, 10 Dec 2005 00:59:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16471 for ; Sat, 10 Dec 2005 00:58:05 -0500 (EST) Received: from [66.209.94.39] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EkxlI-0001ou-1z for ccamp-archive@ietf.org; Sat, 10 Dec 2005 00:59:20 -0500 Received: from YBd@localhost by sK0Q.int (8.11.6/8.11.6); Sat, 10 Dec 2005 01:52:33 -0500 Message-ID: From: "Diane Hager" Reply-To: "Diane Hager" To: ccamp-archive@ietf.org Subject: Adobe, Windows Products available for Download Date: Sat, 10 Dec 2005 02:54:33 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: WilmaGutierrez@bestbuyair.com Content-Type: multipart/mixed; boundary="--1Xn8hPUzdVbYnXtC" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 K5Bq ----1Xn8hPUzdVbYnXtC Content-Type: text/html; Content-Transfer-Encoding: quoted-printable E
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

<= /table>

TOP 10 NEW TITLES

=
 <= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&nbs= p;2 Creative Suite 2
 <= /td>3 MS Office 2003 Pro
 = 4 Adobe Acrobat 7 Pro
&nbs= p;5 Macromedia Flash 8
&nbs= p;6 Dreamweaver 8
 7 Norton Sysworks 2005
 = 8 Adobe GoLive CS2
 = 9 Adobe Illustrator CS2
&= nbsp;10 Borland Architect 2005
  See more by this manufacturer
   Microsoft
 = Macromedia
  = Adobe
  Cu= stomers also bought
   these other items...

M= icrosoft Windows XP Professional *w/SP2*
Microsoft

Choose:
 

List Price:$= 299.00
Price:= $49.99=
You Save:$249.01 (80= %)



Availability: = Available for INSTANT download!
Coupon Code: GlqmCADF
Pl= atform: Windows X= P

Sales Rank: #1
System requirements&nb= sp; |  Other Versions
Date Coupon Expires: December 31st, 2005
= Average Customer Review:3D"5 Based on= 17434 reviews. Write a review.


Adobe Creative Suite 2 *Premium*
Adobe

Choose:
 

List Price:$1199.= 00
Price:$149.99
You Save:$1049.01 (95= %)



Availability: = Available for INSTANT download!
Coupon Code: zsy2CgNBN
P= latform: Windows = XP

Sales Rank: #2
System requirements&n= bsp; |  Other Versions<= span class=3Dtiny>
Date Coupon Expires: December 31st, 2005
= Average Customer Review:3D"5 Based o= n 19124 reviews. Write a review.


Microsoft Office 2003 *Professional*<= br> Microsoft

Choose:
 

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D21 width=3D189><= tr>
List Price:$499.00
Price:$69.99
You = Save:$429.01 (85%)

<= a href=3Dhttp://newyearoem.com/?A>

Availability: Available for INSTANT download!=
Coupon Code: XS8XhWy
Platform: Windows XP

Sales Rank: #3
System requirements
  |  Other Versions

Date Co= upon Expires: December 31st, 2005
Ave= rage Customer Review:3D"5 Based on 18535 reviews. Write a review.


Adobe Acro= bat Professional V 7.0
Adobe

Choose:
 
=
List Pr= ice:$499.00
Pric= e:$69.99
You Save:$429.01 (85%)

<= br>
Availability: Available for INSTANT download!
Coupon= Code: 9R8Gttd6
Platform: Windows XP

Sales Ra= nk: #4 System requirements  |  Other Versions
Date Coupon Expires:= December 31st, 2005
Average Customer= Review:3D"5 Based on 11282 reviews. Write a review.


<= /td>
----1Xn8hPUzdVbYnXtC-- From 2o6u8mf7h928u1@apartmentsbrazil.com Sat Dec 10 12:36:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El8eT-0004fM-Di for ccamp-archive@megatron.ietf.org; Sat, 10 Dec 2005 12:36:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19491 for ; Sat, 10 Dec 2005 12:35:58 -0500 (EST) Received: from host190-165.pool8289.interbusiness.it ([82.89.165.190] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1El8er-0005UR-1r for ccamp-archive@ietf.org; Sat, 10 Dec 2005 12:37:19 -0500 Message-ID: <000001c5fdda$398a7400$0100007f@localhost> From: "Brian Ramirez" <2o6u8mf7h928u1@apartmentsbrazil.com> To: Subject: Photoshop, Windows, Office Date: Sat, 10 Dec 2005 18:38:47 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FDDA.398A7400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.4 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FDDA.398A7400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5FDDA.398A7400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 38 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 39 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 45 reviews)


------=_NextPart_000_0001_01C5FDDA.398A7400-- From revdcope@abintramassage.com Sun Dec 11 06:01:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElOxe-0004V3-C2 for ccamp-archive@megatron.ietf.org; Sun, 11 Dec 2005 06:01:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09032 for ; Sun, 11 Dec 2005 06:00:51 -0500 (EST) Received: from 71-9-143-237.dhcp.mdfd.or.charter.com ([71.9.143.237] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ElOy8-0002NK-Kw for ccamp-archive@ietf.org; Sun, 11 Dec 2005 06:02:22 -0500 Message-ID: <000001c5fe6c$2d4ef700$0100007f@localhost> From: "Cole Green" To: Subject: cheap oem soft shipping //orldwide Date: Sun, 11 Dec 2005 03:06:27 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FE6C.2D4EF700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FE6C.2D4EF700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 42 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5FE6C.2D4EF700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!
!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 46 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 33 reviews)!


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 41 reviews)


------=_NextPart_000_0001_01C5FE6C.2D4EF700-- From nmazer@adultbuffett.com Sun Dec 11 09:17:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElS0v-0007eg-IV for ccamp-archive@megatron.ietf.org; Sun, 11 Dec 2005 09:17:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25951 for ; Sun, 11 Dec 2005 09:16:25 -0500 (EST) Received: from [83.9.225.204] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ElS1U-0007wT-1n for ccamp-archive@ietf.org; Sun, 11 Dec 2005 09:17:59 -0500 Message-ID: <000001c5fe87$3dc09b00$0100007f@localhost> From: "Alejandro Turner" To: Subject: Software At Low Pr1ce Date: Sun, 11 Dec 2005 15:16:58 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FE87.3DC09B00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FE87.3DC09B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5FE87.3DC09B00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!
!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 46 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 40 reviews)!


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 32 reviews)


------=_NextPart_000_0001_01C5FE87.3DC09B00-- From secsaude@amateursofcolor.com Sun Dec 11 14:58:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElXLI-0000c4-Va for ccamp-archive@megatron.ietf.org; Sun, 11 Dec 2005 14:58:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00959 for ; Sun, 11 Dec 2005 14:57:48 -0500 (EST) Received: from toronto-hse-ppp4228457.sympatico.ca ([70.52.154.59] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ElXLw-0002Hv-EN for ccamp-archive@ietf.org; Sun, 11 Dec 2005 14:59:25 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for ccamp-archive@ietf.org; Sun, 11 Dec 2005 14:58:39 -0500 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for ccamp-archive@ietf.org; Sun, 11 Dec 2005 14:58:39 -0500 Message-ID: <000001c5feb7$1b467600$0100007f@localhost> From: "Carter Smith" To: Subject: Last offer- Discount special for PE patch almost over! Date: Sun, 11 Dec 2005 14:58:39 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FEB7.1B467600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FEB7.1B467600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.befaso.net/pt/?46&lpxol ------=_NextPart_000_0001_01C5FEB7.1B467600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5FEB7.1B467600-- From nfo@astroastute.com Sun Dec 11 19:35:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elbep-0002Jv-6R for ccamp-archive@megatron.ietf.org; Sun, 11 Dec 2005 19:35:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29483 for ; Sun, 11 Dec 2005 19:33:59 -0500 (EST) Received: from arennes-351-1-24-197.w82-126.abo.wanadoo.fr ([82.126.117.197] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ElbfE-0003MD-02 for ccamp-archive@ietf.org; Sun, 11 Dec 2005 19:35:38 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for ccamp-archive@ietf.org; Mon, 12 Dec 2005 01:34:33 +0100 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for ccamp-archive@ietf.org; Mon, 12 Dec 2005 01:34:33 +0100 Message-ID: <000001c5fedd$b2bebf80$0100007f@localhost> From: "Jonathon Wright" To: Subject: Hey buddy, whats up Date: Mon, 12 Dec 2005 01:34:33 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FEDD.B2BEBF80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FEDD.B2BEBF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.befaso.net/pt/?46&bbnjnv ------=_NextPart_000_0001_01C5FEDD.B2BEBF80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5FEDD.B2BEBF80-- From fdpd2001@8hats.com Mon Dec 12 05:58:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EllO4-0000D1-5T for ccamp-archive@megatron.ietf.org; Mon, 12 Dec 2005 05:58:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03810 for ; Mon, 12 Dec 2005 05:57:27 -0500 (EST) Received: from [82.155.129.80] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EllOG-00072G-Fa for ccamp-archive@ietf.org; Mon, 12 Dec 2005 05:59:13 -0500 Message-ID: <000001c5ff34$6783cb80$0100007f@localhost> From: "Lucas Allen" To: Subject: Need S0ftware? Date: Mon, 12 Dec 2005 10:57:36 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FF34.6783CB80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FF34.6783CB80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 44 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5FF34.6783CB80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!
!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 34 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 38 reviews)!


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 50 reviews)


------=_NextPart_000_0001_01C5FF34.6783CB80-- From owner-ccamp@ops.ietf.org Mon Dec 12 15:18:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elu7U-000784-Gj for ccamp-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:18:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19380 for ; Mon, 12 Dec 2005 15:16:59 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Elu8D-0004P4-2s for ccamp-archive@ietf.org; Mon, 12 Dec 2005 15:18:45 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eltzl-0009UK-0G for ccamp-data@psg.com; Mon, 12 Dec 2005 20:10:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eltzk-0009To-Dp for ccamp@ops.ietf.org; Mon, 12 Dec 2005 20:10:00 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBCK8K022676; Mon, 12 Dec 2005 12:08:20 -0800 (PST) Message-Id: <200512122008.jBCK8K022676@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4257 on Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 12 Dec 2005 12:08:19 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4257 Title: Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks Author(s): G. Bernstein, E. Mannie, V. Sharma, E. Gray Status: Informational Date: December 2005 Mailbox: gregb@grotto-networking.com, eric.mannie@perceval.net, v.sharma@ieee.org, Eric.Gray@Marconi.com Pages: 35 Characters: 86974 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-sdhsonet-control-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4257.txt Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051212120700.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4257 --OtherAccess Content-Type: Message/External-body; name="rfc4257.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051212120700.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From bbossin1@asian-promise.com Mon Dec 12 15:53:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElugJ-0002WM-9V for ccamp-archive@megatron.ietf.org; Mon, 12 Dec 2005 15:53:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25451 for ; Mon, 12 Dec 2005 15:53:02 -0500 (EST) Received: from ip-69-33-42-236.lax.megapath.net ([69.33.42.236] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eluh8-0006AS-2t for ccamp-archive@ietf.org; Mon, 12 Dec 2005 15:54:53 -0500 Message-ID: <000001c5ff88$1998b300$0100007f@localhost> From: "Hunter Edwards" To: Subject: Software At Low Pr1ce Date: Mon, 12 Dec 2005 12:55:02 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FF88.1998B300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.2 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FF88.1998B300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 42 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5FF88.1998B300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   ! ; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 38 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 48 revi! ews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 41 reviews)


------=_NextPart_000_0001_01C5FF88.1998B300-- From hpt2003@americanoutpost.com Mon Dec 12 17:54:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElwYk-00072x-30 for ccamp-archive@megatron.ietf.org; Mon, 12 Dec 2005 17:54:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09792 for ; Mon, 12 Dec 2005 17:53:20 -0500 (EST) Received: from [200.121.202.191] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ElwZW-0001nW-Eo for ccamp-archive@ietf.org; Mon, 12 Dec 2005 17:55:13 -0500 Message-ID: <000001c5ff98$e14da080$0100007f@localhost> From: "Luke Cooper" To: Subject: Buy OEM Software Date: Sun, 11 Dec 2005 17:55:33 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FF98.E14DA080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.9 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FF98.E14DA080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5FF98.E14DA080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   ! ; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 47 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 31 revi! ews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 50 reviews)


------=_NextPart_000_0001_01C5FF98.E14DA080-- From wzpusherdan@adliqfund.com Mon Dec 12 20:09:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElyfP-0006uc-C5 for ccamp-archive@megatron.ietf.org; Mon, 12 Dec 2005 20:09:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02366 for ; Mon, 12 Dec 2005 20:08:21 -0500 (EST) Received: from 246.209-dsl.sccoast.net ([66.153.209.246] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ElygD-0000MP-Cw for ccamp-archive@ietf.org; Mon, 12 Dec 2005 20:10:13 -0500 Message-ID: <000001c5ffab$a6a13380$0100007f@localhost> From: "Julio Green" To: Subject: Photoshop, Windows, Office Date: Mon, 12 Dec 2005 20:10:41 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5FFAB.A6A13380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.9 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5FFAB.A6A13380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5FFAB.A6A13380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   ! ; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 37 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 43 revi! ews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 45 reviews)


------=_NextPart_000_0001_01C5FFAB.A6A13380-- From owner-ccamp@ops.ietf.org Tue Dec 13 02:11:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em4KL-0002VK-5U for ccamp-archive@megatron.ietf.org; Tue, 13 Dec 2005 02:11:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10255 for ; Tue, 13 Dec 2005 02:11:00 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em4LE-0003jG-LZ for ccamp-archive@ietf.org; Tue, 13 Dec 2005 02:12:56 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Em46G-000KUQ-2Y for ccamp-data@psg.com; Tue, 13 Dec 2005 06:57:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,SPF_PASS autolearn=no version=3.1.0 Received: from [213.46.243.13] (helo=amsfep18-int.chello.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Em46E-000KTu-4d for ccamp@ops.ietf.org; Tue, 13 Dec 2005 06:57:22 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep16-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051212194514.CHNM16294.amsfep16-int.chello.nl@[192.168.1.4]>; Mon, 12 Dec 2005 20:45:14 +0100 Message-ID: <439DD341.7030107@chello.nl> Date: Mon, 12 Dec 2005 20:45:05 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Rabbat CC: ccamp@ops.ietf.org, Diego Caviglia , Greg Bernstein Subject: Re: next steps on diverse path vcat/lcas References: <438B845E.7020600@us.fujitsu.com> In-Reply-To: <438B845E.7020600@us.fujitsu.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Hello Richard, You wrote: > during ietf in vancouver, we had a good discussion related to > draft-bernstein-ccamp-gmpls-vcat-lcas-01.txt > There were many people interested in collaborating on this work item. > Can these interested people drop us a line if they want to collaborate > on a revision to the draft or give feedback on the current version? > we'd like to have some consensus on what extra features are needed and > work on the solutions Because you already mentioned my contributions to the draft I would like to continue providing feedback. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From champion@acer-outlet.com Tue Dec 13 17:13:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIOK-0002gd-CA for ccamp-archive@megatron.ietf.org; Tue, 13 Dec 2005 17:13:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06605 for ; Tue, 13 Dec 2005 17:12:02 -0500 (EST) Received: from c-24-22-158-163.hsd1.wa.comcast.net ([24.22.158.163] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EmIPN-0004uB-OG for ccamp-archive@ietf.org; Tue, 13 Dec 2005 17:14:07 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for ccamp-archive@ietf.org; Tue, 13 Dec 2005 14:13:08 -0800 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for ccamp-archive@ietf.org; Tue, 13 Dec 2005 14:13:08 -0800 Message-ID: <000001c6005c$474f2c00$0100007f@localhost> From: "Axel Martinez" To: Subject: Massive PE patch sale Date: Tue, 13 Dec 2005 14:13:08 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6005C.474F2C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.9 (++++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6005C.474F2C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.befaso.net/pt/?46&ckijsf ------=_NextPart_000_0001_01C6005C.474F2C00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C6005C.474F2C00-- From owner-ccamp@ops.ietf.org Wed Dec 14 05:49:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmUCT-0005ns-Mg for ccamp-archive@megatron.ietf.org; Wed, 14 Dec 2005 05:49:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04000 for ; Wed, 14 Dec 2005 05:48:23 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmUDN-0000RV-UL for ccamp-archive@ietf.org; Wed, 14 Dec 2005 05:50:35 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmU2n-000OwG-2t for ccamp-data@psg.com; Wed, 14 Dec 2005 10:39:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [61.144.161.53] (helo=huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmU2e-000Ovu-Jw for ccamp@ops.ietf.org; Wed, 14 Dec 2005 10:39:30 +0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRH00GI7HL05B@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 14 Dec 2005 18:39:01 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRH009R2HL0CW@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 14 Dec 2005 18:39:00 +0800 (CST) Received: from l37133 ([10.70.76.208]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRH00BW2HTT6K@szxml01-in.huawei.com>; Wed, 14 Dec 2005 18:44:17 +0800 (CST) Date: Wed, 14 Dec 2005 18:30:25 +0800 From: Dan Li Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus To: Dimitri.Papadimitriou@alcatel.be, Adrian Farrel Cc: ccamp , Diego Caviglia Message-id: <016101c60099$657599c0$d04c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Content-Transfer-Encoding: 7BIT See my comments in line. Thanks! - Dan ----- Original Message ----- From: To: "Adrian Farrel" Cc: "ccamp" ; "Diego Caviglia" Sent: Thursday, December 08, 2005 6:29 PM Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > > hi adrian, diego, all > > the scope of the mechanism should have been limited to create a control > plane state when the corr. data plane resources have already been > provisioned for the same connection by local config., MP, MPLS (for PSC > LSP), whatever ... all the specifics in terms of migration from MP to CP > and vice-versa are NOT to be standardized and falls outside the scope of > the GMPLS protocol work per se; on the other side, if we need to initiate a > work item on the migration to GMPLS *CONTROL PLANE* and come out with some > operational guidelines, i strongly recommended to link this work with the > item already started on this specific topic Partially agreed. MP2CP ownership handover is not only the requirement of carriers' migration to ASON, it also can be used to handle the various failures of control plane. During the recent discussion, if the control states of control plane can not be recovered, what should we do? According to the principle "the transport plane should not be touched when there is a failure in the control plane", all the connections should be kept, this actually means CP2MP ownership handover, the MP will take over the control of these connections. Obviously, after the control plane is recovered, the MP2CP ownership handover may also be needed. I think the procedure of MP2CP ownership handover belongs to control plane recovery process which is casued by some failures in the control plane, the only different is who triggers the control plane states recovery. For MP2CP ownership handover, this procedure is triggered by management plane. The process at the Ingress node maybe is a little bit different, but the process at all the following nodes should be same, so we can unify (via Recovery Label object) the processes of MP2CP ownership handover and control plane recovery. In another words, MP2CP ownership handover is the control plane recovery which is triggered by management plane. Compared with the current Recovery procedure, MP2CP ownership handover includes looking up the cross-connection table in the transport plane, this is also compatible with the current recovery procedure. CP2MP ownership handover is also similar to the control plane Graceful Shutdown. After the MP takes over the control of all the connections which previously are controlled by CP, the control plane can be gracefully shutdown. > > note: each time we include a bit in the ADMIN_STATUS object that refers to > an operation which is not limited to a control plane related operation we > should not "standardize" that behaviour; reason is because jumping in the > bandwagon of standardizing usability and applications of the GMPLS control > plane mechanism has as many profiles as users (we have had the same > discussion during the p&r discussion loop); in the present case, we would > be in a situation where we would be std'ing the usability of a CP mechanism > assuming a that a) the MP <-> CP interaction is known (and hence also > std'ized ?) but in a case where the following config is to considered we > would also need to make assumptions about MP_1 <-> MP_2 > > MP_1 ---- MP_2 > | | > CP_1 ---- CP_2 > > > --- > > > > Hi Diego, > > Thanks for taking some of the burden of WG chair from my shoulders. > > Before pushing this any further, I would be interested in your response to > the recent liaison from ITU-T SG15 (text below). > > I would also like to understand whether this type of function is really > likely to be used repeatedly or whether we are describing a "one shot" > solution to an in-service upgrade. > > Cheers, > Adrian > === > Text of liaison from SG15 > > At the recent Q12/15 and Q14/15 Rapporteur meeting, it was reported that > CCAMP is discussing the issue of migration of connections under the > management plane to the control plane. This topic has been discussed in > previous SG15 meetings and some of the conclusions are offered that may be > helpful to CCAMP. > The motivation for migrating calls and connections includes applying a > control plane to an existing transport network, and/or combining a > transport network whose connections are managed by an OSS and one whose > connections are established by a control plane. > Two broad issues with connection migration are dual views of a resource, > and the preconditions before protocol state is created for a connection. > Dual views of a resource concerns the need for a resource to be in both > management and control plane view the same time. This is because although > the control plane may have responsibility of allocating/releasing > connections in subnetworks (a node is a smallest subnetwork), the > management plane still has responsibility for other functions on the > resource. Changing the responsibility of allocating/releasing connections > requires more state for actions like rolling back a migration action due > to failures. > Preconditions for migrating from the management plane to control plane are > extensive and may involve much planning because the context for the > control plane has to be in place. This includes: > - Naming of resources. Both node and link naming are required before > signalling protocols can run. Without this, no explicit route can be > formed to match the resources of the connection. Naming of multiple nodes > and links has to be planned ahead of time. > - Control plane component adjacencies must be established. In GMPLS the > control adjacencies are separate from bearer adjacencies and do not have > to coincide. Planning and establishing those adjacencies is needed before > migration can be initiated. > - Links must be pre-configured and made visible to control plane routing. > - For each service and the associated connections to be migrated, the > service name, connection names, and explicit resource lists (in the > control plane name space) need to be passed from the management plane to > the control plane. > Once this is done, connection state in the control plane can be created > for an existing connection and the resources placed under the view of the > control plane. Taken together, the preparation for migrating even one > connection suggests that a whole set of the transport resources be > prepared at the same time. > Finally, when connection state is being created to match an existing > connection, the connection controllers (signalling entities) should not > require awareness of why this is happening as the context could be > migration or other operation. A mechanism to create control state without > affecting transport plane state is needed in the connection controllers. > It is important to ensure that the connections are not deleted when the > management plane relinquishes control of the resources. Entities that > initiate the connection (Call controllers) do need migration awareness as > they need to obtain/derive service (call) identification from the > management plane. This is because the identity of connections created by > management planes are typically stored in OSS inventory systems, as well > as the identity of the service to which the connection is associated with. > The general conclusion is that the preparation for, and operational > impacts of, connection migration are much larger and more complex than the > actual control plane procedures to create signalling state for an existing > connection. These procedures will only be invoked once in the life time of > the network. For these reasons, Q12/15 and Q14/15 have decided not to > pursue a solution to this problem. > > > ----- Original Message ----- > From: "Diego Caviglia" > To: "ccamp" > Sent: Tuesday, December 06, 2005 11:34 AM > Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > > > > > Folks, > > a week has passed from the below e-mail, there has been only one > > replay from a carrier the answers were for yes for both question 2 and > 3. > > > > Now I'll try to put the question in a different way. > > > > Do anyone think that the ID should not be moved to WG status? > > > > Regards > > > > Diego > > > > > > > > > > > > "Diego Caviglia" @ops.ietf.org on 29/11/2005 > > 08.08.59 > > > > Sent by: owner-ccamp@ops.ietf.org > > > > > > To: ccamp@ops.ietf.org > > cc: "Dino Bramanti" , "Dan Li > > > Subject: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > > > > > Hi all, > > during the last IETF meeting unfortunaltely there was not > enough > > thime to present and discuss the ID in the subject, nevertheless I think > > (but I'm an authour) the ID satisfy a real request from the Carries > > community. > > > > I'd like to ask you some questions > > > > 1. Are there any comments on the ID? > > > > 2. Mainly for the carriers. Do you think the ID describes an > useful > > tool? > > > > 3. Should the ID moved to the WG status? > > > > Of course my answer for 2 and 3 are Yes and Yes ;-) > > > > Regards > > > > Diego > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Wed Dec 14 13:39:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmbXO-0001Lu-1J for ccamp-archive@megatron.ietf.org; Wed, 14 Dec 2005 13:39:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07422 for ; Wed, 14 Dec 2005 13:38:31 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmbYU-0003Q0-IP for ccamp-archive@ietf.org; Wed, 14 Dec 2005 13:40:47 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmbP2-000CkB-TU for ccamp-data@psg.com; Wed, 14 Dec 2005 18:31:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmbP1-000Cjy-Pu for ccamp@ops.ietf.org; Wed, 14 Dec 2005 18:30:59 +0000 Received: from du-069-0153.access.clara.net ([217.158.132.153] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1EmbOz-000DaD-IW; Wed, 14 Dec 2005 18:30:58 +0000 Message-ID: <0c6d01c600dd$04761de0$9d849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Acee Lindem" , Subject: Cross-WG review requested Date: Wed, 14 Dec 2005 18:31: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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Hi OSPF Working Group, CCAMP has just accepted two I-Ds that may be of interest to you. Routing extensions for discovery of Traffic Engineering Node Capabilities http://www.ietf.org/internet-drafts/draft-ietf-ccamp-te-node-cap-00.txt This I-D specifies OSPF and IS-IS traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. This I-D makes use of draft-ietf-ospf-cap by defining a new TLV to be included in the Router Information LSA. Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-00.txt This document specifies OSPF and IS-IS traffic engineering extensions so as to provide an automatic discovery of the set of LSRs members of a mesh, leading to an automatic mechanism to set up TE LSP mesh(es) (also referred to as a mesh-group). This I-D makes use of draft-ietf-ospf-cap by defining a new TLV to be included in the Router Information LSA. We would appreciate your feedback, ideally on the CCAMP mailing list, but alternatively to the WG chairs or to the authors direct. (We will also be consulting the IS-IS mailing list). Since this work is relatively mature, we will be progressing the documents to WG last call in the New Year, after suitable editorial refinement. Many thanks, Adrian per pro CCAMP From owner-ccamp@ops.ietf.org Wed Dec 14 13:43:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Embb4-00021N-M6 for ccamp-archive@megatron.ietf.org; Wed, 14 Dec 2005 13:43:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07795 for ; Wed, 14 Dec 2005 13:42:27 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmbcJ-0003YA-CD for ccamp-archive@ietf.org; Wed, 14 Dec 2005 13:44:44 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmbRQ-000D34-Ml for ccamp-data@psg.com; Wed, 14 Dec 2005 18:33:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmbRQ-000D2s-0k for ccamp@ops.ietf.org; Wed, 14 Dec 2005 18:33:28 +0000 Received: from du-069-0153.access.clara.net ([217.158.132.153] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1EmbRK-000E1M-IR; Wed, 14 Dec 2005 18:33:26 +0000 Message-ID: <0c7001c600dd$5bd620d0$9d849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Christian Hopps" , "Dave Ward" Subject: Cross-WG review requested Date: Wed, 14 Dec 2005 18:36: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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Hi IS-IS Working Group, CCAMP has just accepted two I-Ds that may be of interest to you. Routing extensions for discovery of Traffic Engineering Node Capabilities http://www.ietf.org/internet-drafts/draft-ietf-ccamp-te-node-cap-00.txt This I-D specifies OSPF and IS-IS traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. This I-D makes use of draft-ietf-isis-caps by defining a new TLV to be included in the ISIS Capability TLV. Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-00.txt This document specifies OSPF and IS-IS traffic engineering extensions so as to provide an automatic discovery of the set of LSRs members of a mesh, leading to an automatic mechanism to set up TE LSP mesh(es) (also referred to as a mesh-group). This I-D makes use of draft-ietf-isis-caps by defining a new TLV to be included in the ISIS Capability TLV. We would appreciate your feedback, ideally on the CCAMP mailing list, but alternatively to the WG chairs or to the authors direct. (We will also be consulting the OSPF mailing list). Since this work is relatively mature, we will be progressing the documents to WG last call in the New Year, after suitable editorial refinement. Many thanks, Adrian per pro CCAMP From owner-ccamp@ops.ietf.org Wed Dec 14 19:00:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmgXY-0002s2-M7 for ccamp-archive@megatron.ietf.org; Wed, 14 Dec 2005 19:00:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15678 for ; Wed, 14 Dec 2005 18:59:01 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmgYi-0007Og-MU for ccamp-archive@ietf.org; Wed, 14 Dec 2005 19:01:21 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmgNo-000J2n-Ov for ccamp-data@psg.com; Wed, 14 Dec 2005 23:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmgNm-000J1g-Ji for ccamp@ops.ietf.org; Wed, 14 Dec 2005 23:50:02 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EmgNl-0005z2-EE; Wed, 14 Dec 2005 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt Message-Id: Date: Wed, 14 Dec 2005 18:50:01 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --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-05.txt Pages : 17 Date : 2005-12-14 Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-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-ason-lexicography-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-ason-lexicography-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-12-14155633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-lexicography-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-14155633.I-D@ietf.org> --OtherAccess-- --NextPart-- From g.retamal@anymisl.com Wed Dec 14 21:16:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emif6-0008Lt-7F for ccamp-archive@megatron.ietf.org; Wed, 14 Dec 2005 21:16:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28569 for ; Wed, 14 Dec 2005 21:14:56 -0500 (EST) Received: from archiveco2.pck.nerim.net ([213.41.240.105] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EmigG-0003qY-Rc for ccamp-archive@ietf.org; Wed, 14 Dec 2005 21:17:18 -0500 Message-ID: <000001c60147$5fe84080$0100007f@localhost> From: "Robert Ross" To: Subject: What IS 0EM Software And Why D0 You Care? Date: Thu, 15 Dec 2005 03:15:42 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60147.5FE84080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60147.5FE84080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 31 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60147.5FE84080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   ! ; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 46 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 33 revi! ews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 36 reviews)


------=_NextPart_000_0001_01C60147.5FE84080-- From brad@ardea-management.com Wed Dec 14 23:22:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmkdL-0005Xo-QO for ccamp-archive@megatron.ietf.org; Wed, 14 Dec 2005 23:22:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09208 for ; Wed, 14 Dec 2005 23:21:21 -0500 (EST) Received: from [211.224.235.87] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Emkeb-0007bt-1E for ccamp-archive@ietf.org; Wed, 14 Dec 2005 23:23:42 -0500 Message-ID: <000001c60159$0557e000$0100007f@localhost> From: "Hunter King" To: Subject: 0EM Software Date: Thu, 15 Dec 2005 13:22:00 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60159.0557E000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60159.0557E000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 44 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 31 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60159.0557E000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   ! ; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 49 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 37 revi! ews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 34 reviews)


------=_NextPart_000_0001_01C60159.0557E000-- From owner-ccamp@ops.ietf.org Thu Dec 15 03:58:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emow8-00082m-0t for ccamp-archive@megatron.ietf.org; Thu, 15 Dec 2005 03:58:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05234 for ; Thu, 15 Dec 2005 03:56:58 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmoxL-0000HL-2M for ccamp-archive@ietf.org; Thu, 15 Dec 2005 03:59:21 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Emonu-000606-T1 for ccamp-data@psg.com; Thu, 15 Dec 2005 08:49:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [62.105.161.4] (helo=mail.twang.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Emont-0005zk-I7 for ccamp@ops.ietf.org; Thu, 15 Dec 2005 08:49:33 +0000 Received: from [62.105.167.210] by mail.twang.net (GMS 10.03.3304/NY1676.00.b5a0c909) with ESMTP id kivnibba for ccamp@ops.ietf.org; Thu, 15 Dec 2005 08:40:59 +0000 Received: from mail pickup service by exchange01.twang.net with Microsoft SMTPSVC; Thu, 15 Dec 2005 08:46:01 +0000 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mailcleaner.twang.net (Vircom SMTPRS 4.2.425.16) with ESMTP id for ; Thu, 15 Dec 2005 00:15:57 +0000 X-Modus-ReverseDNS: OK X-Modus-BlackList: 132.151.6.71=OK;i-d-announce-bounces@ietf.org=OK X-Modus-RBL: 132.151.6.71=OK X-Modus-Trusted: 132.151.6.71=NO Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmgNu-0001lF-7c; Wed, 14 Dec 2005 18:50:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmgNm-0001js-7e for i-d-announce@megatron.ietf.org; Wed, 14 Dec 2005 18:50:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14712 for ; Wed, 14 Dec 2005 18:49:03 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmgP4-000767-Sw for i-d-announce@ietf.org; Wed, 14 Dec 2005 18:51:23 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EmgNl-0005z2-EE; Wed, 14 Dec 2005 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Dec 2005 18:50:01 -0500 X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-OriginalArrivalTime: 15 Dec 2005 08:46:01.0064 (UTC) FILETIME=[F9BFAE80:01C60153] X-AntiSpam: Checked for restricted content by Gordano's AntiSpam Software Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e --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-05.txt Pages : 17 Date : 2005-12-14 Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-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-ason-lexicography-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-ason-lexicography-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-12-14155633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-lexicography-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-14155633.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-ccamp@ops.ietf.org Thu Dec 15 05:23:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmqGL-0003ms-Nt for ccamp-archive@megatron.ietf.org; Thu, 15 Dec 2005 05:23:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14504 for ; Thu, 15 Dec 2005 05:22:03 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmqHb-0003Ma-LS for ccamp-archive@ietf.org; Thu, 15 Dec 2005 05:24:27 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Emq5a-000BUb-IE for ccamp-data@psg.com; Thu, 15 Dec 2005 10:11:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [156.106.192.41] (helo=protext01.itu.ch) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Emq5Z-000BUM-OR for ccamp@ops.ietf.org; Thu, 15 Dec 2005 10:11:53 +0000 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Dec 2005 11:11:51 +0100 Received: From mail5.itu.ch ([156.106.192.21]) by protext01.itu.ch (WebShield SMTP v4.5 MR1a); id 1134641511421; Thu, 15 Dec 2005 11:11:51 +0100 Received: from ties.itu.ch (ties.itu.ch [156.106.192.33]) by mail5.itu.ch (8.13.4/8.13.4) with ESMTP id jBFABnhZ318905 for ; Thu, 15 Dec 2005 11:11:50 +0100 (MET) Received: from localhost (tokaj.itu.ch [156.106.192.34]) by ties.itu.ch (8.12.9/8.12.9) with ESMTP id jBFABnwX020660 for ; Thu, 15 Dec 2005 11:11:49 +0100 (MET) Received: from 156.106.192.159 ( [156.106.192.159]) as user jingr@ties.itu.ch by gold.itu.ch with HTTP; Thu, 15 Dec 2005 11:11:49 +0100 Message-ID: <1134641509.43a14165b9dbd@gold.itu.ch> Date: Thu, 15 Dec 2005 11:11:49 +0100 From: ruiquan.jing@ties.itu.ch To: ccamp@ops.ietf.org Subject: RE: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 156.106.192.159 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mail5.itu.ch [156.106.192.21]); Thu, 15 Dec 2005 11:11:51 +0100 (MET) X-OriginalArrivalTime: 15 Dec 2005 10:11:51.0906 (UTC) FILETIME=[F7E3CC20:01C6015F] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA14504 Hi all, =20 Please see inline. =20 Best regards =20 Ruiquan Jing China=A1=A1Telecom Beijing Research=A1=A1Institute =20 ----- Original Message -----=20 From: Diego Caviglia=20 To: ccamp@ops.ietf.org=20 Cc: Dino Bramanti ; Dan Li ; Thu, 15 Dec 2005 09:12:59 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmttA-0003LP-6R for ccamp-archive@ietf.org; Thu, 15 Dec 2005 09:15:27 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Emtf6-00010b-Ch for ccamp-data@psg.com; Thu, 15 Dec 2005 14:00:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Emtf3-00010O-Pd for ccamp@ops.ietf.org; Thu, 15 Dec 2005 14:00:45 +0000 Received: from du-069-0212.access.clara.net ([217.158.132.212] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1Emtf1-000Kvz-Hb; Thu, 15 Dec 2005 14:00:44 +0000 Message-ID: <0d8701c60180$6f811510$9d849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Igor Bryskin" References: Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt Date: Thu, 15 Dec 2005 14:04:11 -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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Hi, The 04 revision recently published reflected updates from our liaison exchange with the ITU-T. We believe that all points are now closed down and that document is complete. This 05 revision corrects a typo that Kohei spotted (thanks). I will ask Kireeti to run a last call, since I'm an editor. During your review, I would like you to pay particularly good attention to the text that describes GMPLS concepts. This text is not intended to be definitive, but it will be read by many people as providing clarification, so it needs to be right. Thanks, Adrian > 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-05.txt > Pages : 17 > Date : 2005-12-14 > > Generalized Multiprotocol Label Switching (GMPLS) has been developed > by the IETF to facilitate the establishment of Label Switched Paths > (LSPs) in a variety of data plane technologies and across several > architectural models. The ITU-T has specified an architecture for > the control of Automatically Switched Optical Networks (ASON). > > This document provides a lexicography for the interpretation of GMPLS > terminology within the context of the ASON architecture. > > It is important to note that GMPLS is applicable in a wider set of > contexts than just ASON. The definitions presented in this document > do not provide exclusive or complete interpretations of GMPLS > concepts. This document simply allows the GMPLS terms to be applied > within the ASON context. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-05.txt From owner-ccamp@ops.ietf.org Thu Dec 15 12:58:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmxN9-0003wU-VC for ccamp-archive@megatron.ietf.org; Thu, 15 Dec 2005 12:58:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11044 for ; Thu, 15 Dec 2005 12:57:32 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmxOX-0003QR-04 for ccamp-archive@ietf.org; Thu, 15 Dec 2005 13:00:01 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmxHe-000NEq-1l for ccamp-data@psg.com; Thu, 15 Dec 2005 17:52:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmxHd-000NEb-2d for ccamp@ops.ietf.org; Thu, 15 Dec 2005 17:52:49 +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 jBFHqm075883 for ; Thu, 15 Dec 2005 09:52:48 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jBFHqh576265 for ; Thu, 15 Dec 2005 09:52:43 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id jBFHqh7v044931 for ; Thu, 15 Dec 2005 09:52: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 jBFHqhZo044928 for ; Thu, 15 Dec 2005 09:52:43 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 15 Dec 2005 09:52:43 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd) Message-ID: <20051215094432.J44886@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hi All, This begins a two week (+ 1 day) WG Last Call for this document. As Adrian said: | During your review, I would like you to pay particularly good | attention to the text that describes GMPLS concepts. This text is | not intended to be definitive, but it will be read by many people as | providing clarification, so it needs to be right. The Last Call ends 5pm PST on Fri Dec 30. Get it done early so you can enjoy your New Year bash :-) Kireeti. ------- ---------- Forwarded message ---------- Date: Wed, 14 Dec 2005 18:50:01 -0500 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : 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-05.txt Pages : 17 Date : 2005-12-14 Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-05.txt From owner-ccamp@ops.ietf.org Thu Dec 15 14:14:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmyYG-0004rW-17 for ccamp-archive@megatron.ietf.org; Thu, 15 Dec 2005 14:14:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19653 for ; Thu, 15 Dec 2005 14:12:45 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmyZM-0006A6-Ut for ccamp-archive@ietf.org; Thu, 15 Dec 2005 14:15:15 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmyMJ-0004K0-Au for ccamp-data@psg.com; Thu, 15 Dec 2005 19:01:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmyMI-0004Jl-6D for ccamp@ops.ietf.org; Thu, 15 Dec 2005 19:01:42 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id jBFJ1Zf4032320; Thu, 15 Dec 2005 20:01:35 +0100 To: Kireeti Kompella Cc: ccamp@ops.ietf.org From: Dimitri.Papadimitriou@alcatel.be Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd) MIME-Version: 1.0 Date: Thu, 15 Dec 2005 20:01:34 +0100 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 12/15/2005 20:01:35 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c hi all 1. i still don't understand the need for the [ ... ] after each term - if authors could clarify this would be helpful 2. in general, i don't see why this document meant to clarify GMPLS terms for ASON includes ASON specific terms/definitions and interpretations hence the need for each "ASON terms" sub-section is unclear some other specifics 3. " Node [Control & Data Planes] is a logical combination of a transport node and the controller that manages the transport node. In early deployments, all control plane and data plane functions associated with a transport node were collocated in a node and referred to as a Label Switching Router (LSR)." the second sentence is imho outside the scope of such definition 4. "3.4.1. GMPLS Terms Label [Control Plane] is an abstraction that provides an identifier for use in the control plane in order to identify a transport plane resource." how to interpreet an MPLS label with this definition ? or is MPLS out of scope ? 5. "3.5.1. GMPLS Terms Unidirectional data link end [Data Plane] is a set of resources of a particular layer that belong to the same transport node and could be allocated for the transfer of traffic in this layer to the same neighbor in the same direction." what "same transport node" means here ? 6. " The need for advertisement of adaptation and termination capabilities within GMPLS has been recognized and work is in progress to determine how these will be advertised. It is likely that they will be advertised as a single combined attribute, or as separate attributes of the TE link local end associated with the link interface." afaik, GMPLS is able to advertize "termination" capabilities - thanks, - dimitri. From director@2judithjordan.com Thu Dec 15 14:46:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emz3b-0007Sy-Qd for ccamp-archive@megatron.ietf.org; Thu, 15 Dec 2005 14:46:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24161 for ; Thu, 15 Dec 2005 14:45:01 -0500 (EST) Received: from toronto-hse-ppp4228409.sympatico.ca ([70.52.154.11] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Emz4c-0007UL-7j for ccamp-archive@ietf.org; Thu, 15 Dec 2005 14:47:32 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for ccamp-archive@ietf.org; Thu, 15 Dec 2005 14:45:49 -0500 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for ccamp-archive@ietf.org; Thu, 15 Dec 2005 14:45:49 -0500 Message-ID: <000001c601da$257bb380$0100007f@localhost> From: "Adrian Washington" To: Subject: Hey baby, found this site and wanted you to check it out firstNeed Software? Date: Thu, 15 Dec 2005 14:45:49 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C601DA.257BB380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C601DA.257BB380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.oklasc.com/pt/?46&kwaut ------=_NextPart_000_0001_01C601DA.257BB380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C601DA.257BB380-- From dh83_uk@basic-sg.com Thu Dec 15 16:39:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En0pB-00067m-Fa for ccamp-archive@megatron.ietf.org; Thu, 15 Dec 2005 16:39:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17435 for ; Thu, 15 Dec 2005 16:38:42 -0500 (EST) Received: from user-0c6sh6p.cable.mindspring.com ([24.110.68.217] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1En0qc-0006Yj-Vb for ccamp-archive@ietf.org; Thu, 15 Dec 2005 16:41:12 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for ccamp-archive@ietf.org; Thu, 15 Dec 2005 16:37:28 -0800 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for ccamp-archive@ietf.org; Thu, 15 Dec 2005 16:37:28 -0800 Message-ID: <000001c601ea$038a2d00$0100007f@localhost> From: "Alfredo Bell" To: Subject: The Industries leading enhancement product, now on sale! Date: Thu, 15 Dec 2005 16:37:28 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C601EA.038A2D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.8 (+++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C601EA.038A2D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.oklasc.com/pt/?46&kfvqss ------=_NextPart_000_0001_01C601EA.038A2D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C601EA.038A2D00-- From owner-ccamp@ops.ietf.org Fri Dec 16 19:04:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnPYm-0001tb-I8 for ccamp-archive@megatron.ietf.org; Fri, 16 Dec 2005 19:04:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04180 for ; Fri, 16 Dec 2005 19:03:24 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnPaJ-0005kb-IL for ccamp-archive@ietf.org; Fri, 16 Dec 2005 19:06:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnPNh-000Mc0-4Z for ccamp-data@psg.com; Fri, 16 Dec 2005 23:52:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnPNf-000Mbj-Gf for ccamp@ops.ietf.org; Fri, 16 Dec 2005 23:52:55 +0000 Received: from du-069-0153.access.clara.net ([217.158.132.153] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1EnPNb-000HHk-Gz; Fri, 16 Dec 2005 23:52:52 +0000 Message-ID: <010701c6029c$5078de10$99849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Kireeti Kompella" , "Dimitri Papadimitriou" Cc: References: Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd) Date: Fri, 16 Dec 2005 23:55: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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Hi Dimitri, Thanks for reading. > 1. i still don't understand the need for the [ ... ] after each term - if > authors could clarify this would be helpful Hmm. Well the intention was to provide extra information in a quick way. I guess we could replace each [...] with a full sentence such as "This term applies to the control plane." I suppose that the RFC editor is going to object to our use of square brackets :-( > 2. in general, i don't see why this document meant to clarify GMPLS terms > for ASON includes ASON specific terms/definitions and interpretations hence > the need for each "ASON terms" sub-section is unclear The intention is not just to clarify the GMPLS terms, but also to provide a mapping. The full purpose (of making GMPLS comprehensible to ASON cognoscenti) is aided by the inclusion of corresponding ASON terms. What we have done, therefore, is split the text into: - a description of the GMPLS term - a translation into "equivalent" ASON terms Do you have an objection to this? > some other specifics > > 3. " Node [Control & Data Planes] is a logical combination of a > transport node and the controller that manages the transport node. > In early deployments, all control plane and data plane functions > associated with a transport node were collocated in a node and > referred to as a Label Switching Router (LSR)." > > the second sentence is imho outside the scope of such definition Some of the GMPLS RFCs are simplified by the use of "LSR", but it has been pointed out on numerous occasions that this creates an impression that in GMPLS there is *always* a tight binding (collocation) between control and data plane functions. As you know, this impression is contrary to reality. A couple of questions back to you. Is what it says incorrect? Would it help if we had a separate entry for LSR? > 4. "3.4.1. GMPLS Terms > > Label [Control Plane] is an abstraction that provides an identifier > for use in the control plane in order to identify a transport plane > resource." > > how to interpreet an MPLS label with this definition ? or is MPLS out of > scope ? MPLS is out of scope because there is possible translation to ASON. Note, however, we felt it helpful to include "Packet based resource" > 5. "3.5.1. GMPLS Terms > > Unidirectional data link end [Data Plane] is a set of resources of a > particular layer that belong to the same transport node and could > be allocated for the transfer of traffic in this layer to the same > neighbor in the same direction." > > what "same transport node" means here ? Erm? It means "same transport node" :-) The intention is to imply that all of the resources in the set belong to the same transport node. Maybe rephrase as: Unidirectional data link end [Data Plane] is a set of resources that all belong to the same transport node, all are in the same layer, and that could be allocated for the transfer of traffic in this layer to the same neighbor in the same direction." > 6. " The need for advertisement of adaptation and termination capabilities > within GMPLS has been recognized and work is in progress to determine > how these will be advertised. It is likely that they will be > advertised as a single combined attribute, or as separate attributes > of the TE link local end associated with the link interface." > > afaik, GMPLS is able to advertize "termination" capabilities - Does it? It seems to me that it advertizes switching capabilities only. Termination, like adaptation, is not the same thing as switching capability. Switching capability says how the link terminates, but not whether the node can terminate data flows. Cheers, Adrian From wd3t1@alfa-ome.com Sat Dec 17 08:47:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EncPT-0005Tb-3j for ccamp-archive@megatron.ietf.org; Sat, 17 Dec 2005 08:47:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25993 for ; Sat, 17 Dec 2005 08:46:37 -0500 (EST) Received: from atoulon-151-1-32-54.w83-197.abo.wanadoo.fr ([83.197.207.54] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EncRD-0006N3-FR for ccamp-archive@ietf.org; Sat, 17 Dec 2005 08:49:31 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for ccamp-archive@ietf.org; Sat, 17 Dec 2005 14:46:48 +0100 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for ccamp-archive@ietf.org; Sat, 17 Dec 2005 14:46:48 +0100 Message-ID: <000001c6033a$1e6bb700$0100007f@localhost> From: "Jaxon Miller" To: Subject: Hey bro, found this site Date: Sat, 17 Dec 2005 14:46:48 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6033A.1E6BB700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6033A.1E6BB700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.leropard.net/pt/?46&samia ------=_NextPart_000_0001_01C6033A.1E6BB700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C6033A.1E6BB700-- From andrewsaj@artist-printing.com Sat Dec 17 09:53:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EndQu-0004PC-Aw for ccamp-archive@megatron.ietf.org; Sat, 17 Dec 2005 09:53:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01838 for ; Sat, 17 Dec 2005 09:52:11 -0500 (EST) Received: from c-24-127-236-248.hsd1.fl.comcast.net ([24.127.236.248] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EndSi-00008M-Q7 for ccamp-archive@ietf.org; Sat, 17 Dec 2005 09:55:06 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for ccamp-archive@ietf.org; Sat, 17 Dec 2005 09:52:59 -0500 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for ccamp-archive@ietf.org; Sat, 17 Dec 2005 09:52:59 -0500 Message-ID: <000001c60343$97bbd780$0100007f@localhost> From: "Oscar Phillips" To: Subject: Hey baby, found this site and wanted you to check it out firstNeed Software? Date: Sat, 17 Dec 2005 09:52:59 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60343.97BBD780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60343.97BBD780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.leropard.net/pt/?46&jmblhb ------=_NextPart_000_0001_01C60343.97BBD780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C60343.97BBD780-- From myronw12@asharr.com Sat Dec 17 10:31:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ene2D-000542-BI for ccamp-archive@megatron.ietf.org; Sat, 17 Dec 2005 10:31:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06188 for ; Sat, 17 Dec 2005 10:30:44 -0500 (EST) Received: from softbank219009090019.bbtec.net ([219.9.90.19] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ene42-0001Gx-NA for ccamp-archive@ietf.org; Sat, 17 Dec 2005 10:33:39 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for ccamp-archive@ietf.org; Sun, 18 Dec 2005 00:31:32 +0900 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for ccamp-archive@ietf.org; Sun, 18 Dec 2005 00:31:32 +0900 Message-ID: <000001c60348$f0da3a00$0100007f@localhost> From: "Connor Foster" To: Subject: Hey bro, check out the huge sale these guys are offering Date: Sun, 18 Dec 2005 00:31:32 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60348.F0DA3A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.5 (+++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60348.F0DA3A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.leropard.net/pt/?46&ihskes ------=_NextPart_000_0001_01C60348.F0DA3A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C60348.F0DA3A00-- From 188chandler@accessvt.com Sat Dec 17 20:05:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Enmz4-0003iE-8A for ccamp-archive@megatron.ietf.org; Sat, 17 Dec 2005 20:05:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27428 for ; Sat, 17 Dec 2005 20:04:05 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Enn0x-0000Gf-OG for ccamp-archive@ietf.org; Sat, 17 Dec 2005 20:07:05 -0500 Received: from pcp0011098625pcs.elictc01.md.comcast.net ([68.50.246.99] helo=68.50.246.99) by mx2.foretec.com with smtp (Exim 4.24) id 1Enmyt-0000M1-6V for ccamp-archive@ietf.org; Sat, 17 Dec 2005 20:04:55 -0500 Message-ID: <590501c6036f$f8e7c9e1$e7013141@accessvt.com> From: "Steven A. Norman" <188chandler@accessvt.com> To: ccamp-archive@ietf.org Subject: Replica watch models Date: Sun, 18 Dec 2005 01:05:17 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_0A38231A.29628A4C" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.9 (++++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0000_0A38231A.29628A4C Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_0529B933.95937D07" ------=_NextPart_001_0001_0529B933.95937D07 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit REPLICA WATCH MODELS - exact copies of V.I.P. watches - perfect as a gift for your colleagues and friends - free gift box Rolex, Patek Philippe, Omega Cartier, Bvlgari, Franck Muller .. and 15 other most famous manufacturers. http://www.watches-for-people.com All watches are for only $239.95 - $279.95! ________________________________ To change your mail preferences, go here ________________________________ ------=_NextPart_001_0001_0529B933.95937D07 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
REPLICA WATCH MODELS

- exact copies of V.I.P. watches
- perfect as a gift for your colleagues and friends
- free gift box

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

.. and 15 other most famous manufacturers.

http://www.watches-for-people.com

All watches are for only $239.95 - $279.95!


________________________________
To change your mail preferences, go here
________________________________

------=_NextPart_001_0001_0529B933.95937D07-- ------=_NextPart_000_0000_0A38231A.29628A4C-- From thomas.hobbes@19312.com Sat Dec 17 22:43:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnpRr-0005Vo-FR for ccamp-archive@megatron.ietf.org; Sat, 17 Dec 2005 22:43:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11231 for ; Sat, 17 Dec 2005 22:41:57 -0500 (EST) Received: from pcp0012296250pcs.nrockv01.md.comcast.net ([68.55.19.82] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EnpTk-0004Zl-I2 for ccamp-archive@ietf.org; Sat, 17 Dec 2005 22:44:59 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for ccamp-archive@ietf.org; Sat, 17 Dec 2005 22:42:48 -0500 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for ccamp-archive@ietf.org; Sat, 17 Dec 2005 22:42:48 -0500 Message-ID: <000001c603ae$ea7ea900$0100007f@localhost> From: "Nicholas Anderson" To: Subject: The Industries leading enhancement product, now on sale! Date: Sat, 17 Dec 2005 22:42:48 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C603AE.EA7EA900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.3 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C603AE.EA7EA900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.leropard.net/pt/?46&funeu ------=_NextPart_000_0001_01C603AE.EA7EA900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C603AE.EA7EA900-- From inge-eckhard@art-movements.com Sat Dec 17 23:37:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnqIN-0000FE-FW for ccamp-archive@megatron.ietf.org; Sat, 17 Dec 2005 23:37:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16374 for ; Sat, 17 Dec 2005 23:36:13 -0500 (EST) Received: from 71-36-8-161.bois.qwest.net ([71.36.8.161] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EnqKJ-00065Y-5U for ccamp-archive@ietf.org; Sat, 17 Dec 2005 23:39:15 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for ccamp-archive@ietf.org; Sat, 17 Dec 2005 21:36:58 -0700 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for ccamp-archive@ietf.org; Sat, 17 Dec 2005 21:36:58 -0700 Message-ID: <000001c603b6$a8f1fc00$0100007f@localhost> From: "Damien Hill" To: Subject: Be the "biggest" out of all your friends Date: Sat, 17 Dec 2005 21:36:58 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C603B6.A8F1FC00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C603B6.A8F1FC00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.leropard.net/pt/?46&pbeyd ------=_NextPart_000_0001_01C603B6.A8F1FC00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C603B6.A8F1FC00-- From owner-ccamp@ops.ietf.org Sun Dec 18 16:57:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo6X5-00039Z-Nr for ccamp-archive@megatron.ietf.org; Sun, 18 Dec 2005 16:57:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27682 for ; Sun, 18 Dec 2005 16:56:29 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eo6Z5-00078G-3i for ccamp-archive@ietf.org; Sun, 18 Dec 2005 16:59:40 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eo6Gi-0000c4-EU for ccamp-data@psg.com; Sun, 18 Dec 2005 21:40:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_24_48,DNS_FROM_RFC_ABUSE,RCVD_IN_NJABL_PROXY autolearn=no version=3.1.0 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eo6Gh-0000WO-0a for ccamp@ops.ietf.org; Sun, 18 Dec 2005 21:40:35 +0000 Received: from pc6 (1Cust199.tnt21.lnd4.gbr.da.uu.net [62.188.150.199]) by ranger.systems.pipex.net (Postfix) with SMTP id 75DF7E000180; Sun, 18 Dec 2005 21:40:30 +0000 (GMT) Message-ID: <000f01c60412$f1f31540$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , Cc: References: Subject: [what's this?] was Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd) Date: Sat, 17 Dec 2005 18:27:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.3 (+) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: 7bit The use of brackets puzzled me for a while; nothing wrong with it as a convention but I would suggest explaining it in a Conventions section somewhere early on - and yes, I would change from [] to {} or <> or ... Tom Petch ----- Original Message ----- From: To: "Adrian Farrel" Cc: "Kireeti Kompella" ; "Dimitri Papadimitriou" ; Sent: Saturday, December 17, 2005 11:57 AM Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd) > hi adrian > > Thanks for reading. > > > 1. i still don't understand the need for the [ ... ] after each term - > if > > authors could clarify this would be helpful > > Hmm. Well the intention was to provide extra information in a quick way. I > guess we could replace each [...] with a full sentence such as "This term > applies to the control plane." > > I suppose that the RFC editor is going to object to our use of square > brackets :-( > > > [dp] my confusion is where it is for inst. listed in Section 3.7.1 > > "Unidirectional connection (LSP) [data plane]" the term in GMPLS is "Unidirectional LSP" while there is a non-GMPLS term as part of the term the text introduces, i don't see anymore whether the text in brackets refers to as an LSP is a representation of a data plane connection (or whatever term is suitable here) > > [dp] i think in general that the GMPLS term that are listed for clarification should make use of their exact denomination > > > > 2. in general, i don't see why this document meant to clarify GMPLS > > terms for ASON includes ASON specific terms/definitions and interpretations > > hence the need for each "ASON terms" sub-section is unclear > > The intention is not just to clarify the GMPLS terms, but also to provide > a mapping. The full purpose (of making GMPLS comprehensible to ASON > cognoscenti) is aided by the inclusion of corresponding ASON terms. What > we have done, therefore, is split the text into: > - a description of the GMPLS term > - a translation into "equivalent" ASON terms > > Do you have an objection to this? > > [dp] let's take the example of Section 3.7.2 "A GMPLS connection is an ASON network connection" the notion of "ASON network connection" is probably correctly interpreted if you make use of the term "GMPLS connection" > > [dp] the other aspect is also the "equivalence" notion leads to things a "H-LSP is a trail" probably but the whole text coming earlier in the document seem to refer to it as a "link" > > [dp] in brief, what i mean is that i find that for the "GMPLS reader" the reverse reading quite difficult > > > some other specifics > > > > 3. " Node [Control & Data Planes] is a logical combination of a > > transport node and the controller that manages the transport node. > > In early deployments, all control plane and data plane functions > > associated with a transport node were collocated in a node and > > referred to as a Label Switching Router (LSR)." > > > > the second sentence is imho outside the scope of such definition > > Some of the GMPLS RFCs are simplified by the use of "LSR", but it has been > pointed out on numerous occasions that this creates an impression that in > GMPLS there is *always* a tight binding (collocation) between control and > data plane functions. As you know, this impression is contrary to reality. > > A couple of questions back to you. > > Is what it says incorrect? > > [dp] yes, current deployments still make use of what you seem to refer to as history ("in early deployments") > > > Would it help if we had a separate entry for LSR? > > [dp] yes > > > 4. "3.4.1. GMPLS Terms > > > > Label [Control Plane] is an abstraction that provides an identifier > > for use in the control plane in order to identify a transport plane > > resource." > > > > how to interpreet an MPLS label with this definition ? or is MPLS out of > > scope ? > > MPLS is out of scope because there is possible translation to ASON. > > Note, however, we felt it helpful to include "Packet based resource" > > [dp] this is also what i understood but it seems that closing the ring of definition and interpretations is impossible; hence, my suggestion either to have a complete definition of packet-related interpretation or no coverage at all > > > 5. "3.5.1. GMPLS Terms > > > > Unidirectional data link end [Data Plane] is a set of resources of a > > particular layer that belong to the same transport node and could > > be allocated for the transfer of traffic in this layer to the same > > neighbor in the same direction." > > > > what "same transport node" means here ? > > Erm? > > It means "same transport node" :-) > > The intention is to imply that all of the resources in the set belong to > the same transport node. > > Maybe rephrase as: > > > Unidirectional data link end [Data Plane] is a set of resources that > all belong to the same transport node, all are in the same layer, > and that could be allocated for the transfer of traffic in this > layer to the same neighbor in the same direction." > > > [dp] ok (guess you will align subsequent text along the same line) > > > > > 6. " The need for advertisement of adaptation and termination > capabilities > > within GMPLS has been recognized and work is in progress to determine > > how these will be advertised. It is likely that they will be > > advertised as a single combined attribute, or as separate attributes > > of the TE link local end associated with the link interface." > > > > afaik, GMPLS is able to advertize "termination" capabilities - > > Does it? > > > > [dp] yes but implicitly when you have a [LSC,PSC] TE link, meaning one side says in its interface SC descriptor TLV PSC and the other LSC, it implicitly means the "PSC side" terminates LSC and switches at the PSC level > > > It seems to me that it advertizes switching capabilities only. > Termination, like adaptation, is not the same thing as switching > capability. > > Switching capability says how the link terminates, but not whether the > node can terminate data flows. > > Cheers, > Adrian > > > > > > From bmo@4cattlemen.com Sun Dec 18 19:05:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo8WX-0001bE-Co for ccamp-archive@megatron.ietf.org; Sun, 18 Dec 2005 19:05:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10888 for ; Sun, 18 Dec 2005 19:04:02 -0500 (EST) Received: from [69.245.101.120] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eo8Yb-00035Q-9U for ccamp-archive@ietf.org; Sun, 18 Dec 2005 19:07:16 -0500 Message-ID: <000001c60459$c75d0380$0100007f@localhost> From: "Sean Robinson" To: Subject: cheap oem soft shipping //orldwide Date: Sun, 18 Dec 2005 19:04:42 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60459.C75D0380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.5 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60459.C75D0380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 31 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60459.C75D0380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT downloa! d!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 47 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 50 r! eviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 37 reviews)


------=_NextPart_000_0001_01C60459.C75D0380-- From vleybag@addvaluegroup.com.cnri.reston.va.us Sun Dec 18 20:30:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo9ra-0007v9-Cw for ccamp-archive@megatron.ietf.org; Sun, 18 Dec 2005 20:30:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18781 for ; Sun, 18 Dec 2005 20:29:51 -0500 (EST) Received: from user-12ldc84.cable.mindspring.com ([69.86.177.4] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eo9te-0005bB-Ne for ccamp-archive@ietf.org; Sun, 18 Dec 2005 20:33:06 -0500 Message-ID: <000001c60465$d649b300$0100007f@localhost> From: "Jayson Jackson" To: Subject: Software At Low Pr1ce Date: Sun, 18 Dec 2005 17:30:44 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60465.D649B300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60465.D649B300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60465.D649B300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT downloa! d!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 48 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 44 r! eviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 33 reviews)


------=_NextPart_000_0001_01C60465.D649B300-- From texas-holdem739@aromaoilburner.com Sun Dec 18 21:20:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoAdQ-00005W-Sz for ccamp-archive@megatron.ietf.org; Sun, 18 Dec 2005 21:20:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24466 for ; Sun, 18 Dec 2005 21:19:19 -0500 (EST) Received: from s01060011d88d7d7d.vf.shawcable.net ([70.68.110.197] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EoAfX-0007Fq-CB for ccamp-archive@ietf.org; Sun, 18 Dec 2005 21:22:33 -0500 Message-ID: <000001c6046c$bc5f9e80$0100007f@localhost> From: "Liam Murphy" To: Subject: 0EM Software Date: Sun, 18 Dec 2005 18:20:23 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6046C.BC5F9E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6046C.BC5F9E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 44 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 48 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C6046C.BC5F9E80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT downloa! d!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 36 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 31 r! eviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 32 reviews)


------=_NextPart_000_0001_01C6046C.BC5F9E80-- From ljones@2fbtp.com Mon Dec 19 11:07:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoNXy-0007Av-0z for ccamp-archive@megatron.ietf.org; Mon, 19 Dec 2005 11:07:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05455 for ; Mon, 19 Dec 2005 11:06:31 -0500 (EST) Received: from [216.16.218.133] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EoNaC-0002Zl-00 for ccamp-archive@ietf.org; Mon, 19 Dec 2005 11:09:53 -0500 Message-ID: <000001c604e0$4e54bf00$0100007f@localhost> From: "Jonah Nelson" To: Subject: Software At Low Pr1ce Date: Mon, 19 Dec 2005 11:07:28 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C604E0.4E54BF00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C604E0.4E54BF00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C604E0.4E54BF00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

!

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT downl! oad!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 32 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 40! reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 37 reviews)


------=_NextPart_000_0001_01C604E0.4E54BF00-- From owner-ccamp@ops.ietf.org Mon Dec 19 17:21:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoTNy-0005w4-N7 for ccamp-archive@megatron.ietf.org; Mon, 19 Dec 2005 17:21:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24133 for ; Mon, 19 Dec 2005 17:20:36 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoTQF-0008O5-SY for ccamp-archive@ietf.org; Mon, 19 Dec 2005 17:24:01 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoTDH-0003kd-Bj for ccamp-data@psg.com; Mon, 19 Dec 2005 22:10:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoTDE-0003kI-Jq for ccamp@ops.ietf.org; Mon, 19 Dec 2005 22:10:32 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 19 Dec 2005 14:10:32 -0800 X-IronPort-AV: i="3.99,268,1131350400"; d="scan'208,217"; a="242893567:sNHT45041984" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBJM9rqB021205; Mon, 19 Dec 2005 14:10:29 -0800 (PST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Dec 2005 17:10:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C604E9.00BA3618" Subject: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Date: Mon, 19 Dec 2005 17:10:21 -0500 Message-ID: Thread-Topic: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Thread-Index: AcYE6QCTl8IWQZHwQbiGe/Av7cpNAw== From: "Zafar Ali \(zali\)" To: Cc: "Adrian Farrel" , X-OriginalArrivalTime: 19 Dec 2005 22:10:21.0500 (UTC) FILETIME=[00DCCFC0:01C604E9] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 This is a multi-part message in MIME format. ------_=_NextPart_001_01C604E9.00BA3618 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All,=20 =20 It's a bit confusing how one would encode protection object for dedicated 1:1 protection (without traffic duplication) and I thought it deserves a confirmation.=20 =20 I just wanted to confirm that to signal an LSP that is dedicated 1:1 protection, where * Traffic is NOT duplicated at working and protecting LSP-es (i.e., this is not 1+1 protection), * There is NO extra traffic on the protecting LSP (i.e., it's dedicated protection),=20 we are expected to:=20 * Set O-bit in protection object to 1 in signaling protecting LSP, to indicate that the protecting LSP is (only) carrying the normal traffic after protection switching (i.e., It's NOT 1+1 setup). If contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is the intended use.=20 * LSP (Protection Type) Flags to 0x10 =3D 1+1 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is a dedicated protection. If above is not the intended use of O-bit, I am not sure why O-bit is defined (as protection LSP is expected to carry normal traffic after switchover). In which is it expected to use 0x04 =3D 1:N Protection with Extra-Traffic as LSP (Protection Type) Flags?=20 =20 Thanks =20 Regards... Zafar=20 =20 ------_=_NextPart_001_01C604E9.00BA3618 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi = All,=20
 
It's a = bit confusing=20 how one would encode protection object for dedicated 1:1 protection = (without=20 traffic duplication) and I thought it deserves a confirmation.=20
 
I just = wanted to=20 confirm that to signal an LSP that is dedicated 1:1 protection,=20 where
  • Traffic is NOT=20 duplicated at working and protecting LSP-es (i.e., this is not 1+1=20 protection),
  • There = is NO extra=20 traffic on the protecting LSP (i.e., it's dedicated protection),=20
we are = expected to:=20
  • Set = O-bit in=20 protection object to 1 in signaling protecting LSP, to indicate that = the=20 protecting LSP is (only) carrying the normal traffic after = protection=20 switching (i.e., It's NOT 1+1 setup). If contrasting 1:1 with 1+1 is = NOT the=20 intended use of O-bit, what is the intended use.
  • LSP=20 (Protection Type) Flags to 0x10 =3D 1+1 Bi-directional Protection = (for=20 GMPLS optical LSPs). I.e., this is a dedicated=20 protection.
If above=20 is not the intended use of O-bit, I am not sure why O-bit is = defined (as=20 protection LSP is expected to carry normal traffic after switchover). In = which=20 is it expected to use 0x04 =3D 1:N Protection with = Extra-Traffic as=20 LSP (Protection Type) Flags?=20
 
Thanks
 
Regards... Zafar=20
 
------_=_NextPart_001_01C604E9.00BA3618-- From reganme@atuingenierias.com Tue Dec 20 03:41:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eod3f-0006i2-O8 for ccamp-archive@megatron.ietf.org; Tue, 20 Dec 2005 03:41:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27688 for ; Tue, 20 Dec 2005 03:40:15 -0500 (EST) Received: from [85.93.149.58] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eod62-00030w-7e for ccamp-archive@ietf.org; Tue, 20 Dec 2005 03:43:47 -0500 Message-ID: <000001c6056b$25c5d700$0100007f@localhost> From: "Maxwell Clark" To: Subject: cheap oem soft shipping //orldwide Date: Tue, 20 Dec 2005 11:41:02 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6056B.25C5D700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6056B.25C5D700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C6056B.25C5D700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 33 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 41 revie! ws)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 33 reviews)


------=_NextPart_000_0001_01C6056B.25C5D700-- From owner-ccamp@ops.ietf.org Tue Dec 20 08:13:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EohJC-0002eM-R2 for ccamp-archive@megatron.ietf.org; Tue, 20 Dec 2005 08:13:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24455 for ; Tue, 20 Dec 2005 08:12:35 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EohLa-0003JO-Ly for ccamp-archive@ietf.org; Tue, 20 Dec 2005 08:16:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EohBD-0000tO-Us for ccamp-data@psg.com; Tue, 20 Dec 2005 13:05:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EohBC-0000sT-9K; Tue, 20 Dec 2005 13:05:22 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id jBKD59H9026247; Tue, 20 Dec 2005 14:05:15 +0100 In-Reply-To: To: "Zafar Ali \(zali\)" Cc: "Adrian Farrel" , ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Tue, 20 Dec 2005 14:05:12 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 12/20/2005 14:05:15, Serialize complete at 12/20/2005 14:05:15 Content-Type: multipart/alternative; boundary="=_alternative 0047E3A2C12570DD_=" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c This is a multipart message in MIME format. --=_alternative 0047E3A2C12570DD_= Content-Type: text/plain; charset="US-ASCII" zafar, i am not sure to fully understand your question the O-bit is used for 1+1 and 1:1 protection scheme such as to have an indication when a protecting LSP is carrying the "normal" traffic after protection switching (so it applies only in case of 1+1 LSP uni-/bidirectional protection or 1:1 LSP protection) thanks, - dimitri. ps: purpose is not to "contrast" between protection schemes "Zafar Ali \(zali\)" Sent by: owner-ccamp@ops.ietf.org 19/12/2005 23:10 To: cc: "Adrian Farrel" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL Subject: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Hi All, It's a bit confusing how one would encode protection object for dedicated 1:1 protection (without traffic duplication) and I thought it deserves a confirmation. I just wanted to confirm that to signal an LSP that is dedicated 1:1 protection, where Traffic is NOT duplicated at working and protecting LSP-es (i.e., this is not 1+1 protection), There is NO extra traffic on the protecting LSP (i.e., it's dedicated protection), we are expected to: Set O-bit in protection object to 1 in signaling protecting LSP, to indicate that the protecting LSP is (only) carrying the normal traffic after protection switching (i.e., It's NOT 1+1 setup). If contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is the intended use. LSP (Protection Type) Flags to 0x10 = 1+1 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is a dedicated protection. If above is not the intended use of O-bit, I am not sure why O-bit is defined (as protection LSP is expected to carry normal traffic after switchover). In which is it expected to use 0x04 = 1:N Protection with Extra-Traffic as LSP (Protection Type) Flags? Thanks Regards... Zafar --=_alternative 0047E3A2C12570DD_= Content-Type: text/html; charset="US-ASCII"
zafar, i am not sure to fully understand your question

the O-bit is used for 1+1 and 1:1 protection scheme such as to have an indication when a protecting LSP is carrying the "normal" traffic after protection switching (so it applies only in case of 1+1 LSP uni-/bidirectional protection or 1:1 LSP protection)

thanks,
- dimitri.

ps: purpose is not to "contrast" between protection schemes



"Zafar Ali \(zali\)" <zali@cisco.com>
Sent by: owner-ccamp@ops.ietf.org

19/12/2005 23:10

       
        To:        <ccamp@ops.ietf.org>
        cc:        "Adrian Farrel" <adrian@olddog.co.uk>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        Subject:        A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt



Hi All,
 
It's a bit confusing how one would encode protection object for dedicated 1:1 protection (without traffic duplication) and I thought it deserves a confirmation.
 
I just wanted to confirm that to signal an LSP that is dedicated 1:1 protection, where
  • Traffic is NOT duplicated at working and protecting LSP-es (i.e., this is not 1+1 protection),
  • There is NO extra traffic on the protecting LSP (i.e., it's dedicated protection),
we are expected to:
  • Set O-bit in protection object to 1 in signaling protecting LSP, to indicate that the protecting LSP is (only) carrying the normal traffic after protection switching (i.e., It's NOT 1+1 setup). If contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is the intended use.
  • LSP (Protection Type) Flags to 0x10 = 1+1 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is a dedicated protection.
If above is not the intended use of O-bit, I am not sure why O-bit is defined (as protection LSP is expected to carry normal traffic after switchover). In which is it expected to use 0x04 = 1:N Protection with Extra-Traffic as LSP (Protection Type) Flags?
 
Thanks
 
Regards... Zafar
 
--=_alternative 0047E3A2C12570DD_=-- From rattleking@ariatechnologies.com Tue Dec 20 08:36:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eohfb-0007k9-55 for ccamp-archive@megatron.ietf.org; Tue, 20 Dec 2005 08:36:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26684 for ; Tue, 20 Dec 2005 08:35:43 -0500 (EST) Received: from [194.84.189.116] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eohi0-00045V-Mp for ccamp-archive@ietf.org; Tue, 20 Dec 2005 08:39:17 -0500 Message-ID: <000001c60594$6a199d00$0100007f@localhost> From: "Eli Russell" To: Subject: 0EM Software Date: Tue, 20 Dec 2005 16:36:32 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60594.6A199D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60594.6A199D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60594.6A199D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 41 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 46 revie! ws)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 40 reviews)


------=_NextPart_000_0001_01C60594.6A199D00-- From owner-ccamp@ops.ietf.org Tue Dec 20 08:55:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eohy9-0003vb-PA for ccamp-archive@megatron.ietf.org; Tue, 20 Dec 2005 08:55:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29006 for ; Tue, 20 Dec 2005 08:54:54 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eoi0V-0004lR-6G for ccamp-archive@ietf.org; Tue, 20 Dec 2005 08:58:28 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EohpW-0000PD-HN for ccamp-data@psg.com; Tue, 20 Dec 2005 13:47:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,SPF_PASS autolearn=no version=3.1.0 Received: from [213.46.243.25] (helo=amsfep16-int.chello.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EohpU-0000Ou-PD for ccamp@ops.ietf.org; Tue, 20 Dec 2005 13:47:01 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep16-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051220134642.WFOJ23945.amsfep16-int.chello.nl@[192.168.1.4]>; Tue, 20 Dec 2005 14:46:42 +0100 Message-ID: <43A80B3C.3040500@chello.nl> Date: Tue, 20 Dec 2005 14:46:36 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: "Zafar Ali (zali)" , Adrian Farrel , ccamp@ops.ietf.org Subject: Re: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Hi Dimitri, You wrote: > zafar, i am not sure to fully understand your question > > the O-bit is used for 1+1 and 1:1 protection scheme such as to have an > indication when a protecting LSP is carrying the "normal" traffic after > protection switching (so it applies only in case of 1+1 LSP > uni-/bidirectional protection or 1:1 LSP protection) [hvh] in 1+1 "normal" traffic is bridged to both working and protecting LSP, at the receiving end a switch is used to select either the working or protecting LSP. In this case the O-bit you describe above has no meaning. In uni-directional protection switching the switch state is independent of the switch state of the return LSP. In bi-directional protection switching both switches will switch simultaneously (both working LSP or protecting LSP). Cheers, Huub. > thanks, > - dimitri. > > ps: purpose is not to "contrast" between protection schemes > > "Zafar Ali \(zali\)" > Sent by: owner-ccamp@ops.ietf.org > > 19/12/2005 23:10 > > > To: > cc: "Adrian Farrel" , Dimitri > PAPADIMITRIOU/BE/ALCATEL@ALCATEL > Subject: A quick question on > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt > > > > > Hi All, > > It's a bit confusing how one would encode protection object for > dedicated 1:1 protection (without traffic duplication) and I thought it > deserves a confirmation. > > I just wanted to confirm that to signal an LSP that is dedicated 1:1 > protection, where > > * Traffic is NOT duplicated at working and protecting LSP-es (i.e., > this is not 1+1 protection), > * There is NO extra traffic on the protecting LSP (i.e., it's > dedicated protection), > > we are expected to: > > * Set O-bit in protection object to 1 in signaling protecting LSP, > to indicate that the protecting LSP is (only) carrying the normal > traffic after protection switching (i.e., It's NOT 1+1 setup). If > contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is > the intended use. > * LSP (Protection Type) Flags to 0x10 = 1+1 Bi-directional > Protection (for GMPLS optical LSPs). I.e., this is a dedicated > protection. > > If above is not the intended use of O-bit, I am not sure why O-bit is > defined (as protection LSP is expected to carry normal traffic after > switchover). In which is it expected to use 0x04 = 1:N Protection with > Extra-Traffic as LSP (Protection Type) Flags? > > Thanks > > Regards... Zafar > -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Tue Dec 20 10:03:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoj19-0004xA-LI for ccamp-archive@megatron.ietf.org; Tue, 20 Dec 2005 10:03:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08598 for ; Tue, 20 Dec 2005 10:02:03 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eoj3Y-00079m-4a for ccamp-archive@ietf.org; Tue, 20 Dec 2005 10:05:39 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eoio0-0009yC-Lb for ccamp-data@psg.com; Tue, 20 Dec 2005 14:49:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_50_60,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eoinz-0009sZ-Cd; Tue, 20 Dec 2005 14:49:31 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Dec 2005 06:49:30 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,273,1131350400"; d="scan'208,217"; a="17775580:sNHT41125884" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBKEmvUr001368; Tue, 20 Dec 2005 09:49:27 -0500 (EST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Dec 2005 09:49:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C60574.93171DC4" Subject: RE: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Date: Tue, 20 Dec 2005 09:49:26 -0500 Message-ID: Thread-Topic: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Thread-Index: AcYFZjCQkY2kna9LTMGA9hkjtA/q1wADgIYA From: "Zafar Ali \(zali\)" To: Cc: "Adrian Farrel" , , X-OriginalArrivalTime: 20 Dec 2005 14:49:27.0186 (UTC) FILETIME=[93469720:01C60574] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.0 (+) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb This is a multi-part message in MIME format. ------_=_NextPart_001_01C60574.93171DC4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be]=20 Sent: Tuesday, December 20, 2005 8:05 AM To: Zafar Ali (zali) Cc: Adrian Farrel; ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org Subject: Re: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e- signaling-03.txt =09 =09 zafar, i am not sure to fully understand your question=20 =09 the O-bit is used for 1+1 and 1:1 protection scheme such as to have an indication when a protecting LSP is carrying the "normal" traffic after protection switching (so it applies only in case of 1+1 LSP uni-/bidirectional protection or 1:1 LSP protection) . =20 Dimitri,=20 =20 More specifically, my question was mainly on what "LSP (Protection Type) Flags" to use for, dedicated 1:1 protection, where=20 * Traffic is NOT duplicated at working and protecting LSP-es (i.e., this is not 1+1 protection),=20 * There is NO extra traffic on the protecting LSP (i.e., it's dedicated protection),=20 In this case there is NO duplication of the traffic on the backup resource (it's NOT 1+1). There is also NO extra traffic that protection resources carry.=20 =20 Thanks =20 Regards... Zafar=20 =20 =20 =09 thanks,=20 - dimitri.=20 =09 ps: purpose is not to "contrast" between protection schemes=20 =09 =09 =09 =09 "Zafar Ali \(zali\)" =20 Sent by: owner-ccamp@ops.ietf.org=20 19/12/2005 23:10=20 =20 To: =20 cc: "Adrian Farrel" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL=20 Subject: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e- signaling-03.txt Hi All,=20 =20 It's a bit confusing how one would encode protection object for dedicated 1:1 protection (without traffic duplication) and I thought it deserves a confirmation.=20 =20 I just wanted to confirm that to signal an LSP that is dedicated 1:1 protection, where=20 * Traffic is NOT duplicated at working and protecting LSP-es (i.e., this is not 1+1 protection),=20 * There is NO extra traffic on the protecting LSP (i.e., it's dedicated protection),=20 we are expected to:=20 * Set O-bit in protection object to 1 in signaling protecting LSP, to indicate that the protecting LSP is (only) carrying the normal traffic after protection switching (i.e., It's NOT 1+1 setup). If contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is the intended use.=20 * LSP (Protection Type) Flags to 0x10 =3D 1+1 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is a dedicated protection. If above is not the intended use of O-bit, I am not sure why O-bit is defined (as protection LSP is expected to carry normal traffic after switchover). In which is it expected to use 0x04 =3D 1:N = Protection with Extra-Traffic as LSP (Protection Type) Flags?=20 =20 Thanks=20 =20 Regards... Zafar=20 =20 =09 ------_=_NextPart_001_01C60574.93171DC4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 


From: = Dimitri.Papadimitriou@alcatel.be=20 [mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Tuesday, = December=20 20, 2005 8:05 AM
To: Zafar Ali (zali)
Cc: Adrian = Farrel;=20 ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
Subject: Re: A = quick=20 question on=20 = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-s= ignaling-03.txt


zafar, i am not sure to = fully=20 understand your question

the=20 O-bit is used for 1+1 and 1:1 protection scheme such as to have an = indication=20 when a protecting LSP is carrying the "normal" traffic after = protection=20 switching (so it applies only in case of 1+1 LSP uni-/bidirectional = protection=20 or 1:1 LSP protection)  .
 
Dimitri,
 
More=20 specifically, my question was mainly on what "LSP (Protection = Type)=20 Flags" to use for, dedicated 1:1 protection, where =
  • Traffic is NOT = duplicated at working=20 and protecting LSP-es (i.e., this is not 1+1 protection),
  • There is NO extra = traffic on the=20 protecting LSP (i.e., it's dedicated protection), =
In=20 this case there is NO duplication of the traffic on the backup resource = (it's=20 NOT 1+1). There is also NO extra traffic that protection resources = carry.=20
 
Thanks
 
Regards... Zafar
 
 

thanks,
-=20 dimitri.

ps: = purpose is not to=20 "contrast" between protection schemes



"Zafar Ali \(zali\)"=20 <zali@cisco.com>
Sent=20 by: owner-ccamp@ops.ietf.org=20

19/12/2005 23:10

        =
        To: =    =20    <ccamp@ops.ietf.org>
        cc:      =20  "Adrian Farrel" <adrian@olddog.co.uk>, Dimitri=20 PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        Subject:     =    A=20 quick question on=20 = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-s= ignaling-03.txt



Hi All,
  =
It's a bit confusing how one would encode = protection object=20 for dedicated 1:1 protection (without traffic duplication) and I = thought it=20 deserves a confirmation.
  =
I just wanted to confirm that to signal an LSP = that is=20 dedicated 1:1 protection, where=20
  • Traffic is NOT duplicated at working = and=20 protecting LSP-es (i.e., this is not 1+1 protection),=20
  • There is NO extra traffic on the = protecting LSP=20 (i.e., it's dedicated protection),
we=20 are expected to:
  • Set O-bit in protection object to 1 = in signaling=20 protecting LSP, to indicate that the protecting LSP is (only) = carrying the=20 normal traffic after protection switching (i.e., It's NOT 1+1 = setup). If=20 contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is = the=20 intended use.
  • LSP (Protection Type) Flags to 0x10 = =3D 1+1=20 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is a=20 dedicated protection.
If = above is not=20 the intended use of O-bit, I am not sure why O-bit is defined (as = protection=20 LSP is expected to carry normal traffic after switchover). In which is = it=20 expected to use 0x04 =3D 1:N Protection with Extra-Traffic as LSP = (Protection=20 Type) Flags?
 
Thanks
 
Regards... Zafar
 =20
------_=_NextPart_001_01C60574.93171DC4-- From owner-ccamp@ops.ietf.org Tue Dec 20 10:18:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EojFe-00080d-Qx for ccamp-archive@megatron.ietf.org; Tue, 20 Dec 2005 10:18:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10754 for ; Tue, 20 Dec 2005 10:17:02 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EojI4-0007lp-Vk for ccamp-archive@ietf.org; Tue, 20 Dec 2005 10:20:38 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eoj5t-000L3H-7Y for ccamp-data@psg.com; Tue, 20 Dec 2005 15:08:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eoj5s-000L1F-4y; Tue, 20 Dec 2005 15:08:00 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id jBKF7q95015870; Tue, 20 Dec 2005 16:07:52 +0100 In-Reply-To: To: "Zafar Ali \(zali\)" Cc: "Adrian Farrel" , ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: RE: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Tue, 20 Dec 2005 16:07:50 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 12/20/2005 16:07:52, Serialize complete at 12/20/2005 16:07:52 Content-Type: multipart/alternative; boundary="=_alternative 00531DD8C12570DD_=" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb This is a multipart message in MIME format. --=_alternative 00531DD8C12570DD_= Content-Type: text/plain; charset="US-ASCII" zafar > More specifically, my question was mainly on what > "LSP (Protection Type) Flags" to use for, dedicated > 1:1 protection, where > - Traffic is NOT duplicated at working and protecting > LSP-es (i.e., this is not 1+1 protection), > - There is NO extra traffic on the protecting LSP > (i.e., it's dedicated protection), > In this case there is NO duplication of the traffic > on the backup resource (it's NOT 1+1). There is also > NO extra traffic that protection resources carry. as pointed into the document for the 1:1 LSP protection: "Although the resources for the protecting LSP are pre-allocated, preemptable traffic may be carried end-to-end using this LSP. Thus, the protecting LSP is capable of carrying extra-traffic with the caveat that this traffic will be preempted if the working LSP fails." hope this clarifies (i.e. there is no specific flag when there is no extra-traffic) > Thanks > > Regards... Zafar thanks, - dimitri. ps: purpose is not to "contrast" between protection schemes "Zafar Ali \(zali\)" Sent by: owner-ccamp@ops.ietf.org 19/12/2005 23:10 To: cc: "Adrian Farrel" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL Subject: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Hi All, It's a bit confusing how one would encode protection object for dedicated 1:1 protection (without traffic duplication) and I thought it deserves a confirmation. I just wanted to confirm that to signal an LSP that is dedicated 1:1 protection, where Traffic is NOT duplicated at working and protecting LSP-es (i.e., this is not 1+1 protection), There is NO extra traffic on the protecting LSP (i.e., it's dedicated protection), we are expected to: Set O-bit in protection object to 1 in signaling protecting LSP, to indicate that the protecting LSP is (only) carrying the normal traffic after protection switching (i.e., It's NOT 1+1 setup). If contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is the intended use. LSP (Protection Type) Flags to 0x10 = 1+1 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is a dedicated protection. If above is not the intended use of O-bit, I am not sure why O-bit is defined (as protection LSP is expected to carry normal traffic after switchover). In which is it expected to use 0x04 = 1:N Protection with Extra-Traffic as LSP (Protection Type) Flags? Thanks Regards... Zafar --=_alternative 00531DD8C12570DD_= Content-Type: text/html; charset="US-ASCII"


zafar
 
> More specifically, my question was mainly on what
> "LSP (Protection Type) Flags" to use for, dedicated
> 1:1 protection, where
> - Traffic is NOT duplicated at working and protecting
>   LSP-es (i.e., this is not 1+1 protection),
> - There is NO extra traffic on the protecting LSP
>   (i.e., it's dedicated protection),
> In this case there is NO duplication of the traffic
> on the backup resource (it's NOT 1+1). There is also
> NO extra traffic that protection resources carry.
 
as pointed into the document for the 1:1 LSP protection:

   "Although the resources for the protecting LSP are pre-allocated,
  preemptable traffic may be carried end-to-end using this LSP. Thus,
  the protecting LSP is capable of carrying extra-traffic with the
  caveat that this traffic will be preempted if the working LSP fails."  


hope this clarifies (i.e. there is no specific flag when there is no extra-traffic)

> Thanks
>
> Regards... Zafar
 
 

thanks,

- dimitri.


ps: purpose is not to "contrast" between protection schemes



"Zafar Ali \(zali\)" <zali@cisco.com>
Sent by: owner-ccamp@ops.ietf.org

19/12/2005 23:10

       
       To:        <ccamp@ops.ietf.org>

       cc:        "Adrian Farrel" <adrian@olddog.co.uk>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL

       Subject:        A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt




Hi All,

 

It's a bit confusing how one would encode protection object for dedicated 1:1 protection (without traffic duplication) and I thought it deserves a confirmation.

 

I just wanted to confirm that to signal an LSP that is dedicated 1:1 protection, where
  • Traffic is NOT duplicated at working and protecting LSP-es (i.e., this is not 1+1 protection),
  • There is NO extra traffic on the protecting LSP (i.e., it's dedicated protection),
we are expected to:
  • Set O-bit in protection object to 1 in signaling protecting LSP, to indicate that the protecting LSP is (only) carrying the normal traffic after protection switching (i.e., It's NOT 1+1 setup). If contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is the intended use.
  • LSP (Protection Type) Flags to 0x10 = 1+1 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is a dedicated protection.
If above is not the intended use of O-bit, I am not sure why O-bit is defined (as protection LSP is expected to carry normal traffic after switchover). In which is it expected to use 0x04 = 1:N Protection with Extra-Traffic as LSP (Protection Type) Flags?
 

Thanks

 

Regards... Zafar

 

--=_alternative 00531DD8C12570DD_=-- From owner-ccamp@ops.ietf.org Tue Dec 20 10:58:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eojso-0001UA-F9 for ccamp-archive@megatron.ietf.org; Tue, 20 Dec 2005 10:58:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16191 for ; Tue, 20 Dec 2005 10:57:30 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EojvA-0000qA-Vc for ccamp-archive@ietf.org; Tue, 20 Dec 2005 11:01:06 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eojcq-0005ZF-Al for ccamp-data@psg.com; Tue, 20 Dec 2005 15:42:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.0 Received: from [216.82.241.195] (helo=mail121.messagelabs.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eojco-0005Mh-3c for ccamp@ops.ietf.org; Tue, 20 Dec 2005 15:42:03 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1135093129!9287470!52 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 1444 invoked from network); 20 Dec 2005 15:41:49 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-121.messagelabs.com with SMTP; 20 Dec 2005 15:41:49 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 43A3035900059DB1; Tue, 20 Dec 2005 10:41:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Date: Tue, 20 Dec 2005 09:41:48 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0B407837@OCCLUST04EVS1.ugd.att.com> Thread-Topic: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Thread-Index: AcYFa/jBhNOjrJLOQwKRKwgHrNzmjQADFLCQ From: "Brungard, Deborah A, ALABS" To: "Huub van Helvoort" , Cc: "Zafar Ali \(zali\)" , "Adrian Farrel" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Hi Huub, The 0-bit is a control plane parameter, it's not controlling data plane operations, it's an indication reflecting the data plane operations. As you note, traffic is bridged. Operationally though GMPLS needs to know the administrative state for each. Section 3 (Introduction) has the data plane definitions which you are referencing below. And the other recovery RFCs provide much more detail on the ITU Rec'ds definitions. Thanks, Deborah -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Huub van Helvoort Sent: Tuesday, December 20, 2005 8:47 AM To: Dimitri.Papadimitriou@alcatel.be Cc: Zafar Ali (zali); Adrian Farrel; ccamp@ops.ietf.org Subject: Re: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e- signaling-03.txt Hi Dimitri, You wrote: > zafar, i am not sure to fully understand your question >=20 > the O-bit is used for 1+1 and 1:1 protection scheme such as to have an > indication when a protecting LSP is carrying the "normal" traffic after=20 > protection switching (so it applies only in case of 1+1 LSP=20 > uni-/bidirectional protection or 1:1 LSP protection) [hvh] in 1+1 "normal" traffic is bridged to both working and protecting LSP, at the receiving end a switch is used to select either the working or protecting LSP. In this case the O-bit you describe above has no meaning. In uni-directional protection switching the switch state is independent of the switch state of the return LSP. In bi-directional protection switching both switches will switch simultaneously (both working LSP or protecting LSP). Cheers, Huub. > thanks, > - dimitri. >=20 > ps: purpose is not to "contrast" between protection schemes >=20 > "Zafar Ali \(zali\)" > Sent by: owner-ccamp@ops.ietf.org >=20 > 19/12/2005 23:10 >=20 > =20 > To: > cc: "Adrian Farrel" , Dimitri=20 > PAPADIMITRIOU/BE/ALCATEL@ALCATEL > Subject: A quick question on=20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e- signaling-03.txt >=20 >=20 >=20 >=20 > Hi All, > =20 > It's a bit confusing how one would encode protection object for=20 > dedicated 1:1 protection (without traffic duplication) and I thought it=20 > deserves a confirmation. > =20 > I just wanted to confirm that to signal an LSP that is dedicated 1:1=20 > protection, where >=20 > * Traffic is NOT duplicated at working and protecting LSP-es (i.e., > this is not 1+1 protection), > * There is NO extra traffic on the protecting LSP (i.e., it's > dedicated protection),=20 >=20 > we are expected to: >=20 > * Set O-bit in protection object to 1 in signaling protecting LSP, > to indicate that the protecting LSP is (only) carrying the normal > traffic after protection switching (i.e., It's NOT 1+1 setup). If > contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is > the intended use. > * LSP (Protection Type) Flags to 0x10 =3D 1+1 Bi-directional > Protection (for GMPLS optical LSPs). I.e., this is a dedicated > protection. >=20 > If above is not the intended use of O-bit, I am not sure why O-bit is=20 > defined (as protection LSP is expected to carry normal traffic after=20 > switchover). In which is it expected to use 0x04 =3D 1:N Protection = with > Extra-Traffic as LSP (Protection Type) Flags? > =20 > Thanks > =20 > Regards... Zafar > =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://members.chello.nl/hhelvoort/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Tue Dec 20 11:32:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EokPA-0002og-EL for ccamp-archive@megatron.ietf.org; Tue, 20 Dec 2005 11:32:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21454 for ; Tue, 20 Dec 2005 11:30:57 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EokRX-0002Fx-Oq for ccamp-archive@ietf.org; Tue, 20 Dec 2005 11:34:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eok9x-000IXZ-I6 for ccamp-data@psg.com; Tue, 20 Dec 2005 16:16:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eok9v-000IXA-T7; Tue, 20 Dec 2005 16:16:16 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id EE4E0AC25; Tue, 20 Dec 2005 11:14:22 -0500 (EST) Message-ID: <073f01c60580$b32866c0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Zafar Ali (zali)" , Cc: "Adrian Farrel" , , References: Subject: Re: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Date: Tue, 20 Dec 2005 11:16:14 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_073C_01C60556.CA16DC60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.0 (+) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 This is a multi-part message in MIME format. ------=_NextPart_000_073C_01C60556.CA16DC60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zafar, I have a question to you. Why would you need a dedicated 1:1 protection = without allowing the protection LSP to be used for carrying extra = traffic? If the resources of the protection LSP are allocated anyway and = the LSP is totally dedicated to protect the working LSP you might as = well bridge the traffic on the protection LSP with an immediate benefit = of much better recovery time. The whole point of 1:1 protection is to = allow using resources of the protection LSP for something else - = carrying extra traffic in case of dedicated 1:1 or extra traffic and = other protection LSPs in cases of shared 1:1 protection. The other thing to note is that extra traffic does not have to be = carried all the time or any time for that matter - 1:1 protected service = is provisioned in such a way that extra traffic could be carried over = idle protection LSP should such need arise in the future. Thus, Dimitri = is right: O-bit is set to zero for the protection LSP to signal the fact = that originally the protection LSP is going to be idle in a sense that = it will not be carrying the"normal" (read protected traffic) and is = ready to carry extra traffic. Cheers and Happy Holidays, Igor ----- Original Message -----=20 From: Zafar Ali (zali)=20 To: Dimitri.Papadimitriou@alcatel.be=20 Cc: Adrian Farrel ; ccamp@ops.ietf.org ; owner-ccamp@ops.ietf.org=20 Sent: Tuesday, December 20, 2005 9:49 AM Subject: RE: A quick question on = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-s= ignaling-03.txt -------------------------------------------------------------------------= --- From: Dimitri.Papadimitriou@alcatel.be = [mailto:Dimitri.Papadimitriou@alcatel.be]=20 Sent: Tuesday, December 20, 2005 8:05 AM To: Zafar Ali (zali) Cc: Adrian Farrel; ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org Subject: Re: A quick question on = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-s= ignaling-03.txt zafar, i am not sure to fully understand your question=20 the O-bit is used for 1+1 and 1:1 protection scheme such as to have = an indication when a protecting LSP is carrying the "normal" traffic = after protection switching (so it applies only in case of 1+1 LSP = uni-/bidirectional protection or 1:1 LSP protection) . Dimitri,=20 More specifically, my question was mainly on what "LSP (Protection = Type) Flags" to use for, dedicated 1:1 protection, where=20 a.. Traffic is NOT duplicated at working and protecting LSP-es = (i.e., this is not 1+1 protection),=20 b.. There is NO extra traffic on the protecting LSP (i.e., it's = dedicated protection),=20 In this case there is NO duplication of the traffic on the backup = resource (it's NOT 1+1). There is also NO extra traffic that protection = resources carry.=20 Thanks Regards... Zafar=20 thanks,=20 - dimitri.=20 ps: purpose is not to "contrast" between protection schemes=20 "Zafar Ali \(zali\)" =20 Sent by: owner-ccamp@ops.ietf.org=20 19/12/2005 23:10=20 =20 To: =20 cc: "Adrian Farrel" , = Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL=20 Subject: A quick question on = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-s= ignaling-03.txt=20 Hi All,=20 =20 It's a bit confusing how one would encode protection object for = dedicated 1:1 protection (without traffic duplication) and I thought it = deserves a confirmation.=20 =20 I just wanted to confirm that to signal an LSP that is dedicated 1:1 = protection, where=20 a.. Traffic is NOT duplicated at working and protecting LSP-es = (i.e., this is not 1+1 protection),=20 b.. There is NO extra traffic on the protecting LSP (i.e., it's = dedicated protection),=20 we are expected to:=20 a.. Set O-bit in protection object to 1 in signaling protecting = LSP, to indicate that the protecting LSP is (only) carrying the normal = traffic after protection switching (i.e., It's NOT 1+1 setup). If = contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is the = intended use.=20 b.. LSP (Protection Type) Flags to 0x10 =3D 1+1 Bi-directional = Protection (for GMPLS optical LSPs). I.e., this is a dedicated = protection. If above is not the intended use of O-bit, I am not sure why O-bit = is defined (as protection LSP is expected to carry normal traffic after = switchover). In which is it expected to use 0x04 =3D 1:N Protection with = Extra-Traffic as LSP (Protection Type) Flags?=20 =20 Thanks=20 =20 Regards... Zafar=20 =20 ------=_NextPart_000_073C_01C60556.CA16DC60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Zafar,
 
I have a question to you. Why would you = need a=20 dedicated 1:1 protection without allowing the protection LSP to be used = for=20 carrying extra traffic? If the resources of the protection LSP are = allocated=20 anyway and the LSP is totally dedicated to protect the working LSP you = might as=20 well bridge the traffic on the protection LSP with an immediate benefit = of much=20 better recovery time. The whole point of 1:1 protection is to allow = using=20 resources of the protection LSP for something else - carrying extra = traffic in=20 case of dedicated 1:1 or extra traffic and other protection LSPs in = cases of=20 shared 1:1 protection.
 
The other thing to note is that extra = traffic does=20 not have to be carried all the time or any time for that matter - 1:1 = protected=20 service is provisioned in such a way that extra traffic could be carried = over=20 idle protection LSP should such need arise in the future. Thus, Dimitri = is=20 right: O-bit is set to zero for the protection LSP to signal the fact = that=20 originally the protection LSP is going to be idle in a sense that it = will not be=20 carrying the"normal" (read protected traffic) and is ready to carry = extra=20 traffic.
 
Cheers and Happy Holidays,
Igor
----- Original Message -----
From:=20 Zafar Ali = (zali)=20
To: Dimitri.Papadimitriou@al= catel.be=20
Cc: Adrian Farrel ; ccamp@ops.ietf.org ; owner-ccamp@ops.ietf.org =
Sent: Tuesday, December 20, = 2005 9:49=20 AM
Subject: RE: A quick question = on http://www.ietf.org/internet-drafts/draft-ietf-c= camp-gmpls-recovery-e2e-signaling-03.txt

 


From: Dimitri.Papadimitriou@al= catel.be=20 [mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Tuesday, = December=20 20, 2005 8:05 AM
To: Zafar Ali (zali)
Cc: Adrian = Farrel;=20 ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
= Subject:=20 Re: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-c= camp-gmpls-recovery-e2e-signaling-03.txt


zafar, i am not sure to = fully=20 understand your question

the=20 O-bit is used for 1+1 and 1:1 protection scheme such as to have an=20 indication when a protecting LSP is carrying the "normal" traffic = after=20 protection switching (so it applies only in case of 1+1 LSP=20 uni-/bidirectional protection or 1:1 LSP = protection)  .
 
Dimitri,
 
More=20 specifically, my question was mainly on what "LSP (Protection = Type)=20 Flags" to use for, dedicated 1:1 protection, where =
  • Traffic is NOT = duplicated at=20 working and protecting LSP-es (i.e., this is not 1+1 protection), =
  • There is NO extra = traffic on the=20 protecting LSP (i.e., it's dedicated protection),=20
In=20 this case there is NO duplication of the traffic on the backup = resource (it's=20 NOT 1+1). There is also NO extra traffic that protection resources = carry.=20
 
Thanks
 
Regards... Zafar
 


thanks,
- = dimitri.=20

ps: purpose is not to = "contrast"=20 between protection schemes



"Zafar Ali \(zali\)"=20 <zali@cisco.com>
Sent by: owner-ccamp@ops.ietf.org=20

19/12/2005 23:10 =

       =20
    =    =20 To:       =  <ccamp@ops.ietf.org>=20
      =   cc:=20        "Adrian Farrel"=20 <adrian@olddog.co.uk>, Dimitri=20 PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        Subject:     =  =20  A quick question on=20 = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-s= ignaling-03.txt



Hi All,
 
It's a bit confusing how one would encode = protection=20 object for dedicated 1:1 protection (without traffic duplication) = and I=20 thought it deserves a confirmation.
 =20
I just wanted to confirm that to = signal an LSP=20 that is dedicated 1:1 protection, where=20
  • Traffic is NOT duplicated at = working and=20 protecting LSP-es (i.e., this is not 1+1 protection),=20
  • There is NO extra traffic on the = protecting=20 LSP (i.e., it's dedicated protection),
we are expected to:
  • Set O-bit in protection object to = 1 in=20 signaling protecting LSP, to indicate that the protecting LSP is = (only)=20 carrying the normal traffic after protection switching (i.e., It's = NOT 1+1=20 setup). If contrasting 1:1 with 1+1 is NOT the intended use of = O-bit, what=20 is the intended use.
  • LSP (Protection Type) Flags to = 0x10 =3D 1+1=20 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is = a=20 dedicated protection.
If above is=20 not the intended use of O-bit, I am not sure why O-bit is defined = (as=20 protection LSP is expected to carry normal traffic after = switchover). In=20 which is it expected to use 0x04 =3D 1:N Protection with = Extra-Traffic as LSP=20 (Protection Type) Flags?
  =
Thanks
  =
Regards... Zafar
 =20
------=_NextPart_000_073C_01C60556.CA16DC60-- From owner-ccamp@ops.ietf.org Tue Dec 20 16:00:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EooaW-0002AE-9j for ccamp-archive@megatron.ietf.org; Tue, 20 Dec 2005 16:00:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07576 for ; Tue, 20 Dec 2005 15:58:56 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eoocz-0006ff-MC for ccamp-archive@ietf.org; Tue, 20 Dec 2005 16:02:35 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EooQt-000JEe-Ld for ccamp-data@psg.com; Tue, 20 Dec 2005 20:50:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EooQs-000JE5-N9 for ccamp@ops.ietf.org; Tue, 20 Dec 2005 20:50:02 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EooQr-0008RL-J9; Tue, 20 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-rfc3946bis-01.txt Message-Id: Date: Tue, 20 Dec 2005 15:50:01 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-rfc3946bis-01.txt Pages : 24 Date : 2005-12-20 This document provides minor clarification to RFC 3946. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc3946bis-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-rfc3946bis-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-rfc3946bis-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-12-20123224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rfc3946bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rfc3946bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-20123224.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Tue Dec 20 17:01:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EopYK-0000cM-Pa for ccamp-archive@megatron.ietf.org; Tue, 20 Dec 2005 17:01:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04333 for ; Tue, 20 Dec 2005 17:00:44 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eopak-0007f0-It for ccamp-archive@ietf.org; Tue, 20 Dec 2005 17:04:24 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EopQU-000NKV-TD for ccamp-data@psg.com; Tue, 20 Dec 2005 21:53:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EopQT-000NKF-VY for ccamp@ops.ietf.org; Tue, 20 Dec 2005 21:53:42 +0000 Received: from du-069-0183.access.clara.net ([217.158.132.183] helo=Puppy) by relay2.mail.uk.clara.net with esmtp (Exim 4.50) id 1EopQS-0009rP-77 for ccamp@ops.ietf.org; Tue, 20 Dec 2005 21:53:41 +0000 Message-ID: <05d301c605b0$56be68a0$99849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: Subject: Working Group Last Call draft-ietf-ccamp-rfc3946bis-01.txt Date: Tue, 20 Dec 2005 21:55: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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Hi, This begins a working group last call on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc3946bis-01.txt As we have been discussing on the list, the changes are very small (if you need to see exactly what they are, you'll have to go back to the 00 revision that had markers in place. We *can* accept other changes to the RFC at this stage, although I might express some surprise that you have left any suggestions until this late stage. The last call will end on Friday 6th January at 12.00 GMT. (A couple of extra days to get you over the festive break.) Thanks, Adrian From dsd2@anthonyweb.com Wed Dec 21 13:06:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep8Lv-0003lo-7e for ccamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 13:06:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24711 for ; Wed, 21 Dec 2005 13:05:11 -0500 (EST) Received: from [85.206.86.248] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ep8Oa-0007jb-2S for ccamp-archive@ietf.org; Wed, 21 Dec 2005 13:09:01 -0500 Message-ID: <000001c60683$08842c00$0100007f@localhost> From: "Ramon Campbell" To: Subject: Buy OEM Software Date: Wed, 21 Dec 2005 20:06:13 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60683.08842C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60683.08842C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 48 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60683.08842C00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   ! ; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 45 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 49 revi! ews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 43 reviews)


------=_NextPart_000_0001_01C60683.08842C00-- From owner-ccamp@ops.ietf.org Wed Dec 21 21:55:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpGbe-0000rZ-DE for ccamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 21:55:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15855 for ; Wed, 21 Dec 2005 21:53:57 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpGeG-0000kq-60 for ccamp-archive@ietf.org; Wed, 21 Dec 2005 21:57:52 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpGUd-000Cry-06 for ccamp-data@psg.com; Thu, 22 Dec 2005 02:47:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpGUc-000Crm-DI for ccamp@ops.ietf.org; Thu, 22 Dec 2005 02:47:46 +0000 Received: from du-069-0102.access.clara.net ([217.158.132.102] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1EpGUb-000DGS-G8 for ccamp@ops.ietf.org; Thu, 22 Dec 2005 02:47:45 +0000 Message-ID: <098a01c606a2$97e4f130$99849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: VCAT/LCAS Date: Thu, 22 Dec 2005 00:27:09 -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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Hi, In Vancouver there was clear support in the room that a group wanted to work on this topic. draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and provides a fair summary of the problem space in sections 1 and 2. The draft fades out in section 3 "Possible Extensions to GMPLS to support additional VCAT/LCAS scenarios" as it starts to identify the specific requirements to extend GMPLS protocols. I suggest that the authors should: - gather a group of interest parties to work on this - keep in mind that protocol extensions are done in support of implementations (that is, not for completeness, but because someone is building product) - beef up section 3 to list the requirements - write a new section for the solutions I think that we will be able to adopt this work as a WG draft, but we should not do that until we have seen a first stab at the protocol extensions. If the authors could let us know their progress and plans, that would be great. Thanks, Adrian From owner-ccamp@ops.ietf.org Wed Dec 21 21:56:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpGcr-0001Ls-QO for ccamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 21:56:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16006 for ; Wed, 21 Dec 2005 21:55:13 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpGfb-0000oD-Vi for ccamp-archive@ietf.org; Wed, 21 Dec 2005 21:59:08 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpGUa-000Cre-3e for ccamp-data@psg.com; Thu, 22 Dec 2005 02:47:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.0 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpGUZ-000CrQ-6N for ccamp@ops.ietf.org; Thu, 22 Dec 2005 02:47:43 +0000 Received: from du-069-0102.access.clara.net ([217.158.132.102] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1EpGUX-000DGS-HJ for ccamp@ops.ietf.org; Thu, 22 Dec 2005 02:47:42 +0000 Message-ID: <098801c606a2$95ba4900$99849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Opinion on WG drafts for Multi-region/layer networks Date: Wed, 21 Dec 2005 21:55:41 -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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hi, We have a charter milestone to start WG work on a Requirements I-D for MRN/MLN, and also an Evaluation I-D to examine how the current protocols shape up to the challenge. There are two appropriate I-Ds that have been around for a while. draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt draft-leroux-ccamp-gmpls-mrn-eval-02.txt I propose that we make these WG documents and then give them a thorough review and edit. Opinions please. Yes or no will suffice, but reasons are always nice. Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Dec 22 03:07:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpLTZ-0004tv-9X for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 03:07:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11612 for ; Thu, 22 Dec 2005 03:05:56 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpLWJ-0000uo-Ri for ccamp-archive@ietf.org; Thu, 22 Dec 2005 03:09:54 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpLKz-000BPB-Vq for ccamp-data@psg.com; Thu, 22 Dec 2005 07:58:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpLKy-000BOm-VP; Thu, 22 Dec 2005 07:58:09 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id jBM7w4lf020683; Thu, 22 Dec 2005 08:58:04 +0100 In-Reply-To: <098801c606a2$95ba4900$99849ed9@Puppy> To: "Adrian Farrel" Cc: ccamp@ops.ietf.org, dpapadimitriou@psg.com Subject: Re: Opinion on WG drafts for Multi-region/layer networks MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 22 Dec 2005 08:58:02 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 12/22/2005 08:58:04, Serialize complete at 12/22/2005 08:58:04 Content-Type: multipart/alternative; boundary="=_alternative 002BC460C12570DF_=" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 This is a multipart message in MIME format. --=_alternative 002BC460C12570DF_= Content-Type: text/plain; charset="US-ASCII" agreed - with the increase trend in building multi-layer capable devices/networks this becomes a sensible topic to be covered by the WG; now, these documents are more than probably not perfect (note: perfection is not obtained when there is nothing to be added but when there is nothing to be removed) but imho are in reasonable shape and they certainly deserve attention from the WG in order to shape subsequent GMPLS mechanisms and operations for such environments "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org 21/12/2005 22:55 Please respond to "Adrian Farrel" To: cc: Subject: Opinion on WG drafts for Multi-region/layer networks Hi, We have a charter milestone to start WG work on a Requirements I-D for MRN/MLN, and also an Evaluation I-D to examine how the current protocols shape up to the challenge. There are two appropriate I-Ds that have been around for a while. draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt draft-leroux-ccamp-gmpls-mrn-eval-02.txt I propose that we make these WG documents and then give them a thorough review and edit. Opinions please. Yes or no will suffice, but reasons are always nice. Thanks, Adrian --=_alternative 002BC460C12570DF_= Content-Type: text/html; charset="US-ASCII"
agreed -

with the increase trend in building multi-layer capable devices/networks this becomes a sensible topic to be covered by the WG;

now, these documents are more than probably not perfect (note: perfection is not obtained when there is nothing to be added but when there is nothing to be removed) but imho are in reasonable shape and they certainly deserve attention from the WG in order to shape subsequent GMPLS mechanisms and operations for such environments




"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org

21/12/2005 22:55
Please respond to "Adrian Farrel"

       
        To:        <ccamp@ops.ietf.org>
        cc:        
        Subject:        Opinion on WG drafts for Multi-region/layer networks



Hi,

We have a charter milestone to start WG work on a Requirements I-D for
MRN/MLN, and also an Evaluation I-D to examine how the current protocols
shape up to the challenge.

There are two appropriate I-Ds that have been around for a while.

draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt
draft-leroux-ccamp-gmpls-mrn-eval-02.txt

I propose that we make these WG documents and then give them a thorough
review and edit.

Opinions please.

Yes or no will suffice, but reasons are always nice.

Thanks,
Adrian



--=_alternative 002BC460C12570DF_=-- From owner-ccamp@ops.ietf.org Thu Dec 22 07:42:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpPln-0007Vl-O4 for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 07:42:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04867 for ; Thu, 22 Dec 2005 07:41:01 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpPoU-0000at-IH for ccamp-archive@ietf.org; Thu, 22 Dec 2005 07:45:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpPZN-0008JB-PF for ccamp-data@psg.com; Thu, 22 Dec 2005 12:29:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpPZM-0008Iw-EQ for ccamp@ops.ietf.org; Thu, 22 Dec 2005 12:29:16 +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 jBMCTFYt004221 for ; Thu, 22 Dec 2005 21:29:15 +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 jBMCTEeV029835 for ; Thu, 22 Dec 2005 21:29:14 +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 jBMCTDsx012787 for ; Thu, 22 Dec 2005 21:29:13 +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 jBMCTDeQ015537 for ; Thu, 22 Dec 2005 21:29:13 +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 jBMCTC8d017080 for ; Thu, 22 Dec 2005 21:29:12 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf.m.ecl.ntt.co.jp [129.60.5.230]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBMCTCmq017076 for ; Thu, 22 Dec 2005 21:29:12 +0900 (JST) Received: from TAKEDA_PANA.lab.ntt.co.jp ([129.60.15.201]) by imf.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id jBMCTBgl026867 for ; Thu, 22 Dec 2005 21:29:11 +0900 (JST) Message-Id: <5.1.1.9.2.20051222205630.0697e008@imf.m.ecl.ntt.co.jp> X-Sender: tt043@imf.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Thu, 22 Dec 2005 21:30:13 +0900 To: From: Tomonori TAKEDA Subject: Re: Opinion on WG drafts for Multi-region/layer networks In-Reply-To: <098801c606a2$95ba4900$99849ed9@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Yes (to both). Regards, Tomonori At 21:55 05/12/21 +0000, Adrian Farrel wrote: >Hi, > >We have a charter milestone to start WG work on a Requirements I-D for >MRN/MLN, and also an Evaluation I-D to examine how the current protocols >shape up to the challenge. > >There are two appropriate I-Ds that have been around for a while. > >draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt >draft-leroux-ccamp-gmpls-mrn-eval-02.txt > >I propose that we make these WG documents and then give them a thorough >review and edit. > >Opinions please. > >Yes or no will suffice, but reasons are always nice. > >Thanks, >Adrian From owner-ccamp@ops.ietf.org Thu Dec 22 07:54:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpPxo-0003BP-Uk for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 07:54:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06019 for ; Thu, 22 Dec 2005 07:53:26 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpQ0d-0000zH-8S for ccamp-archive@ietf.org; Thu, 22 Dec 2005 07:57:28 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpPqM-0009gF-2G for ccamp-data@psg.com; Thu, 22 Dec 2005 12:46:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpPqL-0009fy-94 for ccamp@ops.ietf.org; Thu, 22 Dec 2005 12:46:49 +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 jBMCkmRn008533 for ; Thu, 22 Dec 2005 21:46:48 +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 jBMCkl1e009159 for ; Thu, 22 Dec 2005 21:46:47 +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 jBMCkkZk020254 for ; Thu, 22 Dec 2005 21:46:46 +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 jBMCkkGq017755 for ; Thu, 22 Dec 2005 21:46:46 +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 jBMCkjXU020753 for ; Thu, 22 Dec 2005 21:46:46 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb.m.ecl.ntt.co.jp [129.60.5.226]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBMCkj0B020748 for ; Thu, 22 Dec 2005 21:46:45 +0900 (JST) Received: from INOUE-LETS-CFW2.lab.ntt.co.jp ([129.60.15.201]) by imb.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id jBMCkjNm023642 for ; Thu, 22 Dec 2005 21:46:45 +0900 (JST) Message-Id: <6.0.0.20.2.20051222213918.062d4fc0@imb.m.ecl.ntt.co.jp> X-Sender: ii004@imb.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 22 Dec 2005 21:40:02 +0900 To: From: "inoue.ichiro@lab.ntt.co.jp" Subject: Re: Opinion on WG drafts for Multi-region/layer networks In-Reply-To: <5.1.1.9.2.20051222205630.0697e008@imf.m.ecl.ntt.co.jp> References: <098801c606a2$95ba4900$99849ed9@Puppy> <5.1.1.9.2.20051222205630.0697e008@imf.m.ecl.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit In favor. Ichiro Inoue >At 21:55 05/12/21 +0000, Adrian Farrel wrote: >>Hi, >> >>We have a charter milestone to start WG work on a Requirements I-D for >>MRN/MLN, and also an Evaluation I-D to examine how the current protocols >>shape up to the challenge. >> >>There are two appropriate I-Ds that have been around for a while. >> >>draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt >>draft-leroux-ccamp-gmpls-mrn-eval-02.txt >> >>I propose that we make these WG documents and then give them a thorough >>review and edit. >> >>Opinions please. >> >>Yes or no will suffice, but reasons are always nice. >> >>Thanks, >>Adrian From owner-ccamp@ops.ietf.org Thu Dec 22 07:54:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpPy5-0003Mp-47 for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 07:54:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06035 for ; Thu, 22 Dec 2005 07:53:42 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpQ0s-0000zq-8i for ccamp-archive@ietf.org; Thu, 22 Dec 2005 07:57:44 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpPrb-0009lQ-7I for ccamp-data@psg.com; Thu, 22 Dec 2005 12:48:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.0 Received: from [216.82.254.83] (helo=mail126.messagelabs.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpPra-0009l8-DS for ccamp@ops.ietf.org; Thu, 22 Dec 2005 12:48:06 +0000 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-2.tower-126.messagelabs.com!1135252982!11002434!69 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 1931 invoked from network); 22 Dec 2005 12:10:47 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-2.tower-126.messagelabs.com with SMTP; 22 Dec 2005 12:10:47 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 43A303590009F196; Thu, 22 Dec 2005 07:10:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Opinion on WG drafts for Multi-region/layer networks Date: Thu, 22 Dec 2005 06:10:46 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9816@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Opinion on WG drafts for Multi-region/layer networks Thread-Index: AcYGonGm5TuqpjcHToedtn/s9WEm4wATheNQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , Cc: "Ash, Gerald R \(Jerry\), ALABS" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable > There are two appropriate I-Ds that have been around for a while. >=20 > draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt > draft-leroux-ccamp-gmpls-mrn-eval-02.txt >=20 > I propose that we make these WG documents and then give them=20 > a thorough review and edit. >=20 > Opinions please. In favor. Thanks, Jerry From owner-ccamp@ops.ietf.org Thu Dec 22 08:30:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpQWJ-0001Tj-W2 for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 08:30:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11262 for ; Thu, 22 Dec 2005 08:29:07 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpQZ8-0002eU-Lc for ccamp-archive@ietf.org; Thu, 22 Dec 2005 08:33:08 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpQPN-000CSk-1t for ccamp-data@psg.com; Thu, 22 Dec 2005 13:23:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpQPM-000CSW-HT for ccamp@ops.ietf.org; Thu, 22 Dec 2005 13:23:00 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 22 Dec 2005 05:23:00 -0800 X-IronPort-AV: i="3.99,283,1131350400"; d="scan'208"; a="382050123:sNHT41479652" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBMDMd7E020123; Thu, 22 Dec 2005 05:22:57 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Dec 2005 08:22:38 -0500 Received: from [192.168.1.101] ([10.86.242.241]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Dec 2005 08:22:38 -0500 In-Reply-To: <098801c606a2$95ba4900$99849ed9@Puppy> References: <098801c606a2$95ba4900$99849ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9218C3B2-EC44-4AD5-9FDD-A3D20D1C0C75@cisco.com> Cc: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: Opinion on WG drafts for Multi-region/layer networks Date: Thu, 22 Dec 2005 08:22:03 -0500 To: "Adrian Farrel" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 22 Dec 2005 13:22:38.0814 (UTC) FILETIME=[C7AB97E0:01C606FA] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit in favor. JP. On Dec 21, 2005, at 4:55 PM, Adrian Farrel wrote: > Hi, > > We have a charter milestone to start WG work on a Requirements I-D for > MRN/MLN, and also an Evaluation I-D to examine how the current > protocols > shape up to the challenge. > > There are two appropriate I-Ds that have been around for a while. > > draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt > draft-leroux-ccamp-gmpls-mrn-eval-02.txt > > I propose that we make these WG documents and then give them a > thorough > review and edit. > > Opinions please. > > Yes or no will suffice, but reasons are always nice. > > Thanks, > Adrian From owner-ccamp@ops.ietf.org Thu Dec 22 09:41:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpRdf-0004ww-Jd for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 09:41:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19911 for ; Thu, 22 Dec 2005 09:40:46 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpRgR-0004y9-BE for ccamp-archive@ietf.org; Thu, 22 Dec 2005 09:44:48 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpRWo-000ICN-JE for ccamp-data@psg.com; Thu, 22 Dec 2005 14:34:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.0 Received: from [216.82.255.211] (helo=mail120.messagelabs.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpRWn-000IC9-RE for ccamp@ops.ietf.org; Thu, 22 Dec 2005 14:34:46 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1135262036!11078577!15 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 26039 invoked from network); 22 Dec 2005 14:34:42 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-120.messagelabs.com with SMTP; 22 Dec 2005 14:34:42 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 43A30359000A44BD; Thu, 22 Dec 2005 09:34:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Opinion on WG drafts for Multi-region/layer networks Date: Thu, 22 Dec 2005 08:34:34 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0B45272D@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Opinion on WG drafts for Multi-region/layer networks Thread-Index: AcYGonGACtNyFgEZQw2xgU7vDdVU+AAYlbog From: "Brungard, Deborah A, ALABS" To: "Adrian Farrel" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Yes (both)- Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, December 21, 2005 4:56 PM To: ccamp@ops.ietf.org Subject: Opinion on WG drafts for Multi-region/layer networks Hi, We have a charter milestone to start WG work on a Requirements I-D for MRN/MLN, and also an Evaluation I-D to examine how the current protocols shape up to the challenge. There are two appropriate I-Ds that have been around for a while. draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt draft-leroux-ccamp-gmpls-mrn-eval-02.txt I propose that we make these WG documents and then give them a thorough review and edit. Opinions please. Yes or no will suffice, but reasons are always nice. Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Dec 22 10:05:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpS0C-0005bZ-LO for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 10:05:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22755 for ; Thu, 22 Dec 2005 10:04:03 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpS2y-0005rT-Op for ccamp-archive@ietf.org; Thu, 22 Dec 2005 10:08:05 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpRrn-000JwU-Gd for ccamp-data@psg.com; Thu, 22 Dec 2005 14:56:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE autolearn=no version=3.1.0 Received: from [68.142.200.153] (helo=web30810.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpRrm-000JwJ-T1 for ccamp@ops.ietf.org; Thu, 22 Dec 2005 14:56:27 +0000 Received: (qmail 56914 invoked by uid 60001); 22 Dec 2005 14:56:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0b2hpueGUsAa/6vEghLY1q7xdAoG39S+Zp6E64KGiq0vVktjz1ehJeWpgx3FGWm8WHl5V98HuQHRm0t/QQOVO5tLkY5/ks4L60GKUgTvQfwIKB4wPrDtIcV09Jpl1xYZLsJ5aOVVjijagoT7eRmJ9EgaQVICAvha8EF6ZE0KPUg= ; Message-ID: <20051222145626.56912.qmail@web30810.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30810.mail.mud.yahoo.com via HTTP; Thu, 22 Dec 2005 06:56:25 PST Date: Thu, 22 Dec 2005 06:56:25 -0800 (PST) From: Igor Bryskin Subject: Re: Opinion on WG drafts for Multi-region/layer networks To: Adrian Farrel , ccamp@ops.ietf.org In-Reply-To: <098801c606a2$95ba4900$99849ed9@Puppy> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-424139101-1135263385=:55868" Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 --0-424139101-1135263385=:55868 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I believe this work is very important. Igor Adrian Farrel wrote: Hi, We have a charter milestone to start WG work on a Requirements I-D for MRN/MLN, and also an Evaluation I-D to examine how the current protocols shape up to the challenge. There are two appropriate I-Ds that have been around for a while. draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt draft-leroux-ccamp-gmpls-mrn-eval-02.txt I propose that we make these WG documents and then give them a thorough review and edit. Opinions please. Yes or no will suffice, but reasons are always nice. Thanks, Adrian __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-424139101-1135263385=:55868 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
 
I believe this work is very important.
 
Igor

Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi,

We have a charter milestone to start WG work on a Requirements I-D for
MRN/MLN, and also an Evaluation I-D to examine how the current protocols
shape up to the challenge.

There are two appropriate I-Ds that have been around for a while.

draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt
draft-leroux-ccamp-gmpls-mrn-eval-02.txt

I propose that we make these WG documents and then give them a thorough
review and edit.

Opinions please.

Yes or no will suffice, but reasons are always nice.

Thanks,
Adrian



__________________________________________________
Do You Yahoo!?
Tired of spam? Y! ahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-424139101-1135263385=:55868-- From owner-ccamp@ops.ietf.org Thu Dec 22 10:09:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpS4U-0006xr-Em for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 10:09:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23213 for ; Thu, 22 Dec 2005 10:08:29 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpS7K-00062M-MW for ccamp-archive@ietf.org; Thu, 22 Dec 2005 10:12:31 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpRsP-000Jyx-Og for ccamp-data@psg.com; Thu, 22 Dec 2005 14:57:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_10_20,HTML_MESSAGE autolearn=no version=3.1.0 Received: from [68.142.200.149] (helo=web30806.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpRsP-000Jym-5B for ccamp@ops.ietf.org; Thu, 22 Dec 2005 14:57:05 +0000 Received: (qmail 54439 invoked by uid 60001); 22 Dec 2005 14:57:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0XJOgqiPJn8C73ZRUih7HZGep5Di8rKmoC8TJhJt2mBm1k1mxJ7ZQxJcjk2jbqYwU7Z+Mp9h/6FRKVUnDM/SK6Ez3OYiLkO+2fyoG568nvP4kqx0Kk91n0y1OCBpvuFO5AbuLKJ2GbREYbpch06OpdEpiBRLKr98WpS2mjMnKOM= ; Message-ID: <20051222145704.54437.qmail@web30806.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30806.mail.mud.yahoo.com via HTTP; Thu, 22 Dec 2005 06:57:04 PST Date: Thu, 22 Dec 2005 06:57:04 -0800 (PST) From: Igor Bryskin Subject: Re: VCAT/LCAS To: Adrian Farrel , ccamp@ops.ietf.org In-Reply-To: <098a01c606a2$97e4f130$99849ed9@Puppy> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-518656425-1135263424=:53907" Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 --0-518656425-1135263424=:53907 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I support this work. Igor Adrian Farrel wrote: Hi, In Vancouver there was clear support in the room that a group wanted to work on this topic. draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and provides a fair summary of the problem space in sections 1 and 2. The draft fades out in section 3 "Possible Extensions to GMPLS to support additional VCAT/LCAS scenarios" as it starts to identify the specific requirements to extend GMPLS protocols. I suggest that the authors should: - gather a group of interest parties to work on this - keep in mind that protocol extensions are done in support of implementations (that is, not for completeness, but because someone is building product) - beef up section 3 to list the requirements - write a new section for the solutions I think that we will be able to adopt this work as a WG draft, but we should not do that until we have seen a first stab at the protocol extensions. If the authors could let us know their progress and plans, that would be great. Thanks, Adrian __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-518656425-1135263424=:53907 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

I support this work.
 
Igor

Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi,

In Vancouver there was clear support in the room that a group wanted to
work on this topic.

draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and
provides a fair summary of the problem space in sections 1 and 2.

The draft fades out in section 3 "Possible Extensions to GMPLS to support
additional VCAT/LCAS scenarios" as it starts to identify the specific
requirements to extend GMPLS protocols.

I suggest that the authors should:
- gather a group of interest parties to work on this
- keep in mind that protocol extensions are done in support of
implementations (that is, not for completeness, but because someone
is building product)
- beef up section 3 to list the requirements
- write a new section for the solutions

I think that we will be able to adopt this work as a WG draft, but we
should not do that until we have seen a first stab at the protocol
extensions.

If the authors could let us know their progress and plans, that would be
great.

Thanks,
Adrian



__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-518656425-1135263424=:53907-- From owner-ccamp@ops.ietf.org Thu Dec 22 10:57:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpSp4-00019S-7y for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 10:57:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28316 for ; Thu, 22 Dec 2005 10:56:36 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpSrr-0007bF-0r for ccamp-archive@ietf.org; Thu, 22 Dec 2005 11:00:39 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpSiB-000Nfo-9z for ccamp-data@psg.com; Thu, 22 Dec 2005 15:50:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,SUBJ_ALL_CAPS autolearn=no version=3.1.0 Received: from [66.163.169.227] (helo=smtp107.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpSiA-000NfU-K2 for ccamp@ops.ietf.org; Thu, 22 Dec 2005 15:50:34 +0000 Received: (qmail 64778 invoked from network); 22 Dec 2005 15:50:30 -0000 Received: from unknown (HELO LIFEBOOK) (vsharma87@59.184.31.185 with login) by smtp107.mail.sc5.yahoo.com with SMTP; 22 Dec 2005 15:50:29 -0000 Reply-To: From: "Vishal Sharma" To: "'Adrian Farrel'" , Subject: RE: VCAT/LCAS Date: Thu, 22 Dec 2005 07:50:05 -0800 Organization: Metanoia, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcYGosg0hRdWAq9dREWXPDQlKytioAAbH+mg In-Reply-To: <098a01c606a2$97e4f130$99849ed9@Puppy> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: X-Spam-Score: 0.6 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Hi Adrian, I've had occasion to look at this work, and think it is a useful work item, and support it. -Vishal -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, December 21, 2005 4:27 PM To: ccamp@ops.ietf.org Subject: VCAT/LCAS Hi, In Vancouver there was clear support in the room that a group wanted to work on this topic. draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and provides a fair summary of the problem space in sections 1 and 2. The draft fades out in section 3 "Possible Extensions to GMPLS to support additional VCAT/LCAS scenarios" as it starts to identify the specific requirements to extend GMPLS protocols. I suggest that the authors should: - gather a group of interest parties to work on this - keep in mind that protocol extensions are done in support of implementations (that is, not for completeness, but because someone is building product) - beef up section 3 to list the requirements - write a new section for the solutions I think that we will be able to adopt this work as a WG draft, but we should not do that until we have seen a first stab at the protocol extensions. If the authors could let us know their progress and plans, that would be great. Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Dec 22 11:32:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpTMz-0006ha-27 for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 11:32:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02436 for ; Thu, 22 Dec 2005 11:31:39 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpTPl-0000KP-Kd for ccamp-archive@ietf.org; Thu, 22 Dec 2005 11:35:42 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpTFQ-0000Fp-H8 for ccamp-data@psg.com; Thu, 22 Dec 2005 16:24:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,SPF_PASS autolearn=no version=3.1.0 Received: from [213.46.243.23] (helo=amsfep13-int.chello.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpTFN-0000FM-JC for ccamp@ops.ietf.org; Thu, 22 Dec 2005 16:24:54 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep13-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051222162436.JFMX11814.amsfep13-int.chello.nl@[192.168.1.4]>; Thu, 22 Dec 2005 17:24:36 +0100 Message-ID: <43AAD340.4070307@chello.nl> Date: Thu, 22 Dec 2005 17:24:32 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: VCAT/LCAS References: <098a01c606a2$97e4f130$99849ed9@Puppy> In-Reply-To: <098a01c606a2$97e4f130$99849ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Hello Adrian, You wrote: > In Vancouver there was clear support in the room that a group wanted to > work on this topic. Yes, and I still support it. > draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and > provides a fair summary of the problem space in sections 1 and 2. > > The draft fades out in section 3 "Possible Extensions to GMPLS to support > additional VCAT/LCAS scenarios" as it starts to identify the specific > requirements to extend GMPLS protocols. > > I suggest that the authors should: > - gather a group of interest parties to work on this A small group already started, maybe others would like to join. > - keep in mind that protocol extensions are done in support of > implementations (that is, not for completeness, but because someone > is building product) > - beef up section 3 to list the requirements > - write a new section for the solutions OK, thansk for the advise. > I think that we will be able to adopt this work as a WG draft, but we > should not do that until we have seen a first stab at the protocol > extensions. > > If the authors could let us know their progress and plans, that would be > great. After the Holidays we know more. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Thu Dec 22 13:33:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpVFp-0004FX-0p for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 13:33:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16743 for ; Thu, 22 Dec 2005 13:32:22 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpVIa-0004jj-Pg for ccamp-archive@ietf.org; Thu, 22 Dec 2005 13:36:27 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpV8j-0008wU-EY for ccamp-data@psg.com; Thu, 22 Dec 2005 18:26:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpV8i-0008wG-GU for ccamp@ops.ietf.org; Thu, 22 Dec 2005 18:26:08 +0000 Received: from [192.168.0.103] (c-24-4-177-139.hsd1.ca.comcast.net [24.4.177.139]) (authenticated bits=0) by pro.abac.com (8.13.4/8.13.4) with ESMTP id jBMIQ2Qx067394; Thu, 22 Dec 2005 10:26:05 -0800 (PST) (envelope-from gregb@grotto-networking.com) Message-ID: <43AAEFBD.1010806@grotto-networking.com> Date: Thu, 22 Dec 2005 10:26:05 -0800 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: VCAT/LCAS References: <098a01c606a2$97e4f130$99849ed9@Puppy> In-Reply-To: <098a01c606a2$97e4f130$99849ed9@Puppy> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Hi Adrian, we've gathered a group of folks together that includes the original authors and anyone else who has so far expressed interest. Anyone else who is interested just send an e-mail to any of the authors to get involved. The plan is roughly as follows: (a) Survey of current GMPLS WG drafts that have may have mechanisms usable for VCAT/LCAS operation. List mechanisms (generally objects and such added to signaling or routing). Adrian your supplemental website with the up to date listing of CCAMP is either broken or the link from the IETF website is broken :-< Can you fix or send the right link? (b) Analysis of these mechanisms for applicability to base VCAT/LCAS scenarios. (c) Write up additional enabled applications with walk throughs for each mechanism adopted, e.g., make before you break... However, we've currently been dealing with the note from the last IETF meeting that claimed that this effort was "strictly for the diverse path" case. One of the basic VCAT/LCAS scenarios is dynamic bandwidth adjustment (whether co-routed or not). GMPLS VCAT connection bandwidth modification (even in co-routed) seems different from the MPLS case in the sense we'd need to either add or delete member connections (not just modify connection bandwidth parameters at each node). We're not sure that this important case can be currently handled in the co-routed case without modification. So we've also added this analysis to our list of ToDo's (volunteers for a complete write up on this?) That said look for activity again after the holidays! Greg -------------------------------------------------- Greg Bernstein, Grotto Networking Adrian Farrel wrote: >Hi, > >In Vancouver there was clear support in the room that a group wanted to >work on this topic. > >draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and >provides a fair summary of the problem space in sections 1 and 2. > >The draft fades out in section 3 "Possible Extensions to GMPLS to support >additional VCAT/LCAS scenarios" as it starts to identify the specific >requirements to extend GMPLS protocols. > >I suggest that the authors should: >- gather a group of interest parties to work on this >- keep in mind that protocol extensions are done in support of > implementations (that is, not for completeness, but because someone > is building product) >- beef up section 3 to list the requirements >- write a new section for the solutions > >I think that we will be able to adopt this work as a WG draft, but we >should not do that until we have seen a first stab at the protocol >extensions. > >If the authors could let us know their progress and plans, that would be >great. > >Thanks, >Adrian > > > > > From owner-ccamp@ops.ietf.org Thu Dec 22 17:14:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpYi4-0006g5-CI for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 17:14:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10982 for ; Thu, 22 Dec 2005 17:13:46 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpYkw-0003mU-95 for ccamp-archive@ietf.org; Thu, 22 Dec 2005 17:17:52 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpYY2-0004LP-Tv for ccamp-data@psg.com; Thu, 22 Dec 2005 22:04:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,SPF_PASS autolearn=no version=3.1.0 Received: from [213.46.243.25] (helo=amsfep16-int.chello.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpYY1-0004L7-JJ for ccamp@ops.ietf.org; Thu, 22 Dec 2005 22:04:30 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep16-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051222220412.FUCD23945.amsfep16-int.chello.nl@[192.168.1.4]>; Thu, 22 Dec 2005 23:04:12 +0100 Message-ID: <43AB22D8.7010001@chello.nl> Date: Thu, 22 Dec 2005 23:04:08 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks References: <098801c606a2$95ba4900$99849ed9@Puppy> In-Reply-To: <098801c606a2$95ba4900$99849ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hello Adrian, You porposed: > There are two appropriate I-Ds that have been around for a while. > > draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt > draft-leroux-ccamp-gmpls-mrn-eval-02.txt > > I propose that we make these WG documents and then give them a thorough > review and edit. I am in favor to progress these drafts. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Thu Dec 22 17:32:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpYzO-0004BY-JA for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 17:32:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12867 for ; Thu, 22 Dec 2005 17:31:41 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpZ29-0004Nm-MU for ccamp-archive@ietf.org; Thu, 22 Dec 2005 17:35:47 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpYuH-00067D-U3 for ccamp-data@psg.com; Thu, 22 Dec 2005 22:27:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpYuG-00066p-9r for ccamp@ops.ietf.org; Thu, 22 Dec 2005 22:27:28 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id jBMMRPJD016076; Thu, 22 Dec 2005 14:27:25 -0800 (PST) Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id jBMMRPkP016064; Thu, 22 Dec 2005 14:27:25 -0800 (PST) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.5/8.13.5) with ESMTP id jBMMROkd004945; Thu, 22 Dec 2005 14:27:25 -0800 (PST) Received: from [133.164.4.13] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id jBMMRO424677; Thu, 22 Dec 2005 14:27:24 -0800 (PST) Message-ID: <43AB2854.2030704@us.fujitsu.com> Date: Thu, 22 Dec 2005 14:27:32 -0800 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks References: <098801c606a2$95ba4900$99849ed9@Puppy> In-Reply-To: <098801c606a2$95ba4900$99849ed9@Puppy> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit yes to both two questions: 1. since MLN is a special case of MRN, can we collapse this whole topic to MRN? is there a compelling reason for keeping these 2 notation? 2. Section 3 of draft-leroux-ccamp-gmpls-mrn-eval-02.txt is a requirments section and therefore not relevant to this draft but belongs to draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt. there is no advantage to repeting requirements. thanks, richard. Adrian Farrel wrote: >Hi, > >We have a charter milestone to start WG work on a Requirements I-D for >MRN/MLN, and also an Evaluation I-D to examine how the current protocols >shape up to the challenge. > >There are two appropriate I-Ds that have been around for a while. > >draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt >draft-leroux-ccamp-gmpls-mrn-eval-02.txt > >I propose that we make these WG documents and then give them a thorough >review and edit. > >Opinions please. > >Yes or no will suffice, but reasons are always nice. > >Thanks, >Adrian > > > > From kjmurdock@19465.com Thu Dec 22 21:56:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epd6N-0003Db-5O for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 21:56:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13808 for ; Thu, 22 Dec 2005 21:55:09 -0500 (EST) Received: from [84.90.82.65] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Epd9G-00071R-El for ccamp-archive@ietf.org; Thu, 22 Dec 2005 21:59:18 -0500 Message-ID: <000001c60796$6f463a00$0100007f@localhost> From: "Colin Mitchell" To: Subject: Need S0ftware? Date: Fri, 23 Dec 2005 02:50:31 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60796.6F463A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60796.6F463A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60796.6F463A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 44 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 33 re! views)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 37 reviews)


------=_NextPart_000_0001_01C60796.6F463A00-- From 3725e952.c6a33eca@atw3.com Thu Dec 22 23:05:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpeBp-0005dk-4b for ccamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 23:05:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19720 for ; Thu, 22 Dec 2005 23:04:49 -0500 (EST) Received: from cpe00095bc228fb-cm014270111845.cpe.net.cable.rogers.com ([72.140.84.45] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EpeEj-0000gH-Od for ccamp-archive@ietf.org; Thu, 22 Dec 2005 23:08:58 -0500 Message-ID: <000001c607a0$17143580$0100007f@localhost> From: "Drake Bailey" <3725e952.c6a33eca@atw3.com> To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Thu, 22 Dec 2005 23:05:39 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C607A0.17143580" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.4 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C607A0.17143580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C607A0.17143580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 42 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 39 re! views)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 38 reviews)


------=_NextPart_000_0001_01C607A0.17143580-- From owner-ccamp@ops.ietf.org Fri Dec 23 03:17:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epi7L-0001R8-6u for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 03:17:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10495 for ; Fri, 23 Dec 2005 03:16:30 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpiAK-0008Mr-H6 for ccamp-archive@ietf.org; Fri, 23 Dec 2005 03:20:41 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ephun-0005WB-KX for ccamp-data@psg.com; Fri, 23 Dec 2005 08:04:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ephum-0005Vt-9L for ccamp@ops.ietf.org; Fri, 23 Dec 2005 08:04:36 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Dec 2005 09:04:28 +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: Opinion on WG drafts for Multi-region/layer networks Date: Fri, 23 Dec 2005 09:04:26 +0100 Message-ID: Thread-Topic: Opinion on WG drafts for Multi-region/layer networks Thread-Index: AcYHR21dZ9/AOvZaROmCgWQjfC+iAgATXvrg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Richard Rabbat" , Cc: X-OriginalArrivalTime: 23 Dec 2005 08:04:28.0451 (UTC) FILETIME=[7F571F30:01C60797] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Hi Richard See inline,=20 > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] De la part de Richard Rabbat > Envoy=E9 : jeudi 22 d=E9cembre 2005 23:28 > =C0 : zzx-adrian@olddog.co.uk > Cc : ccamp@ops.ietf.org > Objet : Re: Opinion on WG drafts for Multi-region/layer networks >=20 > yes to both >=20 > two questions: > 1. since MLN is a special case of MRN, can we collapse this=20 > whole topic to MRN? is there a compelling reason for keeping=20 > these 2 notation? Actually a MLN is not a special case of MRN. Rather a MRN is a special = case of MLN. A network comprised of VC4 and VC4-64c capable node is a = MLN but not a MRN. "Layer" refers to a data plane switching layer (e.g. VC4, VC4-64c...). = While "region" refers to a switching capablity (PSC, TDM...). The term MLN is used to discuss mechanisms that apply equally to layers = and regions (VNT...) while the term MRN is used to discuss multi-regions = specific mechanisms (e.g. Adaptation capability).=20 > 2. Section 3 of draft-leroux-ccamp-gmpls-mrn-eval-02.txt is a=20 > requirments section and therefore not relevant to this draft=20 > but belongs to draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt.=20 > there is no advantage to repeting requirements. The objective was to ease the reading, but we can easily remove it if = considered as irrelevant. Thanks for your support and for these comments. Regards, JL >=20 > thanks, > richard. >=20 > Adrian Farrel wrote: >=20 > >Hi, > > > >We have a charter milestone to start WG work on a=20 > Requirements I-D for=20 > >MRN/MLN, and also an Evaluation I-D to examine how the current=20 > >protocols shape up to the challenge. > > > >There are two appropriate I-Ds that have been around for a while. > > > >draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt > >draft-leroux-ccamp-gmpls-mrn-eval-02.txt > > > >I propose that we make these WG documents and then give them=20 > a thorough=20 > >review and edit. > > > >Opinions please. > > > >Yes or no will suffice, but reasons are always nice. > > > >Thanks, > >Adrian > > > > > > =20 > > >=20 >=20 From owner-ccamp@ops.ietf.org Fri Dec 23 03:20:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpiAV-0002FE-QX for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 03:20:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10770 for ; Fri, 23 Dec 2005 03:19:46 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpiDS-0008Sn-BV for ccamp-archive@ietf.org; Fri, 23 Dec 2005 03:23:57 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Epi3J-0006Gy-NY for ccamp-data@psg.com; Fri, 23 Dec 2005 08:13:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [61.144.161.53] (helo=huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Epi3I-0006Gi-MK for ccamp@ops.ietf.org; Fri, 23 Dec 2005 08:13:24 +0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRX00L21Z13J6@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Fri, 23 Dec 2005 16:17:27 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRX00FLPZ13SD@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Fri, 23 Dec 2005 16:17:27 +0800 (CST) Received: from l37133 ([10.70.76.208]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRX00EO0ZA1JI@szxml01-in.huawei.com>; Fri, 23 Dec 2005 16:22:49 +0800 (CST) Date: Fri, 23 Dec 2005 16:08:41 +0800 From: Dan Li Subject: Re: VCAT/LCAS To: Adrian Farrel , ccamp@ops.ietf.org Message-id: <008701c60798$1605cc60$d04c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <098a01c606a2$97e4f130$99849ed9@Puppy> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7BIT I support this work. When we consider the requirements in section 3, do we also need to consider the scenario which the Ethernet service is supported by Xc or by the combination of Xc and Xv? Another scenario is if we have the optional Xc and Xv flexible adapatations at both ends, does the signaling need to support the selection? Dan Li ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, December 22, 2005 8:27 AM Subject: VCAT/LCAS > Hi, > > In Vancouver there was clear support in the room that a group wanted to > work on this topic. > > draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and > provides a fair summary of the problem space in sections 1 and 2. > > The draft fades out in section 3 "Possible Extensions to GMPLS to support > additional VCAT/LCAS scenarios" as it starts to identify the specific > requirements to extend GMPLS protocols. > > I suggest that the authors should: > - gather a group of interest parties to work on this > - keep in mind that protocol extensions are done in support of > implementations (that is, not for completeness, but because someone > is building product) > - beef up section 3 to list the requirements > - write a new section for the solutions > > I think that we will be able to adopt this work as a WG draft, but we > should not do that until we have seen a first stab at the protocol > extensions. > > If the authors could let us know their progress and plans, that would be > great. > > Thanks, > Adrian > > From owner-ccamp@ops.ietf.org Fri Dec 23 09:21:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpnnR-0005ha-Kk for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 09:21:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17328 for ; Fri, 23 Dec 2005 09:20:18 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpnqQ-00038p-8r for ccamp-archive@ietf.org; Fri, 23 Dec 2005 09:24:34 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Epnfv-000F3c-By for ccamp-data@psg.com; Fri, 23 Dec 2005 14:13:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Epnfs-000F3A-RK for ccamp@ops.ietf.org; Fri, 23 Dec 2005 14:13:37 +0000 Received: from ib (vpn17.atlanta.movaz.com [172.18.0.17]) by jera.movaz.com (Postfix) with SMTP id 0935316213; Fri, 23 Dec 2005 09:11:36 -0500 (EST) Message-ID: <002d01c607cb$0f405e30$6601a8c0@movaz.com> From: "Igor Bryskin" To: "LE ROUX Jean-Louis RD-CORE-LAN" , "Richard Rabbat" , Cc: References: Subject: Re: Opinion on WG drafts for Multi-region/layer networks Date: Fri, 23 Dec 2005 09:13:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA17328 JL. I have a correction. Please,see in-line. Igor ----- Original Message -----=20 From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Richard Rabbat" ; Cc: Sent: Friday, December 23, 2005 3:04 AM Subject: RE: Opinion on WG drafts for Multi-region/layer networks Hi Richard See inline, > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] De la part de Richard Rabbat > Envoy=E9 : jeudi 22 d=E9cembre 2005 23:28 > =C0 : zzx-adrian@olddog.co.uk > Cc : ccamp@ops.ietf.org > Objet : Re: Opinion on WG drafts for Multi-region/layer networks > > yes to both > > two questions: > 1. since MLN is a special case of MRN, can we collapse this > whole topic to MRN? is there a compelling reason for keeping > these 2 notation? Actually a MLN is not a special case of MRN. Rather a MRN is a special ca= se of MLN. A network comprised of VC4 and VC4-64c capable node is a MLN but = not a MRN. IB>> Agree "Layer" refers to a data plane switching layer (e.g. VC4, VC4-64c...). Wh= ile "region" refers to a switching capablity (PSC, TDM...). IB>> "Layer" is all about data plane. Layers exist independently of contr= ol plane.. "Region" refers to control plane peculiarities pertinent to netwo= rks with different switching types. Signaling objects specific to TDM , optic= al impairment constraints specific to optical transparent networks are examp= les of region related issues. Therefore, "region" is purely control plane concept. See more in the lexicography draft. The term MLN is used to discuss mechanisms that apply equally to layers a= nd regions (VNT...) while the term MRN is used to discuss multi-regions specific mechanisms (e.g. Adaptation capability). ; IB>> Disagree. Adaptation capability is entirely MLN issue. According to your own example you need to adopt VC4 onto VC4-64c. Cheers, Igor > 2. Section 3 of draft-leroux-ccamp-gmpls-mrn-eval-02.txt is a > requirments section and therefore not relevant to this draft > but belongs to draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt. > there is no advantage to repeting requirements. The objective was to ease the reading, but we can easily remove it if considered as irrelevant. Thanks for your support and for these comments. Regards, JL > > thanks, > richard. > > Adrian Farrel wrote: > > >Hi, > > > >We have a charter milestone to start WG work on a > Requirements I-D for > >MRN/MLN, and also an Evaluation I-D to examine how the current > >protocols shape up to the challenge. > > > >There are two appropriate I-Ds that have been around for a while. > > > >draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt > >draft-leroux-ccamp-gmpls-mrn-eval-02.txt > > > >I propose that we make these WG documents and then give them > a thorough > >review and edit. > > > >Opinions please. > > > >Yes or no will suffice, but reasons are always nice. > > > >Thanks, > >Adrian > > > > > > > > > > From owner-ccamp@ops.ietf.org Fri Dec 23 09:43:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epo8v-00030k-L0 for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 09:43:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19856 for ; Fri, 23 Dec 2005 09:42:32 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpoBt-0003v6-85 for ccamp-archive@ietf.org; Fri, 23 Dec 2005 09:46:46 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Epnw5-000H2F-5X for ccamp-data@psg.com; Fri, 23 Dec 2005 14:30:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,SPF_PASS autolearn=no version=3.1.0 Received: from [213.46.243.17] (helo=amsfep12-int.chello.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Epnw3-000H1U-KP for ccamp@ops.ietf.org; Fri, 23 Dec 2005 14:30:20 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep12-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051223143006.HNMG21130.amsfep12-int.chello.nl@[192.168.1.4]>; Fri, 23 Dec 2005 15:30:06 +0100 Message-ID: <43AC09EC.3030308@chello.nl> Date: Fri, 23 Dec 2005 15:30:04 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN CC: Richard Rabbat , adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Hello JL, You explained: >> two questions: 1. since MLN is a special case of MRN, can we >> collapse this whole topic to MRN? is there a compelling reason for >> keeping these 2 notation? > > Actually a MLN is not a special case of MRN. Rather a MRN is a > special case of MLN. A network comprised of VC4 and VC4-64c capable > node is a MLN but not a MRN. "Layer" refers to a data plane switching > layer (e.g. VC4, VC4-64c...). While "region" refers to a switching > capablity (PSC, TDM...). The term MLN is used to discuss mechanisms > that apply equally to layers and regions (VNT...) while the term MRN > is used to discuss multi-regions specific mechanisms (e.g. Adaptation > capability). I am still confused by the definition of MRN. Suppose I have a TDM MRN, I can distinguish in this TDM MRN e.g. VC-12 layer switching, VC-4 layer switching, MS-n layer switching, so according to the above all MLN. Why is an MRN then a special case of MLN. With the next generation nodes: Multi Service Platforms within the same node there can also be ethernet switching on top of the above mentioned TDM MRN and optical switching (DWDM) below this TDM MRN.... IMO the definition of MRN will be very difficult (impossible). I would propose to use only the MLN definition, with this layering and partitioning a network can be described completely. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Fri Dec 23 09:48:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpoE4-0004SA-C7 for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 09:48:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20329 for ; Fri, 23 Dec 2005 09:47:49 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpoH4-00044P-I9 for ccamp-archive@ietf.org; Fri, 23 Dec 2005 09:52:04 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Epo4o-000HuS-1h for ccamp-data@psg.com; Fri, 23 Dec 2005 14:39:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,SPF_PASS autolearn=no version=3.1.0 Received: from [213.46.243.15] (helo=amsfep17-int.chello.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Epo4n-000HuD-01 for ccamp@ops.ietf.org; Fri, 23 Dec 2005 14:39:21 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep17-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051223143902.BNQI3085.amsfep17-int.chello.nl@[192.168.1.4]>; Fri, 23 Dec 2005 15:39:02 +0100 Message-ID: <43AC0C04.1040504@chello.nl> Date: Fri, 23 Dec 2005 15:39:00 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Li CC: Adrian Farrel , ccamp@ops.ietf.org Subject: Re: VCAT/LCAS References: <098a01c606a2$97e4f130$99849ed9@Puppy> <008701c60798$1605cc60$d04c460a@china.huawei.com> In-Reply-To: <008701c60798$1605cc60$d04c460a@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Hello Dan, You wrote: > When we consider the requirements in section 3, do we also need to > consider the scenario which the Ethernet service is supported by Xc > or by the combination of Xc and Xv? Contiguous concatenation Xc and virtual concatenation Xv cannot be combined (there is only one exception: an STS-3c can be virual concatenated) > Another scenario is if we have the optional Xc and Xv flexible > adapatations at both ends, does the signaling need to support the > selection? A selection is certainly needed to match the transport capability with the required bandwidth. A selection can be: - a single VC-n - a single VC-n-Xc - a VC-n-Xv which provides additional flexibility if LCAS is supported. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Fri Dec 23 09:58:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpoNh-0007u2-0T for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 09:58:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21516 for ; Fri, 23 Dec 2005 09:57:47 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpoQh-0004Ug-NR for ccamp-archive@ietf.org; Fri, 23 Dec 2005 10:02:02 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpoGZ-000JBS-12 for ccamp-data@psg.com; Fri, 23 Dec 2005 14:51:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpoGY-000JB4-0v for ccamp@ops.ietf.org; Fri, 23 Dec 2005 14:51:30 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id jBNEpPYV020427; Fri, 23 Dec 2005 15:51:25 +0100 In-Reply-To: <098a01c606a2$97e4f130$99849ed9@Puppy> To: "Adrian Farrel" Cc: ccamp@ops.ietf.org Subject: Re: VCAT/LCAS MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 23 Dec 2005 15:51:25 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 12/23/2005 15:51:24, Serialize complete at 12/23/2005 15:51:24 Content-Type: multipart/alternative; boundary="=_alternative 00519D32C12570E0_=" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c This is a multipart message in MIME format. --=_alternative 00519D32C12570E0_= Content-Type: text/plain; charset="US-ASCII" adrian - would it be possible to take into account compatibility with RFC3946 when addressing the following point you mentioned here below "I think that we will be able to adopt this work as a WG draft, but we should not do that until we have seen a first stab at the protocol extensions." much thanks, - dimitri. "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org 22/12/2005 01:27 Please respond to "Adrian Farrel" To: cc: Subject: VCAT/LCAS Hi, In Vancouver there was clear support in the room that a group wanted to work on this topic. draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and provides a fair summary of the problem space in sections 1 and 2. The draft fades out in section 3 "Possible Extensions to GMPLS to support additional VCAT/LCAS scenarios" as it starts to identify the specific requirements to extend GMPLS protocols. I suggest that the authors should: - gather a group of interest parties to work on this - keep in mind that protocol extensions are done in support of implementations (that is, not for completeness, but because someone is building product) - beef up section 3 to list the requirements - write a new section for the solutions I think that we will be able to adopt this work as a WG draft, but we should not do that until we have seen a first stab at the protocol extensions. If the authors could let us know their progress and plans, that would be great. Thanks, Adrian --=_alternative 00519D32C12570E0_= Content-Type: text/html; charset="US-ASCII"
adrian -

would it be possible to take into account compatibility with RFC3946 when addressing the following point you mentioned here below

"I think that we will be able to adopt this work as a WG draft, but we
should not do that until we have seen a first stab at the protocol
extensions.
"

much thanks,
- dimitri.





"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org

22/12/2005 01:27
Please respond to "Adrian Farrel"

       
        To:        <ccamp@ops.ietf.org>
        cc:        
        Subject:        VCAT/LCAS



Hi,

In Vancouver there was clear support in the room that a group wanted to
work on this topic.

draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and
provides a fair summary of the problem space in sections 1 and 2.

The draft fades out in section 3 "Possible Extensions to GMPLS to support
additional VCAT/LCAS scenarios" as it starts to identify the specific
requirements to extend GMPLS protocols.

I suggest that the authors should:
- gather a group of interest parties to work on this
- keep in mind that protocol extensions are done in support of
 implementations (that is, not for completeness, but because someone
 is building product)
- beef up section 3 to list the requirements
- write a new section for the solutions

I think that we will be able to adopt this work as a WG draft, but we
should not do that until we have seen a first stab at the protocol
extensions.

If the authors could let us know their progress and plans, that would be
great.

Thanks,
Adrian



--=_alternative 00519D32C12570E0_=-- From owner-ccamp@ops.ietf.org Fri Dec 23 10:19:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpohX-0005DY-45 for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 10:19:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23448 for ; Fri, 23 Dec 2005 10:18:17 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpokV-00058j-TZ for ccamp-archive@ietf.org; Fri, 23 Dec 2005 10:22:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpoYE-000Kt1-S0 for ccamp-data@psg.com; Fri, 23 Dec 2005 15:09:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,SPF_PASS autolearn=no version=3.1.0 Received: from [213.46.243.21] (helo=amsfep14-int.chello.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpoYD-000Krx-Il for ccamp@ops.ietf.org; Fri, 23 Dec 2005 15:09:46 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep14-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051223150927.XYIJ18747.amsfep14-int.chello.nl@[192.168.1.4]>; Fri, 23 Dec 2005 16:09:27 +0100 Message-ID: <43AC1325.2000104@chello.nl> Date: Fri, 23 Dec 2005 16:09:25 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Bryskin CC: LE ROUX Jean-Louis RD-CORE-LAN , adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks References: <002d01c607cb$0f405e30$6601a8c0@movaz.com> In-Reply-To: <002d01c607cb$0f405e30$6601a8c0@movaz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Hello Igor, I have a small correction see [hvh]: > The term MLN is used to discuss mechanisms that apply equally to layers and > regions (VNT...) while the term MRN is used to discuss multi-regions > specific mechanisms (e.g. Adaptation capability). > ; > IB>> Disagree. Adaptation capability is entirely MLN issue. According to > your own example you need to adopt VC4 onto VC4-64c. There exists no adaptation function with VC-4 client and VC-4-64c as server. A VC-4-64c can be used as a server to transport a 10GbE LAN client signal, or other 10 Gbit/s signals using e.g. GFP. A VC-4 can be used as a server for VC-3, VC-12, VC-11 signals, be a member of a VC-4-64v, or thransport a 150 Mbit/s client signal using e.g. GFP. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Fri Dec 23 10:26:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epooj-0007lq-TM for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 10:26:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24010 for ; Fri, 23 Dec 2005 10:25:44 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eporm-0005JS-4p for ccamp-archive@ietf.org; Fri, 23 Dec 2005 10:29:59 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpodD-000LD7-LC for ccamp-data@psg.com; Fri, 23 Dec 2005 15:14:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,SPF_PASS autolearn=no version=3.1.0 Received: from [213.46.243.15] (helo=amsfep17-int.chello.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpodC-000LCh-KD for ccamp@ops.ietf.org; Fri, 23 Dec 2005 15:14:55 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep17-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051223151437.DUGV3085.amsfep17-int.chello.nl@[192.168.1.4]>; Fri, 23 Dec 2005 16:14:37 +0100 Message-ID: <43AC145A.3040404@chello.nl> Date: Fri, 23 Dec 2005 16:14:34 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: Adrian Farrel , ccamp@ops.ietf.org Subject: Re: VCAT/LCAS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hello Dimitri, You suggested: > would it be possible to take into account compatibility with RFC3946 > when addressing the following point you mentioned here below > > "I think that we will be able to adopt this work as a WG draft, but we > should not do that until we have seen a first stab at the protocol > extensions." Thanks for your help, I already had this RFC on the list of RFCs to check. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Fri Dec 23 15:11:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EptGe-0004wO-FO for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 15:11:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00794 for ; Fri, 23 Dec 2005 15:10:49 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EptJb-00076W-0a for ccamp-archive@ietf.org; Fri, 23 Dec 2005 15:15:08 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ept7d-000E3l-SX for ccamp-data@psg.com; Fri, 23 Dec 2005 20:02:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ept7c-000E3O-VO for ccamp@ops.ietf.org; Fri, 23 Dec 2005 20:02:37 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id jBNK2WCo011588; Fri, 23 Dec 2005 12:02:32 -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 jBNK2V8E011583; Fri, 23 Dec 2005 12:02:31 -0800 (PST) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.5/8.13.5) with ESMTP id jBNK2Thi021287; Fri, 23 Dec 2005 12:02:29 -0800 (PST) Received: from [133.164.59.55] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id jBNK2Q410126; Fri, 23 Dec 2005 12:02:28 -0800 (PST) Message-ID: <43AC57D9.2070207@us.fujitsu.com> Date: Fri, 23 Dec 2005 12:02:33 -0800 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN CC: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA00794 hi Jean-Louis, thanks for the reply, inline... LE ROUX Jean-Louis RD-CORE-LAN wrote: >Hi Richard > >See inline,=20 > > =20 > >>-----Message d'origine----- >>De : owner-ccamp@ops.ietf.org=20 >>[mailto:owner-ccamp@ops.ietf.org] De la part de Richard Rabbat >>Envoy=E9 : jeudi 22 d=E9cembre 2005 23:28 >>=C0 : zzx-adrian@olddog.co.uk >>Cc : ccamp@ops.ietf.org >>Objet : Re: Opinion on WG drafts for Multi-region/layer networks >> >>yes to both >> >>two questions: >>1. since MLN is a special case of MRN, can we collapse this=20 >>whole topic to MRN? is there a compelling reason for keeping=20 >>these 2 notation? >> =20 >> > >Actually a MLN is not a special case of MRN. Rather a MRN is a special c= ase of MLN. A network comprised of VC4 and VC4-64c capable node is a MLN = but not a MRN. >"Layer" refers to a data plane switching layer (e.g. VC4, VC4-64c...). W= hile "region" refers to a switching capablity (PSC, TDM...). > =20 > My comment was incorrect. Let me use better math wording.=20 Do all elements of the set MRN belong to the set MLN? I suggest that both terms MRN and MLN be clearly defined somewhere. >The term MLN is used to discuss mechanisms that apply equally to layers = and regions (VNT...) while the term MRN is used to discuss multi-regions = specific mechanisms (e.g. Adaptation capability).=20 > If Igor is right about adaptation (though the example is wrong from=20 Huub's email), then what are other MR specific mechanisms? >>2. Section 3 of draft-leroux-ccamp-gmpls-mrn-eval-02.txt is a=20 >>requirments section and therefore not relevant to this draft=20 >>but belongs to draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt.=20 >>there is no advantage to repeting requirements. >> =20 >> > >The objective was to ease the reading, but we can easily remove it if co= nsidered as irrelevant. > =20 > My suggestion is to drop it in this draft and if there is need to have a=20 summary for clarity, then clarify in the req's doc. >Thanks for your support and for these comments. > >Regards, > >JL > =20 > thanks, richard. > > =20 > >>thanks, >>richard. >> >>Adrian Farrel wrote: >> >> =20 >> >>>Hi, >>> >>>We have a charter milestone to start WG work on a=20 >>> =20 >>> >>Requirements I-D for=20 >> =20 >> >>>MRN/MLN, and also an Evaluation I-D to examine how the current=20 >>>protocols shape up to the challenge. >>> >>>There are two appropriate I-Ds that have been around for a while. >>> >>>draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt >>>draft-leroux-ccamp-gmpls-mrn-eval-02.txt >>> >>>I propose that we make these WG documents and then give them=20 >>> =20 >>> >>a thorough=20 >> =20 >> >>>review and edit. >>> >>>Opinions please. >>> >>>Yes or no will suffice, but reasons are always nice. >>> >>>Thanks, >>>Adrian >>> >>> >>>=20 >>> >>> =20 >>> >> =20 >> From owner-ccamp@ops.ietf.org Fri Dec 23 15:16:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EptKy-0006Lw-BN for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 15:16:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01143 for ; Fri, 23 Dec 2005 15:15:17 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EptO1-0007G9-W7 for ccamp-archive@ietf.org; Fri, 23 Dec 2005 15:19:36 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EptAr-000EL3-1a for ccamp-data@psg.com; Fri, 23 Dec 2005 20:05:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.0 Received: from [216.82.255.211] (helo=mail120.messagelabs.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EptAp-000EKq-VZ for ccamp@ops.ietf.org; Fri, 23 Dec 2005 20:05:56 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1135368325!6359565!10 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30939 invoked from network); 23 Dec 2005 20:05:54 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-15.tower-120.messagelabs.com with SMTP; 23 Dec 2005 20:05:54 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 43A30359000D1B02; Fri, 23 Dec 2005 15:05:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Opinion on WG drafts for Multi-region/layer networks Date: Fri, 23 Dec 2005 14:05:53 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0B452F44@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Opinion on WG drafts for Multi-region/layer networks Thread-Index: AcYHzZQ8n5+BvG8gQl+FKSXtFTcU3AAKFDgg From: "Brungard, Deborah A, ALABS" To: "Huub van Helvoort" , "LE ROUX Jean-Louis RD-CORE-LAN" Cc: "Richard Rabbat" , , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Hi all, As JL notes, MLN is referring to data plane and MRN to (GMPLS) control plane. A MLN may support one ISC or multiple ISCs i.e. GMPLS regions (a GMPLS region is defined in RFC 3495/4206,,). In the updated requirements draft for Nov's meeting, we added text to clarify MRN and MLN, refer to section 1 and 3.1: "A data plane layer is associated with a region in the control plane (e.g. VC4 associated to TDM, IP associated to PSC). However, more than one data plane layer can be associated to the same region (e.g. both VC4 and VC12 are associated to TDM)." Richard, in the earlier versions of this draft, we thought also we should only use GMPLS constructs, and we had based the discussion on region. Though then many were confused how (control) region related to (data) multi-layer networks. We included in this latest version both terms to help distinguish between the data plane and control plane. Similar to the lexio draft. Take a look at section 1 and 3.1, and if you have suggestions, please send. (an eggnog/whisky/wine/martini should also help when reading - here (EST) it is just about that time - 'till next year - Good Holidays everyone) Deborah -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Huub van Helvoort Sent: Friday, December 23, 2005 9:30 AM To: LE ROUX Jean-Louis RD-CORE-LAN Cc: Richard Rabbat; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks Hello JL, You explained: >> two questions: 1. since MLN is a special case of MRN, can we >> collapse this whole topic to MRN? is there a compelling reason for >> keeping these 2 notation? >=20 > Actually a MLN is not a special case of MRN. Rather a MRN is a > special case of MLN. A network comprised of VC4 and VC4-64c capable > node is a MLN but not a MRN. "Layer" refers to a data plane switching > layer (e.g. VC4, VC4-64c...). While "region" refers to a switching > capablity (PSC, TDM...). The term MLN is used to discuss mechanisms > that apply equally to layers and regions (VNT...) while the term MRN > is used to discuss multi-regions specific mechanisms (e.g. Adaptation > capability). I am still confused by the definition of MRN. Suppose I have a TDM MRN, I can distinguish in this TDM MRN e.g. VC-12 layer switching, VC-4 layer switching, MS-n layer switching, so according to the above all MLN. Why is an MRN then a special case of MLN. With the next generation nodes: Multi Service Platforms within the same node there can also be ethernet switching on top of the above mentioned TDM MRN and optical switching (DWDM) below this TDM MRN.... IMO the definition of MRN will be very difficult (impossible). I would propose to use only the MLN definition, with this layering and partitioning a network can be described completely. Cheers, Huub. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://members.chello.nl/hhelvoort/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Fri Dec 23 16:28:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpuSR-0008CJ-HY for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 16:28:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09238 for ; Fri, 23 Dec 2005 16:27:05 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpuVQ-0001Az-Hm for ccamp-archive@ietf.org; Fri, 23 Dec 2005 16:31:24 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpuKc-000IkO-2D for ccamp-data@psg.com; Fri, 23 Dec 2005 21:20:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpuKb-000Ik9-E5 for ccamp@ops.ietf.org; Fri, 23 Dec 2005 21:20:05 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id jBNLJuV0016141; Fri, 23 Dec 2005 13:19:56 -0800 (PST) Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id jBNLJtBE016133; Fri, 23 Dec 2005 13:19:55 -0800 (PST) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.5/8.13.5) with ESMTP id jBNLJspZ000064; Fri, 23 Dec 2005 13:19:54 -0800 (PST) Received: from [133.164.59.55] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id jBNLJr421010; Fri, 23 Dec 2005 13:19:53 -0800 (PST) Message-ID: <43AC6A00.2060804@us.fujitsu.com> Date: Fri, 23 Dec 2005 13:20:00 -0800 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: Huub van Helvoort , LE ROUX Jean-Louis RD-CORE-LAN , adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks References: <449B2580D802A443A923DABF3EAB82AF0B452F44@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF0B452F44@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit hi Deborah, thanks for your comments. sorry for being so slow today; must be the wine or is it the martini? :-) Your description is different from that of JL as he is saying that MRN is a special case of MLN but you're saying that they refer to different planes. I understand what a region is but see no definition of a multi-region network anywhere. the lexico draft is clear in describing layers and regions but the MLN/MRN concepts don't seem to be defined. For example, when is it the case that you don't have a multi-layer network? A network is by definition multi-layer since it follows some layering (OSI or otherwise). Is there a network that doesn't have a physical layer, mac layer and above? thanks, and happy holidays! Richard. Brungard, Deborah A, ALABS wrote: >Hi all, > >As JL notes, MLN is referring to data plane and MRN to (GMPLS) control >plane. A MLN may support one ISC or multiple ISCs i.e. GMPLS regions (a >GMPLS region is defined in RFC 3495/4206,,). In the updated >requirements draft for Nov's meeting, we added text to clarify MRN and >MLN, refer to section 1 and 3.1: >"A data plane layer is associated with a region in the control plane >(e.g. VC4 associated to TDM, IP associated to PSC). However, more than >one data plane layer can be associated to the same region (e.g. both VC4 >and VC12 are associated to TDM)." > >Richard, in the earlier versions of this draft, we thought also we >should only use GMPLS constructs, and we had based the discussion on >region. Though then many were confused how (control) region related to >(data) multi-layer networks. We included in this latest version both >terms to help distinguish between the data plane and control plane. >Similar to the lexio draft. Take a look at section 1 and 3.1, and if you >have suggestions, please send. > >(an eggnog/whisky/wine/martini should also help when reading - here >(EST) it is just about that time - 'till next year - Good Holidays >everyone) >Deborah > >-----Original Message----- >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >Behalf Of Huub van Helvoort >Sent: Friday, December 23, 2005 9:30 AM >To: LE ROUX Jean-Louis RD-CORE-LAN >Cc: Richard Rabbat; adrian@olddog.co.uk; ccamp@ops.ietf.org >Subject: Re: Opinion on WG drafts for Multi-region/layer networks > >Hello JL, > >You explained: > > > >>>two questions: 1. since MLN is a special case of MRN, can we >>>collapse this whole topic to MRN? is there a compelling reason for >>>keeping these 2 notation? >>> >>> >>Actually a MLN is not a special case of MRN. Rather a MRN is a >>special case of MLN. A network comprised of VC4 and VC4-64c capable >>node is a MLN but not a MRN. "Layer" refers to a data plane switching >>layer (e.g. VC4, VC4-64c...). While "region" refers to a switching >>capablity (PSC, TDM...). The term MLN is used to discuss mechanisms >>that apply equally to layers and regions (VNT...) while the term MRN >>is used to discuss multi-regions specific mechanisms (e.g. Adaptation >>capability). >> >> > >I am still confused by the definition of MRN. >Suppose I have a TDM MRN, I can distinguish in this TDM MRN e.g. >VC-12 layer switching, VC-4 layer switching, MS-n layer switching, >so according to the above all MLN. >Why is an MRN then a special case of MLN. > >With the next generation nodes: Multi Service Platforms within >the same node there can also be ethernet switching on top of >the above mentioned TDM MRN and optical switching (DWDM) below >this TDM MRN.... > >IMO the definition of MRN will be very difficult (impossible). > >I would propose to use only the MLN definition, with this layering >and partitioning a network can be described completely. > >Cheers, Huub. > > > From advent2000@antoniofurundarena.com Fri Dec 23 16:53:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epuqw-0007Nj-Jl for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 16:53:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14576 for ; Fri, 23 Dec 2005 16:52:24 -0500 (EST) Received: from dyn-83-152-149-25.ppp.tiscali.fr ([83.152.149.25] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Epuu1-0002rj-AB for ccamp-archive@ietf.org; Fri, 23 Dec 2005 16:56:42 -0500 Message-ID: <000001c60835$58a2f000$0100007f@localhost> From: "Jaime Allen" To: Subject: Corel Draw Date: Fri, 23 Dec 2005 22:53:14 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60835.58A2F000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60835.58A2F000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60835.58A2F000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

!

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT downl! oad!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 48 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 39! reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 35 reviews)


------=_NextPart_000_0001_01C60835.58A2F000-- From owner-ccamp@ops.ietf.org Fri Dec 23 17:37:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpvXX-0004ni-Df for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 17:37:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22622 for ; Fri, 23 Dec 2005 17:36:25 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epvac-0005bK-85 for ccamp-archive@ietf.org; Fri, 23 Dec 2005 17:40:44 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpvSO-0000Pb-DZ for ccamp-data@psg.com; Fri, 23 Dec 2005 22:32:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,SPF_PASS autolearn=no version=3.1.0 Received: from [213.46.243.13] (helo=amsfep18-int.chello.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpvSN-0000PM-3m for ccamp@ops.ietf.org; Fri, 23 Dec 2005 22:32:11 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep18-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051223223153.JAGO29486.amsfep18-int.chello.nl@[192.168.1.4]>; Fri, 23 Dec 2005 23:31:53 +0100 Message-ID: <43AC7AD6.6010908@chello.nl> Date: Fri, 23 Dec 2005 23:31:50 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks References: <449B2580D802A443A923DABF3EAB82AF0B452F44@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF0B452F44@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Helli Deborah, Thanks for the clarification, after reading draft-shiomoto-ccamp-gmpls-mrn-reqs the definitions are more clear to me. (even with my handicap ;-) Happy Holidays to all of you. Huub. > Hi all, > > As JL notes, MLN is referring to data plane and MRN to (GMPLS) control > plane. A MLN may support one ISC or multiple ISCs i.e. GMPLS regions (a > GMPLS region is defined in RFC 3495/4206,,). In the updated > requirements draft for Nov's meeting, we added text to clarify MRN and > MLN, refer to section 1 and 3.1: > "A data plane layer is associated with a region in the control plane > (e.g. VC4 associated to TDM, IP associated to PSC). However, more than > one data plane layer can be associated to the same region (e.g. both VC4 > and VC12 are associated to TDM)." > > Richard, in the earlier versions of this draft, we thought also we > should only use GMPLS constructs, and we had based the discussion on > region. Though then many were confused how (control) region related to > (data) multi-layer networks. We included in this latest version both > terms to help distinguish between the data plane and control plane. > Similar to the lexio draft. Take a look at section 1 and 3.1, and if you > have suggestions, please send. > > (an eggnog/whisky/wine/martini should also help when reading - here > (EST) it is just about that time - 'till next year - Good Holidays > everyone) > Deborah > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of Huub van Helvoort > Sent: Friday, December 23, 2005 9:30 AM > To: LE ROUX Jean-Louis RD-CORE-LAN > Cc: Richard Rabbat; adrian@olddog.co.uk; ccamp@ops.ietf.org > Subject: Re: Opinion on WG drafts for Multi-region/layer networks > > Hello JL, > > You explained: > > >>>two questions: 1. since MLN is a special case of MRN, can we >>>collapse this whole topic to MRN? is there a compelling reason for >>>keeping these 2 notation? >> >>Actually a MLN is not a special case of MRN. Rather a MRN is a >>special case of MLN. A network comprised of VC4 and VC4-64c capable >>node is a MLN but not a MRN. "Layer" refers to a data plane switching >>layer (e.g. VC4, VC4-64c...). While "region" refers to a switching >>capablity (PSC, TDM...). The term MLN is used to discuss mechanisms >>that apply equally to layers and regions (VNT...) while the term MRN >>is used to discuss multi-regions specific mechanisms (e.g. Adaptation >>capability). > > > I am still confused by the definition of MRN. > Suppose I have a TDM MRN, I can distinguish in this TDM MRN e.g. > VC-12 layer switching, VC-4 layer switching, MS-n layer switching, > so according to the above all MLN. > Why is an MRN then a special case of MLN. > > With the next generation nodes: Multi Service Platforms within > the same node there can also be ethernet switching on top of > the above mentioned TDM MRN and optical switching (DWDM) below > this TDM MRN.... > > IMO the definition of MRN will be very difficult (impossible). > > I would propose to use only the MLN definition, with this layering > and partitioning a network can be described completely. > > Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Fri Dec 23 18:27:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpwKJ-00021P-5h for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 18:27:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26920 for ; Fri, 23 Dec 2005 18:26:48 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpwNN-00071Z-On for ccamp-archive@ietf.org; Fri, 23 Dec 2005 18:31:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpwEv-0005OV-4i for ccamp-data@psg.com; Fri, 23 Dec 2005 23:22:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpwEt-0005OG-UN for ccamp@ops.ietf.org; Fri, 23 Dec 2005 23:22:20 +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 jBNNMFsS015567; Sat, 24 Dec 2005 08:22:16 +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 jBNNME7e011950; Sat, 24 Dec 2005 08:22:14 +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 jBNNMDsa011332; Sat, 24 Dec 2005 08:22:13 +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 jBNNMDTA017901; Sat, 24 Dec 2005 08:22:13 +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 jBNNMDCP019404; Sat, 24 Dec 2005 08:22:13 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc.m.ecl.ntt.co.jp [129.60.5.227]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBNNMCoV019401; Sat, 24 Dec 2005 08:22:12 +0900 (JST) Received: from [127.0.0.1] ([129.60.15.201]) by imc.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id jBNNMAqL021412; Sat, 24 Dec 2005 08:22:12 +0900 (JST) Message-ID: <43AC86A2.1090802@lab.ntt.co.jp> Date: Sat, 24 Dec 2005 08:22:10 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728 X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks References: <098801c606a2$95ba4900$99849ed9@Puppy> In-Reply-To: <098801c606a2$95ba4900$99849ed9@Puppy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Yes, I agree that we make two documents WG documents. -- Kohei Shiomoto NTT Network Service Systems Laboratories Adrian Farrel wrote: > Hi, > > We have a charter milestone to start WG work on a Requirements I-D for > MRN/MLN, and also an Evaluation I-D to examine how the current protocols > shape up to the challenge. > > There are two appropriate I-Ds that have been around for a while. > > draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt > draft-leroux-ccamp-gmpls-mrn-eval-02.txt > > I propose that we make these WG documents and then give them a thorough > review and edit. > > Opinions please. > > Yes or no will suffice, but reasons are always nice. > > Thanks, > Adrian > > > > From owner-ccamp@ops.ietf.org Fri Dec 23 19:01:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpwrD-0002SF-DK for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 19:01:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00152 for ; Fri, 23 Dec 2005 19:00:48 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpwuK-0007za-PL for ccamp-archive@ietf.org; Fri, 23 Dec 2005 19:05:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpwkH-0008d1-2r for ccamp-data@psg.com; Fri, 23 Dec 2005 23:54:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=3.1.0 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpwkF-0008cd-KI; Fri, 23 Dec 2005 23:54:44 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id jBNNsWKn005629; Sat, 24 Dec 2005 00:54:32 +0100 In-Reply-To: <43AC6A00.2060804@us.fujitsu.com> To: Richard Rabbat Cc: adrian@olddog.co.uk, ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" , Huub van Helvoort , LE ROUX Jean-Louis RD-CORE-LAN , owner-ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Sat, 24 Dec 2005 00:54:31 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 12/24/2005 00:54:32, Serialize complete at 12/24/2005 00:54:32 Content-Type: multipart/alternative; boundary="=_alternative 00835632C12570E0_=" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 This is a multipart message in MIME format. --=_alternative 00835632C12570E0_= Content-Type: text/plain; charset="US-ASCII" richard > I understand what a region is but see no definition of a multi-region > network anywhere. see page 3. > For example, when is it the case that you don't have a multi-layer > network? see section 3, in summary, it says multiple regions always cover multiple layers but not the other way around Richard Rabbat Sent by: owner-ccamp@ops.ietf.org 23/12/2005 22:20 To: "Brungard, Deborah A, ALABS" cc: Huub van Helvoort , LE ROUX Jean-Louis RD-CORE-LAN , adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks hi Deborah, thanks for your comments. sorry for being so slow today; must be the wine or is it the martini? :-) Your description is different from that of JL as he is saying that MRN is a special case of MLN but you're saying that they refer to different planes. I understand what a region is but see no definition of a multi-region network anywhere. the lexico draft is clear in describing layers and regions but the MLN/MRN concepts don't seem to be defined. For example, when is it the case that you don't have a multi-layer network? A network is by definition multi-layer since it follows some layering (OSI or otherwise). Is there a network that doesn't have a physical layer, mac layer and above? thanks, and happy holidays! Richard. Brungard, Deborah A, ALABS wrote: >Hi all, > >As JL notes, MLN is referring to data plane and MRN to (GMPLS) control >plane. A MLN may support one ISC or multiple ISCs i.e. GMPLS regions (a >GMPLS region is defined in RFC 3495/4206,,). In the updated >requirements draft for Nov's meeting, we added text to clarify MRN and >MLN, refer to section 1 and 3.1: >"A data plane layer is associated with a region in the control plane >(e.g. VC4 associated to TDM, IP associated to PSC). However, more than >one data plane layer can be associated to the same region (e.g. both VC4 >and VC12 are associated to TDM)." > >Richard, in the earlier versions of this draft, we thought also we >should only use GMPLS constructs, and we had based the discussion on >region. Though then many were confused how (control) region related to >(data) multi-layer networks. We included in this latest version both >terms to help distinguish between the data plane and control plane. >Similar to the lexio draft. Take a look at section 1 and 3.1, and if you >have suggestions, please send. > >(an eggnog/whisky/wine/martini should also help when reading - here >(EST) it is just about that time - 'till next year - Good Holidays >everyone) >Deborah > >-----Original Message----- >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >Behalf Of Huub van Helvoort >Sent: Friday, December 23, 2005 9:30 AM >To: LE ROUX Jean-Louis RD-CORE-LAN >Cc: Richard Rabbat; adrian@olddog.co.uk; ccamp@ops.ietf.org >Subject: Re: Opinion on WG drafts for Multi-region/layer networks > >Hello JL, > >You explained: > > > >>>two questions: 1. since MLN is a special case of MRN, can we >>>collapse this whole topic to MRN? is there a compelling reason for >>>keeping these 2 notation? >>> >>> >>Actually a MLN is not a special case of MRN. Rather a MRN is a >>special case of MLN. A network comprised of VC4 and VC4-64c capable >>node is a MLN but not a MRN. "Layer" refers to a data plane switching >>layer (e.g. VC4, VC4-64c...). While "region" refers to a switching >>capablity (PSC, TDM...). The term MLN is used to discuss mechanisms >>that apply equally to layers and regions (VNT...) while the term MRN >>is used to discuss multi-regions specific mechanisms (e.g. Adaptation >>capability). >> >> > >I am still confused by the definition of MRN. >Suppose I have a TDM MRN, I can distinguish in this TDM MRN e.g. >VC-12 layer switching, VC-4 layer switching, MS-n layer switching, >so according to the above all MLN. >Why is an MRN then a special case of MLN. > >With the next generation nodes: Multi Service Platforms within >the same node there can also be ethernet switching on top of >the above mentioned TDM MRN and optical switching (DWDM) below >this TDM MRN.... > >IMO the definition of MRN will be very difficult (impossible). > >I would propose to use only the MLN definition, with this layering >and partitioning a network can be described completely. > >Cheers, Huub. > > > --=_alternative 00835632C12570E0_= Content-Type: text/html; charset="US-ASCII"
richard

> I understand what a region is but see no definition of a multi-region
> network anywhere.


see page 3.

> For example, when is it the case that you don't have a multi-layer
> network?


see section 3, in summary, it says multiple regions always cover multiple layers but not the other way around



Richard Rabbat <richard@us.fujitsu.com>
Sent by: owner-ccamp@ops.ietf.org

23/12/2005 22:20

       
        To:        "Brungard, Deborah A, ALABS" <dbrungard@att.com>
        cc:        Huub van Helvoort <hhelvoort@chello.nl>, LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@francetelecom.com>, adrian@olddog.co.uk, ccamp@ops.ietf.org
        Subject:        Re: Opinion on WG drafts for Multi-region/layer networks



hi Deborah,
thanks for your comments.
sorry for being so slow today; must be the wine or is it the martini? :-)
Your description is different from that of JL as he is saying that MRN
is a special case of MLN but you're saying that they refer to different
planes.
I understand what a region is but see no definition of a multi-region
network anywhere.
the lexico draft is clear in describing layers and regions but the
MLN/MRN concepts don't seem to be defined.
For example, when is it the case that you don't have a multi-layer
network? A network is by definition multi-layer since it follows some
layering (OSI or otherwise). Is there a network that doesn't have a
physical layer, mac layer and above?

thanks, and happy holidays!
Richard.

Brungard, Deborah A, ALABS wrote:

>Hi all,
>
>As JL notes, MLN is referring to data plane and MRN to (GMPLS) control
>plane. A MLN may support one ISC or multiple ISCs i.e. GMPLS regions (a
>GMPLS region is defined in RFC 3495/4206,,).  In the updated
>requirements draft for Nov's meeting, we added text to clarify MRN and
>MLN, refer to section 1 and 3.1:
>"A data plane layer is associated with a region in the control plane
>(e.g. VC4 associated to TDM, IP associated to PSC). However, more than
>one data plane layer can be associated to the same region (e.g. both VC4
>and VC12 are associated to TDM)."
>
>Richard, in the earlier versions of this draft, we thought also we
>should only use GMPLS constructs, and we had based the discussion on
>region. Though then many were confused how (control) region related to
>(data) multi-layer networks. We included in this latest version both
>terms to help distinguish between the data plane and control plane.
>Similar to the lexio draft. Take a look at section 1 and 3.1, and if you
>have suggestions, please send.
>
>(an eggnog/whisky/wine/martini should also help when reading - here
>(EST) it is just about that time - 'till next year - Good Holidays
>everyone)
>Deborah
>
>-----Original Message-----
>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
>Behalf Of Huub van Helvoort
>Sent: Friday, December 23, 2005 9:30 AM
>To: LE ROUX Jean-Louis RD-CORE-LAN
>Cc: Richard Rabbat; adrian@olddog.co.uk; ccamp@ops.ietf.org
>Subject: Re: Opinion on WG drafts for Multi-region/layer networks
>
>Hello JL,
>
>You explained:
>
>  
>
>>>two questions: 1. since MLN is a special case of MRN, can we
>>>collapse this whole topic to MRN? is there a compelling reason for
>>>keeping these 2 notation?
>>>      
>>>
>>Actually a MLN is not a special case of MRN. Rather a MRN is a
>>special case of MLN. A network comprised of VC4 and VC4-64c capable
>>node is a MLN but not a MRN. "Layer" refers to a data plane switching
>>layer (e.g. VC4, VC4-64c...). While "region" refers to a switching
>>capablity (PSC, TDM...). The term MLN is used to discuss mechanisms
>>that apply equally to layers and regions (VNT...) while the term MRN
>>is used to discuss multi-regions specific mechanisms (e.g. Adaptation
>>capability).
>>    
>>
>
>I am still confused by the definition of MRN.
>Suppose I have a TDM MRN, I can distinguish in this TDM MRN e.g.
>VC-12 layer switching, VC-4 layer switching, MS-n layer switching,
>so according to the above all MLN.
>Why is an MRN then a special case of MLN.
>
>With the next generation nodes: Multi Service Platforms within
>the same node there can also be ethernet switching on top of
>the above mentioned TDM MRN and optical switching (DWDM) below
>this TDM MRN....
>
>IMO the definition of MRN will be very difficult (impossible).
>
>I would propose to use only the MLN definition, with this layering
>and partitioning a network can be described completely.
>
>Cheers, Huub.
>
>  
>


--=_alternative 00835632C12570E0_=-- From owner-ccamp@ops.ietf.org Fri Dec 23 19:28:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpxH4-0001aM-GZ for ccamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 19:28:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02945 for ; Fri, 23 Dec 2005 19:27:31 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpxKC-0000NR-59 for ccamp-archive@ietf.org; Fri, 23 Dec 2005 19:31:52 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpxBk-000BfJ-SC for ccamp-data@psg.com; Sat, 24 Dec 2005 00:23:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpxBj-000Beo-Uz for ccamp@ops.ietf.org; Sat, 24 Dec 2005 00:23:08 +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 jBO0MwLR026676; Sat, 24 Dec 2005 09:22:58 +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 jBO0MveY009710; Sat, 24 Dec 2005 09:22:57 +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 jBO0MvZw002576; Sat, 24 Dec 2005 09:22:57 +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 jBO0Mv8o023509; Sat, 24 Dec 2005 09:22:57 +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 jBO0MukS029784; Sat, 24 Dec 2005 09:22:56 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc.m.ecl.ntt.co.jp [129.60.5.227]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBO0Mu4c029781; Sat, 24 Dec 2005 09:22:56 +0900 (JST) Received: from [127.0.0.1] ([129.60.15.201]) by imc.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id jBO0Msnp025513; Sat, 24 Dec 2005 09:22:55 +0900 (JST) Message-ID: <43AC94DE.4060608@lab.ntt.co.jp> Date: Sat, 24 Dec 2005 09:22:54 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728 X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Huub van Helvoort CC: LE ROUX Jean-Louis RD-CORE-LAN , Richard Rabbat , adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks References: <43AC09EC.3030308@chello.nl> In-Reply-To: <43AC09EC.3030308@chello.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Hi Huub Thank you for your support and comments. Please see in line. Huub van Helvoort wrote: > Hello JL, > > You explained: > >>> two questions: 1. since MLN is a special case of MRN, can we >>> collapse this whole topic to MRN? is there a compelling reason for >>> keeping these 2 notation? >> >> >> Actually a MLN is not a special case of MRN. Rather a MRN is a >> special case of MLN. A network comprised of VC4 and VC4-64c capable >> node is a MLN but not a MRN. "Layer" refers to a data plane switching >> layer (e.g. VC4, VC4-64c...). While "region" refers to a switching >> capablity (PSC, TDM...). The term MLN is used to discuss mechanisms >> that apply equally to layers and regions (VNT...) while the term MRN >> is used to discuss multi-regions specific mechanisms (e.g. Adaptation >> capability). > > > I am still confused by the definition of MRN. > Suppose I have a TDM MRN, I can distinguish in this TDM MRN e.g. > VC-12 layer switching, VC-4 layer switching, MS-n layer switching, > so according to the above all MLN. > Why is an MRN then a special case of MLN. As JL explained, a MRN is a special case of MLN. As far as the same interface switching capability is used, the MLN is not called the MRN [RFC4206]. The same switching type is used in control plane as long as it is in the same region. The switching type TDM is used in control plane of the TDM multi-layer network consisting of VC-12 and VC-4 for instance. A region uniquely identifies a particular data plane technology (PSC, L2SC, TDM, LSC, and FSC) while a layer describes a data plane switching granularity level. A region (e.g. TDM) can be sub-divided into smaller granularity based on the bandwidth that defines the "data plane switching layers" (e.g. from VC-11 to VC4-256c in TDM). In other words, more than one data plane layer can be associated to the same region (e.g. both VC4 and VC12 are associated to TDM). > > With the next generation nodes: Multi Service Platforms within > the same node there can also be ethernet switching on top of > the above mentioned TDM MRN and optical switching (DWDM) below > this TDM MRN.... > > IMO the definition of MRN will be very difficult (impossible). > > I would propose to use only the MLN definition, with this layering > and partitioning a network can be described completely. Thank you for your comments. Again a MRN is a special case of MLN. The term MLN could replace the term MRN in our documents where appropriate. We should see whether appropriate wording is used in the next revision to resolve confusion. > > Cheers, Huub. > Thanks, Kohei From owner-ccamp@ops.ietf.org Sat Dec 24 08:42:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eq9fY-0005tq-O1 for ccamp-archive@megatron.ietf.org; Sat, 24 Dec 2005 08:42:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20227 for ; Sat, 24 Dec 2005 08:41:37 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eq9ij-00073l-Fe for ccamp-archive@ietf.org; Sat, 24 Dec 2005 08:46:06 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eq9Vg-00079w-01 for ccamp-data@psg.com; Sat, 24 Dec 2005 13:32:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE autolearn=no version=3.1.0 Received: from [68.142.200.152] (helo=web30809.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eq9Vf-00079k-04 for ccamp@ops.ietf.org; Sat, 24 Dec 2005 13:32:31 +0000 Received: (qmail 23863 invoked by uid 60001); 24 Dec 2005 13:32:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=K4GfHslAG4UnZiagpoOUV0UFqZu7g1lM7OHVx+XOEWOCU24K0qMv2p1kYHYLqRgLmmOR4y2BbEsgzJrLKFG3IBkloSi+/sX+4SiPwoIY8/s1sHAjCVFTwEgUmv4xL5pObbefMpQKgt5dq92q/RynFCf8g1WcUJSZTI2s8hdU7+o= ; Message-ID: <20051224133230.23861.qmail@web30809.mail.mud.yahoo.com> Received: from [68.100.80.11] by web30809.mail.mud.yahoo.com via HTTP; Sat, 24 Dec 2005 05:32:30 PST Date: Sat, 24 Dec 2005 05:32:30 -0800 (PST) From: Igor Bryskin Subject: Re: Opinion on WG drafts for Multi-region/layer networks To: Huub van Helvoort , Igor Bryskin Cc: LE ROUX Jean-Louis RD-CORE-LAN , adrian@olddog.co.uk, ccamp@ops.ietf.org In-Reply-To: <43AC1325.2000104@chello.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1899917514-1135431150=:23564" Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 --0-1899917514-1135431150=:23564 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Huub, I am sure you are right. My only point - and I see you agree with me - that adaptation capabilities - to adopt/to be adopted - is a property of layer. Igor Huub van Helvoort wrote: Hello Igor, I have a small correction see [hvh]: > The term MLN is used to discuss mechanisms that apply equally to layers and > regions (VNT...) while the term MRN is used to discuss multi-regions > specific mechanisms (e.g. Adaptation capability). > ; > IB>> Disagree. Adaptation capability is entirely MLN issue. According to > your own example you need to adopt VC4 onto VC4-64c. There exists no adaptation function with VC-4 client and VC-4-64c as server. A VC-4-64c can be used as a server to transport a 10GbE LAN client signal, or other 10 Gbit/s signals using e.g. GFP. A VC-4 can be used as a server for VC-3, VC-12, VC-11 signals, be a member of a VC-4-64v, or thransport a 150 Mbit/s client signal using e.g. GFP. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1899917514-1135431150=:23564 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Huub,

I am sure you are right. My only point - and I see you agree with me - that adaptation capabilities - to adopt/to be adopted - is a property of layer.

Igor

Huub van Helvoort <hhelvoort@chello.nl> wrote:
Hello Igor,

I have a small correction see [hvh]:

> The term MLN is used to discuss mechanisms that apply equally to layers and
> regions (VNT...) while the term MRN is used to discuss multi-regions
> specific mechanisms (e.g. Adaptation capability).
> ;
> IB>> Disagree. Adaptation capability is entirely MLN issue. According to
> your own example you need to adopt VC4 onto VC4-64c.

There exists no adaptation function with VC-4 client and
VC-4-64c as server.
A VC-4-64c can be used as a server to transport a 10GbE LAN
clie! nt signal, or other 10 Gbit/s signals using e.g. GFP.
A VC-4 can be used as a server for VC-3, VC-12, VC-11 signals,
be a member of a VC-4-64v, or thransport a 150 Mbit/s client
signal using e.g. GFP.

Cheers, Huub.

--
================================================================
http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...



Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1899917514-1135431150=:23564-- From owner-ccamp@ops.ietf.org Sat Dec 24 08:55:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eq9rY-0008Pe-DI for ccamp-archive@megatron.ietf.org; Sat, 24 Dec 2005 08:55:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21093 for ; Sat, 24 Dec 2005 08:54:00 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eq9ul-0007Mr-Fa for ccamp-archive@ietf.org; Sat, 24 Dec 2005 08:58:29 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eq9lx-0008dV-1A for ccamp-data@psg.com; Sat, 24 Dec 2005 13:49:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE autolearn=no version=3.1.0 Received: from [68.142.200.150] (helo=web30807.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eq9lw-0008d5-4d for ccamp@ops.ietf.org; Sat, 24 Dec 2005 13:49:20 +0000 Received: (qmail 70649 invoked by uid 60001); 24 Dec 2005 13:49:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fq27rEy3hZyu4pO6xuH/yl5vH4IB4YALKCtyp3aFwY6c0JlRVr6hVNA0zjJR7qs88AjD8kHbJTUq0OaCLnfmZ1lw+oHpvJOCsH1WlXXoyP2wKtVx39xzRNUnxN6Dw4qubpQ48G6XdxRsmjL+oLVexdgLIi+eI5zr+vkUxfIERZU= ; Message-ID: <20051224134919.70647.qmail@web30807.mail.mud.yahoo.com> Received: from [68.100.80.11] by web30807.mail.mud.yahoo.com via HTTP; Sat, 24 Dec 2005 05:49:19 PST Date: Sat, 24 Dec 2005 05:49:19 -0800 (PST) From: Igor Bryskin Subject: Re: Opinion on WG drafts for Multi-region/layer networks To: Richard Rabbat , LE ROUX Jean-Louis RD-CORE-LAN Cc: adrian@olddog.co.uk, ccamp@ops.ietf.org In-Reply-To: <43AC57D9.2070207@us.fujitsu.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-361610227-1135432159=:66874" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 --0-361610227-1135432159=:66874 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA21093 Richard, =20 See in line. Igor =20 Richard Rabbat wrote: hi Jean-Louis, thanks for the reply, inline... LE ROUX Jean-Louis RD-CORE-LAN wrote: >Hi Richard > >See inline,=20 > > =20 > >>-----Message d'origine----- >>De : owner-ccamp@ops.ietf.org=20 >>[mailto:owner-ccamp@ops.ietf.org] De la part de Richard Rabbat >>Envoy=E9 : jeudi 22 d=E9cembre 2005 23:28 >>=C0 : zzx-adrian@olddog.co.uk >>Cc : ccamp@ops.ietf.org >>Objet : Re: Opinion on WG drafts for Multi-region/layer networks >> >>yes to both >> >>two questions: >>1. since MLN is a special case of MRN, can we collapse this=20 >>whole topic to MRN? is there a compelling reason for keeping=20 >>these 2 notation? >> =20 >> > >Actually a MLN is not a special case of MRN. Rather a MRN is a special = case of MLN. A network comprised of VC4 and VC4-64c capable node is a ML= N but not a MRN. >"Layer" refers to a data plane switching layer (e.g. VC4, VC4-64c...). = While "region" refers to a switching capablity (PSC, TDM...). > =20 > My comment was incorrect. Let me use better math wording.=20 Do all elements of the set MRN belong to the set MLN? I suggest that both terms MRN and MLN be clearly defined somewhere. >The term MLN is used to discuss mechanisms that apply equally to layers= and regions (VNT...) while the term MRN is used to discuss multi-region= s specific mechanisms (e.g. Adaptation capability).=20 > If Igor is right about adaptation (though the example is wrong from=20 Huub's email), then what are other MR specific mechanisms? =20 IB>> Deborah is right. Region is purely control plane concept. Region = ( e.g. TDM. WDM. etc.) specific signaling object, translation of signali= ng messages when they pass through the region boundaries is an example o= f a multi-region operation. Your own draft about advertising available = lambdas and computing paths in terms of lambdas is an example of region = specific operation.=20 Anything to do with data plane is all about layers and not regions. =20 Igor >>2. Section 3 of draft-leroux-ccamp-gmpls-mrn-eval-02.txt is a=20 >>requirments section and therefore not relevant to this draft=20 >>but belongs to draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt.=20 >>there is no advantage to repeting requirements. >> =20 >> > >The objective was to ease the reading, but we can easily remove it if co= nsidered as irrelevant. > =20 > My suggestion is to drop it in this draft and if there is need to have a=20 summary for clarity, then clarify in the req's doc. >Thanks for your support and for these comments. > >Regards, > >JL > =20 > thanks, richard. > > =20 > >>thanks, >>richard. >> >>Adrian Farrel wrote: >> >> =20 >> >>>Hi, >>> >>>We have a charter milestone to start WG work on a=20 >>> =20 >>> >>Requirements I-D for=20 >> =20 >> >>>MRN/MLN, and also an Evaluation I-D to examine how the current=20 >>>protocols shape up to the challenge. >>> >>>There are two appropriate I-Ds that have been around for a while. >>> >>>draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt >>>draft-leroux-ccamp-gmpls-mrn-eval-02.txt >>> >>>I propose that we make these WG documents and then give them=20 >>> =20 >>> >>a thorough=20 >> =20 >> >>>review and edit. >>> >>>Opinions please. >>> >>>Yes or no will suffice, but reasons are always nice. >>> >>>Thanks, >>>Adrian >>> >>> >>>=20 >>> >>> =20 >>> >> =20 >> =09 --------------------------------- Yahoo! for Good - Make a difference this year.=20 --0-361610227-1135432159=:66874 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA21093
Richard,

See in line.
Igor

Richard Rabbat <richard@us.fujitsu.com> wrote:<= blockquote class=3D"replbq" style=3D"border-left: 2px solid rgb(16, 16, 2= 55); margin-left: 5px; padding-left: 5px;"> hi Jean-Louis,
thanks for= the reply,
inline...


LE ROUX Jean-Louis RD-CORE-LAN wrote:=

>Hi Richard
>
>See inline,
>
>
&= gt;
>>-----Message d'origine-----
>>De : owner-ccamp@op= s.ietf.org
>>[mailto:owner-ccamp@ops.ietf.org] De la part de R= ichard Rabbat
>>Envoy=E9 : jeudi 22 d=E9cembre 2005 23:28
>= ;>=C0 : zzx-adrian@olddog.co.uk
>>Cc : ccamp@ops.ietf.org
= >>Objet : Re: Opinion on WG drafts for Multi-region/layer networks<= br>>>
>>yes to both
>>
>>two questions:<= br>>>1. since MLN is a special case of MRN, can we collapse this >>whole topic to MRN? is there a compelling reason for keeping
>>these 2 notation?
>>
>>
>= ;
>Actually a MLN is not a special case of MRN. Rather a MRN is a = special case of MLN. A network comprised of VC4 and VC4-64c capable node= is a MLN but not a MRN.
>"Layer" refers to a data plane switching= layer (e.g. VC4, VC4-64c...). While "region" refers to a switching capa= blity (PSC, TDM...).
>
>
My comment was incorrect. Let = me use better math wording.
Do all elements of the set MRN belong to = the set MLN?

I suggest that both terms MRN and MLN be clearly defi= ned somewhere.

>The term MLN is used to discuss mechanisms tha= t apply equally to layers and regions (VNT...) while the term MRN is use= d to discuss multi-regions specific mechanisms (e.g. Adaptation capabili= ty).
>
If Igor is right about adaptation (though the example is= wrong from
Huub's email), then what are other MR specific mechanisms= ?

IB>> Deborah is right. Region is purely control plane concept. Region ( e.g. TDM. WDM. etc.) s= pecific signaling object, translation of signaling messages when they pa= ss through the region boundaries is an example of  a multi-region o= peration. Your own draft about advertising available lambdas and computi= ng paths in terms of lambdas is an example of region specific operation.=
Anything to do with data plane is all about layers and not regions= .

Igor

>>2. Section 3 of draft-leroux-ccamp-gmp= ls-mrn-eval-02.txt is a
>>requirments section and therefore not= relevant to this draft
>>but belongs to draft-shiomoto-ccamp-g= mpls-mrn-reqs-03.txt.
>>there is no advantage to repeting requi= rements.
>>
>>
>
>The objective was to = ease the reading, but we can easily remove it if considered as irrelevant= .
>
>
My suggestion is to drop it in this draft and if t= here is need to have a
summary for clarity, then clarify in the req's doc.

>Thanks for your support and fo= r these comments.
>
>Regards,
>
>JL
>
= >
thanks,
richard.

>
>
>
>>than= ks,
>>richard.
>>
>>Adrian Farrel wrote:
&g= t;>
>>
>>
>>>Hi,
>>>
= >>>We have a charter milestone to start WG work on a
>>= ;>
>>>
>>Requirements I-D for
>> =
>>
>>>MRN/MLN, and also an Evaluation I-D to exa= mine how the current
>>>protocols shape up to the challenge.=
>>>
>>>There are two appropriate I-Ds that have = been around for a while.
>>>
>>>draft-shiomoto-cc= amp-gmpls-mrn-reqs-03.txt
>>>draft-leroux-ccamp-gmpls-mrn-eva= l-02.txt
>>>
>>>I propose that we make these WG d= ocuments and then give them
>>> =20
>>>
>>a thorough
>>
>>
&= gt;>>review and edit.
>>>
>>>Opinions pleas= e.
>>>
>>>Yes or no will suffice, but reasons are= always nice.
>>>
>>>Thanks,
>>>Adria= n
>>>
>>>
>>>
>>>
>= ;>>
>>>
>>
>>



Yahoo! for Good -=20 Make a difference this year.=20 --0-361610227-1135432159=:66874-- From kpm_attacks@afriel-nelson.com Sat Dec 24 19:36:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqJsC-000138-SX for ccamp-archive@megatron.ietf.org; Sat, 24 Dec 2005 19:36:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10302 for ; Sat, 24 Dec 2005 19:35:21 -0500 (EST) Received: from [71.226.41.253] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EqJvW-0007Vo-QG for ccamp-archive@ietf.org; Sat, 24 Dec 2005 19:39:55 -0500 Message-ID: <000001c60915$44cebb00$0100007f@localhost> From: "Tony Torres" To: Subject: Corel Draw Date: Sat, 24 Dec 2005 17:36:16 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60915.44CEBB00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60915.44CEBB00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60915.44CEBB00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 39 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 39 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 46 reviews)


------=_NextPart_000_0001_01C60915.44CEBB00-- From dcox10@aspenads.com Sun Dec 25 11:27:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqYiW-0005sS-W0 for ccamp-archive@megatron.ietf.org; Sun, 25 Dec 2005 11:27:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27942 for ; Sun, 25 Dec 2005 11:26:20 -0500 (EST) Received: from 201008141194.user.veloxzone.com.br ([201.8.141.194] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EqYlx-0004e0-40 for ccamp-archive@ietf.org; Sun, 25 Dec 2005 11:31:04 -0500 Message-ID: <000001c6099a$1b0ba780$0100007f@localhost> From: "Theodore Flores" To: Subject: What IS 0EM Software And Why D0 You Care? Date: Sun, 25 Dec 2005 14:31:40 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6099A.1B0BA780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6099A.1B0BA780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C6099A.1B0BA780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 34 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 35 re! views)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 32 reviews)


------=_NextPart_000_0001_01C6099A.1B0BA780-- From eve-jenta89@a-moto.com Mon Dec 26 15:27:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqywK-0008JZ-Of for ccamp-archive@megatron.ietf.org; Mon, 26 Dec 2005 15:27:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29648 for ; Mon, 26 Dec 2005 15:26:19 -0500 (EST) Received: from crous-eseo.univ-angers.fr ([194.57.169.167] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eqyyh-0003gz-GK for ccamp-archive@ietf.org; Mon, 26 Dec 2005 15:31:18 -0500 Message-ID: <000001c60a84$bed18200$0100007f@localhost> From: "Dillon Morris" To: Subject: Corel Draw Date: Mon, 26 Dec 2005 21:26:49 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60A84.BED18200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60A84.BED18200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60A84.BED18200 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 42 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 48 revie! ws)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 49 reviews)


------=_NextPart_000_0001_01C60A84.BED18200-- From ToriHubbard@jodiesel.com Mon Dec 26 16:17:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqziW-0006Bp-1n for ccamp-archive@megatron.ietf.org; Mon, 26 Dec 2005 16:17:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03990 for ; Mon, 26 Dec 2005 16:16:06 -0500 (EST) Received: from g179124.upc-g.chello.nl ([80.57.179.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EqzmC-0005Gi-0e for ccamp-archive@ietf.org; Mon, 26 Dec 2005 16:21:05 -0500 Received: from S5B@localhost by tpm.int (8.11.6/8.11.6); Mon, 26 Dec 2005 11:33:02 -0700 Message-ID: From: "Maureen Payton" Reply-To: "Maureen Payton" To: cm@ietf.org, ccamp-archive@ietf.org Subject: 0nline software, Download XP, Photoshop & others Instantly Date: Mon, 26 Dec 2005 12:28:02 -0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: ToriHubbard@jodiesel.com Content-Type: multipart/mixed; boundary="--og2OTKznzaeRxmAb" X-Spam-Score: 2.8 (++) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 vJH ----og2OTKznzaeRxmAb Content-Type: text/html; Content-Transfer-Encoding: quoted-printable O
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

TOP 10 NEW TITLES

=
= = = <= td width=3D4> 
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&n= bsp;2 Creative Suite 2
&= nbsp;3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6<= /td> Dreamweaver 8
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 10 Borland Architect 2005
  See more by this manufact= urer
   Microsoft
  = Macromedia
 =   = Adobe
  Customers also bought
   <= font face=3Dverdana,arial,helvetica size=3D1> these other items...

Microsoft Windows XP Professional *w/SP2*
Microsoft

Choose:<= td width=3D135>
 

=
List Pr= ice:$299.00
Pric= e:$49.99
You Save:$249.01 (80%)



Availability: Available for INSTANT download!
Coup= on Code: fcTtSIj
Platform: Windows XP

Sales R= ank: #1
System requirements  |  Other Versions
Date Coupon Exp= ires: December 31st, 2005
Average Cus= tomer Review:3D"5 Based on 17818 reviews. Write a review.


Adobe Creative Suite 2 *Premi= um*
Adobe=

Choose:
 

List Pr= ice:$1199.00
Pri= ce:$149.99
You Save:= $1049.01 (95%)

=

Availability: Available for INSTANT download!
C= oupon Code: uyAvjBkum
Platform: Windows XP

Sa= les Rank: #2
System requirements  |  Other Versions
Date Coupo= n Expires: December 31st, 2005
Averag= e Customer Review:3D"5 Based on 1939 reviews. Write a review.


Microsoft = Office 2003 *Professional*
Microsoft

=
Choose= :
 

<= /p>

List Price:$499.00
Price:$69.99
You Save:$429.0= 1 (85%)

<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/buttons/add-to= -cart-yellow-short.gif width=3D113 height=3D23>

Availabilit= y: Available for INSTANT download!
Coupon Code: 8Yoy9CM
= Platform: Win= dows XP

Sales Rank: #3
System requirement= s
  |  Other Versions

Date Coupon Expires: December 31st,= 2005
Average Customer Review:3D"5 Based on 16741 reviews.
Write a rev= iew.


Adobe Acrobat Professional V 7.0 Adobe

Choose:=
 

List Price:$499.00
Price:$69.99
You Save:$429.0= 1 (85%)

<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/buttons/add-to= -cart-yellow-short.gif width=3D113 height=3D23>

Availabilit= y: Available for INSTANT download!
Coupon Code: 8w1K9a
= Platform: Wind= ows XP

Sales Rank: #4
System requirements=
  |  Other Versions=

Date Coupon Expires: December 31st, = 2005
Average Customer Review:3D"5= Based on 112115 reviews. Write a rev= iew.


=
----og2OTKznzaeRxmAb-- From hejoe@4waywhores.com Mon Dec 26 23:58:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Er6uk-0002XO-JM for ccamp-archive@megatron.ietf.org; Mon, 26 Dec 2005 23:58:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18853 for ; Mon, 26 Dec 2005 23:57:12 -0500 (EST) Received: from chello084112078209.20.11.vie.surfer.at ([84.112.78.209] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Er6yV-0002c1-Vr for ccamp-archive@ietf.org; Tue, 27 Dec 2005 00:02:16 -0500 Message-ID: <000001c60acc$49899f80$0100007f@localhost> From: "Michael Scott" To: Subject: Buy OEM Software Date: Tue, 27 Dec 2005 05:58:07 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60ACC.49899F80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60ACC.49899F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 35 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60ACC.49899F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 39 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 50 revie! ws)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 42 reviews)


------=_NextPart_000_0001_01C60ACC.49899F80-- From director@7secretsproducts.com Tue Dec 27 03:51:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErAYn-0008K5-W0 for ccamp-archive@megatron.ietf.org; Tue, 27 Dec 2005 03:51:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12368 for ; Tue, 27 Dec 2005 03:50:48 -0500 (EST) Received: from bethalpark-cadent2-24-51-142-237.pittpa.adelphia.net ([24.51.142.237] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ErAca-0001Xx-SL for ccamp-archive@ietf.org; Tue, 27 Dec 2005 03:55:54 -0500 Message-ID: <000001c60aec$eceaac80$0100007f@localhost> From: "Timothy Collins" To: Subject: cheap oem soft shipping //orldwide Date: Tue, 27 Dec 2005 03:51:49 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60AEC.ECEAAC80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60AEC.ECEAAC80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60AEC.ECEAAC80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 50 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 47 revie! ws)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 35 reviews)


------=_NextPart_000_0001_01C60AEC.ECEAAC80-- From jleonard@acesvegascasino.com Tue Dec 27 07:02:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErDWy-0000q5-A2 for ccamp-archive@megatron.ietf.org; Tue, 27 Dec 2005 07:02:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04947 for ; Tue, 27 Dec 2005 07:01:05 -0500 (EST) Received: from c-71-196-161-98.hsd1.co.comcast.net ([71.196.161.98] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ErDam-0000Ig-OY for ccamp-archive@ietf.org; Tue, 27 Dec 2005 07:06:13 -0500 Message-ID: <000001c60b07$6becde80$0100007f@localhost> From: "Elijah Lopez" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Tue, 27 Dec 2005 05:02:34 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60B07.6BECDE80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.2 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60B07.6BECDE80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 42 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60B07.6BECDE80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!

!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 45 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 46 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 33 reviews)


------=_NextPart_000_0001_01C60B07.6BECDE80-- From evergreen@babyfaceheel.com Tue Dec 27 07:49:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErEGZ-00013L-TL for ccamp-archive@megatron.ietf.org; Tue, 27 Dec 2005 07:49:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11579 for ; Tue, 27 Dec 2005 07:48:15 -0500 (EST) Received: from 12-208-93-200.client.insightbb.com ([12.208.93.200] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ErEKN-0002HO-Bf for ccamp-archive@ietf.org; Tue, 27 Dec 2005 07:53:22 -0500 Message-ID: <000001c60b0e$0a7c3e00$0100007f@localhost> From: "Shawn Ross" To: Subject: Need S0ftware? Date: Tue, 27 Dec 2005 06:49:12 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60B0E.0A7C3E00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60B0E.0A7C3E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 35 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60B0E.0A7C3E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!

!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 41 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 49 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 48 reviews)


------=_NextPart_000_0001_01C60B0E.0A7C3E00-- From victori191@agundez.com Tue Dec 27 10:57:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErHCV-0000E1-QJ for ccamp-archive@megatron.ietf.org; Tue, 27 Dec 2005 10:57:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04962 for ; Tue, 27 Dec 2005 10:56:14 -0500 (EST) Received: from ti521110a080-0640.bb.online.no ([80.213.50.128] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ErHGL-0000tV-JB for ccamp-archive@ietf.org; Tue, 27 Dec 2005 11:01:24 -0500 Message-ID: <000001c60b28$4d4b0f80$0100007f@localhost> From: "Arthur Rivera" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Tue, 27 Dec 2005 16:57:06 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60B28.4D4B0F80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60B28.4D4B0F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60B28.4D4B0F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!
!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 43 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 36 reviews)!


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 32 reviews)


------=_NextPart_000_0001_01C60B28.4D4B0F80-- From bacon@1websit.com Tue Dec 27 13:18:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErJP9-0007zZ-HT for ccamp-archive@megatron.ietf.org; Tue, 27 Dec 2005 13:18:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24192 for ; Tue, 27 Dec 2005 13:17:24 -0500 (EST) Received: from pcp02554461pcs.clnt3401.mi.comcast.net ([68.32.87.118] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ErJT0-0006BI-Cn for ccamp-archive@ietf.org; Tue, 27 Dec 2005 13:22:36 -0500 Message-ID: <000001c60b3c$0e26b980$0100007f@localhost> From: "Zachary Simmons" To: Subject: What IS 0EM Software And Why D0 You Care? Date: Tue, 27 Dec 2005 13:19:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60B3C.0E26B980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60B3C.0E26B980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 31 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60B3C.0E26B980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!
!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 36 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 43 reviews)!


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 44 reviews)


------=_NextPart_000_0001_01C60B3C.0E26B980-- From toothmaker@baldan-tcs.com Tue Dec 27 13:46:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErJpu-0003xX-D4 for ccamp-archive@megatron.ietf.org; Tue, 27 Dec 2005 13:46:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27787 for ; Tue, 27 Dec 2005 13:45:03 -0500 (EST) Received: from xdsl-84-44-229-52.netcologne.de ([84.44.229.52] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ErJtl-0007A3-Qw for ccamp-archive@ietf.org; Tue, 27 Dec 2005 13:50:15 -0500 Message-ID: <000001c60b3f$e174a100$0100007f@localhost> From: "Aaron Perez" To: Subject: 0EM Software Date: Tue, 27 Dec 2005 19:45:58 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60B3F.E174A100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60B3F.E174A100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60B3F.E174A100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!
!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 45 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 35 reviews)!


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 46 reviews)


------=_NextPart_000_0001_01C60B3F.E174A100-- From owner-ccamp@ops.ietf.org Tue Dec 27 17:23:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErNEb-0005kQ-BO for ccamp-archive@megatron.ietf.org; Tue, 27 Dec 2005 17:23:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26854 for ; Tue, 27 Dec 2005 17:22:47 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErNIV-0007Fb-MH for ccamp-archive@ietf.org; Tue, 27 Dec 2005 17:28:01 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErN3x-0005gi-Hn for ccamp-data@psg.com; Tue, 27 Dec 2005 22:12:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErN3v-0005gS-4b for ccamp@ops.ietf.org; Tue, 27 Dec 2005 22:12:55 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 27 Dec 2005 14:12:38 -0800 X-IronPort-AV: i="3.99,297,1131350400"; d="scan'208"; a="384006672:sNHT44961540144" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBRMCbZe018983; Tue, 27 Dec 2005 14:12:37 -0800 (PST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Dec 2005 17:12:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Opinion on WG drafts for Multi-region/layer networks Date: Tue, 27 Dec 2005 17:12:36 -0500 Message-ID: Thread-Topic: Opinion on WG drafts for Multi-region/layer networks Thread-Index: AcYG86u5hdoYewG8RQ2jsqfx3GtM/gEPtheQ From: "Zafar Ali \(zali\)" To: , "Adrian Farrel" X-OriginalArrivalTime: 27 Dec 2005 22:12:37.0349 (UTC) FILETIME=[A523B950:01C60B32] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable > At 21:55 05/12/21 +0000, Adrian Farrel wrote: > >Hi, > > > >We have a charter milestone to start WG work on a=20 > Requirements I-D for=20 > >MRN/MLN, and also an Evaluation I-D to examine how the current=20 > >protocols shape up to the challenge. > > > >There are two appropriate I-Ds that have been around for a while. > > > >draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt > >draft-leroux-ccamp-gmpls-mrn-eval-02.txt > > > >I propose that we make these WG documents and then give them=20 > a thorough=20 > >review and edit. Yes, to both.=20 Thanks Regards... Zafar > > > >Opinions please. > > > >Yes or no will suffice, but reasons are always nice. > > > >Thanks, > >Adrian >=20 From jeanssdc@baldan-tcs.com Tue Dec 27 21:01:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErQcr-00079E-PQ for ccamp-archive@megatron.ietf.org; Tue, 27 Dec 2005 21:01:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27626 for ; Tue, 27 Dec 2005 21:00:04 -0500 (EST) Received: from c-71-198-76-228.hsd1.ca.comcast.net ([71.198.76.228] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ErQgl-0000PJ-Kv for ccamp-archive@ietf.org; Tue, 27 Dec 2005 21:05:19 -0500 Message-ID: <000001c60b7c$a349a280$0100007f@localhost> From: "Hunter Cox" To: Subject: cheap oem soft shipping //orldwide Date: Tue, 27 Dec 2005 18:01:00 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60B7C.A349A280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60B7C.A349A280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 44 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60B7C.A349A280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!
!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 48 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 37 reviews)!


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 48 reviews)


------=_NextPart_000_0001_01C60B7C.A349A280-- From ray0074@19317.com Wed Dec 28 00:28:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErTre-00072J-KQ for ccamp-archive@megatron.ietf.org; Wed, 28 Dec 2005 00:28:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16674 for ; Wed, 28 Dec 2005 00:27:31 -0500 (EST) Received: from [85.136.46.171] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ErTvb-000745-BS for ccamp-archive@ietf.org; Wed, 28 Dec 2005 00:32:48 -0500 Message-ID: <000001c60b99$7c4d9980$0100007f@localhost> From: "Jesus Robinson" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Wed, 28 Dec 2005 06:28:26 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60B99.7C4D9980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60B99.7C4D9980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 35 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60B99.7C4D9980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 48 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 48 revie! ws)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 37 reviews)


------=_NextPart_000_0001_01C60B99.7C4D9980-- From owner-ccamp@ops.ietf.org Wed Dec 28 06:17:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErZJ4-0001Xj-Mn for ccamp-archive@megatron.ietf.org; Wed, 28 Dec 2005 06:17:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24436 for ; Wed, 28 Dec 2005 06:16:12 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErZN6-00038g-Kg for ccamp-archive@ietf.org; Wed, 28 Dec 2005 06:21:33 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErZ4k-000K2i-6W for ccamp-data@psg.com; Wed, 28 Dec 2005 11:02:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: **** X-Spam-Status: No, score=4.8 required=5.0 tests=AWL,BAYES_50,HTML_40_50, HTML_MESSAGE,MIME_BASE64_NO_NAME,MIME_BASE64_TEXT,NO_REAL_NAME, RCVD_DOUBLE_IP_SPAM autolearn=no version=3.1.0 Received: from [202.103.147.144] (helo=mail2.zte.com.cn) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErZ4h-000K2M-VQ for ccamp@ops.ietf.org; Wed, 28 Dec 2005 11:02:33 +0000 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 79206.2083781988; Wed, 28 Dec 2005 20:05:25 +0800 (CST) To: ccamp@ops.ietf.org Subject: Introduction to "draft-jian-ccamp-multinodes-rsvp-restart-00". MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: jiang.weilian@zte.com.cn Date: Wed, 28 Dec 2005 19:04:24 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.3|September 14, 2004) at 2005-12-28 19:05:25, Serialize complete at 2005-12-28 19:05:25 Content-Type: multipart/alternative; boundary="=_alternative 003C7299482570E5_=" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.4 (+) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 This is a multipart message in MIME format. --=_alternative 003C7299482570E5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpXZSBzdWJtaXR0ZWQgYSBkcmFmdCAiZHJhZnQtamlhbi1jY2FtcC1tdWx0aW5v ZGVzLXJzdnAtcmVzdGFydC0wMCIgdG8gDQpJRVRGIHNvbWUgdGltZSBhZ28uDQoNClRpdGxlIG9m IG91ciBkcmFmdCBpcyAiIE1lY2hhbmlzbSBvZiBtdWx0aXBsZSBhZGphY2VudCBub2RlcyBSU1ZQ IA0KZ3JhY2VmdWwgcmVzdGFydCBTaW11bHRhbmVvdXNseSAiLg0KDQpCYXNlZCBvbiB0aGUgUlNW UCBncmFjZWZ1bCByZXN0YXJ0IGRlZmluZWQgaW4gdGhlIFJGQzM0NzMsIFJGQzMyMDksIA0KZHJh ZnQtaWV0Zi1jY2FtcC1yc3ZwIC1ub2RlLWlkLWJhc2VkLWhlbGxvLTAyIGFuZCBkcmFmdC1pZXRm LWNjYW1wLQ0KcnN2cC1yZXN0YXJ0LWV4dC0wNSwgd2UgcHV0cyBmb3J3YXJkIGV4dGVuc2lvbnMu DQoNCldlIGhhdmUgdHdvIG1vdGl2YXRpb25zIGluIG91ciBkcmFmdDoNCjGholdlIHRoaW5rIHRo ZSByZXN0YXJ0ZWQgbm9kZSBpcyB1c3VhbGx5IGF0IGEgcGFzc2l2ZSBwb3NpdGlvbi4gT25seSAN CmFmdGVyIGl0IHJlY2VpdmVzIHRoZSBSU1ZQIEdSIEhlbGxvIG1lc3NhZ2UgZnJvbSB0aGUgbmVp Z2hib3IsIHdpbGwgDQppdCAgaW5mb3JtIHRoZSBuZWlnaGJvciBvZiBpdHMgR1IgY2FwYWJpbGl0 eSBieSByZXR1cm5pbmcgdGhlIEFDSyBtZXNzYWdlLg0KU28gd2UgcHV0cyBmb3J3YXJkIGV4dGVu c2lvbnMgYnkgdXNpbmcgbXVsdGljYXN0IGFkZHJlc3MgYXMgZGVzdGluYXRpb24gDQphZGRyZXNz IG9mIEdSIEhFTExPIHJlcXVlc3QgbWVzc2FnZSBvciBhZG9wdGluZyBob3QgYmFja3VwIGtleSBk YXRhIG9mIA0KdGhlIGVzdGFibGlzaGVkIEdSIEhFTExPIGluc3RhbmNlIGJlZm9yZSByZXN0YXJp bmcgdG8gbWFrZSB0aGUgcmVzdGFydGVkIA0Kbm9kZSBjYW4gYWN0aXZlbHkgaW5mb3JtIGhpbXNl bGYgUlNWUCBncmFjZWZ1bCByZXN0YXJ0IGNhcGFiaWxpdHkgdG8gdGhlIA0KbmVpZ2hib3IuIA0K MqGiV2UgZnVydGhlciBwcm92aWRlIHRoZSByZWxldmFudCBtZWNoYW5pc20gdG8gc3VwcG9ydCBy ZWNvdmVyeSANCnByb2Nlc3NpbmcNCm9mIFJTVlAgZ3JhY2VmdWwgcmVzdGFydCBhdCBzaW11bHRh bmVvdXMgcmVzdGFydCBvZiBtdWx0aXBsZSBhZGphY2VudCANCm5vZGVzLg0KDQpTbyB3ZSB3b3Vs ZCBsaWtlIGludml0ZSBldmVyeW9uZSB0byBqb2luIHRoZSBkaXNjdXNzaW9uIGFib3V0IG91ciBk cmFmdC4gDQpBbmQgDQpsZXQgdXMga25vdyB5b3VyIG9waW5pb25zIGFib3V0IG91ciBkcmFmdC4N Cg0KDQpUaGFua3MgaW4gYWR2YW5jZS4NCg0KSmlhbmcgV2VpbGlhbg0KCgoKKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK0MXPorCyyKvJ+cP3o7qxvtPKvP6w /Lqs0MXPornpWlRFy/nT0KOsClpURbbUuMPTyrz+07XT0Mv509DIqMD7oaPH673TytXV39ei0uIK saPD3KOszrS+rbeivP7Iy8rpw+bQ7b/Jo6yyu7XDz/LIzrrOtdoKyP23vdfp1q+6zbj2yMvNuMK2 sb7Tyrz+y/m6rNDFz6K1xMirsr8Ku/Kyv7fWoaPS1MnPyfnD9732ysrTw9PauaTX99PKvP6howpJ bmZvcm1hdGlvbiBTZWN1cml0eSAgTm90aWNlo7oKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIG1haWwgaXMKc29sZWx5IHByb3BlcnR5IG9mICBaVEUgQ29ycG9yYXRpb24uIApUaGlz IG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuClJlY2lwaWVudHMgbmFtZWQgYWJv dmUgYXJlIG9ibGlnYXRlZCB0bwptYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRl ZCB0bwpkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uCnRvIG90aGVy cy4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK --=_alternative 003C7299482570E5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8ZGl2Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5IaSBhbGwsPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZSBzdWJtaXR0ZWQg YSBkcmFmdCAmcXVvdDtkcmFmdC1qaWFuLWNjYW1wLW11bHRpbm9kZXMtcnN2cC1yZXN0YXJ0LTAw JnF1b3Q7DQp0byA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklF VEYgc29tZSB0aW1lIGFnby48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPlRpdGxlIG9mIG91ciBkcmFmdCBpcyAmcXVvdDsgTWVjaGFuaXNtDQpvZiBtdWx0 aXBsZSBhZGphY2VudCBub2RlcyBSU1ZQIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Z3JhY2VmdWwgcmVzdGFydCBTaW11bHRhbmVvdXNseSAmcXVvdDsuPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CYXNlZCBvbiB0aGUg UlNWUCBncmFjZWZ1bCByZXN0YXJ0IGRlZmluZWQNCmluIHRoZSBSRkMzNDczLCBSRkMzMjA5LCA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmRyYWZ0LWlldGYtY2Nh bXAtcnN2cCAtbm9kZS1pZC1iYXNlZC1oZWxsby0wMg0KYW5kIGRyYWZ0LWlldGYtY2NhbXAtPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5yc3ZwLXJlc3RhcnQtZXh0 LTA1LCB3ZSBwdXRzIGZvcndhcmQNCmV4dGVuc2lvbnMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZSBoYXZlIHR3byBtb3RpdmF0aW9ucyBpbiBvdXIg ZHJhZnQ6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xoaJXZSB0 aGluayB0aGUgcmVzdGFydGVkIG5vZGUgaXMgdXN1YWxseQ0KYXQgYSBwYXNzaXZlIHBvc2l0aW9u LiBPbmx5IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YWZ0ZXIg aXQgcmVjZWl2ZXMgdGhlIFJTVlAgR1IgSGVsbG8NCm1lc3NhZ2UgZnJvbSB0aGUgbmVpZ2hib3Is IHdpbGwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pdCAmbmJz cDtpbmZvcm0gdGhlIG5laWdoYm9yIG9mIGl0cw0KR1IgY2FwYWJpbGl0eSBieSByZXR1cm5pbmcg dGhlIEFDSyBtZXNzYWdlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+U28gd2UgcHV0cyBmb3J3YXJkIGV4dGVuc2lvbnMgYnkgdXNpbmcNCm11bHRpY2FzdCBhZGRy ZXNzIGFzIGRlc3RpbmF0aW9uIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+YWRkcmVzcyBvZiBHUiBIRUxMTyByZXF1ZXN0IG1lc3NhZ2UNCm9yIGFkb3B0aW5nIGhv dCBiYWNrdXAga2V5IGRhdGEgb2YgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj50aGUgZXN0YWJsaXNoZWQgR1IgSEVMTE8gaW5zdGFuY2UgYmVmb3JlDQpyZXN0YXJp bmcgdG8gbWFrZSB0aGUgcmVzdGFydGVkIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+bm9kZSBjYW4gYWN0aXZlbHkgaW5mb3JtIGhpbXNlbGYgUlNWUA0KZ3JhY2Vm dWwgcmVzdGFydCBjYXBhYmlsaXR5IHRvIHRoZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPm5laWdoYm9yLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjKholdlIGZ1cnRoZXIgcHJvdmlkZSB0aGUgcmVsZXZhbnQNCm1lY2hhbmlz bSB0byBzdXBwb3J0IHJlY292ZXJ5IHByb2Nlc3Npbmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPm9mIFJTVlAgZ3JhY2VmdWwgcmVzdGFydCBhdCBzaW11bHRhbmVv dXMNCnJlc3RhcnQgb2YgbXVsdGlwbGUgYWRqYWNlbnQgbm9kZXMuPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TbyB3ZSB3b3VsZCBsaWtlIGludml0ZSBl dmVyeW9uZSB0bw0Kam9pbiB0aGUgZGlzY3Vzc2lvbiBhYm91dCBvdXIgZHJhZnQuIEFuZCA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmxldCB1cyBrbm93IHlvdXIg b3BpbmlvbnMgYWJvdXQgb3VyDQpkcmFmdC48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBpbiBhZHZhbmNlLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SmlhbmcgV2VpbGlhbjwvZm9udD48 L2Rpdj4NCjxicj48YnI+PGJyPgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKjxicj4K0MXPorCyyKvJ+cP3o7qxvtPKvP6w/Lqs0MXPornpWlRFy/nT0KOsPGJy PgpaVEW21LjD08q8/tO109DL+dPQyKjA+6Gjx+u908rV1d/XotLiPGJyPgqxo8Pco6zOtL6tt6K8 /sjLyunD5tDtv8mjrLK7tcPP8sjOus612jxicj4KyP23vdfp1q+6zbj2yMvNuMK2sb7Tyrz+y/m6 rNDFz6K1xMirsr88YnI+Crvysr+31qGj0tTJz8n5w/e99srK08PT2rmk1/fTyrz+oaM8YnI+Cklu Zm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDsmbmJzcDtOb3RpY2Wjujxicj4KVGhlJm5ic3A7 aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5i c3A7aXM8YnI+CnNvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDsmbmJzcDtaVEUmbmJz cDtDb3Jwb3JhdGlvbi4mbmJzcDs8YnI+ClRoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLjxicj4KUmVjaXBpZW50cyZuYnNwO25hbWVkJm5i c3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0bzxicj4KbWFpbnRhaW4mbmJz cDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7 dG88YnI+CmRpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMm bmJzcDtjb21tdW5pY2F0aW9uPGJyPgp0byZuYnNwO290aGVycy48YnI+CioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPgo= --=_alternative 003C7299482570E5_=-- From openminds@bitpride.com Wed Dec 28 11:27:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ere8w-0003hR-BQ for ccamp-archive@megatron.ietf.org; Wed, 28 Dec 2005 11:27:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04379 for ; Wed, 28 Dec 2005 11:26:01 -0500 (EST) Received: from chello213047127035.30.11.vie.surfer.at ([213.47.127.35] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EreCv-0008Ho-UR for ccamp-archive@ietf.org; Wed, 28 Dec 2005 11:31:23 -0500 Message-ID: <000001c60bf5$a2088c00$0100007f@localhost> From: "Brody Parker" To: Subject: 0EM Software Date: Wed, 28 Dec 2005 17:26:32 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60BF5.A2088C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60BF5.A2088C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 48 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60BF5.A2088C00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
&nbs! p;   Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT dow! nload!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 50 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on ! 49 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 49 reviews)


------=_NextPart_000_0001_01C60BF5.A2088C00-- From osmanyasar@betweenboyfriends.com Wed Dec 28 12:27:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erf5B-00029G-Ec for ccamp-archive@megatron.ietf.org; Wed, 28 Dec 2005 12:27:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13875 for ; Wed, 28 Dec 2005 12:26:12 -0500 (EST) Received: from pool-70-108-33-251.res.east.verizon.net ([70.108.33.251] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Erf9C-00031Y-9z for ccamp-archive@ietf.org; Wed, 28 Dec 2005 12:31:36 -0500 Message-ID: <000001c60bfe$1b0be180$0100007f@localhost> From: "Jorge Bennett" To: Subject: Buy OEM Software Date: Wed, 28 Dec 2005 12:27:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60BFE.1B0BE180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60BFE.1B0BE180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60BFE.1B0BE180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
&nbs! p;   Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT dow! nload!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 33 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on ! 32 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 44 reviews)


------=_NextPart_000_0001_01C60BFE.1B0BE180-- From owner-ccamp@ops.ietf.org Wed Dec 28 13:10:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erfku-0005X6-Ao for ccamp-archive@megatron.ietf.org; Wed, 28 Dec 2005 13:10:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19945 for ; Wed, 28 Dec 2005 13:09:21 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Erfot-0004mf-DD for ccamp-archive@ietf.org; Wed, 28 Dec 2005 13:14:46 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErfZ8-000McC-B3 for ccamp-data@psg.com; Wed, 28 Dec 2005 17:58:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ErfZ6-000MbS-NU for ccamp@ops.ietf.org; Wed, 28 Dec 2005 17:58:21 +0000 Received: from du-069-0061.access.clara.net ([217.158.132.61] helo=Puppy) by relay2.mail.uk.clara.net with esmtp (Exim 4.50) id 1ErfZ0-000D63-7V; Wed, 28 Dec 2005 17:58:17 +0000 Message-ID: <02f301c60bd8$ca410ca0$2a849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Kireeti Kompella" , "Dimitri Papadimitriou" , References: Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd) Date: Wed, 28 Dec 2005 17:56: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 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: 7bit Hi, >>> 1. i still don't understand the need for the [ ... ] after each term - >>> if authors could clarify this would be helpful >> >> Hmm. Well the intention was to provide extra information in a quick way. >> I guess we could replace each [...] with a full sentence such as "This >> term applies to the control plane." > > [dp] my confusion is where it is for inst. listed in Section 3.7.1 > > "Unidirectional connection (LSP) [data plane]" the term in GMPLS is > "Unidirectional LSP" while there is a non-GMPLS term as part of the > term the text introduces, i don't see anymore whether the text in brackets > refers to as an LSP is a representation of a data plane connection (or > whatever term is suitable here) > > [dp] i think in general that the GMPLS term that are listed for clarification > should make use of their exact denomination OK. I misunderstood your concern. I thought you were objecting to the notation and habit of assigning a term to a specific plane. It appears that you are more concerned that we have used a phrase not common in the GMPLS RFCs and assigned it as the main terminology. To handle that specific case we will rewrite the first sentence of 3.7.1 "In GMPLS a connection is known as a Label Switched Path (LSP)" to provide a definition of LSP (noting that there is no neat and tidy definition that is applicable in 3031 or 3945. Do you have any other specific cases? >>> 2. in general, i don't see why this document meant to clarify GMPLS >>> terms for ASON includes ASON specific terms/definitions and >>> interpretations hence the need for each "ASON terms" sub-section >>> is unclear >> >> The intention is not just to clarify the GMPLS terms, but also to provide >> a mapping. The full purpose (of making GMPLS comprehensible to ASON >> cognoscenti) is aided by the inclusion of corresponding ASON terms. What >> we have done, therefore, is split the text into: >> - a description of the GMPLS term >> - a translation into "equivalent" ASON terms >> >> Do you have an objection to this? > > [dp] let's take the example of Section 3.7.2 "A GMPLS connection is an > ASON network connection" the notion of "ASON network connection" > is probably correctly interpreted if you make use of the term "GMPLS > connection" OK. So this is the same point as before. > [dp] the other aspect is also the "equivalence" notion leads to things a > "H-LSP is a trail" probably but the whole text coming earlier in the > document seem to refer to it as a "link" No, I don't see that text. I do see where it says that LSPs created in lower layers for the purpose of providing data links (extra network flexibility) in higher layers are called hierarchical connections or LSPs (H-LSPs) That says that an H-LSP is a data link in a higher layer. But what is an H-LSP in the layer where it is found? It is a trail. > [dp] in brief, what i mean is that i find that for the "GMPLS reader" > the reverse reading quite difficult Right. But it is not supposed to provide the reverse reading. This question has been discussed several times and in several places. Just as bilingual dictionaries are published in two volumes, so we would be open to the publication of a reverse direction lexicography if anyone wants to work on it. Several people have even suggested that the correct place for that work is in the ITU-T since its purpose would be to "explain" ASON terminology to the GMPLS-world. >>> some other specifics >>> >>> 3. " Node [Control & Data Planes] is a logical combination of a >>> transport node and the controller that manages the transport node. >>> In early deployments, all control plane and data plane functions >>> associated with a transport node were collocated in a node and >>> referred to as a Label Switching Router (LSR)." >>> >>> the second sentence is imho outside the scope of such definition >> >> Some of the GMPLS RFCs are simplified by the use of "LSR", but it has been >> pointed out on numerous occasions that this creates an impression that in >> GMPLS there is *always* a tight binding (collocation) between control and >> data plane functions. As you know, this impression is contrary to reality. >> >> A couple of questions back to you. >> >> Is what it says incorrect? > > [dp] yes, current deployments still make use of what you seem to refer to as > history ("in early deployments") History is being made! We are still dealing with early deployments. This document, however, will live somewhat longer. I will remove refernce to time from the text. >> Would it help if we had a separate entry for LSR? > > [dp] yes Done. >>> 4. "3.4.1. GMPLS Terms >>> >>> Label [Control Plane] is an abstraction that provides an identifier >>> for use in the control plane in order to identify a transport plane >>> resource." >>> >>> how to interpreet an MPLS label with this definition ? or is MPLS out of >>> scope ? >> >> MPLS is out of scope because there is possible translation to ASON. >> >> Note, however, we felt it helpful to include "Packet based resource" > > [dp] this is also what i understood but it seems that closing the ring of > definition and interpretations is impossible; hence, my suggestion either > to have a complete definition of packet-related interpretation or no > coverage at all I really don't see a significant problem here. >>> 5. "3.5.1. GMPLS Terms >>> >>> Unidirectional data link end [Data Plane] is a set of resources of a >>> particular layer that belong to the same transport node and could >>> be allocated for the transfer of traffic in this layer to the same >>> neighbor in the same direction." >>> >>> what "same transport node" means here ? >> >> Erm? >> >> It means "same transport node" :-) >> >> The intention is to imply that all of the resources in the set belong to >> the same transport node. >> >> Maybe rephrase as: >> >> Unidirectional data link end [Data Plane] is a set of resources that >> all belong to the same transport node, all are in the same layer, >> and that could be allocated for the transfer of traffic in this >> layer to the same neighbor in the same direction." >> > > [dp] ok (guess you will align subsequent text along the same line) Yes. Done. >>> 6. " The need for advertisement of adaptation and termination >>> capabilities within GMPLS has been recognized and work is in >>> progress to determine how these will be advertised. It is likely >>> that they will be advertised as a single combined attribute, or as >>> separate attributes of the TE link local end associated with the >>> link interface." >>> >>> afaik, GMPLS is able to advertize "termination" capabilities - >> >> Does it? > > [dp] yes but implicitly when you have a [LSC,PSC] TE link, meaning > one side says in its interface SC descriptor TLV PSC and the other > LSC, it implicitly means the "PSC side" terminates LSC and switches > at the PSC level No. Swithiching is not termination, it is switching. It is true that the lambda flow is terminated at this point, but not that the content is delivered, rather that the content goes on being switched. So this is a very limited form of expressing termination and, as you say, it is implicit (I would rather say incidental). The more common case is surely the last link in an LSP where there is no continued switching of the content, but the data is delivered to another layer or to an application. This termination capability is not currently advertised. As I said before... >> It seems to me that it advertizes switching capabilities only. >> Termination, like adaptation, is not the same thing as switching >> capability. >> >> Switching capability says how the link terminates, but not whether the >> node can terminate data flows. Thanks, Adrian From info@mail.jdza.com Wed Dec 28 17:55:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErkD9-0004af-Sv for ccamp-archive@megatron.ietf.org; Wed, 28 Dec 2005 17:55:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00503 for ; Wed, 28 Dec 2005 17:54:48 -0500 (EST) Received: from [61.232.3.83] (helo=mail.jdza.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ErkH6-0000zy-H1 for ccamp-archive@ietf.org; Wed, 28 Dec 2005 18:00:15 -0500 Received: (qmail 32034 invoked by uid 510); 29 Dec 2005 01:20:46 +0900 Date: 29 Dec 2005 01:20:46 +0900 Message-ID: <20051228162046.32033.qmail@mail.jdza.com> From: info@jdza.com To: ccamp-archive@ietf.org Subject: $BF~6bCW$7$^$9(B X-Spam-Score: 4.8 (++++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 $B$"$J$?$KG%?17@Ls4uK>=w@-!'(B $B!Z(B165171$B!!CRH~$5$^![$r>R2p$$$?$7$^$9!*7@LsFb(B $BMF$NDL$j(B30$BK|$NM=Ls6b$r@h$KF~6b$7$^$9$N$G!"@'(B $BHs@hJ}$HO"Mm$$$?$@$1$l$P$H;W$$$^$9!#(B http://www.otakkujp.net?star2 $B:#$9$07hDj3NG'$r$*4j$$$G$-$l$P!"!ZL5NABN83![(B $B$NMxMQ; Thu, 29 Dec 2005 05:16:23 -0500 (EST) Received: from [61.232.3.56] (helo=mail.hvnk.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eruux-0005S9-Az for ccamp-archive@ietf.org; Thu, 29 Dec 2005 05:21:56 -0500 Received: (qmail 4843 invoked by uid 509); 29 Dec 2005 12:39:34 +0900 Date: 29 Dec 2005 12:39:34 +0900 Message-ID: <20051229033934.4842.qmail@mail.hvnk.com> From: info@hvnk.com To: ccamp-archive@ietf.org Subject: $BF~6bCW$7$^$9(B X-Spam-Score: 4.8 (++++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 $B$"$J$?$KG%?17@Ls4uK>=w@-!'(B $B!Z(B165171$B!!CRH~$5$^![$r>R2p$$$?$7$^$9!*7@LsFb(B $BMF$NDL$j(B30$BK|$NM=Ls6b$r@h$KF~6b$7$^$9$N$G!"@'(B $BHs@hJ}$HO"Mm$$$?$@$1$l$P$H;W$$$^$9!#(B http://www.otakkujp.net?star2 $B:#$9$07hDj3NG'$r$*4j$$$G$-$l$P!"!ZL5NABN83![(B $B$NMxMQ; Thu, 29 Dec 2005 06:41:45 -0500 (EST) Received: from gsv95-2-82-240-168-112.fbx.proxad.net ([82.240.168.112] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ErwFa-0000WL-JZ for ccamp-archive@ietf.org; Thu, 29 Dec 2005 06:47:19 -0500 Message-ID: <000001c60c97$22cb9480$0100007f@localhost> From: "Alfredo Richardson" To: Subject: Need S0ftware? Date: Thu, 29 Dec 2005 12:42:46 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60C97.22CB9480" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60C97.22CB9480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60C97.22CB9480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 47 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 46 revie! ws)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 33 reviews)


------=_NextPart_000_0001_01C60C97.22CB9480-- From biter@aneyapi.com Thu Dec 29 18:44:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es7Rs-00059O-R2 for ccamp-archive@megatron.ietf.org; Thu, 29 Dec 2005 18:44:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02627 for ; Thu, 29 Dec 2005 18:43:28 -0500 (EST) Received: from pool-71-118-100-121.lsanca.dsl-w.verizon.net ([71.118.100.121] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Es7W7-00011y-Tn for ccamp-archive@ietf.org; Thu, 29 Dec 2005 18:49:09 -0500 Message-ID: <000001c60cfb$c2227300$0100007f@localhost> From: "Armando Patterson" To: Subject: Need S0ftware? Date: Thu, 29 Dec 2005 15:44:06 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60CFB.C2227300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60CFB.C2227300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 42 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60CFB.C2227300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 ! Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   ! ; Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 44 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 33 revi! ews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 35 reviews)


------=_NextPart_000_0001_01C60CFB.C2227300-- From schildl@actualitejuive.com Fri Dec 30 06:12:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsIBo-0000au-W6 for ccamp-archive@megatron.ietf.org; Fri, 30 Dec 2005 06:12:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03824 for ; Fri, 30 Dec 2005 06:11:41 -0500 (EST) Received: from adsl-dyn-243-170.heliweb.de ([83.216.243.170] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EsIG6-0005SK-Bn for ccamp-archive@ietf.org; Fri, 30 Dec 2005 06:17:27 -0500 Message-ID: <000001c60d5c$0ba2aa80$0100007f@localhost> From: "Tyson Walker" To: Subject: Software At Low Pr1ce Date: Fri, 30 Dec 2005 12:11:43 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60D5C.0BA2AA80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60D5C.0BA2AA80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60D5C.0BA2AA80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 36 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 46 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 40 reviews)


------=_NextPart_000_0001_01C60D5C.0BA2AA80-- From punk_republic182@audioprompts.com Fri Dec 30 09:11:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsKys-0002wW-9i for ccamp-archive@megatron.ietf.org; Fri, 30 Dec 2005 09:11:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22588 for ; Fri, 30 Dec 2005 09:10:29 -0500 (EST) Received: from [85.108.21.140] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EsL3F-00033N-OU for ccamp-archive@ietf.org; Fri, 30 Dec 2005 09:16:19 -0500 Message-ID: <000001c60d74$c9399780$0100007f@localhost> From: "Quinn Sanders" To: Subject: Photoshop, Windows, Office Date: Fri, 30 Dec 2005 16:11:08 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60D74.C9399780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60D74.C9399780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60D74.C9399780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 44 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 32 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 38 reviews)


------=_NextPart_000_0001_01C60D74.C9399780-- From invisiblelibrary@albuquerquedoctors.com Fri Dec 30 18:29:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsTgr-0002kx-C2 for ccamp-archive@megatron.ietf.org; Fri, 30 Dec 2005 18:29:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26483 for ; Fri, 30 Dec 2005 18:28:29 -0500 (EST) Received: from c-24-30-75-215.hsd1.ga.comcast.net ([24.30.75.215] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EsTlJ-0006cb-Sg for ccamp-archive@ietf.org; Fri, 30 Dec 2005 18:34:22 -0500 Message-ID: <000001c60dc3$0cbaf280$0100007f@localhost> From: "Kevin Young" To: Subject: Software At Low Pr1ce Date: Fri, 30 Dec 2005 18:29:31 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60DC3.0CBAF280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60DC3.0CBAF280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 31 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60DC3.0CBAF280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 41 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 39 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 40 reviews)


------=_NextPart_000_0001_01C60DC3.0CBAF280-- From ezekiel@aachen.heimat.de Fri Dec 30 19:37:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsUkd-0002g0-M9 for ccamp-archive@megatron.ietf.org; Fri, 30 Dec 2005 19:37:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05810 for ; Fri, 30 Dec 2005 19:36:27 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsUp6-0000oT-9G for ccamp-archive@ietf.org; Fri, 30 Dec 2005 19:42:21 -0500 Received: from [211.110.171.119] (helo=211.110.171.119) by mx2.foretec.com with smtp (Exim 4.24) id 1EsUkN-0005L4-Oy for ccamp-archive@ietf.org; Fri, 30 Dec 2005 19:37:25 -0500 Message-ID: From: George King To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?SG9ybnkgcGlsbHMgLSAkMi45OS9kb3Nl?= Date: Sat, 31 Dec 2005 00:21:07 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_C6ED61FA.B623BFEA" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.4 (+++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------=_NextPart_000_0000_C6ED61FA.B623BFEA Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_0D5F9165.F91A065C" ------=_NextPart_001_0001_0D5F9165.F91A065C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Viagra - Cialis ..in 1 pack! http://www.10pills.net Only $2.99/dose! ___________________ To get removed, go here ------=_NextPart_001_0001_0D5F9165.F91A065C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Viagra - Cialis
..in 1 pack!

http://www.10pills.net

Only $2.99/dose!


___________________
To get removed, go here

------=_NextPart_001_0001_0D5F9165.F91A065C-- ------=_NextPart_000_0000_C6ED61FA.B623BFEA-- From victori191@avosdemarques.com Fri Dec 30 20:45:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsVoQ-00016h-S2 for ccamp-archive@megatron.ietf.org; Fri, 30 Dec 2005 20:45:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12159 for ; Fri, 30 Dec 2005 20:44:22 -0500 (EST) Received: from [219.94.118.123] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EsVss-0002xr-DU for ccamp-archive@ietf.org; Fri, 30 Dec 2005 20:50:18 -0500 Message-ID: <000001c60dd5$ee122700$0100007f@localhost> From: "Caden Long" To: Subject: 0EM Software Date: Sat, 31 Dec 2005 09:47:14 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60DD5.EE122700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60DD5.EE122700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60DD5.EE122700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 36 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 33 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 48 reviews)


------=_NextPart_000_0001_01C60DD5.EE122700-- From ladarozan@aodisho.com Fri Dec 30 21:59:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsWyG-00080L-BP for ccamp-archive@megatron.ietf.org; Fri, 30 Dec 2005 21:59:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18422 for ; Fri, 30 Dec 2005 21:58:39 -0500 (EST) Received: from [12.153.205.77] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EsX2k-000573-6G for ccamp-archive@ietf.org; Fri, 30 Dec 2005 22:04:36 -0500 Message-ID: <000001c60de0$6c73c680$0100007f@localhost> From: "Yahir Reed" To: Subject: cheap oem soft shipping //orldwide Date: Fri, 30 Dec 2005 20:57:32 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60DE0.6C73C680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60DE0.6C73C680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60DE0.6C73C680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 39 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 34 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 37 reviews)


------=_NextPart_000_0001_01C60DE0.6C73C680-- From debbie@biotechnetwork.com Fri Dec 30 22:44:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsXfa-000159-Oj for ccamp-archive@megatron.ietf.org; Fri, 30 Dec 2005 22:44:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22023 for ; Fri, 30 Dec 2005 22:43:25 -0500 (EST) Received: from i60-35-85-179.s02.a027.ap.plala.or.jp ([60.35.85.179] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EsXk8-0006NZ-R6 for ccamp-archive@ietf.org; Fri, 30 Dec 2005 22:49:22 -0500 Message-ID: <000001c60de6$98924600$0100007f@localhost> From: "Jimmy Campbell" To: Subject: What IS 0EM Software And Why D0 You Care? Date: Sat, 31 Dec 2005 12:44:13 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60DE6.98924600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60DE6.98924600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 35 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60DE6.98924600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 44 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 48 reviews)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 42 reviews)


------=_NextPart_000_0001_01C60DE6.98924600-- From info@mail.iokx.com Fri Dec 30 23:49:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsYgb-0006xo-Qt for ccamp-archive@megatron.ietf.org; Fri, 30 Dec 2005 23:49:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28367 for ; Fri, 30 Dec 2005 23:48:33 -0500 (EST) Received: from [61.232.3.57] (helo=mail.iokx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EsYl4-000089-JC for ccamp-archive@ietf.org; Fri, 30 Dec 2005 23:54:29 -0500 Received: (qmail 31316 invoked by uid 509); 31 Dec 2005 13:50:16 +0900 Date: 31 Dec 2005 13:50:16 +0900 Message-ID: <20051231045016.31315.qmail@mail.iokx.com> From: info@iokx.com To: ccamp-archive@ietf.org Subject: $BF~6bCW$7$^$9(B X-Spam-Score: 4.2 (++++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 $B$"$J$?$KG%?17@Ls4uK>=w@-!'(B $B!Z(B165171$B!!CRH~$5$^![$r>R2p$$$?$7$^$9!*7@LsFb(B $BMF$NDL$j(B30$BK|$NM=Ls6b$r@h$KF~6b$7$^$9$N$G!"@'(B $BHs@hJ}$HO"Mm$$$?$@$1$l$P$H;W$$$^$9!#(B http://www.otakkujp.net?star2 $B:#$9$07hDj3NG'$r$*4j$$$G$-$l$P!"!ZL5NABN83![(B $B$NMxMQ; Sat, 31 Dec 2005 18:47:35 -0500 (EST) Received: from igld-84-228-224-19.inter.net.il ([84.228.224.19] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EsqXT-0005LL-V6 for ccamp-archive@ietf.org; Sat, 31 Dec 2005 18:53:42 -0500 Message-ID: <000001c60e8e$57ee0780$0100007f@localhost> From: "Juan Russell" To: Subject: Corel Draw Date: Sun, 01 Jan 2006 01:48:05 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60E8E.57EE0780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60E8E.57EE0780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 35 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60E8E.57EE0780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

Microsoft

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 48 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 50 review! s)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 49 reviews)


------=_NextPart_000_0001_01C60E8E.57EE0780-- From jorgensencmj@ardenavery.com Sat Dec 31 19:37:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsrDz-0008IG-IW for ccamp-archive@megatron.ietf.org; Sat, 31 Dec 2005 19:37:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01100 for ; Sat, 31 Dec 2005 19:36:15 -0500 (EST) Received: from 82-35-69-14.cable.ubr01.dals.blueyonder.co.uk ([82.35.69.14] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EsrIj-0006bP-Hh for ccamp-archive@ietf.org; Sat, 31 Dec 2005 19:42:23 -0500 Message-ID: <000001c60e95$b10d6980$0100007f@localhost> From: "Hector Hall" To: Subject: Software At Low Pr1ce Date: Sat, 19 Mar 2005 07:31:30 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C60E95.B10D6980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C60E95.B10D6980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 46 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C60E95.B10D6980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

Microsoft

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 32 reviews)


Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 45 review! s)


Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 47 reviews)


------=_NextPart_000_0001_01C60E95.B10D6980-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Dec 2005 17:59:37 +0000 Message-ID: <02f301c60bd8$ca410ca0$2a849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Kireeti Kompella" , "Dimitri Papadimitriou" , Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd) Date: Wed, 28 Dec 2005 17:56:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, >>> 1. i still don't understand the need for the [ ... ] after each term - >>> if authors could clarify this would be helpful >> >> Hmm. Well the intention was to provide extra information in a quick way. >> I guess we could replace each [...] with a full sentence such as "This >> term applies to the control plane." > > [dp] my confusion is where it is for inst. listed in Section 3.7.1 > > "Unidirectional connection (LSP) [data plane]" the term in GMPLS is > "Unidirectional LSP" while there is a non-GMPLS term as part of the > term the text introduces, i don't see anymore whether the text in brackets > refers to as an LSP is a representation of a data plane connection (or > whatever term is suitable here) > > [dp] i think in general that the GMPLS term that are listed for clarification > should make use of their exact denomination OK. I misunderstood your concern. I thought you were objecting to the notation and habit of assigning a term to a specific plane. It appears that you are more concerned that we have used a phrase not common in the GMPLS RFCs and assigned it as the main terminology. To handle that specific case we will rewrite the first sentence of 3.7.1 "In GMPLS a connection is known as a Label Switched Path (LSP)" to provide a definition of LSP (noting that there is no neat and tidy definition that is applicable in 3031 or 3945. Do you have any other specific cases? >>> 2. in general, i don't see why this document meant to clarify GMPLS >>> terms for ASON includes ASON specific terms/definitions and >>> interpretations hence the need for each "ASON terms" sub-section >>> is unclear >> >> The intention is not just to clarify the GMPLS terms, but also to provide >> a mapping. The full purpose (of making GMPLS comprehensible to ASON >> cognoscenti) is aided by the inclusion of corresponding ASON terms. What >> we have done, therefore, is split the text into: >> - a description of the GMPLS term >> - a translation into "equivalent" ASON terms >> >> Do you have an objection to this? > > [dp] let's take the example of Section 3.7.2 "A GMPLS connection is an > ASON network connection" the notion of "ASON network connection" > is probably correctly interpreted if you make use of the term "GMPLS > connection" OK. So this is the same point as before. > [dp] the other aspect is also the "equivalence" notion leads to things a > "H-LSP is a trail" probably but the whole text coming earlier in the > document seem to refer to it as a "link" No, I don't see that text. I do see where it says that LSPs created in lower layers for the purpose of providing data links (extra network flexibility) in higher layers are called hierarchical connections or LSPs (H-LSPs) That says that an H-LSP is a data link in a higher layer. But what is an H-LSP in the layer where it is found? It is a trail. > [dp] in brief, what i mean is that i find that for the "GMPLS reader" > the reverse reading quite difficult Right. But it is not supposed to provide the reverse reading. This question has been discussed several times and in several places. Just as bilingual dictionaries are published in two volumes, so we would be open to the publication of a reverse direction lexicography if anyone wants to work on it. Several people have even suggested that the correct place for that work is in the ITU-T since its purpose would be to "explain" ASON terminology to the GMPLS-world. >>> some other specifics >>> >>> 3. " Node [Control & Data Planes] is a logical combination of a >>> transport node and the controller that manages the transport node. >>> In early deployments, all control plane and data plane functions >>> associated with a transport node were collocated in a node and >>> referred to as a Label Switching Router (LSR)." >>> >>> the second sentence is imho outside the scope of such definition >> >> Some of the GMPLS RFCs are simplified by the use of "LSR", but it has been >> pointed out on numerous occasions that this creates an impression that in >> GMPLS there is *always* a tight binding (collocation) between control and >> data plane functions. As you know, this impression is contrary to reality. >> >> A couple of questions back to you. >> >> Is what it says incorrect? > > [dp] yes, current deployments still make use of what you seem to refer to as > history ("in early deployments") History is being made! We are still dealing with early deployments. This document, however, will live somewhat longer. I will remove refernce to time from the text. >> Would it help if we had a separate entry for LSR? > > [dp] yes Done. >>> 4. "3.4.1. GMPLS Terms >>> >>> Label [Control Plane] is an abstraction that provides an identifier >>> for use in the control plane in order to identify a transport plane >>> resource." >>> >>> how to interpreet an MPLS label with this definition ? or is MPLS out of >>> scope ? >> >> MPLS is out of scope because there is possible translation to ASON. >> >> Note, however, we felt it helpful to include "Packet based resource" > > [dp] this is also what i understood but it seems that closing the ring of > definition and interpretations is impossible; hence, my suggestion either > to have a complete definition of packet-related interpretation or no > coverage at all I really don't see a significant problem here. >>> 5. "3.5.1. GMPLS Terms >>> >>> Unidirectional data link end [Data Plane] is a set of resources of a >>> particular layer that belong to the same transport node and could >>> be allocated for the transfer of traffic in this layer to the same >>> neighbor in the same direction." >>> >>> what "same transport node" means here ? >> >> Erm? >> >> It means "same transport node" :-) >> >> The intention is to imply that all of the resources in the set belong to >> the same transport node. >> >> Maybe rephrase as: >> >> Unidirectional data link end [Data Plane] is a set of resources that >> all belong to the same transport node, all are in the same layer, >> and that could be allocated for the transfer of traffic in this >> layer to the same neighbor in the same direction." >> > > [dp] ok (guess you will align subsequent text along the same line) Yes. Done. >>> 6. " The need for advertisement of adaptation and termination >>> capabilities within GMPLS has been recognized and work is in >>> progress to determine how these will be advertised. It is likely >>> that they will be advertised as a single combined attribute, or as >>> separate attributes of the TE link local end associated with the >>> link interface." >>> >>> afaik, GMPLS is able to advertize "termination" capabilities - >> >> Does it? > > [dp] yes but implicitly when you have a [LSC,PSC] TE link, meaning > one side says in its interface SC descriptor TLV PSC and the other > LSC, it implicitly means the "PSC side" terminates LSC and switches > at the PSC level No. Swithiching is not termination, it is switching. It is true that the lambda flow is terminated at this point, but not that the content is delivered, rather that the content goes on being switched. So this is a very limited form of expressing termination and, as you say, it is implicit (I would rather say incidental). The more common case is surely the last link in an LSP where there is no continued switching of the content, but the data is delivered to another layer or to an application. This termination capability is not currently advertised. As I said before... >> It seems to me that it advertizes switching capabilities only. >> Termination, like adaptation, is not the same thing as switching >> capability. >> >> Switching capability says how the link terminates, but not whether the >> node can terminate data flows. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Dec 2005 11:04:23 +0000 To: ccamp@ops.ietf.org Subject: Introduction to "draft-jian-ccamp-multinodes-rsvp-restart-00". MIME-Version: 1.0 Message-ID: From: jiang.weilian@zte.com.cn Date: Wed, 28 Dec 2005 19:04:24 +0800 Content-Type: multipart/alternative; boundary="=_alternative 003C7299482570E5_=" This is a multipart message in MIME format. --=_alternative 003C7299482570E5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpXZSBzdWJtaXR0ZWQgYSBkcmFmdCAiZHJhZnQtamlhbi1jY2FtcC1tdWx0aW5v ZGVzLXJzdnAtcmVzdGFydC0wMCIgdG8gDQpJRVRGIHNvbWUgdGltZSBhZ28uDQoNClRpdGxlIG9m IG91ciBkcmFmdCBpcyAiIE1lY2hhbmlzbSBvZiBtdWx0aXBsZSBhZGphY2VudCBub2RlcyBSU1ZQ IA0KZ3JhY2VmdWwgcmVzdGFydCBTaW11bHRhbmVvdXNseSAiLg0KDQpCYXNlZCBvbiB0aGUgUlNW UCBncmFjZWZ1bCByZXN0YXJ0IGRlZmluZWQgaW4gdGhlIFJGQzM0NzMsIFJGQzMyMDksIA0KZHJh ZnQtaWV0Zi1jY2FtcC1yc3ZwIC1ub2RlLWlkLWJhc2VkLWhlbGxvLTAyIGFuZCBkcmFmdC1pZXRm LWNjYW1wLQ0KcnN2cC1yZXN0YXJ0LWV4dC0wNSwgd2UgcHV0cyBmb3J3YXJkIGV4dGVuc2lvbnMu DQoNCldlIGhhdmUgdHdvIG1vdGl2YXRpb25zIGluIG91ciBkcmFmdDoNCjGholdlIHRoaW5rIHRo ZSByZXN0YXJ0ZWQgbm9kZSBpcyB1c3VhbGx5IGF0IGEgcGFzc2l2ZSBwb3NpdGlvbi4gT25seSAN CmFmdGVyIGl0IHJlY2VpdmVzIHRoZSBSU1ZQIEdSIEhlbGxvIG1lc3NhZ2UgZnJvbSB0aGUgbmVp Z2hib3IsIHdpbGwgDQppdCAgaW5mb3JtIHRoZSBuZWlnaGJvciBvZiBpdHMgR1IgY2FwYWJpbGl0 eSBieSByZXR1cm5pbmcgdGhlIEFDSyBtZXNzYWdlLg0KU28gd2UgcHV0cyBmb3J3YXJkIGV4dGVu c2lvbnMgYnkgdXNpbmcgbXVsdGljYXN0IGFkZHJlc3MgYXMgZGVzdGluYXRpb24gDQphZGRyZXNz IG9mIEdSIEhFTExPIHJlcXVlc3QgbWVzc2FnZSBvciBhZG9wdGluZyBob3QgYmFja3VwIGtleSBk YXRhIG9mIA0KdGhlIGVzdGFibGlzaGVkIEdSIEhFTExPIGluc3RhbmNlIGJlZm9yZSByZXN0YXJp bmcgdG8gbWFrZSB0aGUgcmVzdGFydGVkIA0Kbm9kZSBjYW4gYWN0aXZlbHkgaW5mb3JtIGhpbXNl bGYgUlNWUCBncmFjZWZ1bCByZXN0YXJ0IGNhcGFiaWxpdHkgdG8gdGhlIA0KbmVpZ2hib3IuIA0K MqGiV2UgZnVydGhlciBwcm92aWRlIHRoZSByZWxldmFudCBtZWNoYW5pc20gdG8gc3VwcG9ydCBy ZWNvdmVyeSANCnByb2Nlc3NpbmcNCm9mIFJTVlAgZ3JhY2VmdWwgcmVzdGFydCBhdCBzaW11bHRh bmVvdXMgcmVzdGFydCBvZiBtdWx0aXBsZSBhZGphY2VudCANCm5vZGVzLg0KDQpTbyB3ZSB3b3Vs ZCBsaWtlIGludml0ZSBldmVyeW9uZSB0byBqb2luIHRoZSBkaXNjdXNzaW9uIGFib3V0IG91ciBk cmFmdC4gDQpBbmQgDQpsZXQgdXMga25vdyB5b3VyIG9waW5pb25zIGFib3V0IG91ciBkcmFmdC4N Cg0KDQpUaGFua3MgaW4gYWR2YW5jZS4NCg0KSmlhbmcgV2VpbGlhbg0KCgoKKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK0MXPorCyyKvJ+cP3o7qxvtPKvP6w /Lqs0MXPornpWlRFy/nT0KOsClpURbbUuMPTyrz+07XT0Mv509DIqMD7oaPH673TytXV39ei0uIK saPD3KOszrS+rbeivP7Iy8rpw+bQ7b/Jo6yyu7XDz/LIzrrOtdoKyP23vdfp1q+6zbj2yMvNuMK2 sb7Tyrz+y/m6rNDFz6K1xMirsr8Ku/Kyv7fWoaPS1MnPyfnD9732ysrTw9PauaTX99PKvP6howpJ bmZvcm1hdGlvbiBTZWN1cml0eSAgTm90aWNlo7oKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIG1haWwgaXMKc29sZWx5IHByb3BlcnR5IG9mICBaVEUgQ29ycG9yYXRpb24uIApUaGlz IG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuClJlY2lwaWVudHMgbmFtZWQgYWJv dmUgYXJlIG9ibGlnYXRlZCB0bwptYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRl ZCB0bwpkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uCnRvIG90aGVy cy4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK --=_alternative 003C7299482570E5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8ZGl2Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5IaSBhbGwsPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZSBzdWJtaXR0ZWQg YSBkcmFmdCAmcXVvdDtkcmFmdC1qaWFuLWNjYW1wLW11bHRpbm9kZXMtcnN2cC1yZXN0YXJ0LTAw JnF1b3Q7DQp0byA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklF VEYgc29tZSB0aW1lIGFnby48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPlRpdGxlIG9mIG91ciBkcmFmdCBpcyAmcXVvdDsgTWVjaGFuaXNtDQpvZiBtdWx0 aXBsZSBhZGphY2VudCBub2RlcyBSU1ZQIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Z3JhY2VmdWwgcmVzdGFydCBTaW11bHRhbmVvdXNseSAmcXVvdDsuPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CYXNlZCBvbiB0aGUg UlNWUCBncmFjZWZ1bCByZXN0YXJ0IGRlZmluZWQNCmluIHRoZSBSRkMzNDczLCBSRkMzMjA5LCA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmRyYWZ0LWlldGYtY2Nh bXAtcnN2cCAtbm9kZS1pZC1iYXNlZC1oZWxsby0wMg0KYW5kIGRyYWZ0LWlldGYtY2NhbXAtPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5yc3ZwLXJlc3RhcnQtZXh0 LTA1LCB3ZSBwdXRzIGZvcndhcmQNCmV4dGVuc2lvbnMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZSBoYXZlIHR3byBtb3RpdmF0aW9ucyBpbiBvdXIg ZHJhZnQ6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xoaJXZSB0 aGluayB0aGUgcmVzdGFydGVkIG5vZGUgaXMgdXN1YWxseQ0KYXQgYSBwYXNzaXZlIHBvc2l0aW9u LiBPbmx5IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YWZ0ZXIg aXQgcmVjZWl2ZXMgdGhlIFJTVlAgR1IgSGVsbG8NCm1lc3NhZ2UgZnJvbSB0aGUgbmVpZ2hib3Is IHdpbGwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pdCAmbmJz cDtpbmZvcm0gdGhlIG5laWdoYm9yIG9mIGl0cw0KR1IgY2FwYWJpbGl0eSBieSByZXR1cm5pbmcg dGhlIEFDSyBtZXNzYWdlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+U28gd2UgcHV0cyBmb3J3YXJkIGV4dGVuc2lvbnMgYnkgdXNpbmcNCm11bHRpY2FzdCBhZGRy ZXNzIGFzIGRlc3RpbmF0aW9uIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+YWRkcmVzcyBvZiBHUiBIRUxMTyByZXF1ZXN0IG1lc3NhZ2UNCm9yIGFkb3B0aW5nIGhv dCBiYWNrdXAga2V5IGRhdGEgb2YgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj50aGUgZXN0YWJsaXNoZWQgR1IgSEVMTE8gaW5zdGFuY2UgYmVmb3JlDQpyZXN0YXJp bmcgdG8gbWFrZSB0aGUgcmVzdGFydGVkIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+bm9kZSBjYW4gYWN0aXZlbHkgaW5mb3JtIGhpbXNlbGYgUlNWUA0KZ3JhY2Vm dWwgcmVzdGFydCBjYXBhYmlsaXR5IHRvIHRoZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPm5laWdoYm9yLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjKholdlIGZ1cnRoZXIgcHJvdmlkZSB0aGUgcmVsZXZhbnQNCm1lY2hhbmlz bSB0byBzdXBwb3J0IHJlY292ZXJ5IHByb2Nlc3Npbmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPm9mIFJTVlAgZ3JhY2VmdWwgcmVzdGFydCBhdCBzaW11bHRhbmVv dXMNCnJlc3RhcnQgb2YgbXVsdGlwbGUgYWRqYWNlbnQgbm9kZXMuPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TbyB3ZSB3b3VsZCBsaWtlIGludml0ZSBl dmVyeW9uZSB0bw0Kam9pbiB0aGUgZGlzY3Vzc2lvbiBhYm91dCBvdXIgZHJhZnQuIEFuZCA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmxldCB1cyBrbm93IHlvdXIg b3BpbmlvbnMgYWJvdXQgb3VyDQpkcmFmdC48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBpbiBhZHZhbmNlLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SmlhbmcgV2VpbGlhbjwvZm9udD48 L2Rpdj4NCjxicj48YnI+PGJyPgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKjxicj4K0MXPorCyyKvJ+cP3o7qxvtPKvP6w/Lqs0MXPornpWlRFy/nT0KOsPGJy PgpaVEW21LjD08q8/tO109DL+dPQyKjA+6Gjx+u908rV1d/XotLiPGJyPgqxo8Pco6zOtL6tt6K8 /sjLyunD5tDtv8mjrLK7tcPP8sjOus612jxicj4KyP23vdfp1q+6zbj2yMvNuMK2sb7Tyrz+y/m6 rNDFz6K1xMirsr88YnI+Crvysr+31qGj0tTJz8n5w/e99srK08PT2rmk1/fTyrz+oaM8YnI+Cklu Zm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDsmbmJzcDtOb3RpY2Wjujxicj4KVGhlJm5ic3A7 aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5i c3A7aXM8YnI+CnNvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDsmbmJzcDtaVEUmbmJz cDtDb3Jwb3JhdGlvbi4mbmJzcDs8YnI+ClRoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlv biZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLjxicj4KUmVjaXBpZW50cyZuYnNwO25hbWVkJm5i c3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0bzxicj4KbWFpbnRhaW4mbmJz cDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7 dG88YnI+CmRpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMm bmJzcDtjb21tdW5pY2F0aW9uPGJyPgp0byZuYnNwO290aGVycy48YnI+CioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPgo= --=_alternative 003C7299482570E5_=-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Dec 2005 22:14: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: Opinion on WG drafts for Multi-region/layer networks Date: Tue, 27 Dec 2005 17:12:36 -0500 Message-ID: Thread-Topic: Opinion on WG drafts for Multi-region/layer networks Thread-Index: AcYG86u5hdoYewG8RQ2jsqfx3GtM/gEPtheQ From: "Zafar Ali \(zali\)" To: , "Adrian Farrel" > At 21:55 05/12/21 +0000, Adrian Farrel wrote: > >Hi, > > > >We have a charter milestone to start WG work on a=20 > Requirements I-D for=20 > >MRN/MLN, and also an Evaluation I-D to examine how the current=20 > >protocols shape up to the challenge. > > > >There are two appropriate I-Ds that have been around for a while. > > > >draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt > >draft-leroux-ccamp-gmpls-mrn-eval-02.txt > > > >I propose that we make these WG documents and then give them=20 > a thorough=20 > >review and edit. Yes, to both.=20 Thanks Regards... Zafar > > > >Opinions please. > > > >Yes or no will suffice, but reasons are always nice. > > > >Thanks, > >Adrian >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 24 Dec 2005 13:49:43 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fq27rEy3hZyu4pO6xuH/yl5vH4IB4YALKCtyp3aFwY6c0JlRVr6hVNA0zjJR7qs88AjD8kHbJTUq0OaCLnfmZ1lw+oHpvJOCsH1WlXXoyP2wKtVx39xzRNUnxN6Dw4qubpQ48G6XdxRsmjL+oLVexdgLIi+eI5zr+vkUxfIERZU= ; Message-ID: <20051224134919.70647.qmail@web30807.mail.mud.yahoo.com> Date: Sat, 24 Dec 2005 05:49:19 -0800 (PST) From: Igor Bryskin Subject: Re: Opinion on WG drafts for Multi-region/layer networks To: Richard Rabbat , LE ROUX Jean-Louis RD-CORE-LAN Cc: adrian@olddog.co.uk, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-361610227-1135432159=:66874" Content-Transfer-Encoding: 8bit --0-361610227-1135432159=:66874 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Richard, See in line. Igor Richard Rabbat wrote: hi Jean-Louis, thanks for the reply, inline... LE ROUX Jean-Louis RD-CORE-LAN wrote: >Hi Richard > >See inline, > > > >>-----Message d'origine----- >>De : owner-ccamp@ops.ietf.org >>[mailto:owner-ccamp@ops.ietf.org] De la part de Richard Rabbat >>Envoyé : jeudi 22 décembre 2005 23:28 >>À : zzx-adrian@olddog.co.uk >>Cc : ccamp@ops.ietf.org >>Objet : Re: Opinion on WG drafts for Multi-region/layer networks >> >>yes to both >> >>two questions: >>1. since MLN is a special case of MRN, can we collapse this >>whole topic to MRN? is there a compelling reason for keeping >>these 2 notation? >> >> > >Actually a MLN is not a special case of MRN. Rather a MRN is a special case of MLN. A network comprised of VC4 and VC4-64c capable node is a MLN but not a MRN. >"Layer" refers to a data plane switching layer (e.g. VC4, VC4-64c...). While "region" refers to a switching capablity (PSC, TDM...). > > My comment was incorrect. Let me use better math wording. Do all elements of the set MRN belong to the set MLN? I suggest that both terms MRN and MLN be clearly defined somewhere. >The term MLN is used to discuss mechanisms that apply equally to layers and regions (VNT...) while the term MRN is used to discuss multi-regions specific mechanisms (e.g. Adaptation capability). > If Igor is right about adaptation (though the example is wrong from Huub's email), then what are other MR specific mechanisms? IB>> Deborah is right. Region is purely control plane concept. Region ( e.g. TDM. WDM. etc.) specific signaling object, translation of signaling messages when they pass through the region boundaries is an example of a multi-region operation. Your own draft about advertising available lambdas and computing paths in terms of lambdas is an example of region specific operation. Anything to do with data plane is all about layers and not regions. Igor >>2. Section 3 of draft-leroux-ccamp-gmpls-mrn-eval-02.txt is a >>requirments section and therefore not relevant to this draft >>but belongs to draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt. >>there is no advantage to repeting requirements. >> >> > >The objective was to ease the reading, but we can easily remove it if considered as irrelevant. > > My suggestion is to drop it in this draft and if there is need to have a summary for clarity, then clarify in the req's doc. >Thanks for your support and for these comments. > >Regards, > >JL > > thanks, richard. > > > >>thanks, >>richard. >> >>Adrian Farrel wrote: >> >> >> >>>Hi, >>> >>>We have a charter milestone to start WG work on a >>> >>> >>Requirements I-D for >> >> >>>MRN/MLN, and also an Evaluation I-D to examine how the current >>>protocols shape up to the challenge. >>> >>>There are two appropriate I-Ds that have been around for a while. >>> >>>draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt >>>draft-leroux-ccamp-gmpls-mrn-eval-02.txt >>> >>>I propose that we make these WG documents and then give them >>> >>> >>a thorough >> >> >>>review and edit. >>> >>>Opinions please. >>> >>>Yes or no will suffice, but reasons are always nice. >>> >>>Thanks, >>>Adrian >>> >>> >>> >>> >>> >>> >> >> --------------------------------- Yahoo! for Good - Make a difference this year. --0-361610227-1135432159=:66874 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Richard,

See in line.
Igor


Richard Rabbat <richard@us.fujitsu.com> wrote:
hi Jean-Louis,
thanks for the reply,
inline...


LE ROUX Jean-Louis RD-CORE-LAN wrote:

>Hi Richard
>
>See inline,
>
>
>
>>-----Message d'origine-----
>>De : owner-ccamp@ops.ietf.org
>>[mailto:owner-ccamp@ops.ietf.org] De la part de Richard Rabbat
>>Envoyé : jeudi 22 décembre 2005 23:28
>>À : zzx-adrian@olddog.co.uk
>>Cc : ccamp@ops.ietf.org
>>Objet : Re: Opinion on WG drafts for Multi-region/layer networks
>>
>>yes to both
>>
>>two questions:
>>1. since MLN is a special case of MRN, can we collapse this
>>whole topic to MRN? is there a compelling reason for keeping
>>these 2 notation?
>>
>>
>
>Actually a MLN is not a special case of MRN. Rather a MRN is a special case of MLN. A network comprised of VC4 and VC4-64c capable node is a MLN but not a MRN.
>"Layer" refers to a data plane switching layer (e.g. VC4, VC4-64c...). While "region" refers to a switching capablity (PSC, TDM...).
>
>
My comment was incorrect. Let me use better math wording.
Do all elements of the set MRN belong to the set MLN?

I suggest that both terms MRN and MLN be clearly defined somewhere.

>The term MLN is used to discuss mechanisms that apply equally to layers and regions (VNT...) while the term MRN is used to discuss multi-regions specific mechanisms (e.g. Adaptation capability).
>
If Igor is right about adaptation (though the example is wrong from
Huub's email), then what are other MR specific mechanisms?

IB>> Deborah is right. Region is purely control plane concept. Region ( e.g. TDM. WDM. etc.) specific signaling object, translation of signaling messages when they pass through the region boundaries is an example of  a multi-region operation. Your own draft about advertising available lambdas and computing paths in terms of lambdas is an example of region specific operation.
Anything to do with data plane is all about layers and not regions.

Igor

>>2. Section 3 of draft-leroux-ccamp-gmpls-mrn-eval-02.txt is a
>>requirments section and therefore not relevant to this draft
>>but belongs to draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt.
>>there is no advantage to repeting requirements.
>>
>>
>
>The objective was to ease the reading, but we can easily remove it if considered as irrelevant.
>
>
My suggestion is to drop it in this draft and if there is need to have a
summary for clarity, then clarify in the req's doc.

>Thanks for your support and for these comments.
>
>Regards,
>
>JL
>
>
thanks,
richard.

>
>
>
>>thanks,
>>richard.
>>
>>Adrian Farrel wrote:
>>
>>
>>
>>>Hi,
>>>
>>>We have a charter milestone to start WG work on a
>>>
>>>
>>Requirements I-D for
>>
>>
>>>MRN/MLN, and also an Evaluation I-D to examine how the current
>>>protocols shape up to the challenge.
>>>
>>>There are two appropriate I-Ds that have been around for a while.
>>>
>>>draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt
>>>draft-leroux-ccamp-gmpls-mrn-eval-02.txt
>>>
>>>I propose that we make these WG documents and then give them
>>>
>>>
>>a thorough
>>
>>
>>>review and edit.
>>>
>>>Opinions please.
>>>
>>>Yes or no will suffice, but reasons are always nice.
>>>
>>>Thanks,
>>>Adrian
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>



Yahoo! for Good - Make a difference this year. --0-361610227-1135432159=:66874-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 24 Dec 2005 13:34:02 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=K4GfHslAG4UnZiagpoOUV0UFqZu7g1lM7OHVx+XOEWOCU24K0qMv2p1kYHYLqRgLmmOR4y2BbEsgzJrLKFG3IBkloSi+/sX+4SiPwoIY8/s1sHAjCVFTwEgUmv4xL5pObbefMpQKgt5dq92q/RynFCf8g1WcUJSZTI2s8hdU7+o= ; Message-ID: <20051224133230.23861.qmail@web30809.mail.mud.yahoo.com> Date: Sat, 24 Dec 2005 05:32:30 -0800 (PST) From: Igor Bryskin Subject: Re: Opinion on WG drafts for Multi-region/layer networks To: Huub van Helvoort , Igor Bryskin Cc: LE ROUX Jean-Louis RD-CORE-LAN , adrian@olddog.co.uk, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1899917514-1135431150=:23564" Content-Transfer-Encoding: 8bit --0-1899917514-1135431150=:23564 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Huub, I am sure you are right. My only point - and I see you agree with me - that adaptation capabilities - to adopt/to be adopted - is a property of layer. Igor Huub van Helvoort wrote: Hello Igor, I have a small correction see [hvh]: > The term MLN is used to discuss mechanisms that apply equally to layers and > regions (VNT...) while the term MRN is used to discuss multi-regions > specific mechanisms (e.g. Adaptation capability). > ; > IB>> Disagree. Adaptation capability is entirely MLN issue. According to > your own example you need to adopt VC4 onto VC4-64c. There exists no adaptation function with VC-4 client and VC-4-64c as server. A VC-4-64c can be used as a server to transport a 10GbE LAN client signal, or other 10 Gbit/s signals using e.g. GFP. A VC-4 can be used as a server for VC-3, VC-12, VC-11 signals, be a member of a VC-4-64v, or thransport a 150 Mbit/s client signal using e.g. GFP. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1899917514-1135431150=:23564 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Huub,

I am sure you are right. My only point - and I see you agree with me - that adaptation capabilities - to adopt/to be adopted - is a property of layer.

Igor

Huub van Helvoort <hhelvoort@chello.nl> wrote:
Hello Igor,

I have a small correction see [hvh]:

> The term MLN is used to discuss mechanisms that apply equally to layers and
> regions (VNT...) while the term MRN is used to discuss multi-regions
> specific mechanisms (e.g. Adaptation capability).
> ;
> IB>> Disagree. Adaptation capability is entirely MLN issue. According to
> your own example you need to adopt VC4 onto VC4-64c.

There exists no adaptation function with VC-4 client and
VC-4-64c as server.
A VC-4-64c can be used as a server to transport a 10GbE LAN
client signal, or other 10 Gbit/s signals using e.g. GFP.
A VC-4 can be used as a server for VC-3, VC-12, VC-11 signals,
be a member of a VC-4-64v, or thransport a 150 Mbit/s client
signal using e.g. GFP.

Cheers, Huub.

--
================================================================
http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...



Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-1899917514-1135431150=:23564-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 24 Dec 2005 00:24:03 +0000 Message-ID: <43AC94DE.4060608@lab.ntt.co.jp> Date: Sat, 24 Dec 2005 09:22:54 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Huub van Helvoort CC: LE ROUX Jean-Louis RD-CORE-LAN , Richard Rabbat , adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Huub Thank you for your support and comments. Please see in line. Huub van Helvoort wrote: > Hello JL, > > You explained: > >>> two questions: 1. since MLN is a special case of MRN, can we >>> collapse this whole topic to MRN? is there a compelling reason for >>> keeping these 2 notation? >> >> >> Actually a MLN is not a special case of MRN. Rather a MRN is a >> special case of MLN. A network comprised of VC4 and VC4-64c capable >> node is a MLN but not a MRN. "Layer" refers to a data plane switching >> layer (e.g. VC4, VC4-64c...). While "region" refers to a switching >> capablity (PSC, TDM...). The term MLN is used to discuss mechanisms >> that apply equally to layers and regions (VNT...) while the term MRN >> is used to discuss multi-regions specific mechanisms (e.g. Adaptation >> capability). > > > I am still confused by the definition of MRN. > Suppose I have a TDM MRN, I can distinguish in this TDM MRN e.g. > VC-12 layer switching, VC-4 layer switching, MS-n layer switching, > so according to the above all MLN. > Why is an MRN then a special case of MLN. As JL explained, a MRN is a special case of MLN. As far as the same interface switching capability is used, the MLN is not called the MRN [RFC4206]. The same switching type is used in control plane as long as it is in the same region. The switching type TDM is used in control plane of the TDM multi-layer network consisting of VC-12 and VC-4 for instance. A region uniquely identifies a particular data plane technology (PSC, L2SC, TDM, LSC, and FSC) while a layer describes a data plane switching granularity level. A region (e.g. TDM) can be sub-divided into smaller granularity based on the bandwidth that defines the "data plane switching layers" (e.g. from VC-11 to VC4-256c in TDM). In other words, more than one data plane layer can be associated to the same region (e.g. both VC4 and VC12 are associated to TDM). > > With the next generation nodes: Multi Service Platforms within > the same node there can also be ethernet switching on top of > the above mentioned TDM MRN and optical switching (DWDM) below > this TDM MRN.... > > IMO the definition of MRN will be very difficult (impossible). > > I would propose to use only the MLN definition, with this layering > and partitioning a network can be described completely. Thank you for your comments. Again a MRN is a special case of MLN. The term MLN could replace the term MRN in our documents where appropriate. We should see whether appropriate wording is used in the next revision to resolve confusion. > > Cheers, Huub. > Thanks, Kohei Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Dec 2005 23:56:40 +0000 To: Richard Rabbat Cc: adrian@olddog.co.uk, ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" , Huub van Helvoort , LE ROUX Jean-Louis RD-CORE-LAN , owner-ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Sat, 24 Dec 2005 00:54:31 +0100 Content-Type: multipart/alternative; boundary="=_alternative 00835632C12570E0_=" This is a multipart message in MIME format. --=_alternative 00835632C12570E0_= Content-Type: text/plain; charset="US-ASCII" richard > I understand what a region is but see no definition of a multi-region > network anywhere. see page 3. > For example, when is it the case that you don't have a multi-layer > network? see section 3, in summary, it says multiple regions always cover multiple layers but not the other way around Richard Rabbat Sent by: owner-ccamp@ops.ietf.org 23/12/2005 22:20 To: "Brungard, Deborah A, ALABS" cc: Huub van Helvoort , LE ROUX Jean-Louis RD-CORE-LAN , adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks hi Deborah, thanks for your comments. sorry for being so slow today; must be the wine or is it the martini? :-) Your description is different from that of JL as he is saying that MRN is a special case of MLN but you're saying that they refer to different planes. I understand what a region is but see no definition of a multi-region network anywhere. the lexico draft is clear in describing layers and regions but the MLN/MRN concepts don't seem to be defined. For example, when is it the case that you don't have a multi-layer network? A network is by definition multi-layer since it follows some layering (OSI or otherwise). Is there a network that doesn't have a physical layer, mac layer and above? thanks, and happy holidays! Richard. Brungard, Deborah A, ALABS wrote: >Hi all, > >As JL notes, MLN is referring to data plane and MRN to (GMPLS) control >plane. A MLN may support one ISC or multiple ISCs i.e. GMPLS regions (a >GMPLS region is defined in RFC 3495/4206,,). In the updated >requirements draft for Nov's meeting, we added text to clarify MRN and >MLN, refer to section 1 and 3.1: >"A data plane layer is associated with a region in the control plane >(e.g. VC4 associated to TDM, IP associated to PSC). However, more than >one data plane layer can be associated to the same region (e.g. both VC4 >and VC12 are associated to TDM)." > >Richard, in the earlier versions of this draft, we thought also we >should only use GMPLS constructs, and we had based the discussion on >region. Though then many were confused how (control) region related to >(data) multi-layer networks. We included in this latest version both >terms to help distinguish between the data plane and control plane. >Similar to the lexio draft. Take a look at section 1 and 3.1, and if you >have suggestions, please send. > >(an eggnog/whisky/wine/martini should also help when reading - here >(EST) it is just about that time - 'till next year - Good Holidays >everyone) >Deborah > >-----Original Message----- >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >Behalf Of Huub van Helvoort >Sent: Friday, December 23, 2005 9:30 AM >To: LE ROUX Jean-Louis RD-CORE-LAN >Cc: Richard Rabbat; adrian@olddog.co.uk; ccamp@ops.ietf.org >Subject: Re: Opinion on WG drafts for Multi-region/layer networks > >Hello JL, > >You explained: > > > >>>two questions: 1. since MLN is a special case of MRN, can we >>>collapse this whole topic to MRN? is there a compelling reason for >>>keeping these 2 notation? >>> >>> >>Actually a MLN is not a special case of MRN. Rather a MRN is a >>special case of MLN. A network comprised of VC4 and VC4-64c capable >>node is a MLN but not a MRN. "Layer" refers to a data plane switching >>layer (e.g. VC4, VC4-64c...). While "region" refers to a switching >>capablity (PSC, TDM...). The term MLN is used to discuss mechanisms >>that apply equally to layers and regions (VNT...) while the term MRN >>is used to discuss multi-regions specific mechanisms (e.g. Adaptation >>capability). >> >> > >I am still confused by the definition of MRN. >Suppose I have a TDM MRN, I can distinguish in this TDM MRN e.g. >VC-12 layer switching, VC-4 layer switching, MS-n layer switching, >so according to the above all MLN. >Why is an MRN then a special case of MLN. > >With the next generation nodes: Multi Service Platforms within >the same node there can also be ethernet switching on top of >the above mentioned TDM MRN and optical switching (DWDM) below >this TDM MRN.... > >IMO the definition of MRN will be very difficult (impossible). > >I would propose to use only the MLN definition, with this layering >and partitioning a network can be described completely. > >Cheers, Huub. > > > --=_alternative 00835632C12570E0_= Content-Type: text/html; charset="US-ASCII"
richard

> I understand what a region is but see no definition of a multi-region
> network anywhere.


see page 3.

> For example, when is it the case that you don't have a multi-layer
> network?


see section 3, in summary, it says multiple regions always cover multiple layers but not the other way around



Richard Rabbat <richard@us.fujitsu.com>
Sent by: owner-ccamp@ops.ietf.org

23/12/2005 22:20

       
        To:        "Brungard, Deborah A, ALABS" <dbrungard@att.com>
        cc:        Huub van Helvoort <hhelvoort@chello.nl>, LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@francetelecom.com>, adrian@olddog.co.uk, ccamp@ops.ietf.org
        Subject:        Re: Opinion on WG drafts for Multi-region/layer networks



hi Deborah,
thanks for your comments.
sorry for being so slow today; must be the wine or is it the martini? :-)
Your description is different from that of JL as he is saying that MRN
is a special case of MLN but you're saying that they refer to different
planes.
I understand what a region is but see no definition of a multi-region
network anywhere.
the lexico draft is clear in describing layers and regions but the
MLN/MRN concepts don't seem to be defined.
For example, when is it the case that you don't have a multi-layer
network? A network is by definition multi-layer since it follows some
layering (OSI or otherwise). Is there a network that doesn't have a
physical layer, mac layer and above?

thanks, and happy holidays!
Richard.

Brungard, Deborah A, ALABS wrote:

>Hi all,
>
>As JL notes, MLN is referring to data plane and MRN to (GMPLS) control
>plane. A MLN may support one ISC or multiple ISCs i.e. GMPLS regions (a
>GMPLS region is defined in RFC 3495/4206,,).  In the updated
>requirements draft for Nov's meeting, we added text to clarify MRN and
>MLN, refer to section 1 and 3.1:
>"A data plane layer is associated with a region in the control plane
>(e.g. VC4 associated to TDM, IP associated to PSC). However, more than
>one data plane layer can be associated to the same region (e.g. both VC4
>and VC12 are associated to TDM)."
>
>Richard, in the earlier versions of this draft, we thought also we
>should only use GMPLS constructs, and we had based the discussion on
>region. Though then many were confused how (control) region related to
>(data) multi-layer networks. We included in this latest version both
>terms to help distinguish between the data plane and control plane.
>Similar to the lexio draft. Take a look at section 1 and 3.1, and if you
>have suggestions, please send.
>
>(an eggnog/whisky/wine/martini should also help when reading - here
>(EST) it is just about that time - 'till next year - Good Holidays
>everyone)
>Deborah
>
>-----Original Message-----
>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
>Behalf Of Huub van Helvoort
>Sent: Friday, December 23, 2005 9:30 AM
>To: LE ROUX Jean-Louis RD-CORE-LAN
>Cc: Richard Rabbat; adrian@olddog.co.uk; ccamp@ops.ietf.org
>Subject: Re: Opinion on WG drafts for Multi-region/layer networks
>
>Hello JL,
>
>You explained:
>
>  
>
>>>two questions: 1. since MLN is a special case of MRN, can we
>>>collapse this whole topic to MRN? is there a compelling reason for
>>>keeping these 2 notation?
>>>      
>>>
>>Actually a MLN is not a special case of MRN. Rather a MRN is a
>>special case of MLN. A network comprised of VC4 and VC4-64c capable
>>node is a MLN but not a MRN. "Layer" refers to a data plane switching
>>layer (e.g. VC4, VC4-64c...). While "region" refers to a switching
>>capablity (PSC, TDM...). The term MLN is used to discuss mechanisms
>>that apply equally to layers and regions (VNT...) while the term MRN
>>is used to discuss multi-regions specific mechanisms (e.g. Adaptation
>>capability).
>>    
>>
>
>I am still confused by the definition of MRN.
>Suppose I have a TDM MRN, I can distinguish in this TDM MRN e.g.
>VC-12 layer switching, VC-4 layer switching, MS-n layer switching,
>so according to the above all MLN.
>Why is an MRN then a special case of MLN.
>
>With the next generation nodes: Multi Service Platforms within
>the same node there can also be ethernet switching on top of
>the above mentioned TDM MRN and optical switching (DWDM) below
>this TDM MRN....
>
>IMO the definition of MRN will be very difficult (impossible).
>
>I would propose to use only the MLN definition, with this layering
>and partitioning a network can be described completely.
>
>Cheers, Huub.
>
>  
>


--=_alternative 00835632C12570E0_=-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Dec 2005 23:23:23 +0000 Message-ID: <43AC86A2.1090802@lab.ntt.co.jp> Date: Sat, 24 Dec 2005 08:22:10 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes, I agree that we make two documents WG documents. -- Kohei Shiomoto NTT Network Service Systems Laboratories Adrian Farrel wrote: > Hi, > > We have a charter milestone to start WG work on a Requirements I-D for > MRN/MLN, and also an Evaluation I-D to examine how the current protocols > shape up to the challenge. > > There are two appropriate I-Ds that have been around for a while. > > draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt > draft-leroux-ccamp-gmpls-mrn-eval-02.txt > > I propose that we make these WG documents and then give them a thorough > review and edit. > > Opinions please. > > Yes or no will suffice, but reasons are always nice. > > Thanks, > Adrian > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Dec 2005 22:34:12 +0000 Message-ID: <43AC7AD6.6010908@chello.nl> Date: Fri, 23 Dec 2005 23:31:50 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Helli Deborah, Thanks for the clarification, after reading draft-shiomoto-ccamp-gmpls-mrn-reqs the definitions are more clear to me. (even with my handicap ;-) Happy Holidays to all of you. Huub. > Hi all, > > As JL notes, MLN is referring to data plane and MRN to (GMPLS) control > plane. A MLN may support one ISC or multiple ISCs i.e. GMPLS regions (a > GMPLS region is defined in RFC 3495/4206,,). In the updated > requirements draft for Nov's meeting, we added text to clarify MRN and > MLN, refer to section 1 and 3.1: > "A data plane layer is associated with a region in the control plane > (e.g. VC4 associated to TDM, IP associated to PSC). However, more than > one data plane layer can be associated to the same region (e.g. both VC4 > and VC12 are associated to TDM)." > > Richard, in the earlier versions of this draft, we thought also we > should only use GMPLS constructs, and we had based the discussion on > region. Though then many were confused how (control) region related to > (data) multi-layer networks. We included in this latest version both > terms to help distinguish between the data plane and control plane. > Similar to the lexio draft. Take a look at section 1 and 3.1, and if you > have suggestions, please send. > > (an eggnog/whisky/wine/martini should also help when reading - here > (EST) it is just about that time - 'till next year - Good Holidays > everyone) > Deborah > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of Huub van Helvoort > Sent: Friday, December 23, 2005 9:30 AM > To: LE ROUX Jean-Louis RD-CORE-LAN > Cc: Richard Rabbat; adrian@olddog.co.uk; ccamp@ops.ietf.org > Subject: Re: Opinion on WG drafts for Multi-region/layer networks > > Hello JL, > > You explained: > > >>>two questions: 1. since MLN is a special case of MRN, can we >>>collapse this whole topic to MRN? is there a compelling reason for >>>keeping these 2 notation? >> >>Actually a MLN is not a special case of MRN. Rather a MRN is a >>special case of MLN. A network comprised of VC4 and VC4-64c capable >>node is a MLN but not a MRN. "Layer" refers to a data plane switching >>layer (e.g. VC4, VC4-64c...). While "region" refers to a switching >>capablity (PSC, TDM...). The term MLN is used to discuss mechanisms >>that apply equally to layers and regions (VNT...) while the term MRN >>is used to discuss multi-regions specific mechanisms (e.g. Adaptation >>capability). > > > I am still confused by the definition of MRN. > Suppose I have a TDM MRN, I can distinguish in this TDM MRN e.g. > VC-12 layer switching, VC-4 layer switching, MS-n layer switching, > so according to the above all MLN. > Why is an MRN then a special case of MLN. > > With the next generation nodes: Multi Service Platforms within > the same node there can also be ethernet switching on top of > the above mentioned TDM MRN and optical switching (DWDM) below > this TDM MRN.... > > IMO the definition of MRN will be very difficult (impossible). > > I would propose to use only the MLN definition, with this layering > and partitioning a network can be described completely. > > Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Dec 2005 21:21:37 +0000 Message-ID: <43AC6A00.2060804@us.fujitsu.com> Date: Fri, 23 Dec 2005 13:20:00 -0800 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: Huub van Helvoort , LE ROUX Jean-Louis RD-CORE-LAN , adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hi Deborah, thanks for your comments. sorry for being so slow today; must be the wine or is it the martini? :-) Your description is different from that of JL as he is saying that MRN is a special case of MLN but you're saying that they refer to different planes. I understand what a region is but see no definition of a multi-region network anywhere. the lexico draft is clear in describing layers and regions but the MLN/MRN concepts don't seem to be defined. For example, when is it the case that you don't have a multi-layer network? A network is by definition multi-layer since it follows some layering (OSI or otherwise). Is there a network that doesn't have a physical layer, mac layer and above? thanks, and happy holidays! Richard. Brungard, Deborah A, ALABS wrote: >Hi all, > >As JL notes, MLN is referring to data plane and MRN to (GMPLS) control >plane. A MLN may support one ISC or multiple ISCs i.e. GMPLS regions (a >GMPLS region is defined in RFC 3495/4206,,). In the updated >requirements draft for Nov's meeting, we added text to clarify MRN and >MLN, refer to section 1 and 3.1: >"A data plane layer is associated with a region in the control plane >(e.g. VC4 associated to TDM, IP associated to PSC). However, more than >one data plane layer can be associated to the same region (e.g. both VC4 >and VC12 are associated to TDM)." > >Richard, in the earlier versions of this draft, we thought also we >should only use GMPLS constructs, and we had based the discussion on >region. Though then many were confused how (control) region related to >(data) multi-layer networks. We included in this latest version both >terms to help distinguish between the data plane and control plane. >Similar to the lexio draft. Take a look at section 1 and 3.1, and if you >have suggestions, please send. > >(an eggnog/whisky/wine/martini should also help when reading - here >(EST) it is just about that time - 'till next year - Good Holidays >everyone) >Deborah > >-----Original Message----- >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >Behalf Of Huub van Helvoort >Sent: Friday, December 23, 2005 9:30 AM >To: LE ROUX Jean-Louis RD-CORE-LAN >Cc: Richard Rabbat; adrian@olddog.co.uk; ccamp@ops.ietf.org >Subject: Re: Opinion on WG drafts for Multi-region/layer networks > >Hello JL, > >You explained: > > > >>>two questions: 1. since MLN is a special case of MRN, can we >>>collapse this whole topic to MRN? is there a compelling reason for >>>keeping these 2 notation? >>> >>> >>Actually a MLN is not a special case of MRN. Rather a MRN is a >>special case of MLN. A network comprised of VC4 and VC4-64c capable >>node is a MLN but not a MRN. "Layer" refers to a data plane switching >>layer (e.g. VC4, VC4-64c...). While "region" refers to a switching >>capablity (PSC, TDM...). The term MLN is used to discuss mechanisms >>that apply equally to layers and regions (VNT...) while the term MRN >>is used to discuss multi-regions specific mechanisms (e.g. Adaptation >>capability). >> >> > >I am still confused by the definition of MRN. >Suppose I have a TDM MRN, I can distinguish in this TDM MRN e.g. >VC-12 layer switching, VC-4 layer switching, MS-n layer switching, >so according to the above all MLN. >Why is an MRN then a special case of MLN. > >With the next generation nodes: Multi Service Platforms within >the same node there can also be ethernet switching on top of >the above mentioned TDM MRN and optical switching (DWDM) below >this TDM MRN.... > >IMO the definition of MRN will be very difficult (impossible). > >I would propose to use only the MLN definition, with this layering >and partitioning a network can be described completely. > >Cheers, Huub. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Dec 2005 20:06:32 +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: Opinion on WG drafts for Multi-region/layer networks Date: Fri, 23 Dec 2005 14:05:53 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0B452F44@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Opinion on WG drafts for Multi-region/layer networks Thread-Index: AcYHzZQ8n5+BvG8gQl+FKSXtFTcU3AAKFDgg From: "Brungard, Deborah A, ALABS" To: "Huub van Helvoort" , "LE ROUX Jean-Louis RD-CORE-LAN" Cc: "Richard Rabbat" , , Hi all, As JL notes, MLN is referring to data plane and MRN to (GMPLS) control plane. A MLN may support one ISC or multiple ISCs i.e. GMPLS regions (a GMPLS region is defined in RFC 3495/4206,,). In the updated requirements draft for Nov's meeting, we added text to clarify MRN and MLN, refer to section 1 and 3.1: "A data plane layer is associated with a region in the control plane (e.g. VC4 associated to TDM, IP associated to PSC). However, more than one data plane layer can be associated to the same region (e.g. both VC4 and VC12 are associated to TDM)." Richard, in the earlier versions of this draft, we thought also we should only use GMPLS constructs, and we had based the discussion on region. Though then many were confused how (control) region related to (data) multi-layer networks. We included in this latest version both terms to help distinguish between the data plane and control plane. Similar to the lexio draft. Take a look at section 1 and 3.1, and if you have suggestions, please send. (an eggnog/whisky/wine/martini should also help when reading - here (EST) it is just about that time - 'till next year - Good Holidays everyone) Deborah -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Huub van Helvoort Sent: Friday, December 23, 2005 9:30 AM To: LE ROUX Jean-Louis RD-CORE-LAN Cc: Richard Rabbat; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks Hello JL, You explained: >> two questions: 1. since MLN is a special case of MRN, can we >> collapse this whole topic to MRN? is there a compelling reason for >> keeping these 2 notation? >=20 > Actually a MLN is not a special case of MRN. Rather a MRN is a > special case of MLN. A network comprised of VC4 and VC4-64c capable > node is a MLN but not a MRN. "Layer" refers to a data plane switching > layer (e.g. VC4, VC4-64c...). While "region" refers to a switching > capablity (PSC, TDM...). The term MLN is used to discuss mechanisms > that apply equally to layers and regions (VNT...) while the term MRN > is used to discuss multi-regions specific mechanisms (e.g. Adaptation > capability). I am still confused by the definition of MRN. Suppose I have a TDM MRN, I can distinguish in this TDM MRN e.g. VC-12 layer switching, VC-4 layer switching, MS-n layer switching, so according to the above all MLN. Why is an MRN then a special case of MLN. With the next generation nodes: Multi Service Platforms within the same node there can also be ethernet switching on top of the above mentioned TDM MRN and optical switching (DWDM) below this TDM MRN.... IMO the definition of MRN will be very difficult (impossible). I would propose to use only the MLN definition, with this layering and partitioning a network can be described completely. Cheers, Huub. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://members.chello.nl/hhelvoort/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Dec 2005 20:04:33 +0000 Message-ID: <43AC57D9.2070207@us.fujitsu.com> Date: Fri, 23 Dec 2005 12:02:33 -0800 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN CC: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit hi Jean-Louis, thanks for the reply, inline... LE ROUX Jean-Louis RD-CORE-LAN wrote: >Hi Richard > >See inline, > > > >>-----Message d'origine----- >>De : owner-ccamp@ops.ietf.org >>[mailto:owner-ccamp@ops.ietf.org] De la part de Richard Rabbat >>Envoyé : jeudi 22 décembre 2005 23:28 >>À : zzx-adrian@olddog.co.uk >>Cc : ccamp@ops.ietf.org >>Objet : Re: Opinion on WG drafts for Multi-region/layer networks >> >>yes to both >> >>two questions: >>1. since MLN is a special case of MRN, can we collapse this >>whole topic to MRN? is there a compelling reason for keeping >>these 2 notation? >> >> > >Actually a MLN is not a special case of MRN. Rather a MRN is a special case of MLN. A network comprised of VC4 and VC4-64c capable node is a MLN but not a MRN. >"Layer" refers to a data plane switching layer (e.g. VC4, VC4-64c...). While "region" refers to a switching capablity (PSC, TDM...). > > My comment was incorrect. Let me use better math wording. Do all elements of the set MRN belong to the set MLN? I suggest that both terms MRN and MLN be clearly defined somewhere. >The term MLN is used to discuss mechanisms that apply equally to layers and regions (VNT...) while the term MRN is used to discuss multi-regions specific mechanisms (e.g. Adaptation capability). > If Igor is right about adaptation (though the example is wrong from Huub's email), then what are other MR specific mechanisms? >>2. Section 3 of draft-leroux-ccamp-gmpls-mrn-eval-02.txt is a >>requirments section and therefore not relevant to this draft >>but belongs to draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt. >>there is no advantage to repeting requirements. >> >> > >The objective was to ease the reading, but we can easily remove it if considered as irrelevant. > > My suggestion is to drop it in this draft and if there is need to have a summary for clarity, then clarify in the req's doc. >Thanks for your support and for these comments. > >Regards, > >JL > > thanks, richard. > > > >>thanks, >>richard. >> >>Adrian Farrel wrote: >> >> >> >>>Hi, >>> >>>We have a charter milestone to start WG work on a >>> >>> >>Requirements I-D for >> >> >>>MRN/MLN, and also an Evaluation I-D to examine how the current >>>protocols shape up to the challenge. >>> >>>There are two appropriate I-Ds that have been around for a while. >>> >>>draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt >>>draft-leroux-ccamp-gmpls-mrn-eval-02.txt >>> >>>I propose that we make these WG documents and then give them >>> >>> >>a thorough >> >> >>>review and edit. >>> >>>Opinions please. >>> >>>Yes or no will suffice, but reasons are always nice. >>> >>>Thanks, >>>Adrian >>> >>> >>> >>> >>> >>> >> >> Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Dec 2005 15:15:57 +0000 Message-ID: <43AC145A.3040404@chello.nl> Date: Fri, 23 Dec 2005 16:14:34 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: Adrian Farrel , ccamp@ops.ietf.org Subject: Re: VCAT/LCAS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Dimitri, You suggested: > would it be possible to take into account compatibility with RFC3946 > when addressing the following point you mentioned here below > > "I think that we will be able to adopt this work as a WG draft, but we > should not do that until we have seen a first stab at the protocol > extensions." Thanks for your help, I already had this RFC on the list of RFCs to check. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Dec 2005 15:10:34 +0000 Message-ID: <43AC1325.2000104@chello.nl> Date: Fri, 23 Dec 2005 16:09:25 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: Igor Bryskin CC: LE ROUX Jean-Louis RD-CORE-LAN , adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Igor, I have a small correction see [hvh]: > The term MLN is used to discuss mechanisms that apply equally to layers and > regions (VNT...) while the term MRN is used to discuss multi-regions > specific mechanisms (e.g. Adaptation capability). > ; > IB>> Disagree. Adaptation capability is entirely MLN issue. According to > your own example you need to adopt VC4 onto VC4-64c. There exists no adaptation function with VC-4 client and VC-4-64c as server. A VC-4-64c can be used as a server to transport a 10GbE LAN client signal, or other 10 Gbit/s signals using e.g. GFP. A VC-4 can be used as a server for VC-3, VC-12, VC-11 signals, be a member of a VC-4-64v, or thransport a 150 Mbit/s client signal using e.g. GFP. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Dec 2005 14:52:21 +0000 To: "Adrian Farrel" Cc: ccamp@ops.ietf.org Subject: Re: VCAT/LCAS MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Fri, 23 Dec 2005 15:51:25 +0100 Content-Type: multipart/alternative; boundary="=_alternative 00519D32C12570E0_=" This is a multipart message in MIME format. --=_alternative 00519D32C12570E0_= Content-Type: text/plain; charset="US-ASCII" adrian - would it be possible to take into account compatibility with RFC3946 when addressing the following point you mentioned here below "I think that we will be able to adopt this work as a WG draft, but we should not do that until we have seen a first stab at the protocol extensions." much thanks, - dimitri. "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org 22/12/2005 01:27 Please respond to "Adrian Farrel" To: cc: Subject: VCAT/LCAS Hi, In Vancouver there was clear support in the room that a group wanted to work on this topic. draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and provides a fair summary of the problem space in sections 1 and 2. The draft fades out in section 3 "Possible Extensions to GMPLS to support additional VCAT/LCAS scenarios" as it starts to identify the specific requirements to extend GMPLS protocols. I suggest that the authors should: - gather a group of interest parties to work on this - keep in mind that protocol extensions are done in support of implementations (that is, not for completeness, but because someone is building product) - beef up section 3 to list the requirements - write a new section for the solutions I think that we will be able to adopt this work as a WG draft, but we should not do that until we have seen a first stab at the protocol extensions. If the authors could let us know their progress and plans, that would be great. Thanks, Adrian --=_alternative 00519D32C12570E0_= Content-Type: text/html; charset="US-ASCII"
adrian -

would it be possible to take into account compatibility with RFC3946 when addressing the following point you mentioned here below

"I think that we will be able to adopt this work as a WG draft, but we
should not do that until we have seen a first stab at the protocol
extensions.
"

much thanks,
- dimitri.





"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org

22/12/2005 01:27
Please respond to "Adrian Farrel"

       
        To:        <ccamp@ops.ietf.org>
        cc:        
        Subject:        VCAT/LCAS



Hi,

In Vancouver there was clear support in the room that a group wanted to
work on this topic.

draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and
provides a fair summary of the problem space in sections 1 and 2.

The draft fades out in section 3 "Possible Extensions to GMPLS to support
additional VCAT/LCAS scenarios" as it starts to identify the specific
requirements to extend GMPLS protocols.

I suggest that the authors should:
- gather a group of interest parties to work on this
- keep in mind that protocol extensions are done in support of
 implementations (that is, not for completeness, but because someone
 is building product)
- beef up section 3 to list the requirements
- write a new section for the solutions

I think that we will be able to adopt this work as a WG draft, but we
should not do that until we have seen a first stab at the protocol
extensions.

If the authors could let us know their progress and plans, that would be
great.

Thanks,
Adrian



--=_alternative 00519D32C12570E0_=-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Dec 2005 14:40:08 +0000 Message-ID: <43AC0C04.1040504@chello.nl> Date: Fri, 23 Dec 2005 15:39:00 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: Dan Li CC: Adrian Farrel , ccamp@ops.ietf.org Subject: Re: VCAT/LCAS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Dan, You wrote: > When we consider the requirements in section 3, do we also need to > consider the scenario which the Ethernet service is supported by Xc > or by the combination of Xc and Xv? Contiguous concatenation Xc and virtual concatenation Xv cannot be combined (there is only one exception: an STS-3c can be virual concatenated) > Another scenario is if we have the optional Xc and Xv flexible > adapatations at both ends, does the signaling need to support the > selection? A selection is certainly needed to match the transport capability with the required bandwidth. A selection can be: - a single VC-n - a single VC-n-Xc - a VC-n-Xv which provides additional flexibility if LCAS is supported. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Dec 2005 14:31:10 +0000 Message-ID: <43AC09EC.3030308@chello.nl> Date: Fri, 23 Dec 2005 15:30:04 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: LE ROUX Jean-Louis RD-CORE-LAN CC: Richard Rabbat , adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello JL, You explained: >> two questions: 1. since MLN is a special case of MRN, can we >> collapse this whole topic to MRN? is there a compelling reason for >> keeping these 2 notation? > > Actually a MLN is not a special case of MRN. Rather a MRN is a > special case of MLN. A network comprised of VC4 and VC4-64c capable > node is a MLN but not a MRN. "Layer" refers to a data plane switching > layer (e.g. VC4, VC4-64c...). While "region" refers to a switching > capablity (PSC, TDM...). The term MLN is used to discuss mechanisms > that apply equally to layers and regions (VNT...) while the term MRN > is used to discuss multi-regions specific mechanisms (e.g. Adaptation > capability). I am still confused by the definition of MRN. Suppose I have a TDM MRN, I can distinguish in this TDM MRN e.g. VC-12 layer switching, VC-4 layer switching, MS-n layer switching, so according to the above all MLN. Why is an MRN then a special case of MLN. With the next generation nodes: Multi Service Platforms within the same node there can also be ethernet switching on top of the above mentioned TDM MRN and optical switching (DWDM) below this TDM MRN.... IMO the definition of MRN will be very difficult (impossible). I would propose to use only the MLN definition, with this layering and partitioning a network can be described completely. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Dec 2005 14:15:26 +0000 Message-ID: <002d01c607cb$0f405e30$6601a8c0@movaz.com> From: "Igor Bryskin" To: "LE ROUX Jean-Louis RD-CORE-LAN" , "Richard Rabbat" , Cc: Subject: Re: Opinion on WG drafts for Multi-region/layer networks Date: Fri, 23 Dec 2005 09:13:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit JL. I have a correction. Please,see in-line. Igor ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Richard Rabbat" ; Cc: Sent: Friday, December 23, 2005 3:04 AM Subject: RE: Opinion on WG drafts for Multi-region/layer networks Hi Richard See inline, > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] De la part de Richard Rabbat > Envoyé : jeudi 22 décembre 2005 23:28 > À : zzx-adrian@olddog.co.uk > Cc : ccamp@ops.ietf.org > Objet : Re: Opinion on WG drafts for Multi-region/layer networks > > yes to both > > two questions: > 1. since MLN is a special case of MRN, can we collapse this > whole topic to MRN? is there a compelling reason for keeping > these 2 notation? Actually a MLN is not a special case of MRN. Rather a MRN is a special case of MLN. A network comprised of VC4 and VC4-64c capable node is a MLN but not a MRN. IB>> Agree "Layer" refers to a data plane switching layer (e.g. VC4, VC4-64c...). While "region" refers to a switching capablity (PSC, TDM...). IB>> "Layer" is all about data plane. Layers exist independently of control plane.. "Region" refers to control plane peculiarities pertinent to networks with different switching types. Signaling objects specific to TDM , optical impairment constraints specific to optical transparent networks are examples of region related issues. Therefore, "region" is purely control plane concept. See more in the lexicography draft. The term MLN is used to discuss mechanisms that apply equally to layers and regions (VNT...) while the term MRN is used to discuss multi-regions specific mechanisms (e.g. Adaptation capability). ; IB>> Disagree. Adaptation capability is entirely MLN issue. According to your own example you need to adopt VC4 onto VC4-64c. Cheers, Igor > 2. Section 3 of draft-leroux-ccamp-gmpls-mrn-eval-02.txt is a > requirments section and therefore not relevant to this draft > but belongs to draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt. > there is no advantage to repeting requirements. The objective was to ease the reading, but we can easily remove it if considered as irrelevant. Thanks for your support and for these comments. Regards, JL > > thanks, > richard. > > Adrian Farrel wrote: > > >Hi, > > > >We have a charter milestone to start WG work on a > Requirements I-D for > >MRN/MLN, and also an Evaluation I-D to examine how the current > >protocols shape up to the challenge. > > > >There are two appropriate I-Ds that have been around for a while. > > > >draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt > >draft-leroux-ccamp-gmpls-mrn-eval-02.txt > > > >I propose that we make these WG documents and then give them > a thorough > >review and edit. > > > >Opinions please. > > > >Yes or no will suffice, but reasons are always nice. > > > >Thanks, > >Adrian > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Dec 2005 08:14:05 +0000 Date: Fri, 23 Dec 2005 16:08:41 +0800 From: Dan Li Subject: Re: VCAT/LCAS To: Adrian Farrel , ccamp@ops.ietf.org Message-id: <008701c60798$1605cc60$d04c460a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT I support this work. When we consider the requirements in section 3, do we also need to consider the scenario which the Ethernet service is supported by Xc or by the combination of Xc and Xv? Another scenario is if we have the optional Xc and Xv flexible adapatations at both ends, does the signaling need to support the selection? Dan Li ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, December 22, 2005 8:27 AM Subject: VCAT/LCAS > Hi, > > In Vancouver there was clear support in the room that a group wanted to > work on this topic. > > draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and > provides a fair summary of the problem space in sections 1 and 2. > > The draft fades out in section 3 "Possible Extensions to GMPLS to support > additional VCAT/LCAS scenarios" as it starts to identify the specific > requirements to extend GMPLS protocols. > > I suggest that the authors should: > - gather a group of interest parties to work on this > - keep in mind that protocol extensions are done in support of > implementations (that is, not for completeness, but because someone > is building product) > - beef up section 3 to list the requirements > - write a new section for the solutions > > I think that we will be able to adopt this work as a WG draft, but we > should not do that until we have seen a first stab at the protocol > extensions. > > If the authors could let us know their progress and plans, that would be > great. > > Thanks, > Adrian > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Dec 2005 08:06:38 +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: Opinion on WG drafts for Multi-region/layer networks Date: Fri, 23 Dec 2005 09:04:26 +0100 Message-ID: Thread-Topic: Opinion on WG drafts for Multi-region/layer networks Thread-Index: AcYHR21dZ9/AOvZaROmCgWQjfC+iAgATXvrg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Richard Rabbat" , Cc: Hi Richard See inline,=20 > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] De la part de Richard Rabbat > Envoy=E9 : jeudi 22 d=E9cembre 2005 23:28 > =C0 : zzx-adrian@olddog.co.uk > Cc : ccamp@ops.ietf.org > Objet : Re: Opinion on WG drafts for Multi-region/layer networks >=20 > yes to both >=20 > two questions: > 1. since MLN is a special case of MRN, can we collapse this=20 > whole topic to MRN? is there a compelling reason for keeping=20 > these 2 notation? Actually a MLN is not a special case of MRN. Rather a MRN is a special = case of MLN. A network comprised of VC4 and VC4-64c capable node is a = MLN but not a MRN. "Layer" refers to a data plane switching layer (e.g. VC4, VC4-64c...). = While "region" refers to a switching capablity (PSC, TDM...). The term MLN is used to discuss mechanisms that apply equally to layers = and regions (VNT...) while the term MRN is used to discuss multi-regions = specific mechanisms (e.g. Adaptation capability).=20 > 2. Section 3 of draft-leroux-ccamp-gmpls-mrn-eval-02.txt is a=20 > requirments section and therefore not relevant to this draft=20 > but belongs to draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt.=20 > there is no advantage to repeting requirements. The objective was to ease the reading, but we can easily remove it if = considered as irrelevant. Thanks for your support and for these comments. Regards, JL >=20 > thanks, > richard. >=20 > Adrian Farrel wrote: >=20 > >Hi, > > > >We have a charter milestone to start WG work on a=20 > Requirements I-D for=20 > >MRN/MLN, and also an Evaluation I-D to examine how the current=20 > >protocols shape up to the challenge. > > > >There are two appropriate I-Ds that have been around for a while. > > > >draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt > >draft-leroux-ccamp-gmpls-mrn-eval-02.txt > > > >I propose that we make these WG documents and then give them=20 > a thorough=20 > >review and edit. > > > >Opinions please. > > > >Yes or no will suffice, but reasons are always nice. > > > >Thanks, > >Adrian > > > > > > =20 > > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 22:28:47 +0000 Message-ID: <43AB2854.2030704@us.fujitsu.com> Date: Thu, 22 Dec 2005 14:27:32 -0800 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit yes to both two questions: 1. since MLN is a special case of MRN, can we collapse this whole topic to MRN? is there a compelling reason for keeping these 2 notation? 2. Section 3 of draft-leroux-ccamp-gmpls-mrn-eval-02.txt is a requirments section and therefore not relevant to this draft but belongs to draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt. there is no advantage to repeting requirements. thanks, richard. Adrian Farrel wrote: >Hi, > >We have a charter milestone to start WG work on a Requirements I-D for >MRN/MLN, and also an Evaluation I-D to examine how the current protocols >shape up to the challenge. > >There are two appropriate I-Ds that have been around for a while. > >draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt >draft-leroux-ccamp-gmpls-mrn-eval-02.txt > >I propose that we make these WG documents and then give them a thorough >review and edit. > >Opinions please. > >Yes or no will suffice, but reasons are always nice. > >Thanks, >Adrian > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 22:07:33 +0000 Message-ID: <43AB22D8.7010001@chello.nl> Date: Thu, 22 Dec 2005 23:04:08 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Opinion on WG drafts for Multi-region/layer networks Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Adrian, You porposed: > There are two appropriate I-Ds that have been around for a while. > > draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt > draft-leroux-ccamp-gmpls-mrn-eval-02.txt > > I propose that we make these WG documents and then give them a thorough > review and edit. I am in favor to progress these drafts. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 18:28:11 +0000 Message-ID: <43AAEFBD.1010806@grotto-networking.com> Date: Thu, 22 Dec 2005 10:26:05 -0800 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: VCAT/LCAS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, we've gathered a group of folks together that includes the original authors and anyone else who has so far expressed interest. Anyone else who is interested just send an e-mail to any of the authors to get involved. The plan is roughly as follows: (a) Survey of current GMPLS WG drafts that have may have mechanisms usable for VCAT/LCAS operation. List mechanisms (generally objects and such added to signaling or routing). Adrian your supplemental website with the up to date listing of CCAMP is either broken or the link from the IETF website is broken :-< Can you fix or send the right link? (b) Analysis of these mechanisms for applicability to base VCAT/LCAS scenarios. (c) Write up additional enabled applications with walk throughs for each mechanism adopted, e.g., make before you break... However, we've currently been dealing with the note from the last IETF meeting that claimed that this effort was "strictly for the diverse path" case. One of the basic VCAT/LCAS scenarios is dynamic bandwidth adjustment (whether co-routed or not). GMPLS VCAT connection bandwidth modification (even in co-routed) seems different from the MPLS case in the sense we'd need to either add or delete member connections (not just modify connection bandwidth parameters at each node). We're not sure that this important case can be currently handled in the co-routed case without modification. So we've also added this analysis to our list of ToDo's (volunteers for a complete write up on this?) That said look for activity again after the holidays! Greg -------------------------------------------------- Greg Bernstein, Grotto Networking Adrian Farrel wrote: >Hi, > >In Vancouver there was clear support in the room that a group wanted to >work on this topic. > >draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and >provides a fair summary of the problem space in sections 1 and 2. > >The draft fades out in section 3 "Possible Extensions to GMPLS to support >additional VCAT/LCAS scenarios" as it starts to identify the specific >requirements to extend GMPLS protocols. > >I suggest that the authors should: >- gather a group of interest parties to work on this >- keep in mind that protocol extensions are done in support of > implementations (that is, not for completeness, but because someone > is building product) >- beef up section 3 to list the requirements >- write a new section for the solutions > >I think that we will be able to adopt this work as a WG draft, but we >should not do that until we have seen a first stab at the protocol >extensions. > >If the authors could let us know their progress and plans, that would be >great. > >Thanks, >Adrian > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 16:25:56 +0000 Message-ID: <43AAD340.4070307@chello.nl> Date: Thu, 22 Dec 2005 17:24:32 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: VCAT/LCAS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Adrian, You wrote: > In Vancouver there was clear support in the room that a group wanted to > work on this topic. Yes, and I still support it. > draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and > provides a fair summary of the problem space in sections 1 and 2. > > The draft fades out in section 3 "Possible Extensions to GMPLS to support > additional VCAT/LCAS scenarios" as it starts to identify the specific > requirements to extend GMPLS protocols. > > I suggest that the authors should: > - gather a group of interest parties to work on this A small group already started, maybe others would like to join. > - keep in mind that protocol extensions are done in support of > implementations (that is, not for completeness, but because someone > is building product) > - beef up section 3 to list the requirements > - write a new section for the solutions OK, thansk for the advise. > I think that we will be able to adopt this work as a WG draft, but we > should not do that until we have seen a first stab at the protocol > extensions. > > If the authors could let us know their progress and plans, that would be > great. After the Holidays we know more. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 15:52:07 +0000 Reply-To: From: "Vishal Sharma" To: "'Adrian Farrel'" , Subject: RE: VCAT/LCAS Date: Thu, 22 Dec 2005 07:50:05 -0800 Organization: Metanoia, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcYGosg0hRdWAq9dREWXPDQlKytioAAbH+mg Message-Id: Hi Adrian, I've had occasion to look at this work, and think it is a useful work item, and support it. -Vishal -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, December 21, 2005 4:27 PM To: ccamp@ops.ietf.org Subject: VCAT/LCAS Hi, In Vancouver there was clear support in the room that a group wanted to work on this topic. draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and provides a fair summary of the problem space in sections 1 and 2. The draft fades out in section 3 "Possible Extensions to GMPLS to support additional VCAT/LCAS scenarios" as it starts to identify the specific requirements to extend GMPLS protocols. I suggest that the authors should: - gather a group of interest parties to work on this - keep in mind that protocol extensions are done in support of implementations (that is, not for completeness, but because someone is building product) - beef up section 3 to list the requirements - write a new section for the solutions I think that we will be able to adopt this work as a WG draft, but we should not do that until we have seen a first stab at the protocol extensions. If the authors could let us know their progress and plans, that would be great. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 14:57:37 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0XJOgqiPJn8C73ZRUih7HZGep5Di8rKmoC8TJhJt2mBm1k1mxJ7ZQxJcjk2jbqYwU7Z+Mp9h/6FRKVUnDM/SK6Ez3OYiLkO+2fyoG568nvP4kqx0Kk91n0y1OCBpvuFO5AbuLKJ2GbREYbpch06OpdEpiBRLKr98WpS2mjMnKOM= ; Message-ID: <20051222145704.54437.qmail@web30806.mail.mud.yahoo.com> Date: Thu, 22 Dec 2005 06:57:04 -0800 (PST) From: Igor Bryskin Subject: Re: VCAT/LCAS To: Adrian Farrel , ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-518656425-1135263424=:53907" Content-Transfer-Encoding: 8bit --0-518656425-1135263424=:53907 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I support this work. Igor Adrian Farrel wrote: Hi, In Vancouver there was clear support in the room that a group wanted to work on this topic. draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and provides a fair summary of the problem space in sections 1 and 2. The draft fades out in section 3 "Possible Extensions to GMPLS to support additional VCAT/LCAS scenarios" as it starts to identify the specific requirements to extend GMPLS protocols. I suggest that the authors should: - gather a group of interest parties to work on this - keep in mind that protocol extensions are done in support of implementations (that is, not for completeness, but because someone is building product) - beef up section 3 to list the requirements - write a new section for the solutions I think that we will be able to adopt this work as a WG draft, but we should not do that until we have seen a first stab at the protocol extensions. If the authors could let us know their progress and plans, that would be great. Thanks, Adrian __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-518656425-1135263424=:53907 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
I support this work.
 
Igor

Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi,

In Vancouver there was clear support in the room that a group wanted to
work on this topic.

draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and
provides a fair summary of the problem space in sections 1 and 2.

The draft fades out in section 3 "Possible Extensions to GMPLS to support
additional VCAT/LCAS scenarios" as it starts to identify the specific
requirements to extend GMPLS protocols.

I suggest that the authors should:
- gather a group of interest parties to work on this
- keep in mind that protocol extensions are done in support of
implementations (that is, not for completeness, but because someone
is building product)
- beef up section 3 to list the requirements
- write a new section for the solutions

I think that we will be able to adopt this work as a WG draft, but we
should not do that until we have seen a first stab at the protocol
extensions.

If the authors could let us know their progress and plans, that would be
great.

Thanks,
Adrian



__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-518656425-1135263424=:53907-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 14:57:29 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0b2hpueGUsAa/6vEghLY1q7xdAoG39S+Zp6E64KGiq0vVktjz1ehJeWpgx3FGWm8WHl5V98HuQHRm0t/QQOVO5tLkY5/ks4L60GKUgTvQfwIKB4wPrDtIcV09Jpl1xYZLsJ5aOVVjijagoT7eRmJ9EgaQVICAvha8EF6ZE0KPUg= ; Message-ID: <20051222145626.56912.qmail@web30810.mail.mud.yahoo.com> Date: Thu, 22 Dec 2005 06:56:25 -0800 (PST) From: Igor Bryskin Subject: Re: Opinion on WG drafts for Multi-region/layer networks To: Adrian Farrel , ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-424139101-1135263385=:55868" Content-Transfer-Encoding: 8bit --0-424139101-1135263385=:55868 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I believe this work is very important. Igor Adrian Farrel wrote: Hi, We have a charter milestone to start WG work on a Requirements I-D for MRN/MLN, and also an Evaluation I-D to examine how the current protocols shape up to the challenge. There are two appropriate I-Ds that have been around for a while. draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt draft-leroux-ccamp-gmpls-mrn-eval-02.txt I propose that we make these WG documents and then give them a thorough review and edit. Opinions please. Yes or no will suffice, but reasons are always nice. Thanks, Adrian __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-424139101-1135263385=:55868 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi,
 
I believe this work is very important.
 
Igor

Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi,

We have a charter milestone to start WG work on a Requirements I-D for
MRN/MLN, and also an Evaluation I-D to examine how the current protocols
shape up to the challenge.

There are two appropriate I-Ds that have been around for a while.

draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt
draft-leroux-ccamp-gmpls-mrn-eval-02.txt

I propose that we make these WG documents and then give them a thorough
review and edit.

Opinions please.

Yes or no will suffice, but reasons are always nice.

Thanks,
Adrian



__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-424139101-1135263385=:55868-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 14:36:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Opinion on WG drafts for Multi-region/layer networks Date: Thu, 22 Dec 2005 08:34:34 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0B45272D@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Opinion on WG drafts for Multi-region/layer networks Thread-Index: AcYGonGACtNyFgEZQw2xgU7vDdVU+AAYlbog From: "Brungard, Deborah A, ALABS" To: "Adrian Farrel" , Yes (both)- Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, December 21, 2005 4:56 PM To: ccamp@ops.ietf.org Subject: Opinion on WG drafts for Multi-region/layer networks Hi, We have a charter milestone to start WG work on a Requirements I-D for MRN/MLN, and also an Evaluation I-D to examine how the current protocols shape up to the challenge. There are two appropriate I-Ds that have been around for a while. draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt draft-leroux-ccamp-gmpls-mrn-eval-02.txt I propose that we make these WG documents and then give them a thorough review and edit. Opinions please. Yes or no will suffice, but reasons are always nice. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 13:24:05 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9218C3B2-EC44-4AD5-9FDD-A3D20D1C0C75@cisco.com> Cc: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: Opinion on WG drafts for Multi-region/layer networks Date: Thu, 22 Dec 2005 08:22:03 -0500 To: "Adrian Farrel" in favor. JP. On Dec 21, 2005, at 4:55 PM, Adrian Farrel wrote: > Hi, > > We have a charter milestone to start WG work on a Requirements I-D for > MRN/MLN, and also an Evaluation I-D to examine how the current > protocols > shape up to the challenge. > > There are two appropriate I-Ds that have been around for a while. > > draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt > draft-leroux-ccamp-gmpls-mrn-eval-02.txt > > I propose that we make these WG documents and then give them a > thorough > review and edit. > > Opinions please. > > Yes or no will suffice, but reasons are always nice. > > Thanks, > Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 12:48:41 +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: Opinion on WG drafts for Multi-region/layer networks Date: Thu, 22 Dec 2005 06:10:46 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9816@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Opinion on WG drafts for Multi-region/layer networks Thread-Index: AcYGonGm5TuqpjcHToedtn/s9WEm4wATheNQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , Cc: "Ash, Gerald R \(Jerry\), ALABS" > There are two appropriate I-Ds that have been around for a while. >=20 > draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt > draft-leroux-ccamp-gmpls-mrn-eval-02.txt >=20 > I propose that we make these WG documents and then give them=20 > a thorough review and edit. >=20 > Opinions please. In favor. Thanks, Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 12:47:42 +0000 Message-Id: <6.0.0.20.2.20051222213918.062d4fc0@imb.m.ecl.ntt.co.jp> Date: Thu, 22 Dec 2005 21:40:02 +0900 To: From: "inoue.ichiro@lab.ntt.co.jp" Subject: Re: Opinion on WG drafts for Multi-region/layer networks Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit In favor. Ichiro Inoue >At 21:55 05/12/21 +0000, Adrian Farrel wrote: >>Hi, >> >>We have a charter milestone to start WG work on a Requirements I-D for >>MRN/MLN, and also an Evaluation I-D to examine how the current protocols >>shape up to the challenge. >> >>There are two appropriate I-Ds that have been around for a while. >> >>draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt >>draft-leroux-ccamp-gmpls-mrn-eval-02.txt >> >>I propose that we make these WG documents and then give them a thorough >>review and edit. >> >>Opinions please. >> >>Yes or no will suffice, but reasons are always nice. >> >>Thanks, >>Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 12:30:59 +0000 Message-Id: <5.1.1.9.2.20051222205630.0697e008@imf.m.ecl.ntt.co.jp> Date: Thu, 22 Dec 2005 21:30:13 +0900 To: From: Tomonori TAKEDA Subject: Re: Opinion on WG drafts for Multi-region/layer networks Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Yes (to both). Regards, Tomonori At 21:55 05/12/21 +0000, Adrian Farrel wrote: >Hi, > >We have a charter milestone to start WG work on a Requirements I-D for >MRN/MLN, and also an Evaluation I-D to examine how the current protocols >shape up to the challenge. > >There are two appropriate I-Ds that have been around for a while. > >draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt >draft-leroux-ccamp-gmpls-mrn-eval-02.txt > >I propose that we make these WG documents and then give them a thorough >review and edit. > >Opinions please. > >Yes or no will suffice, but reasons are always nice. > >Thanks, >Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 07:59:42 +0000 To: "Adrian Farrel" Cc: ccamp@ops.ietf.org, dpapadimitriou@psg.com Subject: Re: Opinion on WG drafts for Multi-region/layer networks MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Thu, 22 Dec 2005 08:58:02 +0100 Content-Type: multipart/alternative; boundary="=_alternative 002BC460C12570DF_=" This is a multipart message in MIME format. --=_alternative 002BC460C12570DF_= Content-Type: text/plain; charset="US-ASCII" agreed - with the increase trend in building multi-layer capable devices/networks this becomes a sensible topic to be covered by the WG; now, these documents are more than probably not perfect (note: perfection is not obtained when there is nothing to be added but when there is nothing to be removed) but imho are in reasonable shape and they certainly deserve attention from the WG in order to shape subsequent GMPLS mechanisms and operations for such environments "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org 21/12/2005 22:55 Please respond to "Adrian Farrel" To: cc: Subject: Opinion on WG drafts for Multi-region/layer networks Hi, We have a charter milestone to start WG work on a Requirements I-D for MRN/MLN, and also an Evaluation I-D to examine how the current protocols shape up to the challenge. There are two appropriate I-Ds that have been around for a while. draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt draft-leroux-ccamp-gmpls-mrn-eval-02.txt I propose that we make these WG documents and then give them a thorough review and edit. Opinions please. Yes or no will suffice, but reasons are always nice. Thanks, Adrian --=_alternative 002BC460C12570DF_= Content-Type: text/html; charset="US-ASCII"
agreed -

with the increase trend in building multi-layer capable devices/networks this becomes a sensible topic to be covered by the WG;

now, these documents are more than probably not perfect (note: perfection is not obtained when there is nothing to be added but when there is nothing to be removed) but imho are in reasonable shape and they certainly deserve attention from the WG in order to shape subsequent GMPLS mechanisms and operations for such environments




"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org

21/12/2005 22:55
Please respond to "Adrian Farrel"

       
        To:        <ccamp@ops.ietf.org>
        cc:        
        Subject:        Opinion on WG drafts for Multi-region/layer networks



Hi,

We have a charter milestone to start WG work on a Requirements I-D for
MRN/MLN, and also an Evaluation I-D to examine how the current protocols
shape up to the challenge.

There are two appropriate I-Ds that have been around for a while.

draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt
draft-leroux-ccamp-gmpls-mrn-eval-02.txt

I propose that we make these WG documents and then give them a thorough
review and edit.

Opinions please.

Yes or no will suffice, but reasons are always nice.

Thanks,
Adrian



--=_alternative 002BC460C12570DF_=-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 02:49:58 +0000 Message-ID: <098801c606a2$95ba4900$99849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Opinion on WG drafts for Multi-region/layer networks Date: Wed, 21 Dec 2005 21:55:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, We have a charter milestone to start WG work on a Requirements I-D for MRN/MLN, and also an Evaluation I-D to examine how the current protocols shape up to the challenge. There are two appropriate I-Ds that have been around for a while. draft-shiomoto-ccamp-gmpls-mrn-reqs-03.txt draft-leroux-ccamp-gmpls-mrn-eval-02.txt I propose that we make these WG documents and then give them a thorough review and edit. Opinions please. Yes or no will suffice, but reasons are always nice. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Dec 2005 02:49:50 +0000 Message-ID: <098a01c606a2$97e4f130$99849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: VCAT/LCAS Date: Thu, 22 Dec 2005 00:27:09 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, In Vancouver there was clear support in the room that a group wanted to work on this topic. draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and provides a fair summary of the problem space in sections 1 and 2. The draft fades out in section 3 "Possible Extensions to GMPLS to support additional VCAT/LCAS scenarios" as it starts to identify the specific requirements to extend GMPLS protocols. I suggest that the authors should: - gather a group of interest parties to work on this - keep in mind that protocol extensions are done in support of implementations (that is, not for completeness, but because someone is building product) - beef up section 3 to list the requirements - write a new section for the solutions I think that we will be able to adopt this work as a WG draft, but we should not do that until we have seen a first stab at the protocol extensions. If the authors could let us know their progress and plans, that would be great. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Dec 2005 21:54:41 +0000 Message-ID: <05d301c605b0$56be68a0$99849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Working Group Last Call draft-ietf-ccamp-rfc3946bis-01.txt Date: Tue, 20 Dec 2005 21:55:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, This begins a working group last call on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc3946bis-01.txt As we have been discussing on the list, the changes are very small (if you need to see exactly what they are, you'll have to go back to the 00 revision that had markers in place. We *can* accept other changes to the RFC at this stage, although I might express some surprise that you have left any suggestions until this late stage. The last call will end on Friday 6th January at 12.00 GMT. (A couple of extra days to get you over the festive break.) Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Dec 2005 20:51:52 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-rfc3946bis-01.txt Message-Id: Date: Tue, 20 Dec 2005 15:50:01 -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) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-rfc3946bis-01.txt Pages : 24 Date : 2005-12-20 This document provides minor clarification to RFC 3946. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc3946bis-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-rfc3946bis-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-rfc3946bis-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-12-20123224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rfc3946bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rfc3946bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-20123224.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Dec 2005 16:17:04 +0000 Message-ID: <073f01c60580$b32866c0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Zafar Ali (zali)" , Cc: "Adrian Farrel" , , Subject: Re: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Date: Tue, 20 Dec 2005 11:16:14 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_073C_01C60556.CA16DC60" This is a multi-part message in MIME format. ------=_NextPart_000_073C_01C60556.CA16DC60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zafar, I have a question to you. Why would you need a dedicated 1:1 protection = without allowing the protection LSP to be used for carrying extra = traffic? If the resources of the protection LSP are allocated anyway and = the LSP is totally dedicated to protect the working LSP you might as = well bridge the traffic on the protection LSP with an immediate benefit = of much better recovery time. The whole point of 1:1 protection is to = allow using resources of the protection LSP for something else - = carrying extra traffic in case of dedicated 1:1 or extra traffic and = other protection LSPs in cases of shared 1:1 protection. The other thing to note is that extra traffic does not have to be = carried all the time or any time for that matter - 1:1 protected service = is provisioned in such a way that extra traffic could be carried over = idle protection LSP should such need arise in the future. Thus, Dimitri = is right: O-bit is set to zero for the protection LSP to signal the fact = that originally the protection LSP is going to be idle in a sense that = it will not be carrying the"normal" (read protected traffic) and is = ready to carry extra traffic. Cheers and Happy Holidays, Igor ----- Original Message -----=20 From: Zafar Ali (zali)=20 To: Dimitri.Papadimitriou@alcatel.be=20 Cc: Adrian Farrel ; ccamp@ops.ietf.org ; owner-ccamp@ops.ietf.org=20 Sent: Tuesday, December 20, 2005 9:49 AM Subject: RE: A quick question on = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-s= ignaling-03.txt -------------------------------------------------------------------------= --- From: Dimitri.Papadimitriou@alcatel.be = [mailto:Dimitri.Papadimitriou@alcatel.be]=20 Sent: Tuesday, December 20, 2005 8:05 AM To: Zafar Ali (zali) Cc: Adrian Farrel; ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org Subject: Re: A quick question on = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-s= ignaling-03.txt zafar, i am not sure to fully understand your question=20 the O-bit is used for 1+1 and 1:1 protection scheme such as to have = an indication when a protecting LSP is carrying the "normal" traffic = after protection switching (so it applies only in case of 1+1 LSP = uni-/bidirectional protection or 1:1 LSP protection) . Dimitri,=20 More specifically, my question was mainly on what "LSP (Protection = Type) Flags" to use for, dedicated 1:1 protection, where=20 a.. Traffic is NOT duplicated at working and protecting LSP-es = (i.e., this is not 1+1 protection),=20 b.. There is NO extra traffic on the protecting LSP (i.e., it's = dedicated protection),=20 In this case there is NO duplication of the traffic on the backup = resource (it's NOT 1+1). There is also NO extra traffic that protection = resources carry.=20 Thanks Regards... Zafar=20 thanks,=20 - dimitri.=20 ps: purpose is not to "contrast" between protection schemes=20 "Zafar Ali \(zali\)" =20 Sent by: owner-ccamp@ops.ietf.org=20 19/12/2005 23:10=20 =20 To: =20 cc: "Adrian Farrel" , = Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL=20 Subject: A quick question on = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-s= ignaling-03.txt=20 Hi All,=20 =20 It's a bit confusing how one would encode protection object for = dedicated 1:1 protection (without traffic duplication) and I thought it = deserves a confirmation.=20 =20 I just wanted to confirm that to signal an LSP that is dedicated 1:1 = protection, where=20 a.. Traffic is NOT duplicated at working and protecting LSP-es = (i.e., this is not 1+1 protection),=20 b.. There is NO extra traffic on the protecting LSP (i.e., it's = dedicated protection),=20 we are expected to:=20 a.. Set O-bit in protection object to 1 in signaling protecting = LSP, to indicate that the protecting LSP is (only) carrying the normal = traffic after protection switching (i.e., It's NOT 1+1 setup). If = contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is the = intended use.=20 b.. LSP (Protection Type) Flags to 0x10 =3D 1+1 Bi-directional = Protection (for GMPLS optical LSPs). I.e., this is a dedicated = protection. If above is not the intended use of O-bit, I am not sure why O-bit = is defined (as protection LSP is expected to carry normal traffic after = switchover). In which is it expected to use 0x04 =3D 1:N Protection with = Extra-Traffic as LSP (Protection Type) Flags?=20 =20 Thanks=20 =20 Regards... Zafar=20 =20 ------=_NextPart_000_073C_01C60556.CA16DC60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Zafar,
 
I have a question to you. Why would you = need a=20 dedicated 1:1 protection without allowing the protection LSP to be used = for=20 carrying extra traffic? If the resources of the protection LSP are = allocated=20 anyway and the LSP is totally dedicated to protect the working LSP you = might as=20 well bridge the traffic on the protection LSP with an immediate benefit = of much=20 better recovery time. The whole point of 1:1 protection is to allow = using=20 resources of the protection LSP for something else - carrying extra = traffic in=20 case of dedicated 1:1 or extra traffic and other protection LSPs in = cases of=20 shared 1:1 protection.
 
The other thing to note is that extra = traffic does=20 not have to be carried all the time or any time for that matter - 1:1 = protected=20 service is provisioned in such a way that extra traffic could be carried = over=20 idle protection LSP should such need arise in the future. Thus, Dimitri = is=20 right: O-bit is set to zero for the protection LSP to signal the fact = that=20 originally the protection LSP is going to be idle in a sense that it = will not be=20 carrying the"normal" (read protected traffic) and is ready to carry = extra=20 traffic.
 
Cheers and Happy Holidays,
Igor
----- Original Message -----
From:=20 Zafar Ali = (zali)=20
To: Dimitri.Papadimitriou@al= catel.be=20
Cc: Adrian Farrel ; ccamp@ops.ietf.org ; owner-ccamp@ops.ietf.org =
Sent: Tuesday, December 20, = 2005 9:49=20 AM
Subject: RE: A quick question = on http://www.ietf.org/internet-drafts/draft-ietf-c= camp-gmpls-recovery-e2e-signaling-03.txt

 


From: Dimitri.Papadimitriou@al= catel.be=20 [mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Tuesday, = December=20 20, 2005 8:05 AM
To: Zafar Ali (zali)
Cc: Adrian = Farrel;=20 ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
= Subject:=20 Re: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-c= camp-gmpls-recovery-e2e-signaling-03.txt


zafar, i am not sure to = fully=20 understand your question

the=20 O-bit is used for 1+1 and 1:1 protection scheme such as to have an=20 indication when a protecting LSP is carrying the "normal" traffic = after=20 protection switching (so it applies only in case of 1+1 LSP=20 uni-/bidirectional protection or 1:1 LSP = protection)  .
 
Dimitri,
 
More=20 specifically, my question was mainly on what "LSP (Protection = Type)=20 Flags" to use for, dedicated 1:1 protection, where =
  • Traffic is NOT = duplicated at=20 working and protecting LSP-es (i.e., this is not 1+1 protection), =
  • There is NO extra = traffic on the=20 protecting LSP (i.e., it's dedicated protection),=20
In=20 this case there is NO duplication of the traffic on the backup = resource (it's=20 NOT 1+1). There is also NO extra traffic that protection resources = carry.=20
 
Thanks
 
Regards... Zafar
 


thanks,
- = dimitri.=20

ps: purpose is not to = "contrast"=20 between protection schemes



"Zafar Ali \(zali\)"=20 <zali@cisco.com>
Sent by: owner-ccamp@ops.ietf.org=20

19/12/2005 23:10 =

       =20
    =    =20 To:       =  <ccamp@ops.ietf.org>=20
      =   cc:=20        "Adrian Farrel"=20 <adrian@olddog.co.uk>, Dimitri=20 PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        Subject:     =  =20  A quick question on=20 = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-s= ignaling-03.txt



Hi All,
 
It's a bit confusing how one would encode = protection=20 object for dedicated 1:1 protection (without traffic duplication) = and I=20 thought it deserves a confirmation.
 =20
I just wanted to confirm that to = signal an LSP=20 that is dedicated 1:1 protection, where=20
  • Traffic is NOT duplicated at = working and=20 protecting LSP-es (i.e., this is not 1+1 protection),=20
  • There is NO extra traffic on the = protecting=20 LSP (i.e., it's dedicated protection),
we are expected to:
  • Set O-bit in protection object to = 1 in=20 signaling protecting LSP, to indicate that the protecting LSP is = (only)=20 carrying the normal traffic after protection switching (i.e., It's = NOT 1+1=20 setup). If contrasting 1:1 with 1+1 is NOT the intended use of = O-bit, what=20 is the intended use.
  • LSP (Protection Type) Flags to = 0x10 =3D 1+1=20 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is = a=20 dedicated protection.
If above is=20 not the intended use of O-bit, I am not sure why O-bit is defined = (as=20 protection LSP is expected to carry normal traffic after = switchover). In=20 which is it expected to use 0x04 =3D 1:N Protection with = Extra-Traffic as LSP=20 (Protection Type) Flags?
  =
Thanks
  =
Regards... Zafar
 =20
------=_NextPart_000_073C_01C60556.CA16DC60-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Dec 2005 15:42: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: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Date: Tue, 20 Dec 2005 09:41:48 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF0B407837@OCCLUST04EVS1.ugd.att.com> Thread-Topic: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Thread-Index: AcYFa/jBhNOjrJLOQwKRKwgHrNzmjQADFLCQ From: "Brungard, Deborah A, ALABS" To: "Huub van Helvoort" , Cc: "Zafar Ali \(zali\)" , "Adrian Farrel" , Hi Huub, The 0-bit is a control plane parameter, it's not controlling data plane operations, it's an indication reflecting the data plane operations. As you note, traffic is bridged. Operationally though GMPLS needs to know the administrative state for each. Section 3 (Introduction) has the data plane definitions which you are referencing below. And the other recovery RFCs provide much more detail on the ITU Rec'ds definitions. Thanks, Deborah -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Huub van Helvoort Sent: Tuesday, December 20, 2005 8:47 AM To: Dimitri.Papadimitriou@alcatel.be Cc: Zafar Ali (zali); Adrian Farrel; ccamp@ops.ietf.org Subject: Re: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e- signaling-03.txt Hi Dimitri, You wrote: > zafar, i am not sure to fully understand your question >=20 > the O-bit is used for 1+1 and 1:1 protection scheme such as to have an > indication when a protecting LSP is carrying the "normal" traffic after=20 > protection switching (so it applies only in case of 1+1 LSP=20 > uni-/bidirectional protection or 1:1 LSP protection) [hvh] in 1+1 "normal" traffic is bridged to both working and protecting LSP, at the receiving end a switch is used to select either the working or protecting LSP. In this case the O-bit you describe above has no meaning. In uni-directional protection switching the switch state is independent of the switch state of the return LSP. In bi-directional protection switching both switches will switch simultaneously (both working LSP or protecting LSP). Cheers, Huub. > thanks, > - dimitri. >=20 > ps: purpose is not to "contrast" between protection schemes >=20 > "Zafar Ali \(zali\)" > Sent by: owner-ccamp@ops.ietf.org >=20 > 19/12/2005 23:10 >=20 > =20 > To: > cc: "Adrian Farrel" , Dimitri=20 > PAPADIMITRIOU/BE/ALCATEL@ALCATEL > Subject: A quick question on=20 > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e- signaling-03.txt >=20 >=20 >=20 >=20 > Hi All, > =20 > It's a bit confusing how one would encode protection object for=20 > dedicated 1:1 protection (without traffic duplication) and I thought it=20 > deserves a confirmation. > =20 > I just wanted to confirm that to signal an LSP that is dedicated 1:1=20 > protection, where >=20 > * Traffic is NOT duplicated at working and protecting LSP-es (i.e., > this is not 1+1 protection), > * There is NO extra traffic on the protecting LSP (i.e., it's > dedicated protection),=20 >=20 > we are expected to: >=20 > * Set O-bit in protection object to 1 in signaling protecting LSP, > to indicate that the protecting LSP is (only) carrying the normal > traffic after protection switching (i.e., It's NOT 1+1 setup). If > contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is > the intended use. > * LSP (Protection Type) Flags to 0x10 =3D 1+1 Bi-directional > Protection (for GMPLS optical LSPs). I.e., this is a dedicated > protection. >=20 > If above is not the intended use of O-bit, I am not sure why O-bit is=20 > defined (as protection LSP is expected to carry normal traffic after=20 > switchover). In which is it expected to use 0x04 =3D 1:N Protection = with > Extra-Traffic as LSP (Protection Type) Flags? > =20 > Thanks > =20 > Regards... Zafar > =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://members.chello.nl/hhelvoort/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Dec 2005 15:08:35 +0000 To: "Zafar Ali \(zali\)" Cc: "Adrian Farrel" , ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: RE: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Tue, 20 Dec 2005 16:07:50 +0100 Content-Type: multipart/alternative; boundary="=_alternative 00531DD8C12570DD_=" This is a multipart message in MIME format. --=_alternative 00531DD8C12570DD_= Content-Type: text/plain; charset="US-ASCII" zafar > More specifically, my question was mainly on what > "LSP (Protection Type) Flags" to use for, dedicated > 1:1 protection, where > - Traffic is NOT duplicated at working and protecting > LSP-es (i.e., this is not 1+1 protection), > - There is NO extra traffic on the protecting LSP > (i.e., it's dedicated protection), > In this case there is NO duplication of the traffic > on the backup resource (it's NOT 1+1). There is also > NO extra traffic that protection resources carry. as pointed into the document for the 1:1 LSP protection: "Although the resources for the protecting LSP are pre-allocated, preemptable traffic may be carried end-to-end using this LSP. Thus, the protecting LSP is capable of carrying extra-traffic with the caveat that this traffic will be preempted if the working LSP fails." hope this clarifies (i.e. there is no specific flag when there is no extra-traffic) > Thanks > > Regards... Zafar thanks, - dimitri. ps: purpose is not to "contrast" between protection schemes "Zafar Ali \(zali\)" Sent by: owner-ccamp@ops.ietf.org 19/12/2005 23:10 To: cc: "Adrian Farrel" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL Subject: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Hi All, It's a bit confusing how one would encode protection object for dedicated 1:1 protection (without traffic duplication) and I thought it deserves a confirmation. I just wanted to confirm that to signal an LSP that is dedicated 1:1 protection, where Traffic is NOT duplicated at working and protecting LSP-es (i.e., this is not 1+1 protection), There is NO extra traffic on the protecting LSP (i.e., it's dedicated protection), we are expected to: Set O-bit in protection object to 1 in signaling protecting LSP, to indicate that the protecting LSP is (only) carrying the normal traffic after protection switching (i.e., It's NOT 1+1 setup). If contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is the intended use. LSP (Protection Type) Flags to 0x10 = 1+1 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is a dedicated protection. If above is not the intended use of O-bit, I am not sure why O-bit is defined (as protection LSP is expected to carry normal traffic after switchover). In which is it expected to use 0x04 = 1:N Protection with Extra-Traffic as LSP (Protection Type) Flags? Thanks Regards... Zafar --=_alternative 00531DD8C12570DD_= Content-Type: text/html; charset="US-ASCII"


zafar
 
> More specifically, my question was mainly on what
> "LSP (Protection Type) Flags" to use for, dedicated
> 1:1 protection, where
> - Traffic is NOT duplicated at working and protecting
>   LSP-es (i.e., this is not 1+1 protection),
> - There is NO extra traffic on the protecting LSP
>   (i.e., it's dedicated protection),
> In this case there is NO duplication of the traffic
> on the backup resource (it's NOT 1+1). There is also
> NO extra traffic that protection resources carry.
 
as pointed into the document for the 1:1 LSP protection:

   "Although the resources for the protecting LSP are pre-allocated,
  preemptable traffic may be carried end-to-end using this LSP. Thus,
  the protecting LSP is capable of carrying extra-traffic with the
  caveat that this traffic will be preempted if the working LSP fails."  


hope this clarifies (i.e. there is no specific flag when there is no extra-traffic)

> Thanks
>
> Regards... Zafar
 
 

thanks,

- dimitri.


ps: purpose is not to "contrast" between protection schemes



"Zafar Ali \(zali\)" <zali@cisco.com>
Sent by: owner-ccamp@ops.ietf.org

19/12/2005 23:10

       
       To:        <ccamp@ops.ietf.org>

       cc:        "Adrian Farrel" <adrian@olddog.co.uk>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL

       Subject:        A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt




Hi All,

 

It's a bit confusing how one would encode protection object for dedicated 1:1 protection (without traffic duplication) and I thought it deserves a confirmation.

 

I just wanted to confirm that to signal an LSP that is dedicated 1:1 protection, where
  • Traffic is NOT duplicated at working and protecting LSP-es (i.e., this is not 1+1 protection),
  • There is NO extra traffic on the protecting LSP (i.e., it's dedicated protection),
we are expected to:
  • Set O-bit in protection object to 1 in signaling protecting LSP, to indicate that the protecting LSP is (only) carrying the normal traffic after protection switching (i.e., It's NOT 1+1 setup). If contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is the intended use.
  • LSP (Protection Type) Flags to 0x10 = 1+1 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is a dedicated protection.
If above is not the intended use of O-bit, I am not sure why O-bit is defined (as protection LSP is expected to carry normal traffic after switchover). In which is it expected to use 0x04 = 1:N Protection with Extra-Traffic as LSP (Protection Type) Flags?
 

Thanks

 

Regards... Zafar

 

--=_alternative 00531DD8C12570DD_=-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Dec 2005 14:50:29 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C60574.93171DC4" Subject: RE: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Date: Tue, 20 Dec 2005 09:49:26 -0500 Message-ID: Thread-Topic: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Thread-Index: AcYFZjCQkY2kna9LTMGA9hkjtA/q1wADgIYA From: "Zafar Ali \(zali\)" To: Cc: "Adrian Farrel" , , This is a multi-part message in MIME format. ------_=_NextPart_001_01C60574.93171DC4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be]=20 Sent: Tuesday, December 20, 2005 8:05 AM To: Zafar Ali (zali) Cc: Adrian Farrel; ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org Subject: Re: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e- signaling-03.txt =09 =09 zafar, i am not sure to fully understand your question=20 =09 the O-bit is used for 1+1 and 1:1 protection scheme such as to have an indication when a protecting LSP is carrying the "normal" traffic after protection switching (so it applies only in case of 1+1 LSP uni-/bidirectional protection or 1:1 LSP protection) . =20 Dimitri,=20 =20 More specifically, my question was mainly on what "LSP (Protection Type) Flags" to use for, dedicated 1:1 protection, where=20 * Traffic is NOT duplicated at working and protecting LSP-es (i.e., this is not 1+1 protection),=20 * There is NO extra traffic on the protecting LSP (i.e., it's dedicated protection),=20 In this case there is NO duplication of the traffic on the backup resource (it's NOT 1+1). There is also NO extra traffic that protection resources carry.=20 =20 Thanks =20 Regards... Zafar=20 =20 =20 =09 thanks,=20 - dimitri.=20 =09 ps: purpose is not to "contrast" between protection schemes=20 =09 =09 =09 =09 "Zafar Ali \(zali\)" =20 Sent by: owner-ccamp@ops.ietf.org=20 19/12/2005 23:10=20 =20 To: =20 cc: "Adrian Farrel" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL=20 Subject: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e- signaling-03.txt Hi All,=20 =20 It's a bit confusing how one would encode protection object for dedicated 1:1 protection (without traffic duplication) and I thought it deserves a confirmation.=20 =20 I just wanted to confirm that to signal an LSP that is dedicated 1:1 protection, where=20 * Traffic is NOT duplicated at working and protecting LSP-es (i.e., this is not 1+1 protection),=20 * There is NO extra traffic on the protecting LSP (i.e., it's dedicated protection),=20 we are expected to:=20 * Set O-bit in protection object to 1 in signaling protecting LSP, to indicate that the protecting LSP is (only) carrying the normal traffic after protection switching (i.e., It's NOT 1+1 setup). If contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is the intended use.=20 * LSP (Protection Type) Flags to 0x10 =3D 1+1 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is a dedicated protection. If above is not the intended use of O-bit, I am not sure why O-bit is defined (as protection LSP is expected to carry normal traffic after switchover). In which is it expected to use 0x04 =3D 1:N = Protection with Extra-Traffic as LSP (Protection Type) Flags?=20 =20 Thanks=20 =20 Regards... Zafar=20 =20 =09 ------_=_NextPart_001_01C60574.93171DC4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 


From: = Dimitri.Papadimitriou@alcatel.be=20 [mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Tuesday, = December=20 20, 2005 8:05 AM
To: Zafar Ali (zali)
Cc: Adrian = Farrel;=20 ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
Subject: Re: A = quick=20 question on=20 = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-s= ignaling-03.txt


zafar, i am not sure to = fully=20 understand your question

the=20 O-bit is used for 1+1 and 1:1 protection scheme such as to have an = indication=20 when a protecting LSP is carrying the "normal" traffic after = protection=20 switching (so it applies only in case of 1+1 LSP uni-/bidirectional = protection=20 or 1:1 LSP protection)  .
 
Dimitri,
 
More=20 specifically, my question was mainly on what "LSP (Protection = Type)=20 Flags" to use for, dedicated 1:1 protection, where =
  • Traffic is NOT = duplicated at working=20 and protecting LSP-es (i.e., this is not 1+1 protection),
  • There is NO extra = traffic on the=20 protecting LSP (i.e., it's dedicated protection), =
In=20 this case there is NO duplication of the traffic on the backup resource = (it's=20 NOT 1+1). There is also NO extra traffic that protection resources = carry.=20
 
Thanks
 
Regards... Zafar
 
 

thanks,
-=20 dimitri.

ps: = purpose is not to=20 "contrast" between protection schemes



"Zafar Ali \(zali\)"=20 <zali@cisco.com>
Sent=20 by: owner-ccamp@ops.ietf.org=20

19/12/2005 23:10

        =
        To: =    =20    <ccamp@ops.ietf.org>
        cc:      =20  "Adrian Farrel" <adrian@olddog.co.uk>, Dimitri=20 PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        Subject:     =    A=20 quick question on=20 = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-s= ignaling-03.txt



Hi All,
  =
It's a bit confusing how one would encode = protection object=20 for dedicated 1:1 protection (without traffic duplication) and I = thought it=20 deserves a confirmation.
  =
I just wanted to confirm that to signal an LSP = that is=20 dedicated 1:1 protection, where=20
  • Traffic is NOT duplicated at working = and=20 protecting LSP-es (i.e., this is not 1+1 protection),=20
  • There is NO extra traffic on the = protecting LSP=20 (i.e., it's dedicated protection),
we=20 are expected to:
  • Set O-bit in protection object to 1 = in signaling=20 protecting LSP, to indicate that the protecting LSP is (only) = carrying the=20 normal traffic after protection switching (i.e., It's NOT 1+1 = setup). If=20 contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is = the=20 intended use.
  • LSP (Protection Type) Flags to 0x10 = =3D 1+1=20 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is a=20 dedicated protection.
If = above is not=20 the intended use of O-bit, I am not sure why O-bit is defined (as = protection=20 LSP is expected to carry normal traffic after switchover). In which is = it=20 expected to use 0x04 =3D 1:N Protection with Extra-Traffic as LSP = (Protection=20 Type) Flags?
 
Thanks
 
Regards... Zafar
 =20
------_=_NextPart_001_01C60574.93171DC4-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Dec 2005 13:47:23 +0000 Message-ID: <43A80B3C.3040500@chello.nl> Date: Tue, 20 Dec 2005 14:46:36 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: "Zafar Ali (zali)" , Adrian Farrel , ccamp@ops.ietf.org Subject: Re: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Dimitri, You wrote: > zafar, i am not sure to fully understand your question > > the O-bit is used for 1+1 and 1:1 protection scheme such as to have an > indication when a protecting LSP is carrying the "normal" traffic after > protection switching (so it applies only in case of 1+1 LSP > uni-/bidirectional protection or 1:1 LSP protection) [hvh] in 1+1 "normal" traffic is bridged to both working and protecting LSP, at the receiving end a switch is used to select either the working or protecting LSP. In this case the O-bit you describe above has no meaning. In uni-directional protection switching the switch state is independent of the switch state of the return LSP. In bi-directional protection switching both switches will switch simultaneously (both working LSP or protecting LSP). Cheers, Huub. > thanks, > - dimitri. > > ps: purpose is not to "contrast" between protection schemes > > "Zafar Ali \(zali\)" > Sent by: owner-ccamp@ops.ietf.org > > 19/12/2005 23:10 > > > To: > cc: "Adrian Farrel" , Dimitri > PAPADIMITRIOU/BE/ALCATEL@ALCATEL > Subject: A quick question on > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt > > > > > Hi All, > > It's a bit confusing how one would encode protection object for > dedicated 1:1 protection (without traffic duplication) and I thought it > deserves a confirmation. > > I just wanted to confirm that to signal an LSP that is dedicated 1:1 > protection, where > > * Traffic is NOT duplicated at working and protecting LSP-es (i.e., > this is not 1+1 protection), > * There is NO extra traffic on the protecting LSP (i.e., it's > dedicated protection), > > we are expected to: > > * Set O-bit in protection object to 1 in signaling protecting LSP, > to indicate that the protecting LSP is (only) carrying the normal > traffic after protection switching (i.e., It's NOT 1+1 setup). If > contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is > the intended use. > * LSP (Protection Type) Flags to 0x10 = 1+1 Bi-directional > Protection (for GMPLS optical LSPs). I.e., this is a dedicated > protection. > > If above is not the intended use of O-bit, I am not sure why O-bit is > defined (as protection LSP is expected to carry normal traffic after > switchover). In which is it expected to use 0x04 = 1:N Protection with > Extra-Traffic as LSP (Protection Type) Flags? > > Thanks > > Regards... Zafar > -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Dec 2005 13:06:52 +0000 To: "Zafar Ali \(zali\)" Cc: "Adrian Farrel" , ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org Subject: Re: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Tue, 20 Dec 2005 14:05:12 +0100 Content-Type: multipart/alternative; boundary="=_alternative 0047E3A2C12570DD_=" This is a multipart message in MIME format. --=_alternative 0047E3A2C12570DD_= Content-Type: text/plain; charset="US-ASCII" zafar, i am not sure to fully understand your question the O-bit is used for 1+1 and 1:1 protection scheme such as to have an indication when a protecting LSP is carrying the "normal" traffic after protection switching (so it applies only in case of 1+1 LSP uni-/bidirectional protection or 1:1 LSP protection) thanks, - dimitri. ps: purpose is not to "contrast" between protection schemes "Zafar Ali \(zali\)" Sent by: owner-ccamp@ops.ietf.org 19/12/2005 23:10 To: cc: "Adrian Farrel" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL Subject: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Hi All, It's a bit confusing how one would encode protection object for dedicated 1:1 protection (without traffic duplication) and I thought it deserves a confirmation. I just wanted to confirm that to signal an LSP that is dedicated 1:1 protection, where Traffic is NOT duplicated at working and protecting LSP-es (i.e., this is not 1+1 protection), There is NO extra traffic on the protecting LSP (i.e., it's dedicated protection), we are expected to: Set O-bit in protection object to 1 in signaling protecting LSP, to indicate that the protecting LSP is (only) carrying the normal traffic after protection switching (i.e., It's NOT 1+1 setup). If contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is the intended use. LSP (Protection Type) Flags to 0x10 = 1+1 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is a dedicated protection. If above is not the intended use of O-bit, I am not sure why O-bit is defined (as protection LSP is expected to carry normal traffic after switchover). In which is it expected to use 0x04 = 1:N Protection with Extra-Traffic as LSP (Protection Type) Flags? Thanks Regards... Zafar --=_alternative 0047E3A2C12570DD_= Content-Type: text/html; charset="US-ASCII"
zafar, i am not sure to fully understand your question

the O-bit is used for 1+1 and 1:1 protection scheme such as to have an indication when a protecting LSP is carrying the "normal" traffic after protection switching (so it applies only in case of 1+1 LSP uni-/bidirectional protection or 1:1 LSP protection)

thanks,
- dimitri.

ps: purpose is not to "contrast" between protection schemes



"Zafar Ali \(zali\)" <zali@cisco.com>
Sent by: owner-ccamp@ops.ietf.org

19/12/2005 23:10

       
        To:        <ccamp@ops.ietf.org>
        cc:        "Adrian Farrel" <adrian@olddog.co.uk>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        Subject:        A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt



Hi All,
 
It's a bit confusing how one would encode protection object for dedicated 1:1 protection (without traffic duplication) and I thought it deserves a confirmation.
 
I just wanted to confirm that to signal an LSP that is dedicated 1:1 protection, where
  • Traffic is NOT duplicated at working and protecting LSP-es (i.e., this is not 1+1 protection),
  • There is NO extra traffic on the protecting LSP (i.e., it's dedicated protection),
we are expected to:
  • Set O-bit in protection object to 1 in signaling protecting LSP, to indicate that the protecting LSP is (only) carrying the normal traffic after protection switching (i.e., It's NOT 1+1 setup). If contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is the intended use.
  • LSP (Protection Type) Flags to 0x10 = 1+1 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is a dedicated protection.
If above is not the intended use of O-bit, I am not sure why O-bit is defined (as protection LSP is expected to carry normal traffic after switchover). In which is it expected to use 0x04 = 1:N Protection with Extra-Traffic as LSP (Protection Type) Flags?
 
Thanks
 
Regards... Zafar
 
--=_alternative 0047E3A2C12570DD_=-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Dec 2005 22:13:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C604E9.00BA3618" Subject: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Date: Mon, 19 Dec 2005 17:10:21 -0500 Message-ID: Thread-Topic: A quick question on http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Thread-Index: AcYE6QCTl8IWQZHwQbiGe/Av7cpNAw== From: "Zafar Ali \(zali\)" To: Cc: "Adrian Farrel" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C604E9.00BA3618 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All,=20 =20 It's a bit confusing how one would encode protection object for dedicated 1:1 protection (without traffic duplication) and I thought it deserves a confirmation.=20 =20 I just wanted to confirm that to signal an LSP that is dedicated 1:1 protection, where * Traffic is NOT duplicated at working and protecting LSP-es (i.e., this is not 1+1 protection), * There is NO extra traffic on the protecting LSP (i.e., it's dedicated protection),=20 we are expected to:=20 * Set O-bit in protection object to 1 in signaling protecting LSP, to indicate that the protecting LSP is (only) carrying the normal traffic after protection switching (i.e., It's NOT 1+1 setup). If contrasting 1:1 with 1+1 is NOT the intended use of O-bit, what is the intended use.=20 * LSP (Protection Type) Flags to 0x10 =3D 1+1 Bi-directional Protection (for GMPLS optical LSPs). I.e., this is a dedicated protection. If above is not the intended use of O-bit, I am not sure why O-bit is defined (as protection LSP is expected to carry normal traffic after switchover). In which is it expected to use 0x04 =3D 1:N Protection with Extra-Traffic as LSP (Protection Type) Flags?=20 =20 Thanks =20 Regards... Zafar=20 =20 ------_=_NextPart_001_01C604E9.00BA3618 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi = All,=20
 
It's a = bit confusing=20 how one would encode protection object for dedicated 1:1 protection = (without=20 traffic duplication) and I thought it deserves a confirmation.=20
 
I just = wanted to=20 confirm that to signal an LSP that is dedicated 1:1 protection,=20 where
  • Traffic is NOT=20 duplicated at working and protecting LSP-es (i.e., this is not 1+1=20 protection),
  • There = is NO extra=20 traffic on the protecting LSP (i.e., it's dedicated protection),=20
we are = expected to:=20
  • Set = O-bit in=20 protection object to 1 in signaling protecting LSP, to indicate that = the=20 protecting LSP is (only) carrying the normal traffic after = protection=20 switching (i.e., It's NOT 1+1 setup). If contrasting 1:1 with 1+1 is = NOT the=20 intended use of O-bit, what is the intended use.
  • LSP=20 (Protection Type) Flags to 0x10 =3D 1+1 Bi-directional Protection = (for=20 GMPLS optical LSPs). I.e., this is a dedicated=20 protection.
If above=20 is not the intended use of O-bit, I am not sure why O-bit is = defined (as=20 protection LSP is expected to carry normal traffic after switchover). In = which=20 is it expected to use 0x04 =3D 1:N Protection with = Extra-Traffic as=20 LSP (Protection Type) Flags?=20
 
Thanks
 
Regards... Zafar=20
 
------_=_NextPart_001_01C604E9.00BA3618-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 18 Dec 2005 21:42:34 +0000 Message-ID: <000f01c60412$f1f31540$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , Cc: Subject: [what's this?] was Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd) Date: Sat, 17 Dec 2005 18:27:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The use of brackets puzzled me for a while; nothing wrong with it as a convention but I would suggest explaining it in a Conventions section somewhere early on - and yes, I would change from [] to {} or <> or ... Tom Petch ----- Original Message ----- From: To: "Adrian Farrel" Cc: "Kireeti Kompella" ; "Dimitri Papadimitriou" ; Sent: Saturday, December 17, 2005 11:57 AM Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd) > hi adrian > > Thanks for reading. > > > 1. i still don't understand the need for the [ ... ] after each term - > if > > authors could clarify this would be helpful > > Hmm. Well the intention was to provide extra information in a quick way. I > guess we could replace each [...] with a full sentence such as "This term > applies to the control plane." > > I suppose that the RFC editor is going to object to our use of square > brackets :-( > > > [dp] my confusion is where it is for inst. listed in Section 3.7.1 > > "Unidirectional connection (LSP) [data plane]" the term in GMPLS is "Unidirectional LSP" while there is a non-GMPLS term as part of the term the text introduces, i don't see anymore whether the text in brackets refers to as an LSP is a representation of a data plane connection (or whatever term is suitable here) > > [dp] i think in general that the GMPLS term that are listed for clarification should make use of their exact denomination > > > > 2. in general, i don't see why this document meant to clarify GMPLS > > terms for ASON includes ASON specific terms/definitions and interpretations > > hence the need for each "ASON terms" sub-section is unclear > > The intention is not just to clarify the GMPLS terms, but also to provide > a mapping. The full purpose (of making GMPLS comprehensible to ASON > cognoscenti) is aided by the inclusion of corresponding ASON terms. What > we have done, therefore, is split the text into: > - a description of the GMPLS term > - a translation into "equivalent" ASON terms > > Do you have an objection to this? > > [dp] let's take the example of Section 3.7.2 "A GMPLS connection is an ASON network connection" the notion of "ASON network connection" is probably correctly interpreted if you make use of the term "GMPLS connection" > > [dp] the other aspect is also the "equivalence" notion leads to things a "H-LSP is a trail" probably but the whole text coming earlier in the document seem to refer to it as a "link" > > [dp] in brief, what i mean is that i find that for the "GMPLS reader" the reverse reading quite difficult > > > some other specifics > > > > 3. " Node [Control & Data Planes] is a logical combination of a > > transport node and the controller that manages the transport node. > > In early deployments, all control plane and data plane functions > > associated with a transport node were collocated in a node and > > referred to as a Label Switching Router (LSR)." > > > > the second sentence is imho outside the scope of such definition > > Some of the GMPLS RFCs are simplified by the use of "LSR", but it has been > pointed out on numerous occasions that this creates an impression that in > GMPLS there is *always* a tight binding (collocation) between control and > data plane functions. As you know, this impression is contrary to reality. > > A couple of questions back to you. > > Is what it says incorrect? > > [dp] yes, current deployments still make use of what you seem to refer to as history ("in early deployments") > > > Would it help if we had a separate entry for LSR? > > [dp] yes > > > 4. "3.4.1. GMPLS Terms > > > > Label [Control Plane] is an abstraction that provides an identifier > > for use in the control plane in order to identify a transport plane > > resource." > > > > how to interpreet an MPLS label with this definition ? or is MPLS out of > > scope ? > > MPLS is out of scope because there is possible translation to ASON. > > Note, however, we felt it helpful to include "Packet based resource" > > [dp] this is also what i understood but it seems that closing the ring of definition and interpretations is impossible; hence, my suggestion either to have a complete definition of packet-related interpretation or no coverage at all > > > 5. "3.5.1. GMPLS Terms > > > > Unidirectional data link end [Data Plane] is a set of resources of a > > particular layer that belong to the same transport node and could > > be allocated for the transfer of traffic in this layer to the same > > neighbor in the same direction." > > > > what "same transport node" means here ? > > Erm? > > It means "same transport node" :-) > > The intention is to imply that all of the resources in the set belong to > the same transport node. > > Maybe rephrase as: > > > Unidirectional data link end [Data Plane] is a set of resources that > all belong to the same transport node, all are in the same layer, > and that could be allocated for the transfer of traffic in this > layer to the same neighbor in the same direction." > > > [dp] ok (guess you will align subsequent text along the same line) > > > > > 6. " The need for advertisement of adaptation and termination > capabilities > > within GMPLS has been recognized and work is in progress to determine > > how these will be advertised. It is likely that they will be > > advertised as a single combined attribute, or as separate attributes > > of the TE link local end associated with the link interface." > > > > afaik, GMPLS is able to advertize "termination" capabilities - > > Does it? > > > > [dp] yes but implicitly when you have a [LSC,PSC] TE link, meaning one side says in its interface SC descriptor TLV PSC and the other LSC, it implicitly means the "PSC side" terminates LSC and switches at the PSC level > > > It seems to me that it advertizes switching capabilities only. > Termination, like adaptation, is not the same thing as switching > capability. > > Switching capability says how the link terminates, but not whether the > node can terminate data flows. > > Cheers, > Adrian > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 17 Dec 2005 10:59:32 +0000 To: "Adrian Farrel" Cc: "Kireeti Kompella" , "Dimitri Papadimitriou" , MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd) Date: Sat, 17 Dec 2005 11:57:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmhpIGFkcmlhbiA8L0ZPTlQ+PEJSPjxC Uj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+VGhhbmtzIGZvciByZWFkaW5nLjxCUj48 L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7IDEuIGkgc3RpbGwg ZG9uJ3QgdW5kZXJzdGFuZCB0aGUgbmVlZCBmb3IgdGhlIFsgLi4uIF0gYWZ0ZXIgZWFjaCB0ZXJt IC08QlI+aWY8QlI+Jmd0OyBhdXRob3JzIGNvdWxkIGNsYXJpZnkgdGhpcyB3b3VsZCBiZSBoZWxw ZnVsPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkhtbS4gV2Vs bCB0aGUgaW50ZW50aW9uIHdhcyB0byBwcm92aWRlIGV4dHJhIGluZm9ybWF0aW9uIGluIGEgcXVp Y2sgd2F5LiBJPEJSPmd1ZXNzIHdlIGNvdWxkIHJlcGxhY2UgZWFjaCBbLi4uXSB3aXRoIGEgZnVs bCBzZW50ZW5jZSBzdWNoIGFzICZxdW90O1RoaXMgdGVybTxCUj5hcHBsaWVzIHRvIHRoZSBjb250 cm9sIHBsYW5lLiZxdW90OzxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy aWVyIj5JIHN1cHBvc2UgdGhhdCB0aGUgUkZDIGVkaXRvciBpcyBnb2luZyB0byBvYmplY3QgdG8g b3VyIHVzZSBvZiBzcXVhcmU8QlI+YnJhY2tldHMgOi0oPEJSPjwvRk9OVD48L1A+PFA+PEZPTlQg RkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPltkcF0gbXkgY29uZnVzaW9uIGlzIHdoZXJlIGl0IGlz IGZvciBpbnN0LiBsaXN0ZWQgaW4gU2VjdGlvbiAzLjcuMTwvRk9OVD48L1A+PFA+PEZPTlQgRkFD RT0iTW9ub3NwYWNlLENvdXJpZXIiPiZxdW90O1VuaWRpcmVjdGlvbmFsIGNvbm5lY3Rpb24gKExT UCkgW2RhdGEgcGxhbmVdJnF1b3Q7IHRoZSB0ZXJtIGluIEdNUExTIGlzICZxdW90O1VuaWRpcmVj dGlvbmFsIExTUCZxdW90OyB3aGlsZSB0aGVyZSBpcyBhIG5vbi1HTVBMUyB0ZXJtIGFzIHBhcnQg b2YgdGhlIHRlcm0gdGhlIHRleHQgaW50cm9kdWNlcywgaSBkb24ndCBzZWUgYW55bW9yZSB3aGV0 aGVyIHRoZSB0ZXh0IGluIGJyYWNrZXRzIHJlZmVycyB0byBhcyBhbiBMU1AgaXMgYSByZXByZXNl bnRhdGlvbiBvZiBhIGRhdGEgcGxhbmUgY29ubmVjdGlvbiAob3Igd2hhdGV2ZXIgdGVybSBpcyBz dWl0YWJsZSBoZXJlKTwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi PltkcF0gaSB0aGluayBpbiBnZW5lcmFsIHRoYXQgdGhlIEdNUExTIHRlcm0gdGhhdCBhcmUgbGlz dGVkIGZvciBjbGFyaWZpY2F0aW9uIHNob3VsZCBtYWtlIHVzZSBvZiB0aGVpciBleGFjdCBkZW5v bWluYXRpb248L0ZPTlQ+PC9QPjxQPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+ Jmd0OyAyLiBpbiBnZW5lcmFsLCBpIGRvbid0IHNlZSB3aHkgdGhpcyBkb2N1bWVudCBtZWFudCB0 byBjbGFyaWZ5IEdNUExTPEJSPiZndDsgdGVybXMgZm9yIEFTT04gaW5jbHVkZXMgQVNPTiBzcGVj aWZpYyB0ZXJtcy9kZWZpbml0aW9ucyBhbmQgaW50ZXJwcmV0YXRpb25zPEJSPiZndDsgaGVuY2Ug dGhlIG5lZWQgZm9yIGVhY2ggJnF1b3Q7QVNPTiB0ZXJtcyZxdW90OyBzdWItc2VjdGlvbiBpcyB1 bmNsZWFyPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlRoZSBp bnRlbnRpb24gaXMgbm90IGp1c3QgdG8gY2xhcmlmeSB0aGUgR01QTFMgdGVybXMsIGJ1dCBhbHNv IHRvIHByb3ZpZGU8QlI+YSBtYXBwaW5nLiBUaGUgZnVsbCBwdXJwb3NlIChvZiBtYWtpbmcgR01Q TFMgY29tcHJlaGVuc2libGUgdG8gQVNPTjxCUj5jb2dub3NjZW50aSkgaXMgYWlkZWQgYnkgdGhl IGluY2x1c2lvbiBvZiBjb3JyZXNwb25kaW5nIEFTT04gdGVybXMuIFdoYXQ8QlI+d2UgaGF2ZSBk b25lLCB0aGVyZWZvcmUsIGlzIHNwbGl0IHRoZSB0ZXh0IGludG86PEJSPi0gYSBkZXNjcmlwdGlv biBvZiB0aGUgR01QTFMgdGVybTxCUj4tIGEgdHJhbnNsYXRpb24gaW50byAmcXVvdDtlcXVpdmFs ZW50JnF1b3Q7IEFTT04gdGVybXM8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2Us Q291cmllciI+RG8geW91IGhhdmUgYW4gb2JqZWN0aW9uIHRvIHRoaXM/PC9GT05UPjwvUD48UD48 Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+W2RwXSBsZXQncyB0YWtlIHRoZSBleGFtcGxl IG9mIFNlY3Rpb24gMy43LjIgJnF1b3Q7QSBHTVBMUyBjb25uZWN0aW9uIGlzIGFuIEFTT04gbmV0 d29yayBjb25uZWN0aW9uJnF1b3Q7IHRoZSBub3Rpb24gb2YgJnF1b3Q7QVNPTiBuZXR3b3JrIGNv bm5lY3Rpb24mcXVvdDsgaXMgcHJvYmFibHkgY29ycmVjdGx5IGludGVycHJldGVkIGlmIHlvdSBt YWtlIHVzZSBvZiB0aGUgdGVybSAmcXVvdDtHTVBMUyBjb25uZWN0aW9uJnF1b3Q7IDwvRk9OVD48 L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPltkcF0gdGhlIG90aGVyIGFzcGVj dCBpcyBhbHNvIHRoZSAmcXVvdDtlcXVpdmFsZW5jZSZxdW90OyBub3Rpb24gbGVhZHMgdG8gdGhp bmdzIGEgJnF1b3Q7SC1MU1AgaXMgYSB0cmFpbCZxdW90OyBwcm9iYWJseSBidXQgdGhlIHdob2xl IHRleHQgY29taW5nIGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50IHNlZW0gdG8gcmVmZXIgdG8gaXQg YXMgYSAmcXVvdDtsaW5rJnF1b3Q7IDwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNl LENvdXJpZXIiPltkcF0gaW4gYnJpZWYsIHdoYXQgaSBtZWFuIGlzIHRoYXQgaSBmaW5kIHRoYXQg Zm9yIHRoZSAmcXVvdDtHTVBMUyByZWFkZXImcXVvdDsgdGhlIHJldmVyc2UgcmVhZGluZyBxdWl0 ZSBkaWZmaWN1bHQgPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi PiZndDsgc29tZSBvdGhlciBzcGVjaWZpY3M8QlI+Jmd0OzxCUj4mZ3Q7IDMuICZxdW90OyBOb2Rl IFtDb250cm9sICZhbXA7IERhdGEgUGxhbmVzXSBpcyBhIGxvZ2ljYWwgY29tYmluYXRpb24gb2Yg YTxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHJhbnNwb3J0IG5vZGUgYW5kIHRoZSBjb250 cm9sbGVyIHRoYXQgbWFuYWdlcyB0aGUgdHJhbnNwb3J0IG5vZGUuPEJSPiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtJbiBlYXJseSBkZXBsb3ltZW50cywgYWxsIGNvbnRyb2wgcGxhbmUgYW5kIGRh dGEgcGxhbmUgZnVuY3Rpb25zPEJSPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthc3NvY2lhdGVk IHdpdGggYSB0cmFuc3BvcnQgbm9kZSB3ZXJlIGNvbGxvY2F0ZWQgaW4gYSBub2RlIGFuZDxCUj4m Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVmZXJyZWQgdG8gYXMgYSBMYWJlbCBTd2l0Y2hpbmcg Um91dGVyIChMU1IpLiZxdW90OzxCUj4mZ3Q7PEJSPiZndDsgdGhlIHNlY29uZCBzZW50ZW5jZSBp cyBpbWhvIG91dHNpZGUgdGhlIHNjb3BlIG9mIHN1Y2ggZGVmaW5pdGlvbjxCUj48L0ZPTlQ+PEJS PjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5Tb21lIG9mIHRoZSBHTVBMUyBSRkNzIGFy ZSBzaW1wbGlmaWVkIGJ5IHRoZSB1c2Ugb2YgJnF1b3Q7TFNSJnF1b3Q7LCBidXQgaXQgaGFzIGJl ZW48QlI+cG9pbnRlZCBvdXQgb24gbnVtZXJvdXMgb2NjYXNpb25zIHRoYXQgdGhpcyBjcmVhdGVz IGFuIGltcHJlc3Npb24gdGhhdCBpbjxCUj5HTVBMUyB0aGVyZSBpcyAqYWx3YXlzKiBhIHRpZ2h0 IGJpbmRpbmcgKGNvbGxvY2F0aW9uKSBiZXR3ZWVuICZuYnNwO2NvbnRyb2wgYW5kPEJSPmRhdGEg cGxhbmUgZnVuY3Rpb25zLiBBcyB5b3Uga25vdywgdGhpcyBpbXByZXNzaW9uIGlzIGNvbnRyYXJ5 IHRvIHJlYWxpdHkuPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi PkEgY291cGxlIG9mIHF1ZXN0aW9ucyBiYWNrIHRvIHlvdS48QlI+PC9GT05UPjxCUj48Rk9OVCBG QUNFPSJNb25vc3BhY2UsQ291cmllciI+SXMgd2hhdCBpdCBzYXlzIGluY29ycmVjdD88L0ZPTlQ+ PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5bZHBdIHllcywgY3VycmVudCBk ZXBsb3ltZW50cyBzdGlsbCBtYWtlIHVzZSBvZiB3aGF0IHlvdSBzZWVtIHRvIHJlZmVyIHRvIGFz IGhpc3RvcnkgKCZxdW90O2luIGVhcmx5IGRlcGxveW1lbnRzJnF1b3Q7KTwvRk9OVD48L1A+PFA+ PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPjxCUj5Xb3VsZCBpdCBoZWxwIGlmIHdlIGhh ZCBhIHNlcGFyYXRlIGVudHJ5IGZvciBMU1I/PC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25v c3BhY2UsQ291cmllciI+W2RwXSB5ZXM8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3Bh Y2UsQ291cmllciI+Jmd0OyA0LiAmcXVvdDszLjQuMS4gR01QTFMgVGVybXM8QlI+Jmd0OzxCUj4m Z3Q7ICZuYnNwOyAmbmJzcDtMYWJlbCBbQ29udHJvbCBQbGFuZV0gaXMgYW4gYWJzdHJhY3Rpb24g dGhhdCBwcm92aWRlcyBhbiBpZGVudGlmaWVyPEJSPiZndDsgJm5ic3A7ICZuYnNwO2ZvciB1c2Ug aW4gdGhlIGNvbnRyb2wgcGxhbmUgaW4gb3JkZXIgdG8gaWRlbnRpZnkgYSB0cmFuc3BvcnQgcGxh bmU8QlI+Jmd0OyAmbmJzcDsgJm5ic3A7cmVzb3VyY2UuJnF1b3Q7PEJSPiZndDs8QlI+Jmd0OyBo b3cgdG8gaW50ZXJwcmVldCBhbiBNUExTIGxhYmVsIHdpdGggdGhpcyBkZWZpbml0aW9uID8gb3Ig aXMgTVBMUyBvdXQgb2Y8QlI+Jmd0OyBzY29wZSA/PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0i TW9ub3NwYWNlLENvdXJpZXIiPk1QTFMgaXMgb3V0IG9mIHNjb3BlIGJlY2F1c2UgdGhlcmUgaXMg cG9zc2libGUgdHJhbnNsYXRpb24gdG8gQVNPTi48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJN b25vc3BhY2UsQ291cmllciI+Tm90ZSwgaG93ZXZlciwgd2UgZmVsdCBpdCBoZWxwZnVsIHRvIGlu Y2x1ZGUgJnF1b3Q7UGFja2V0IGJhc2VkIHJlc291cmNlJnF1b3Q7PC9GT05UPjwvUD48UD48Rk9O VCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+W2RwXSB0aGlzIGlzIGFsc28gd2hhdCBpIHVuZGVy c3Rvb2QgYnV0IGl0IHNlZW1zIHRoYXQgY2xvc2luZyB0aGUgcmluZyBvZiBkZWZpbml0aW9uIGFu ZCBpbnRlcnByZXRhdGlvbnMgaXMgaW1wb3NzaWJsZTsgaGVuY2UsIG15IHN1Z2dlc3Rpb24gZWl0 aGVyIHRvIGhhdmUgYSBjb21wbGV0ZSBkZWZpbml0aW9uIG9mIHBhY2tldC1yZWxhdGVkIGludGVy cHJldGF0aW9uIG9yIG5vIGNvdmVyYWdlIGF0IGFsbDxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9 Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7IDUuICZxdW90OzMuNS4xLiBHTVBMUyBUZXJtczxCUj4m Z3Q7PEJSPiZndDsgJm5ic3A7ICZuYnNwO1VuaWRpcmVjdGlvbmFsIGRhdGEgbGluayBlbmQgW0Rh dGEgUGxhbmVdIGlzIGEgc2V0IG9mIHJlc291cmNlcyBvZiBhPEJSPiZndDsgJm5ic3A7ICZuYnNw O3BhcnRpY3VsYXIgbGF5ZXIgdGhhdCBiZWxvbmcgdG8gdGhlIHNhbWUgdHJhbnNwb3J0IG5vZGUg YW5kIGNvdWxkPEJSPiZndDsgJm5ic3A7ICZuYnNwO2JlIGFsbG9jYXRlZCBmb3IgdGhlIHRyYW5z ZmVyIG9mIHRyYWZmaWMgaW4gdGhpcyBsYXllciB0byB0aGUgc2FtZTxCUj4mZ3Q7ICZuYnNwOyAm bmJzcDtuZWlnaGJvciBpbiB0aGUgc2FtZSBkaXJlY3Rpb24uJnF1b3Q7PEJSPiZndDs8QlI+Jmd0 OyB3aGF0ICZxdW90O3NhbWUgdHJhbnNwb3J0IG5vZGUmcXVvdDsgbWVhbnMgaGVyZSA/PEJSPjwv Rk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkVybT88QlI+PC9GT05UPjxC Uj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SXQgbWVhbnMgJnF1b3Q7c2FtZSB0cmFu c3BvcnQgbm9kZSZxdW90OyA6LSk8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2Us Q291cmllciI+VGhlIGludGVudGlvbiBpcyB0byBpbXBseSB0aGF0IGFsbCBvZiB0aGUgcmVzb3Vy Y2VzIGluIHRoZSBzZXQgYmVsb25nIHRvPEJSPnRoZSBzYW1lIHRyYW5zcG9ydCBub2RlLjxCUj48 L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5NYXliZSByZXBocmFzZSBh czo8QlI+PC9GT05UPjwvUD48VUw+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlVuaWRp cmVjdGlvbmFsIGRhdGEgbGluayBlbmQgW0RhdGEgUGxhbmVdIGlzIGEgc2V0IG9mIHJlc291cmNl cyB0aGF0PEJSPmFsbCBiZWxvbmcgdG8gdGhlIHNhbWUgdHJhbnNwb3J0IG5vZGUsIGFsbCBhcmUg aW4gdGhlIHNhbWUgbGF5ZXIsPEJSPmFuZCB0aGF0IGNvdWxkIGJlIGFsbG9jYXRlZCBmb3IgdGhl IHRyYW5zZmVyIG9mIHRyYWZmaWMgaW4gdGhpczxCUj5sYXllciB0byB0aGUgc2FtZSBuZWlnaGJv ciBpbiB0aGUgc2FtZSBkaXJlY3Rpb24uJnF1b3Q7PC9GT05UPjxCUj48L1VMPjxVTD4mbmJzcDs8 L1VMPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5bZHBdIG9rIChndWVzcyB5b3Ug d2lsbCBhbGlnbiBzdWJzZXF1ZW50IHRleHQgYWxvbmcgdGhlIHNhbWUgbGluZSk8L0ZPTlQ+PC9Q PjxQPiZuYnNwOzwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OyA2LiAm cXVvdDsgVGhlIG5lZWQgZm9yIGFkdmVydGlzZW1lbnQgb2YgYWRhcHRhdGlvbiBhbmQgdGVybWlu YXRpb248QlI+Y2FwYWJpbGl0aWVzPEJSPiZndDsgJm5ic3A7ICZuYnNwO3dpdGhpbiBHTVBMUyBo YXMgYmVlbiByZWNvZ25pemVkIGFuZCB3b3JrIGlzIGluIHByb2dyZXNzIHRvIGRldGVybWluZTxC Uj4mZ3Q7ICZuYnNwOyAmbmJzcDtob3cgdGhlc2Ugd2lsbCBiZSBhZHZlcnRpc2VkLiBJdCBpcyBs aWtlbHkgdGhhdCB0aGV5IHdpbGwgYmU8QlI+Jmd0OyAmbmJzcDsgJm5ic3A7YWR2ZXJ0aXNlZCBh cyBhIHNpbmdsZSBjb21iaW5lZCBhdHRyaWJ1dGUsIG9yIGFzIHNlcGFyYXRlIGF0dHJpYnV0ZXM8 QlI+Jmd0OyAmbmJzcDsgJm5ic3A7b2YgdGhlIFRFIGxpbmsgbG9jYWwgZW5kIGFzc29jaWF0ZWQg d2l0aCB0aGUgbGluayBpbnRlcmZhY2UuJnF1b3Q7PEJSPiZndDs8QlI+Jmd0OyBhZmFpaywgR01Q TFMgaXMgYWJsZSB0byBhZHZlcnRpemUgJnF1b3Q7dGVybWluYXRpb24mcXVvdDsgY2FwYWJpbGl0 aWVzIC08QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+RG9lcyBp dD88L0ZPTlQ+PC9QPjxQPiZuYnNwOzwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmll ciI+W2RwXSB5ZXMgYnV0IGltcGxpY2l0bHkgd2hlbiB5b3UgaGF2ZSBhIFtMU0MsUFNDXSBURSBs aW5rLCBtZWFuaW5nIG9uZSBzaWRlIHNheXMgaW4gaXRzIGludGVyZmFjZSBTQyBkZXNjcmlwdG9y IFRMViBQU0MgYW5kIHRoZSBvdGhlciBMU0MsIGl0IGltcGxpY2l0bHkgbWVhbnMgdGhlICZxdW90 O1BTQyBzaWRlJnF1b3Q7IHRlcm1pbmF0ZXMgTFNDIGFuZCBzd2l0Y2hlcyBhdCB0aGUgUFNDIGxl dmVsIDwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPjxCUj5JdCBz ZWVtcyB0byBtZSB0aGF0IGl0IGFkdmVydGl6ZXMgc3dpdGNoaW5nIGNhcGFiaWxpdGllcyBvbmx5 LjxCUj5UZXJtaW5hdGlvbiwgbGlrZSBhZGFwdGF0aW9uLCBpcyBub3QgdGhlIHNhbWUgdGhpbmcg YXMgc3dpdGNoaW5nPEJSPmNhcGFiaWxpdHkuPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9u b3NwYWNlLENvdXJpZXIiPlN3aXRjaGluZyBjYXBhYmlsaXR5IHNheXMgaG93IHRoZSBsaW5rIHRl cm1pbmF0ZXMsIGJ1dCBub3Qgd2hldGhlciB0aGU8QlI+bm9kZSBjYW4gdGVybWluYXRlIGRhdGEg Zmxvd3MuPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkNoZWVy cyw8QlI+QWRyaWFuPEJSPjwvRk9OVD48QlI+PEJSPjxCUj48QlI+PC9QPg== Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Dec 2005 23:55:19 +0000 Message-ID: <010701c6029c$5078de10$99849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Kireeti Kompella" , "Dimitri Papadimitriou" Cc: Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd) Date: Fri, 16 Dec 2005 23:55:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Dimitri, Thanks for reading. > 1. i still don't understand the need for the [ ... ] after each term - if > authors could clarify this would be helpful Hmm. Well the intention was to provide extra information in a quick way. I guess we could replace each [...] with a full sentence such as "This term applies to the control plane." I suppose that the RFC editor is going to object to our use of square brackets :-( > 2. in general, i don't see why this document meant to clarify GMPLS terms > for ASON includes ASON specific terms/definitions and interpretations hence > the need for each "ASON terms" sub-section is unclear The intention is not just to clarify the GMPLS terms, but also to provide a mapping. The full purpose (of making GMPLS comprehensible to ASON cognoscenti) is aided by the inclusion of corresponding ASON terms. What we have done, therefore, is split the text into: - a description of the GMPLS term - a translation into "equivalent" ASON terms Do you have an objection to this? > some other specifics > > 3. " Node [Control & Data Planes] is a logical combination of a > transport node and the controller that manages the transport node. > In early deployments, all control plane and data plane functions > associated with a transport node were collocated in a node and > referred to as a Label Switching Router (LSR)." > > the second sentence is imho outside the scope of such definition Some of the GMPLS RFCs are simplified by the use of "LSR", but it has been pointed out on numerous occasions that this creates an impression that in GMPLS there is *always* a tight binding (collocation) between control and data plane functions. As you know, this impression is contrary to reality. A couple of questions back to you. Is what it says incorrect? Would it help if we had a separate entry for LSR? > 4. "3.4.1. GMPLS Terms > > Label [Control Plane] is an abstraction that provides an identifier > for use in the control plane in order to identify a transport plane > resource." > > how to interpreet an MPLS label with this definition ? or is MPLS out of > scope ? MPLS is out of scope because there is possible translation to ASON. Note, however, we felt it helpful to include "Packet based resource" > 5. "3.5.1. GMPLS Terms > > Unidirectional data link end [Data Plane] is a set of resources of a > particular layer that belong to the same transport node and could > be allocated for the transfer of traffic in this layer to the same > neighbor in the same direction." > > what "same transport node" means here ? Erm? It means "same transport node" :-) The intention is to imply that all of the resources in the set belong to the same transport node. Maybe rephrase as: Unidirectional data link end [Data Plane] is a set of resources that all belong to the same transport node, all are in the same layer, and that could be allocated for the transfer of traffic in this layer to the same neighbor in the same direction." > 6. " The need for advertisement of adaptation and termination capabilities > within GMPLS has been recognized and work is in progress to determine > how these will be advertised. It is likely that they will be > advertised as a single combined attribute, or as separate attributes > of the TE link local end associated with the link interface." > > afaik, GMPLS is able to advertize "termination" capabilities - Does it? It seems to me that it advertizes switching capabilities only. Termination, like adaptation, is not the same thing as switching capability. Switching capability says how the link terminates, but not whether the node can terminate data flows. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Dec 2005 20:51:30 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-12.txt Message-Id: Date: Thu, 15 Dec 2005 15:50:02 -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 Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base Author(s) : T. Nadeau, et al. Filename : draft-ietf-ccamp-gmpls-te-mib-12.txt Pages : 61 Date : 2005-12-15 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-12.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-te-mib-12.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-te-mib-12.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-12-15150632.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-15150632.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Dec 2005 19:02:52 +0000 To: Kireeti Kompella Cc: ccamp@ops.ietf.org From: Dimitri.Papadimitriou@alcatel.be Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd) MIME-Version: 1.0 Date: Thu, 15 Dec 2005 20:01:34 +0100 Message-ID: Content-type: text/plain; charset=us-ascii hi all 1. i still don't understand the need for the [ ... ] after each term - if authors could clarify this would be helpful 2. in general, i don't see why this document meant to clarify GMPLS terms for ASON includes ASON specific terms/definitions and interpretations hence the need for each "ASON terms" sub-section is unclear some other specifics 3. " Node [Control & Data Planes] is a logical combination of a transport node and the controller that manages the transport node. In early deployments, all control plane and data plane functions associated with a transport node were collocated in a node and referred to as a Label Switching Router (LSR)." the second sentence is imho outside the scope of such definition 4. "3.4.1. GMPLS Terms Label [Control Plane] is an abstraction that provides an identifier for use in the control plane in order to identify a transport plane resource." how to interpreet an MPLS label with this definition ? or is MPLS out of scope ? 5. "3.5.1. GMPLS Terms Unidirectional data link end [Data Plane] is a set of resources of a particular layer that belong to the same transport node and could be allocated for the transfer of traffic in this layer to the same neighbor in the same direction." what "same transport node" means here ? 6. " The need for advertisement of adaptation and termination capabilities within GMPLS has been recognized and work is in progress to determine how these will be advertised. It is likely that they will be advertised as a single combined attribute, or as separate attributes of the TE link local end associated with the link interface." afaik, GMPLS is able to advertize "termination" capabilities - thanks, - dimitri. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Dec 2005 17:54:05 +0000 Date: Thu, 15 Dec 2005 09:52:43 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt (fwd) Message-ID: <20051215094432.J44886@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi All, This begins a two week (+ 1 day) WG Last Call for this document. As Adrian said: | During your review, I would like you to pay particularly good | attention to the text that describes GMPLS concepts. This text is | not intended to be definitive, but it will be read by many people as | providing clarification, so it needs to be right. The Last Call ends 5pm PST on Fri Dec 30. Get it done early so you can enjoy your New Year bash :-) Kireeti. ------- ---------- Forwarded message ---------- Date: Wed, 14 Dec 2005 18:50:01 -0500 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : 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-05.txt Pages : 17 Date : 2005-12-14 Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-05.txt Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Dec 2005 14:02:44 +0000 Message-ID: <0d8701c60180$6f811510$9d849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Igor Bryskin" Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt Date: Thu, 15 Dec 2005 14:04:11 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, The 04 revision recently published reflected updates from our liaison exchange with the ITU-T. We believe that all points are now closed down and that document is complete. This 05 revision corrects a typo that Kohei spotted (thanks). I will ask Kireeti to run a last call, since I'm an editor. During your review, I would like you to pay particularly good attention to the text that describes GMPLS concepts. This text is not intended to be definitive, but it will be read by many people as providing clarification, so it needs to be right. Thanks, Adrian > 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-05.txt > Pages : 17 > Date : 2005-12-14 > > Generalized Multiprotocol Label Switching (GMPLS) has been developed > by the IETF to facilitate the establishment of Label Switched Paths > (LSPs) in a variety of data plane technologies and across several > architectural models. The ITU-T has specified an architecture for > the control of Automatically Switched Optical Networks (ASON). > > This document provides a lexicography for the interpretation of GMPLS > terminology within the context of the ASON architecture. > > It is important to note that GMPLS is applicable in a wider set of > contexts than just ASON. The definitions presented in this document > do not provide exclusive or complete interpretations of GMPLS > concepts. This document simply allows the GMPLS terms to be applied > within the ASON context. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-05.txt Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Dec 2005 10:13:01 +0000 Message-ID: <1134641509.43a14165b9dbd@gold.itu.ch> Date: Thu, 15 Dec 2005 11:11:49 +0100 From: ruiquan.jing@ties.itu.int To: ccamp@ops.ietf.org Subject: RE: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 Hi all, Please see inline. Best regards Ruiquan Jing China¡¡Telecom Beijing Research¡¡Institute ----- Original Message ----- From: Diego Caviglia To: ccamp@ops.ietf.org Cc: Dino Bramanti ; Dan Li Date: Wed, 14 Dec 2005 18:50:01 -0500 Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt Reply-To: internet-drafts@ietf.org --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-05.txt Pages : 17 Date : 2005-12-14 Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-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-ason-lexicography-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-ason-lexicography-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-12-14155633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-lexicography-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-14155633.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Dec 2005 23:51:48 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-05.txt Message-Id: Date: Wed, 14 Dec 2005 18:50:01 -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-05.txt Pages : 17 Date : 2005-12-14 Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-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-ason-lexicography-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-ason-lexicography-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-12-14155633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-lexicography-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-14155633.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Dec 2005 18:33:35 +0000 Message-ID: <0c7001c600dd$5bd620d0$9d849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Christian Hopps" , "Dave Ward" Subject: Cross-WG review requested Date: Wed, 14 Dec 2005 18:36:31 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi IS-IS Working Group, CCAMP has just accepted two I-Ds that may be of interest to you. Routing extensions for discovery of Traffic Engineering Node Capabilities http://www.ietf.org/internet-drafts/draft-ietf-ccamp-te-node-cap-00.txt This I-D specifies OSPF and IS-IS traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. This I-D makes use of draft-ietf-isis-caps by defining a new TLV to be included in the ISIS Capability TLV. Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-00.txt This document specifies OSPF and IS-IS traffic engineering extensions so as to provide an automatic discovery of the set of LSRs members of a mesh, leading to an automatic mechanism to set up TE LSP mesh(es) (also referred to as a mesh-group). This I-D makes use of draft-ietf-isis-caps by defining a new TLV to be included in the ISIS Capability TLV. We would appreciate your feedback, ideally on the CCAMP mailing list, but alternatively to the WG chairs or to the authors direct. (We will also be consulting the OSPF mailing list). Since this work is relatively mature, we will be progressing the documents to WG last call in the New Year, after suitable editorial refinement. Many thanks, Adrian per pro CCAMP Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Dec 2005 18:32:19 +0000 Message-ID: <0c6d01c600dd$04761de0$9d849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Acee Lindem" , Subject: Cross-WG review requested Date: Wed, 14 Dec 2005 18:31:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi OSPF Working Group, CCAMP has just accepted two I-Ds that may be of interest to you. Routing extensions for discovery of Traffic Engineering Node Capabilities http://www.ietf.org/internet-drafts/draft-ietf-ccamp-te-node-cap-00.txt This I-D specifies OSPF and IS-IS traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. This I-D makes use of draft-ietf-ospf-cap by defining a new TLV to be included in the Router Information LSA. Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-00.txt This document specifies OSPF and IS-IS traffic engineering extensions so as to provide an automatic discovery of the set of LSRs members of a mesh, leading to an automatic mechanism to set up TE LSP mesh(es) (also referred to as a mesh-group). This I-D makes use of draft-ietf-ospf-cap by defining a new TLV to be included in the Router Information LSA. We would appreciate your feedback, ideally on the CCAMP mailing list, but alternatively to the WG chairs or to the authors direct. (We will also be consulting the IS-IS mailing list). Since this work is relatively mature, we will be progressing the documents to WG last call in the New Year, after suitable editorial refinement. Many thanks, Adrian per pro CCAMP Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Dec 2005 10:41:25 +0000 Date: Wed, 14 Dec 2005 18:30:25 +0800 From: Dan Li Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus To: Dimitri.Papadimitriou@alcatel.be, Adrian Farrel Cc: ccamp , Diego Caviglia Message-id: <016101c60099$657599c0$d04c460a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT See my comments in line. Thanks! - Dan ----- Original Message ----- From: To: "Adrian Farrel" Cc: "ccamp" ; "Diego Caviglia" Sent: Thursday, December 08, 2005 6:29 PM Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > > hi adrian, diego, all > > the scope of the mechanism should have been limited to create a control > plane state when the corr. data plane resources have already been > provisioned for the same connection by local config., MP, MPLS (for PSC > LSP), whatever ... all the specifics in terms of migration from MP to CP > and vice-versa are NOT to be standardized and falls outside the scope of > the GMPLS protocol work per se; on the other side, if we need to initiate a > work item on the migration to GMPLS *CONTROL PLANE* and come out with some > operational guidelines, i strongly recommended to link this work with the > item already started on this specific topic Partially agreed. MP2CP ownership handover is not only the requirement of carriers' migration to ASON, it also can be used to handle the various failures of control plane. During the recent discussion, if the control states of control plane can not be recovered, what should we do? According to the principle "the transport plane should not be touched when there is a failure in the control plane", all the connections should be kept, this actually means CP2MP ownership handover, the MP will take over the control of these connections. Obviously, after the control plane is recovered, the MP2CP ownership handover may also be needed. I think the procedure of MP2CP ownership handover belongs to control plane recovery process which is casued by some failures in the control plane, the only different is who triggers the control plane states recovery. For MP2CP ownership handover, this procedure is triggered by management plane. The process at the Ingress node maybe is a little bit different, but the process at all the following nodes should be same, so we can unify (via Recovery Label object) the processes of MP2CP ownership handover and control plane recovery. In another words, MP2CP ownership handover is the control plane recovery which is triggered by management plane. Compared with the current Recovery procedure, MP2CP ownership handover includes looking up the cross-connection table in the transport plane, this is also compatible with the current recovery procedure. CP2MP ownership handover is also similar to the control plane Graceful Shutdown. After the MP takes over the control of all the connections which previously are controlled by CP, the control plane can be gracefully shutdown. > > note: each time we include a bit in the ADMIN_STATUS object that refers to > an operation which is not limited to a control plane related operation we > should not "standardize" that behaviour; reason is because jumping in the > bandwagon of standardizing usability and applications of the GMPLS control > plane mechanism has as many profiles as users (we have had the same > discussion during the p&r discussion loop); in the present case, we would > be in a situation where we would be std'ing the usability of a CP mechanism > assuming a that a) the MP <-> CP interaction is known (and hence also > std'ized ?) but in a case where the following config is to considered we > would also need to make assumptions about MP_1 <-> MP_2 > > MP_1 ---- MP_2 > | | > CP_1 ---- CP_2 > > > --- > > > > Hi Diego, > > Thanks for taking some of the burden of WG chair from my shoulders. > > Before pushing this any further, I would be interested in your response to > the recent liaison from ITU-T SG15 (text below). > > I would also like to understand whether this type of function is really > likely to be used repeatedly or whether we are describing a "one shot" > solution to an in-service upgrade. > > Cheers, > Adrian > === > Text of liaison from SG15 > > At the recent Q12/15 and Q14/15 Rapporteur meeting, it was reported that > CCAMP is discussing the issue of migration of connections under the > management plane to the control plane. This topic has been discussed in > previous SG15 meetings and some of the conclusions are offered that may be > helpful to CCAMP. > The motivation for migrating calls and connections includes applying a > control plane to an existing transport network, and/or combining a > transport network whose connections are managed by an OSS and one whose > connections are established by a control plane. > Two broad issues with connection migration are dual views of a resource, > and the preconditions before protocol state is created for a connection. > Dual views of a resource concerns the need for a resource to be in both > management and control plane view the same time. This is because although > the control plane may have responsibility of allocating/releasing > connections in subnetworks (a node is a smallest subnetwork), the > management plane still has responsibility for other functions on the > resource. Changing the responsibility of allocating/releasing connections > requires more state for actions like rolling back a migration action due > to failures. > Preconditions for migrating from the management plane to control plane are > extensive and may involve much planning because the context for the > control plane has to be in place. This includes: > - Naming of resources. Both node and link naming are required before > signalling protocols can run. Without this, no explicit route can be > formed to match the resources of the connection. Naming of multiple nodes > and links has to be planned ahead of time. > - Control plane component adjacencies must be established. In GMPLS the > control adjacencies are separate from bearer adjacencies and do not have > to coincide. Planning and establishing those adjacencies is needed before > migration can be initiated. > - Links must be pre-configured and made visible to control plane routing. > - For each service and the associated connections to be migrated, the > service name, connection names, and explicit resource lists (in the > control plane name space) need to be passed from the management plane to > the control plane. > Once this is done, connection state in the control plane can be created > for an existing connection and the resources placed under the view of the > control plane. Taken together, the preparation for migrating even one > connection suggests that a whole set of the transport resources be > prepared at the same time. > Finally, when connection state is being created to match an existing > connection, the connection controllers (signalling entities) should not > require awareness of why this is happening as the context could be > migration or other operation. A mechanism to create control state without > affecting transport plane state is needed in the connection controllers. > It is important to ensure that the connections are not deleted when the > management plane relinquishes control of the resources. Entities that > initiate the connection (Call controllers) do need migration awareness as > they need to obtain/derive service (call) identification from the > management plane. This is because the identity of connections created by > management planes are typically stored in OSS inventory systems, as well > as the identity of the service to which the connection is associated with. > The general conclusion is that the preparation for, and operational > impacts of, connection migration are much larger and more complex than the > actual control plane procedures to create signalling state for an existing > connection. These procedures will only be invoked once in the life time of > the network. For these reasons, Q12/15 and Q14/15 have decided not to > pursue a solution to this problem. > > > ----- Original Message ----- > From: "Diego Caviglia" > To: "ccamp" > Sent: Tuesday, December 06, 2005 11:34 AM > Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > > > > > Folks, > > a week has passed from the below e-mail, there has been only one > > replay from a carrier the answers were for yes for both question 2 and > 3. > > > > Now I'll try to put the question in a different way. > > > > Do anyone think that the ID should not be moved to WG status? > > > > Regards > > > > Diego > > > > > > > > > > > > "Diego Caviglia" @ops.ietf.org on 29/11/2005 > > 08.08.59 > > > > Sent by: owner-ccamp@ops.ietf.org > > > > > > To: ccamp@ops.ietf.org > > cc: "Dino Bramanti" , "Dan Li > > > Subject: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > > > > > Hi all, > > during the last IETF meeting unfortunaltely there was not > enough > > thime to present and discuss the ID in the subject, nevertheless I think > > (but I'm an authour) the ID satisfy a real request from the Carries > > community. > > > > I'd like to ask you some questions > > > > 1. Are there any comments on the ID? > > > > 2. Mainly for the carriers. Do you think the ID describes an > useful > > tool? > > > > 3. Should the ID moved to the WG status? > > > > Of course my answer for 2 and 3 are Yes and Yes ;-) > > > > Regards > > > > Diego > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Dec 2005 06:59:21 +0000 Message-ID: <439DD341.7030107@chello.nl> Date: Mon, 12 Dec 2005 20:45:05 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: Richard Rabbat CC: ccamp@ops.ietf.org, Diego Caviglia , Greg Bernstein Subject: Re: next steps on diverse path vcat/lcas Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Richard, You wrote: > during ietf in vancouver, we had a good discussion related to > draft-bernstein-ccamp-gmpls-vcat-lcas-01.txt > There were many people interested in collaborating on this work item. > Can these interested people drop us a line if they want to collaborate > on a revision to the draft or give feedback on the current version? > we'd like to have some consensus on what extra features are needed and > work on the solutions Because you already mentioned my contributions to the draft I would like to continue providing feedback. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 Dec 2005 20:11:50 +0000 Message-Id: <200512122008.jBCK8K022676@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4257 on Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 12 Dec 2005 12:08:19 -0800 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4257 Title: Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks Author(s): G. Bernstein, E. Mannie, V. Sharma, E. Gray Status: Informational Date: December 2005 Mailbox: gregb@grotto-networking.com, eric.mannie@perceval.net, v.sharma@ieee.org, Eric.Gray@Marconi.com Pages: 35 Characters: 86974 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-sdhsonet-control-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4257.txt Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051212120700.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4257 --OtherAccess Content-Type: Message/External-body; name="rfc4257.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051212120700.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Dec 2005 23:52:52 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-04.txt Message-Id: Date: Fri, 09 Dec 2005 18:50:01 -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-04.txt Pages : 17 Date : 2005-12-9 Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. It is important to note that GMPLS is applicable in a wider contexts than ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply to allows the GMPLS terms to be applied within the ASON context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-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-ason-lexicography-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-ason-lexicography-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-12-9161905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ason-lexicography-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-9161905.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Dec 2005 10:31:23 +0000 To: "Adrian Farrel" Cc: "ccamp" , "Diego Caviglia" From: Dimitri.Papadimitriou@alcatel.be Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus MIME-Version: 1.0 Date: Thu, 8 Dec 2005 11:29:30 +0100 Message-ID: Content-type: text/plain; charset=us-ascii hi adrian, diego, all the scope of the mechanism should have been limited to create a control plane state when the corr. data plane resources have already been provisioned for the same connection by local config., MP, MPLS (for PSC LSP), whatever ... all the specifics in terms of migration from MP to CP and vice-versa are NOT to be standardized and falls outside the scope of the GMPLS protocol work per se; on the other side, if we need to initiate a work item on the migration to GMPLS *CONTROL PLANE* and come out with some operational guidelines, i strongly recommended to link this work with the item already started on this specific topic note: each time we include a bit in the ADMIN_STATUS object that refers to an operation which is not limited to a control plane related operation we should not "standardize" that behaviour; reason is because jumping in the bandwagon of standardizing usability and applications of the GMPLS control plane mechanism has as many profiles as users (we have had the same discussion during the p&r discussion loop); in the present case, we would be in a situation where we would be std'ing the usability of a CP mechanism assuming a that a) the MP <-> CP interaction is known (and hence also std'ized ?) but in a case where the following config is to considered we would also need to make assumptions about MP_1 <-> MP_2 MP_1 ---- MP_2 | | CP_1 ---- CP_2 --- Hi Diego, Thanks for taking some of the burden of WG chair from my shoulders. Before pushing this any further, I would be interested in your response to the recent liaison from ITU-T SG15 (text below). I would also like to understand whether this type of function is really likely to be used repeatedly or whether we are describing a "one shot" solution to an in-service upgrade. Cheers, Adrian === Text of liaison from SG15 At the recent Q12/15 and Q14/15 Rapporteur meeting, it was reported that CCAMP is discussing the issue of migration of connections under the management plane to the control plane. This topic has been discussed in previous SG15 meetings and some of the conclusions are offered that may be helpful to CCAMP. The motivation for migrating calls and connections includes applying a control plane to an existing transport network, and/or combining a transport network whose connections are managed by an OSS and one whose connections are established by a control plane. Two broad issues with connection migration are dual views of a resource, and the preconditions before protocol state is created for a connection. Dual views of a resource concerns the need for a resource to be in both management and control plane view the same time. This is because although the control plane may have responsibility of allocating/releasing connections in subnetworks (a node is a smallest subnetwork), the management plane still has responsibility for other functions on the resource. Changing the responsibility of allocating/releasing connections requires more state for actions like rolling back a migration action due to failures. Preconditions for migrating from the management plane to control plane are extensive and may involve much planning because the context for the control plane has to be in place. This includes: - Naming of resources. Both node and link naming are required before signalling protocols can run. Without this, no explicit route can be formed to match the resources of the connection. Naming of multiple nodes and links has to be planned ahead of time. - Control plane component adjacencies must be established. In GMPLS the control adjacencies are separate from bearer adjacencies and do not have to coincide. Planning and establishing those adjacencies is needed before migration can be initiated. - Links must be pre-configured and made visible to control plane routing. - For each service and the associated connections to be migrated, the service name, connection names, and explicit resource lists (in the control plane name space) need to be passed from the management plane to the control plane. Once this is done, connection state in the control plane can be created for an existing connection and the resources placed under the view of the control plane. Taken together, the preparation for migrating even one connection suggests that a whole set of the transport resources be prepared at the same time. Finally, when connection state is being created to match an existing connection, the connection controllers (signalling entities) should not require awareness of why this is happening as the context could be migration or other operation. A mechanism to create control state without affecting transport plane state is needed in the connection controllers. It is important to ensure that the connections are not deleted when the management plane relinquishes control of the resources. Entities that initiate the connection (Call controllers) do need migration awareness as they need to obtain/derive service (call) identification from the management plane. This is because the identity of connections created by management planes are typically stored in OSS inventory systems, as well as the identity of the service to which the connection is associated with. The general conclusion is that the preparation for, and operational impacts of, connection migration are much larger and more complex than the actual control plane procedures to create signalling state for an existing connection. These procedures will only be invoked once in the life time of the network. For these reasons, Q12/15 and Q14/15 have decided not to pursue a solution to this problem. ----- Original Message ----- From: "Diego Caviglia" To: "ccamp" Sent: Tuesday, December 06, 2005 11:34 AM Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > Folks, > a week has passed from the below e-mail, there has been only one > replay from a carrier the answers were for yes for both question 2 and 3. > > Now I'll try to put the question in a different way. > > Do anyone think that the ID should not be moved to WG status? > > Regards > > Diego > > > > > > "Diego Caviglia" @ops.ietf.org on 29/11/2005 > 08.08.59 > > Sent by: owner-ccamp@ops.ietf.org > > > To: ccamp@ops.ietf.org > cc: "Dino Bramanti" , "Dan Li > Subject: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > > Hi all, > during the last IETF meeting unfortunaltely there was not enough > thime to present and discuss the ID in the subject, nevertheless I think > (but I'm an authour) the ID satisfy a real request from the Carries > community. > > I'd like to ask you some questions > > 1. Are there any comments on the ID? > > 2. Mainly for the carriers. Do you think the ID describes an useful > tool? > > 3. Should the ID moved to the WG status? > > Of course my answer for 2 and 3 are Yes and Yes ;-) > > Regards > > Diego > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 Dec 2005 22:37:55 +0000 Message-ID: <01c401c5fb7f$3344ea60$9d849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Incoming liaisons from the ITU-T Date: Wed, 7 Dec 2005 22:37:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, There were four liaison statements sent to CCAMP by the recent meeting of Questions 12 and 14 of Study Group 15 of the ITU-T. These can be seen at http://www.olddog.co.uk/incoming.htm or through the IETF's liaison tracker pages. The subjects were: - Control plane resilience - Connection migration - ASON-related work - ASON lexicography The last two require a response from us by 27th January. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 Dec 2005 20:54:46 +0000 Message-ID: <016001c5fb70$bcd48380$9d849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Dimitri Papadimitriou" Cc: Subject: RFC 3946 bis Date: Wed, 7 Dec 2005 20:46:52 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Dimitri, Since there has been no further comment on the list about this work, could you: - tidy up the draft (i.e. remove the editorial notes) - update the "Note 3." text as we discussed - re-submit Once that is done, we will last call and move on. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 Dec 2005 14:14:21 +0000 Date: Wed, 07 Dec 2005 22:05:56 +0800 From: lidan 37133 Subject: =?gb2312?B?u9i4tA==?=:Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus To: Adrian Farrel Cc: ccamp , Diego Caviglia Message-id: <168507e1688215.1688215168507e@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline Hi Adrian=2C Please see my comments below=2E Regards=2C Dan Li ----- =D4=AD=D3=CA=BC=FE ----- =B4=D3=3A Adrian Farrel =3Cadrian=40olddog=2Eco=2Euk=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =CA=AE=B6=FE=D4=C2 6=C8=D5=2C 2005 = =CF=C2=CE=E78=3A40 =D6=F7=CC=E2=3A Re=3A Consensus to move draft-caviglia-mp2cpcp2mp-03 to W= G satus =3E Hi Diego=2C =3E = =3E Thanks for taking some of the burden of WG chair from my shoulders=2E= =3E = =3E Before pushing this any further=2C I would be interested in your = =3E response to =3E the recent liaison from ITU-T SG15 (text below)=2E =3E = =3E I would also like to understand whether this type of function is = =3E reallylikely to be used repeatedly or whether we are describing a = =3E =22one shot=22 =3E solution to an in-service upgrade=2E MP2CP and CP2MP migration can be used for many scenarios=2C some cases ar= e given = here=3A 1) For control plane upgrade=2C after introduced the control plane=2C the= services = can be migrated from MP to CP=2E 2) For some reason=2C only partial functions of CP are used by the operat= ors=2C = like resource discovery=2C but services still provided by MP=2E Later the= y want = such services be migrated from MP to CP=2C and MP to CP is also needed ju= st in = case they want to roll back=2E 3) This feature also can be used for CP graceful shutdown=2E 4) For some serious CP failure cases=2C when CP session can not be recove= red in time=2C the connections under control of CP can be migrated to MP=2C s= o the service will not be interrupted=2E 5) More cases are welcome=2E=2E=2E So this is not one time use feature for the carriers=2E =3E = =3E Cheers=2C =3E Adrian =3E =3D=3D=3D =3E Text of liaison from SG15 =3E = =3E At the recent Q12/15 and Q14/15 Rapporteur meeting=2C it was = =3E reported that =3E CCAMP is discussing the issue of migration of connections under the =3E management plane to the control plane=2E This topic has been = =3E discussed in =3E previous SG15 meetings and some of the conclusions are offered = =3E that may be =3E helpful to CCAMP=2E =3E The motivation for migrating calls and connections includes = =3E applying a =3E control plane to an existing transport network=2C and/or combining a =3E transport network whose connections are managed by an OSS and one = =3E whoseconnections are established by a control plane=2E =3E Two broad issues with connection migration are dual views of a = =3E resource=2Cand the preconditions before protocol state is created = =3E for a connection=2E =3E Dual views of a resource concerns the need for a resource to be in = =3E bothmanagement and control plane view the same time=2E This is = =3E because although =3E the control plane may have responsibility of allocating/releasing =3E connections in subnetworks (a node is a smallest subnetwork)=2C the =3E management plane still has responsibility for other functions on the Dual views of resources is not the problem at all=2E When a resource is under the control of CP=2C the MP should still have the visibility of the= = resource=2C because CP is connection focused and *NOT* for all the functi= ons=2C = so MP should response for =22other functions=22 on the resource=2E If the= = resources under control of CP have dual visibility under both CP and MP=2C= = the resources under control of MP should also have dual visibility=2E =3E resource=2E Changing the responsibility of allocating/releasing = =3E connectionsrequires more state for actions like rolling back a = =3E migration action due to failures=2E This is the issue of concurrent access to resources under the control of both CP and MP=2C and it can be deal with some resource access locking scheme=2E But it is a implementation-related issue=2C so it=27s out of sc= ope of this I-D=2E =3E Preconditions for migrating from the management plane to control = =3E plane are =3E extensive and may involve much planning because the context for the =3E control plane has to be in place=2E This includes=3A =3E - Naming of resources=2E Both node and link naming are required befo= re =3E signalling protocols can run=2E Without this=2C no explicit route ca= n be =3E formed to match the resources of the connection=2E Naming of = =3E multiple nodes =3E and links has to be planned ahead of time=2E =3E - Control plane component adjacencies must be established=2E In = =3E GMPLS the =3E control adjacencies are separate from bearer adjacencies and do = =3E not have =3E to coincide=2E Planning and establishing those adjacencies is = =3E needed before =3E migration can be initiated=2E =3E - Links must be pre-configured and made visible to control plane = =3E routing=2E These preconditions assume the resource is either controlled by control plane or by management plane=2E But this is not true=2C as we mentioned b= efore=2C even the resource is under the control of control plane=2C the management= plane still has responsibility for many functions on the resource=2E So t= hese preconditions also can be applied to the resource which under the control= of management plane=2E The current GMPLS can support the resource discovery (naming of resource)= =2C the discovered resource also includes which under the control of MP=2E It=27s doesn=27t matter which plane use it=2EPlanning and establishing th= ose adjacencies are control plane bootstrap problem=2C so it=27s out of scope= of this I-D=2E =3E - For each service and the associated connections to be = =3E migrated=2C the =3E service name=2C connection names=2C and explicit resource lists (in t= he =3E control plane name space) need to be passed from the management = =3E plane to =3E the control plane=2E This already addressed in this I-D=2E =3E Once this is done=2C connection state in the control plane can be = =3E createdfor an existing connection and the resources placed under = =3E the view of the =3E control plane=2E Taken together=2C the preparation for migrating eve= n one =3E connection suggests that a whole set of the transport resources be =3E prepared at the same time=2E This already addressed in this I-D=2E =3E Finally=2C when connection state is being created to match an existin= g =3E connection=2C the connection controllers (signalling entities) = =3E should not =3E require awareness of why this is happening as the context could be =3E migration or other operation=2E A mechanism to create control state = No=2E The connection controllers should aware of this=2C because this action is directed by the management plane=2C it=27s different with other= operations like connection creation=2E =3E without affecting transport plane state is needed in the connection = =3E controllers=2EIt is important to ensure that the connections are not = =3E deleted when the =3E management plane relinquishes control of the resources=2E Entities th= at The transport plane should not be touched=2E Please see I-D for details=2E= =3E initiate the connection (Call controllers) do need migration = =3E awareness as =3E they need to obtain/derive service (call) identification from the =3E management plane=2E This is because the identity of connections = =3E created by =3E management planes are typically stored in OSS inventory systems=2C = =3E as well =3E as the identity of the service to which the connection is = =3E associated with=2E This should be done within the management plane before the migration action be taken=2E So it=27s also out of scope of this I-D=2E =3E The general conclusion is that the preparation for=2C and operational= =3E impacts of=2C connection migration are much larger and more complex = =3E than the =3E actual control plane procedures to create signalling state for an = =3E existingconnection=2E These procedures will only be invoked once in = =3E the life time of These problems actually are the issues of ASON architecture=2C not for GM= PLS=2E It is the time for these issues to be fixed in the ASON architecture=2E =3E the network=2E For these reasons=2C Q12/15 and Q14/15 have decided no= t to =3E pursue a solution to this problem=2E =3E = =3E = =3E ----- Original Message ----- = =3E From=3A =22Diego Caviglia=22 =3CDiego=2ECaviglia=40marconi=2Ecom=3E =3E To=3A =22ccamp=22 =3Cccamp=40ops=2Eietf=2Eorg=3E =3E Sent=3A Tuesday=2C December 06=2C 2005 11=3A34 AM =3E Subject=3A Re=3A Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG= = =3E satus =3E = =3E =3E =3E =3E Folks=2C =3E =3E a week has passed from the below e-mail=2C there has been = =3E only one =3E =3E replay from a carrier the answers were for yes for both question = =3E 2 and =3E 3=2E =3E =3E =3E =3E Now I=27ll try to put the question in a different way=2E =3E =3E =3E =3E Do anyone think that the ID should not be moved to WG status=3F =3E =3E =3E =3E Regards =3E =3E =3E =3E Diego =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =22Diego Caviglia=22 =3CDiego=2ECaviglia=40marconi=2Ecom=3E=40ops= =2Eietf=2Eorg on = =3E 29/11/2005=3E 08=2E08=2E59 =3E =3E =3E =3E Sent by=3A owner-ccamp=40ops=2Eietf=2Eorg =3E =3E =3E =3E =3E =3E To=3A ccamp=40ops=2Eietf=2Eorg =3E =3E cc=3A =22Dino Bramanti=22 =3CDino=2EBramanti=40marconi=2Ecom=3E= =2C =22Dan Li =3Cdanli=22 =3E =3E =3E =3E Subject=3A Consensus to move draft-caviglia-mp2cpcp2mp-03 to W= G = =3E satus=3E =3E =3E =3E =3E Hi all=2C =3E =3E during the last IETF meeting unfortunaltely there was = not =3E enough =3E =3E thime to present and discuss the ID in the subject=2C nevertheles= s = =3E I think =3E =3E (but I=27m an authour) the ID satisfy a real request from the Car= ries =3E =3E community=2E =3E =3E =3E =3E I=27d like to ask you some questions =3E =3E =3E =3E 1=2E Are there any comments on the ID=3F =3E =3E =3E =3E 2=2E Mainly for the carriers=2E Do you think the ID descri= bes an =3E useful =3E =3E tool=3F =3E =3E =3E =3E 3=2E Should the ID moved to the WG status=3F =3E =3E =3E =3E Of course my answer for 2 and 3 are Yes and Yes =3B-) =3E =3E =3E =3E Regards =3E =3E =3E =3E Diego =3E =3E Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Dec 2005 13:32:26 +0000 Sensitivity: Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus To: "Adrian Farrel" Cc: ccamp@ops.ietf.org Message-ID: From: "Diego Caviglia" Date: Tue, 6 Dec 2005 14:32:30 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Adrian, please find response/comments in line. Regards Diego "Adrian Farrel" @ops.ietf.org on 06/12/2005 13.40.34 Please respond to "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org To: "ccamp" , "Diego Caviglia" cc: Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus Hi Diego, Thanks for taking some of the burden of WG chair from my shoulders. [dc] Ouch touched ;-) I apologize if I gave the impression of playing your role, I was just trying to understand if there is interest in this ID or not. Before pushing this any further, I would be interested in your response to the recent liaison from ITU-T SG15 (text below). [dc] Ok I'll give an answer. I would also like to understand whether this type of function is really likely to be used repeatedly or whether we are describing a "one shot" solution to an in-service upgrade. [dc] This is a question that can be answered by Telco. My feeling is that it will be for sure used during the upgrade. Cheers, Adrian === Text of liaison from SG15 At the recent Q12/15 and Q14/15 Rapporteur meeting, it was reported that CCAMP is discussing the issue of migration of connections under the management plane to the control plane. This topic has been discussed in previous SG15 meetings and some of the conclusions are offered that may be helpful to CCAMP. The motivation for migrating calls and connections includes applying a control plane to an existing transport network, and/or combining a transport network whose connections are managed by an OSS and one whose connections are established by a control plane. [dc] Agreed. Two broad issues with connection migration are dual views of a resource, and the preconditions before protocol state is created for a connection. Dual views of a resource concerns the need for a resource to be in both management and control plane view the same time. This is because although the control plane may have responsibility of allocating/releasing connections in subnetworks (a node is a smallest subnetwork), the management plane still has responsibility for other functions on the resource. Changing the responsibility of allocating/releasing connections requires more state for actions like rolling back a migration action due to failures. Preconditions for migrating from the management plane to control plane are extensive and may involve much planning because the context for the control plane has to be in place. This includes: - Naming of resources. Both node and link naming are required before signalling protocols can run. Without this, no explicit route can be formed to match the resources of the connection. Naming of multiple nodes and links has to be planned ahead of time. [dc] Agreed. - Control plane component adjacencies must be established. In GMPLS the control adjacencies are separate from bearer adjacencies and do not have to coincide. Planning and establishing those adjacencies is needed before migration can be initiated. [dc] Agreed. - Links must be pre-configured and made visible to control plane routing. [dc] Agreed. - For each service and the associated connections to be migrated, the service name, connection names, and explicit resource lists (in the control plane name space) need to be passed from the management plane to the control plane. [dc] Agreed. Once this is done, connection state in the control plane can be created for an existing connection and the resources placed under the view of the control plane. Taken together, the preparation for migrating even one connection suggests that a whole set of the transport resources be prepared at the same time. [dc] Of course before migrate an LSP the control plane on the involved resourse needs to be up and running. Finally, when connection state is being created to match an existing connection, the connection controllers (signalling entities) should not require awareness of why this is happening as the context could be migration or other operation. [dc] The only thing that the SC needs to know is that the data plane is alredy configured, of course in case of failure of the signalling date plane resources are not deleted. A mechanism to create control state without affecting transport plane state is needed in the connection controllers. [dc] This is exatly, at least in our intention, what the ID proposes. It is important to ensure that the connections are not deleted when the management plane relinquishes control of the resources. [dc] Agreed Entities that initiate the connection (Call controllers) do need migration awareness as they need to obtain/derive service (call) identification from the management plane. [dc] Agreed, moreover also the intermediate TNEs do need migration awarness, in the ID this is done using an Admin Status flag. This is because the identity of connections created by management planes are typically stored in OSS inventory systems, as well as the identity of the service to which the connection is associated with. [dc] Yes usually it is like this. The general conclusion is that the preparation for, and operational impacts of, connection migration are much larger and more complex than the actual control plane procedures to create signalling state for an existing connection. [dc] Is that meaning that the CP impact is very low? If yes I agree on this and I'm also happy on this. Actually I don't see any significative difference between the impact of adding a control plane to an existing network and migrate the already created circuit under the CP domain. These procedures will only be invoked once in the life time of the network. For these reasons, Q12/15 and Q14/15 have decided not to pursue a solution to this problem. [dc] This may be is correct but that once in the life is when the CP is added to an alredy existing network. So may be is only once in the life but is during a very important and critic moment. ----- Original Message ----- From: "Diego Caviglia" To: "ccamp" Sent: Tuesday, December 06, 2005 11:34 AM Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > Folks, > a week has passed from the below e-mail, there has been only one > replay from a carrier the answers were for yes for both question 2 and 3. > > Now I'll try to put the question in a different way. > > Do anyone think that the ID should not be moved to WG status? > > Regards > > Diego > > > > > > "Diego Caviglia" @ops.ietf.org on 29/11/2005 > 08.08.59 > > Sent by: owner-ccamp@ops.ietf.org > > > To: ccamp@ops.ietf.org > cc: "Dino Bramanti" , "Dan Li > Subject: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > > Hi all, > during the last IETF meeting unfortunaltely there was not enough > thime to present and discuss the ID in the subject, nevertheless I think > (but I'm an authour) the ID satisfy a real request from the Carries > community. > > I'd like to ask you some questions > > 1. Are there any comments on the ID? > > 2. Mainly for the carriers. Do you think the ID describes an useful > tool? > > 3. Should the ID moved to the WG status? > > Of course my answer for 2 and 3 are Yes and Yes ;-) > > Regards > > Diego > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Dec 2005 13:20:36 +0000 Message-ID: <43958FD5.7040601@pi.se> Date: Tue, 06 Dec 2005 14:19:17 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) MIME-Version: 1.0 To: Diego Caviglia CC: ccamp Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Diego, why did this consensus call not come from the wg chairs. I'm afraid that under the current circumstances you need to interpret non-responsiveness as non-interest. /Loa Diego Caviglia wrote: > Folks, > a week has passed from the below e-mail, there has been only one > replay from a carrier the answers were for yes for both question 2 and 3. > > Now I'll try to put the question in a different way. > > Do anyone think that the ID should not be moved to WG status? > > Regards > > Diego > > > > > > "Diego Caviglia" @ops.ietf.org on 29/11/2005 > 08.08.59 > > Sent by: owner-ccamp@ops.ietf.org > > > To: ccamp@ops.ietf.org > cc: "Dino Bramanti" , "Dan Li > Subject: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > > Hi all, > during the last IETF meeting unfortunaltely there was not enough > thime to present and discuss the ID in the subject, nevertheless I think > (but I'm an authour) the ID satisfy a real request from the Carries > community. > > I'd like to ask you some questions > > 1. Are there any comments on the ID? > > 2. Mainly for the carriers. Do you think the ID describes an useful > tool? > > 3. Should the ID moved to the WG status? > > Of course my answer for 2 and 3 are Yes and Yes ;-) > > Regards > > Diego > > > > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Dec 2005 12:39:31 +0000 Message-ID: <09e201c5fa62$7d025110$d9849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "ccamp" , "Diego Caviglia" Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus Date: Tue, 6 Dec 2005 12:40:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Diego, Thanks for taking some of the burden of WG chair from my shoulders. Before pushing this any further, I would be interested in your response to the recent liaison from ITU-T SG15 (text below). I would also like to understand whether this type of function is really likely to be used repeatedly or whether we are describing a "one shot" solution to an in-service upgrade. Cheers, Adrian === Text of liaison from SG15 At the recent Q12/15 and Q14/15 Rapporteur meeting, it was reported that CCAMP is discussing the issue of migration of connections under the management plane to the control plane. This topic has been discussed in previous SG15 meetings and some of the conclusions are offered that may be helpful to CCAMP. The motivation for migrating calls and connections includes applying a control plane to an existing transport network, and/or combining a transport network whose connections are managed by an OSS and one whose connections are established by a control plane. Two broad issues with connection migration are dual views of a resource, and the preconditions before protocol state is created for a connection. Dual views of a resource concerns the need for a resource to be in both management and control plane view the same time. This is because although the control plane may have responsibility of allocating/releasing connections in subnetworks (a node is a smallest subnetwork), the management plane still has responsibility for other functions on the resource. Changing the responsibility of allocating/releasing connections requires more state for actions like rolling back a migration action due to failures. Preconditions for migrating from the management plane to control plane are extensive and may involve much planning because the context for the control plane has to be in place. This includes: - Naming of resources. Both node and link naming are required before signalling protocols can run. Without this, no explicit route can be formed to match the resources of the connection. Naming of multiple nodes and links has to be planned ahead of time. - Control plane component adjacencies must be established. In GMPLS the control adjacencies are separate from bearer adjacencies and do not have to coincide. Planning and establishing those adjacencies is needed before migration can be initiated. - Links must be pre-configured and made visible to control plane routing. - For each service and the associated connections to be migrated, the service name, connection names, and explicit resource lists (in the control plane name space) need to be passed from the management plane to the control plane. Once this is done, connection state in the control plane can be created for an existing connection and the resources placed under the view of the control plane. Taken together, the preparation for migrating even one connection suggests that a whole set of the transport resources be prepared at the same time. Finally, when connection state is being created to match an existing connection, the connection controllers (signalling entities) should not require awareness of why this is happening as the context could be migration or other operation. A mechanism to create control state without affecting transport plane state is needed in the connection controllers. It is important to ensure that the connections are not deleted when the management plane relinquishes control of the resources. Entities that initiate the connection (Call controllers) do need migration awareness as they need to obtain/derive service (call) identification from the management plane. This is because the identity of connections created by management planes are typically stored in OSS inventory systems, as well as the identity of the service to which the connection is associated with. The general conclusion is that the preparation for, and operational impacts of, connection migration are much larger and more complex than the actual control plane procedures to create signalling state for an existing connection. These procedures will only be invoked once in the life time of the network. For these reasons, Q12/15 and Q14/15 have decided not to pursue a solution to this problem. ----- Original Message ----- From: "Diego Caviglia" To: "ccamp" Sent: Tuesday, December 06, 2005 11:34 AM Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > Folks, > a week has passed from the below e-mail, there has been only one > replay from a carrier the answers were for yes for both question 2 and 3. > > Now I'll try to put the question in a different way. > > Do anyone think that the ID should not be moved to WG status? > > Regards > > Diego > > > > > > "Diego Caviglia" @ops.ietf.org on 29/11/2005 > 08.08.59 > > Sent by: owner-ccamp@ops.ietf.org > > > To: ccamp@ops.ietf.org > cc: "Dino Bramanti" , "Dan Li > Subject: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus > > > Hi all, > during the last IETF meeting unfortunaltely there was not enough > thime to present and discuss the ID in the subject, nevertheless I think > (but I'm an authour) the ID satisfy a real request from the Carries > community. > > I'd like to ask you some questions > > 1. Are there any comments on the ID? > > 2. Mainly for the carriers. Do you think the ID describes an useful > tool? > > 3. Should the ID moved to the WG status? > > Of course my answer for 2 and 3 are Yes and Yes ;-) > > Regards > > Diego > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Dec 2005 11:36:43 +0000 Sensitivity: Subject: Re: Consensus to move draft-caviglia-mp2cpcp2mp-03 to WG satus To: "ccamp" Message-ID: From: "Diego Caviglia" Date: Tue, 6 Dec 2005 12:34:47 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Folks, a week has passed from the below e-mail, there has been only one replay from a carrier the answers were for yes for both question 2 and 3. Now I'll try to put the question in a different way. Do anyone think that the ID should not be moved to WG status? Regards Diego "Diego Caviglia" @ops.ietf.org on 29/11/2005 08.08.59 Sent by: owner-ccamp@ops.ietf.org To: ccamp@ops.ietf.org cc: "Dino Bramanti" , "Dan Li