Subject: Get 15% off these watches!

From: "Lynette Nunez" <[email-masked]>
Date: Wed, 30 Apr 2008 16:37:58 -0500

Longines watches have been around for longer than you or I are old. And they have
adorned the wrists of the rich and famous for the same length of time. Prestige Replicas
plans to change that, by offering you a replica watch that is exactly the same in every
detail, except for the price. 
http://nidozibywic52.blogspot.com/

Prestige Replicas now offers a 15% discount on the purchase of two items because of the
site redesign, and this offer won't last. Neither will their new 2008 models! Having the
most expensive Longines watches at the best prices, and ensuring the most expedite
shipping on the web make this online shop the best choice. 

No need to wear that old Timex to that upcoming event, when Prestige Replicas can put
you into a Longines replica for about the same cost in no time!
http://nidozibywic52.blogspot.com/

Delivery-date: Wed, 30 Apr 2008 10:23:15 +0000
Content-class: urn:content-classes:message
Subject: RE: Poll for WG Adoption of Two WSON documents
Date: Wed, 30 Apr 2008 11:20:09 +0100
From: "Daniel King" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8AAAB.E9FF33DF
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello CCAMP,=20

=20

I would like to show my support for both drafts.

=20

I should also disclose that I am a contributor to
"draft-bernstein-ccamp-wavelength-switched-03.txt".

=20

Thanks,
Dan

=20

From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: 29 April 2008 16:39
To: [email-masked]
Subject: Poll for WG Adoption of Two WSON documents

=20

CCAMP,

=20

>From Philadelphia, we had good support for adoption of two of the WSON
documents as CCAMP working group documents:

=20

- Framework for WSON

http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi
tched-03.txt

=20

- Lambda Labels

http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label
s-02.txt

=20

Please express your opinions (authors, we welcome your opinion also).

=20

Thanks,

Adrian and Deborah

------_=_NextPart_001_01C8AAAB.E9FF33DF
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-GB link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hello CCAMP, <o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I would like to show my support for both =
drafts.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I should also disclose that I am a contributor to =
&#8220;draft-bernstein-ccamp-wavelength-switched-03.txt&#8221;.<o:p></o:p=
></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thanks,<br>
Dan<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>BRUNGARD, DEBORAH =
A,
ATTLABS<br>
<b>Sent:</b> 29 April 2008 16:39<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> Poll for WG Adoption of Two WSON =
documents<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>CCAMP,</span>=
<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>From
Philadelphia, we had good support for adoption of two of the WSON =
documents as
CCAMP working group documents:</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>-
Framework for WSON</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><a
href=3D"http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelen=
gth-switched-03.txt">http://www.ietf.org/internet-drafts/draft-bernstein-=
ccamp-wavelength-switched-03.txt</a></span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>-
Lambda Labels</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><a
href=3D"http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambd=
a-labels-02.txt">http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm=
pls-lambda-labels-02.txt</a></span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Please
express your opinions (authors, we welcome your opinion =
also).</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Thanks,</span=
><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Adrian
and Deborah</span><o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C8AAAB.E9FF33DF--

Delivery-date: Wed, 30 Apr 2008 08:16:31 +0000
Date: Wed, 30 Apr 2008 17:14:56 +0900
From: Tomohiro Otani <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Cc: [email-masked]
Subject: Re: Poll for WG Adoption of Two WSON documents

Hi all,

I support both as CCAMP WG documents.

Regards,

Tomo

BRUNGARD, DEBORAH A, ATTLABS =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=
=E3=81=BE=E3=81=97=E3=81=9F:
> CCAMP,
> From Philadelphia, we had good support for adoption of two of the WSON=20
> documents as CCAMP working group documents:
> - Framework for WSON
> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-sw=
itched-03.txt
> - Lambda Labels
> http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labe=
ls-02.txt
> Please express your opinions (authors, we welcome your opinion also).
> Thanks,
> Adrian and Deborah

Delivery-date: Wed, 30 Apr 2008 07:37:42 +0000
Date: Wed, 30 Apr 2008 09:36:10 +0200
From: Gino Carrozzo <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
CC:  [email-masked]
Subject: Re: Poll for WG Adoption of Two WSON documents

Support for both

br
Gino

BRUNGARD, DEBORAH A, ATTLABS wrote:
> CCAMP,
>  
>>From Philadelphia, we had good support for adoption of two of the WSON
> documents as CCAMP working group documents:
>  
> - Framework for WSON
> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi
> tched-03.txt
>  
> - Lambda Labels
> http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label
> s-02.txt
>  
> Please express your opinions (authors, we welcome your opinion also).
>  
> Thanks,
> Adrian and Deborah
> 

Delivery-date: Wed, 30 Apr 2008 07:26:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Poll for WG Adoption of Two WSON documents
Date: Wed, 30 Apr 2008 09:23:51 +0200
From: "Howard Green" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8AA93.24161D8C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I support the adoption of both these drafts
Howard

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: 29 April 2008 17:39
To: [email-masked]
Subject: Poll for WG Adoption of Two WSON documents

CCAMP,
=20
>From Philadelphia, we had good support for adoption of two of the WSON
documents as CCAMP working group documents:
=20
- Framework for WSON
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi
tched-03.txt
=20
- Lambda Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label
s-02.txt
=20
Please express your opinions (authors, we welcome your opinion also).
=20
Thanks,
Adrian and Deborah

------_=_NextPart_001_01C8AA93.24161D8C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16640" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D410052307-30042008>I support the adoption of&nbsp;both these=20
drafts</SPAN></FONT></DIV><SPAN class=3D410052307-30042008></SPAN><FONT=20
face=3DArial><FONT color=3D#0000ff><FONT size=3D2>Howard<SPAN=20
class=3D410052307-30042008></SPAN></FONT></FONT></FONT><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>BRUNGARD, DEBORAH =
A,=20
ATTLABS<BR><B>Sent:</B> 29 April 2008 17:39<BR><B>To:</B>=20
[email-masked]<BR><B>Subject:</B> Poll for WG Adoption of Two WSON=20
documents<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008>CCAMP,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>From =
Philadelphia,=20
we had good support for adoption of two of the WSON documents as CCAMP =
working=20
group documents:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>- =
Framework for=20
WSON</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelen=
gth-switched-03.txt">http://www.ietf.org/internet-drafts/draft-bernstein-=
ccamp-wavelength-switched-03.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>- =
Lambda=20
Labels</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambd=
a-labels-02.txt">http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm=
pls-lambda-labels-02.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>Please =
express your=20
opinions (authors, we welcome your opinion also).</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>Adrian =
and=20
Deborah</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C8AA93.24161D8C--

Delivery-date: Wed, 30 Apr 2008 04:15:01 +0000
Date: Wed, 30 Apr 2008 13:12:18 +0900
From: Sugang XU <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Cc: [email-masked]
Subject: Re: Poll for WG Adoption of Two WSON documents

Hi Adrian and Deborah,

I support both for WG docs.

Best Regards

Sugang

BRUNGARD, DEBORAH A, ATTLABS wrote:
> CCAMP,
>  
>>From Philadelphia, we had good support for adoption of two of the WSON
> documents as CCAMP working group documents:
>  
> - Framework for WSON
> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi
> tched-03.txt
>  
> - Lambda Labels
> http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label
> s-02.txt
>  
> Please express your opinions (authors, we welcome your opinion also).
>  
> Thanks,
> Adrian and Deborah
> 

Delivery-date: Wed, 30 Apr 2008 02:44:35 +0000
Date: Wed, 30 Apr 2008 11:43:10 +0900
From: "Ogaki, Kenichi" <[email-masked]>
To: [email-masked]
Subject: Re: Poll for WG Adoption of Two WSON documents

Hi All,

I support both.

Regards,
Kenichi

BRUNGARD, DEBORAH A, ATTLABS wrote:

>CCAMP,
> 
>>From Philadelphia, we had good support for adoption of two of the WSON
>documents as CCAMP working group documents:
> 
>- Framework for WSON
>http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi
>tched-03.txt
> 
>- Lambda Labels
>http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label
>s-02.txt
> 
>Please express your opinions (authors, we welcome your opinion also).
> 
>Thanks,
>Adrian and Deborah
>
>  
>

Delivery-date: Wed, 30 Apr 2008 01:48:42 +0000
Date: Wed, 30 Apr 2008 09:46:55 +0800
From: Mach Chen <[email-masked]>
Subject: Re: Poll for WG Adoption of Two WSON documents
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, "[email-masked]" <[email-masked]>
Organization: Huawei

Hi,

In favor of both I-Ds.

On 2008-04-29, at 23:56:05 BRUNGARD, DEBORAH A, ATTLABS wrote:

>CCAMP,
> 
>From Philadelphia, we had good support for adoption of two of the WSON
>documents as CCAMP working group documents:
> 
>- Framework for WSON
>http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi
>tched-03.txt
> 
>- Lambda Labels
>http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label
>s-02.txt
> 
>Please express your opinions (authors, we welcome your opinion also).
> 
>Thanks,
>Adrian and Deborah

Best regards,			
Mach Chen

Delivery-date: Wed, 30 Apr 2008 01:01:24 +0000
Date: Wed, 30 Apr 2008 08:59:55 +0800
From: Dan Li <[email-masked]>
Subject: Re: Poll for WG Adoption of Two WSON documents
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_3XHeaD2Jyd+cm/wXucZ5LQ)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Yes, I support both IDs.

Dan

  ----- Original Message ----- 
  From: BRUNGARD, DEBORAH A, ATTLABS 
  To: [email-masked] 
  Sent: Tuesday, April 29, 2008 11:38 PM
  Subject: Poll for WG Adoption of Two WSON documents

  CCAMP,

  From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents:

  - Framework for WSON
  http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt

  - Lambda Labels
  http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt

  Please express your opinions (authors, we welcome your opinion also).

  Thanks,
  Adrian and Deborah

--Boundary_(ID_3XHeaD2Jyd+cm/wXucZ5LQ)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1561" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>Yes, I support both IDs.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Dan</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 9pt &#23435;&#20307;">----- Original Message ----- </DIV>
  <DIV style="BACKGROUND: #e4e4e4; FONT: 9pt &#23435;&#20307;; font-color: black"><B>From:</B> 
  <A title=[email-masked] href="mailto:[email-masked]">BRUNGARD, DEBORAH 
  A, ATTLABS</A> </DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>To:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>Sent:</B> Tuesday, April 29, 2008 11:38 PM</DIV>
  <DIV style="FONT: 9pt &#23435;&#20307;"><B>Subject:</B> Poll for WG Adoption of Two WSON 
  documents</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=Arial size=2><SPAN 
  class=147522615-29042008>CCAMP,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN 
  class=147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2><SPAN class=147522615-29042008>From Philadelphia, 
  we had good support for adoption of two of the WSON documents as CCAMP working 
  group documents:</SPAN></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN 
  class=147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2><SPAN class=147522615-29042008>- Framework for 
  WSON</SPAN></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN class=147522615-29042008><A 
  href="http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt">http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt</A></SPAN></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN 
  class=147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2><SPAN class=147522615-29042008>- Lambda 
  Labels</SPAN></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN class=147522615-29042008><A 
  href="http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt">http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt</A></SPAN></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN 
  class=147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2><SPAN class=147522615-29042008>Please express 
  your opinions (authors, we welcome your opinion also).</SPAN></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN 
  class=147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2><SPAN 
  class=147522615-29042008>Thanks,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial size=2><SPAN class=147522615-29042008>Adrian and 
  Deborah</SPAN></FONT></DIV></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_3XHeaD2Jyd+cm/wXucZ5LQ)--

Delivery-date: Wed, 30 Apr 2008 00:16:20 +0000
Date: Wed, 30 Apr 2008 09:16:43 +0900
To: <[email-masked]>
From: Wataru Imajuku <[email-masked]>
Subject: Re: Poll for WG Adoption of Two WSON documents

Hi, Deborah and Adrian

 Both IDs are very much important and should be WG documents.

Best Regards
Wataru

At 00:38 08/04/30, BRUNGARD, DEBORAH A, ATTLABS wrote:
>CCAMP,
> 
>From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents:
> 
>- Framework for WSON
><http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt>http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt
> 
>- Lambda Labels
><http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt>http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt
> 
>Please express your opinions (authors, we welcome your opinion also).
> 
>Thanks,
>Adrian and Deborah

-------------------------------------
Wataru Imajuku@NTT Network Innovation Labs
TEL: +81-46-859-4315
FAX: +81-46-859-5541

Delivery-date: Tue, 29 Apr 2008 19:20:57 +0000
From: Jonas Martensson <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 29 Apr 2008 21:16:50 +0200
Subject: RE: Poll for WG Adoption of Two WSON documents
Accept-Language: en-US
acceptlanguage: en-US

I support both documents.

Regards,
Jonas

From: [email-masked] [[email-masked]] On Behalf Of BRUN=
GARD, DEBORAH A, ATTLABS [[email-masked]]
Sent: Tuesday, April 29, 2008 5:38 PM
To: [email-masked]
Subject: Poll for WG Adoption of Two WSON documents

CCAMP,

>From Philadelphia, we had good support for adoption of two of the WSON docu=
ments as CCAMP working group documents:

- Framework for WSON
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switch=
ed-03.txt

- Lambda Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-0=
2.txt

Please express your opinions (authors, we welcome your opinion also).

Thanks,
Adrian and Deborah

Delivery-date: Tue, 29 Apr 2008 18:13:16 +0000
Content-class: urn:content-classes:message
Subject: RE: Poll for WG Adoption of Two WSON documents
Date: Tue, 29 Apr 2008 13:11:07 -0500
From: "Bardalai, Snigdho" <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8AA24.657A4588
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In favor of both IDs
=20
Snigdho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On =
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, April 29, 2008 10:39 AM
To: [email-masked]
Subject: Poll for WG Adoption of Two WSON documents

CCAMP,
=20
>From Philadelphia, we had good support for adoption of two of the WSON =
documents as CCAMP working group documents:
=20
- Framework for WSON
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swit=
ched-03.txt
=20
- Lambda Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels=
-02.txt
=20
Please express your opinions (authors, we welcome your opinion also).
=20
Thanks,
Adrian and Deborah

------_=_NextPart_001_01C8AA24.657A4588
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D382201018-29042008><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
favor of both IDs</FONT></SPAN></DIV>
<DIV><SPAN class=3D382201018-29042008><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D382201018-29042008><FONT face=3DArial color=3D#0000ff =

size=3D2>Snigdho</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]]<B>On Behalf Of </B>BRUNGARD, DEBORAH =
A,=20
  ATTLABS<BR><B>Sent:</B> Tuesday, April 29, 2008 10:39 AM<BR><B>To:</B> =

  [email-masked]<BR><B>Subject:</B> Poll for WG Adoption of Two WSON =

  documents<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D147522615-29042008>CCAMP,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>From =
Philadelphia,=20
  we had good support for adoption of two of the WSON documents as CCAMP =
working=20
  group documents:</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>- =
Framework for=20
  WSON</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelen=
gth-switched-03.txt">http://www.ietf.org/internet-drafts/draft-bernstein-=
ccamp-wavelength-switched-03.txt</A></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>- =
Lambda=20
  Labels</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambd=
a-labels-02.txt">http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm=
pls-lambda-labels-02.txt</A></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D147522615-29042008>Please express=20
  your opinions (authors, we welcome your opinion =
also).</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D147522615-29042008>Thanks,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D147522615-29042008>Adrian and=20
  Deborah</SPAN></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C8AA24.657A4588--

Delivery-date: Tue, 29 Apr 2008 17:26:01 +0000
Reply-To: <[email-masked]>
From: "Itaru Nishioka" <[email-masked]>
To: "'BRUNGARD, DEBORAH A, ATTLABS'" <[email-masked]>, <[email-masked]>
Subject: RE: Poll for WG Adoption of Two WSON documents
Date: Wed, 30 Apr 2008 02:24:40 +0900
Organization: nec

This is a multi-part message in MIME format.

------=_NextPart_000_0032_01C8AA69.595DD9F0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Support both as WG drafts.

Itaru.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Wednesday, April 30, 2008 12:39 AM
To: [email-masked]
Subject: Poll for WG Adoption of Two WSON documents

CCAMP,
 
>From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents:
 
- Framework for WSON
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt
 
- Lambda Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt
 
Please express your opinions (authors, we welcome your opinion also).
 
Thanks,
Adrian and Deborah

------=_NextPart_000_0032_01C8AA69.595DD9F0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16640" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D677392317-29042008><FONT =
face=3D"&#65325;&#65331; &#65328;&#12468;&#12471;&#12483;&#12463;"=20
color=3D#0000ff size=3D2>Support both as WG drafts.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D677392317-29042008><FONT =
face=3D"&#65325;&#65331; &#65328;&#12468;&#12471;&#12483;&#12463;"=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D677392317-29042008></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D677392317-29042008><FONT =
face=3D"&#65325;&#65331; &#65328;&#12468;&#12471;&#12483;&#12463;"=20
color=3D#0000ff size=3D2>Itaru.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Dja dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>BRUNGARD, =
DEBORAH A,=20
  ATTLABS<BR><B>Sent:</B> Wednesday, April 30, 2008 12:39 =
AM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Poll for WG Adoption of Two WSON =

  documents<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D147522615-29042008>CCAMP,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>From =
Philadelphia,=20
  we had good support for adoption of two of the WSON documents as CCAMP =
working=20
  group documents:</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>- =
Framework for=20
  WSON</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelen=
gth-switched-03.txt">http://www.ietf.org/internet-drafts/draft-bernstein-=
ccamp-wavelength-switched-03.txt</A></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>- =
Lambda=20
  Labels</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambd=
a-labels-02.txt">http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm=
pls-lambda-labels-02.txt</A></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D147522615-29042008>Please express=20
  your opinions (authors, we welcome your opinion =
also).</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D147522615-29042008>Thanks,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D147522615-29042008>Adrian and=20
  Deborah</SPAN></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0032_01C8AA69.595DD9F0--

Delivery-date: Tue, 29 Apr 2008 16:56:54 +0000
Date: Tue, 29 Apr 2008 11:56:00 -0500
From: Young Lee <[email-masked]>
Subject: RE: Poll for WG Adoption of Two WSON documents
To: "'BRUNGARD, DEBORAH A, ATTLABS'" <[email-masked]>, [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_LrpXkGu+nntqEghXeWEG7w)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

I support both as WG drafts. 

Young

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, April 29, 2008 10:39 AM
To: [email-masked]
Subject: Poll for WG Adoption of Two WSON documents

CCAMP,

>From Philadelphia, we had good support for adoption of two of the WSON
documents as CCAMP working group documents:

- Framework for WSON

http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switche
d-03.txt

- Lambda Labels

http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02
.txt

Please express your opinions (authors, we welcome your opinion also).

Thanks,

Adrian and Deborah

--Boundary_(ID_LrpXkGu+nntqEghXeWEG7w)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I support both as WG drafts. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Young<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style='font-weight:bold'>On Behalf Of </span></b>BRUNGARD, DEBORAH A, ATTLABS<br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, April 29, 2008
10:39 AM<br>
<b><span style='font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> Poll for WG Adoption of
Two WSON documents</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>CCAMP,</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>From <st1:City w:st="on"><st1:place w:st="on">Philadelphia</st1:place></st1:City>,
we had good support for adoption of two of the WSON documents as CCAMP working
group documents:</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>- Framework for WSON</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><a
href="http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt">http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt</a></span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>- Lambda Labels</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><a
href="http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt">http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt</a></span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Please express your opinions (authors, we welcome your
opinion also).</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Adrian and Deborah</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

--Boundary_(ID_LrpXkGu+nntqEghXeWEG7w)--

Delivery-date: Tue, 29 Apr 2008 16:49:36 +0000
From: Anders Gavler <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 29 Apr 2008 18:47:29 +0200
Subject: RE: Poll for WG Adoption of Two WSON documents
Accept-Language: sv-SE, en-US
acceptlanguage: sv-SE, en-US

--_000_73B74934786FBB4F951B5F99724CEB6002BA8CE0CCacreoexc01ada_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Supporting both as wg documents.

/Anders

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of BRUNGARD, DEBORAH A, ATTLABS
Sent: den 29 april 2008 17:39
To: [email-masked]
Subject: Poll for WG Adoption of Two WSON documents

CCAMP,

>From Philadelphia, we had good support for adoption of two of the WSON docu=
ments as CCAMP working group documents:

- Framework for WSON
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switch=
ed-03.txt

- Lambda Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-0=
2.txt

Please express your opinions (authors, we welcome your opinion also).

Thanks,
Adrian and Deborah

--_000_73B74934786FBB4F951B5F99724CEB6002BA8CE0CCacreoexc01ada_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww=
w.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"Person=
Name"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Supporting both as =
wg
documents.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>/Anders<o:p></o:p><=
/span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

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

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>=
</font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-US style=3D'font-size:10.0pt;font-fa=
mily:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>BRUNGARD, DEBORAH A, ATT=
LABS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 29 april 2008 17:3=
9<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Poll for WG Adoptio=
n of
Two WSON documents</span></font><span lang=3DEN-US><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>CCAMP,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>From Philadelphia, we had good <st1:PersonName w:st=3D"o=
n">support</st1:PersonName>
for adoption of two of the WSON documents as CCAMP working group documents:=
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>- Framework for WSON</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><a
href=3D"http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelengt=
h-switched-03.txt">http://www.ietf.org/internet-drafts/draft-bernstein-ccam=
p-wavelength-switched-03.txt</a></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>- Lambda Labels</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><a
href=3D"http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-=
labels-02.txt">http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-=
lambda-labels-02.txt</a></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Please express your opinions (authors, we welcome your
opinion also).</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Adrian and Deborah</span></font><o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_73B74934786FBB4F951B5F99724CEB6002BA8CE0CCacreoexc01ada_--

Delivery-date: Tue, 29 Apr 2008 16:28:34 +0000
Date: Tue, 29 Apr 2008 11:26:57 -0500
From: Linda Dunbar <[email-masked]>
Subject: RE: Poll for WG Adoption of Two WSON documents
To: "'BRUNGARD, DEBORAH A, ATTLABS'" <[email-masked]>, [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_49jiLnoVjuv7myoIcxekEg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

I support both. 

Linda Dunbar

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, April 29, 2008 10:39 AM
To: [email-masked]
Subject: Poll for WG Adoption of Two WSON documents

CCAMP,

>From Philadelphia, we had good support for adoption of two of the WSON
documents as CCAMP working group documents:

- Framework for WSON

http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switche
d-03.txt

- Lambda Labels

http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02
.txt

Please express your opinions (authors, we welcome your opinion also).

Thanks,

Adrian and Deborah

--Boundary_(ID_49jiLnoVjuv7myoIcxekEg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I support both. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Linda Dunbar<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=4 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style='font-weight:bold'>On Behalf Of </span></b>BRUNGARD, DEBORAH A, ATTLABS<br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, April 29, 2008
10:39 AM<br>
<b><span style='font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> Poll for WG Adoption of
Two WSON documents</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>CCAMP,</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>From <st1:City w:st="on"><st1:place w:st="on">Philadelphia</st1:place></st1:City>,
we had good support for adoption of two of the WSON documents as CCAMP working
group documents:</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>- Framework for WSON</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><a
href="http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt">http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt</a></span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>- Lambda Labels</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><a
href="http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt">http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt</a></span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Please express your opinions (authors, we welcome your
opinion also).</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Adrian and Deborah</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

--Boundary_(ID_49jiLnoVjuv7myoIcxekEg)--

Delivery-date: Tue, 29 Apr 2008 16:23:27 +0000
Content-class: urn:content-classes:message
Subject: RE: Poll for WG Adoption of Two WSON documents
Date: Tue, 29 Apr 2008 12:22:29 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8AA15.386621E8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I support both as WG drafts.
=20
Lyndon

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, April 29, 2008 8:39 AM
To: [email-masked]
Subject: Poll for WG Adoption of Two WSON documents

CCAMP,
=20
>From Philadelphia, we had good support for adoption of two of the WSON
documents as CCAMP working group documents:
=20
- Framework for WSON
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi
tched-03.txt
=20
- Lambda Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label
s-02.txt
=20
Please express your opinions (authors, we welcome your opinion also).
=20
Thanks,
Adrian and Deborah

------_=_NextPart_001_01C8AA15.386621E8
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16640" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D611152216-29042008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I support both as WG =
drafts.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D611152216-29042008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D611152216-29042008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Lyndon</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>BRUNGARD, DEBORAH =
A,=20
ATTLABS<BR><B>Sent:</B> Tuesday, April 29, 2008 8:39 AM<BR><B>To:</B>=20
[email-masked]<BR><B>Subject:</B> Poll for WG Adoption of Two WSON=20
documents<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008>CCAMP,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>From =
Philadelphia,=20
we had good support for adoption of two of the WSON documents as CCAMP =
working=20
group documents:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>- =
Framework for=20
WSON</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelen=
gth-switched-03.txt">http://www.ietf.org/internet-drafts/draft-bernstein-=
ccamp-wavelength-switched-03.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>- =
Lambda=20
Labels</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambd=
a-labels-02.txt">http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm=
pls-lambda-labels-02.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>Please =
express your=20
opinions (authors, we welcome your opinion also).</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>Adrian =
and=20
Deborah</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C8AA15.386621E8--

Delivery-date: Tue, 29 Apr 2008 16:19:36 +0000
Date: Tue, 29 Apr 2008 09:18:32 -0700
From: Greg Bernstein <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
CC: [email-masked]
Subject: Re: Poll for WG Adoption of Two WSON documents

This is a multi-part message in MIME format.
--------------030601000304010609010808
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi WG chairs,  Very much in favor of both becoming WG documents.

Regards

Greg B.

BRUNGARD, DEBORAH A, ATTLABS wrote:
> CCAMP,
>  
> From Philadelphia, we had good support for adoption of two of the WSON 
> documents as CCAMP working group documents:
>  
> - Framework for WSON
> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt
>  
> - Lambda Labels
> http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt
>  
> Please express your opinions (authors, we welcome your opinion also).
>  
> Thanks,
> Adrian and Deborah

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

--------------030601000304010609010808
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi WG chairs,&nbsp; Very much in favor of both becoming WG documents.<br>
<br>
Regards<br>
<br>
Greg B.<br>
<br>
BRUNGARD, DEBORAH A, ATTLABS wrote:
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.3314" name="GENERATOR">
  <div><font face="Arial" size="2"><span class="147522615-29042008">CCAMP,</span></font></div>
  <div><font face="Arial" size="2"><span class="147522615-29042008"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="147522615-29042008">From
Philadelphia, we had good support for adoption of two of the WSON
documents as CCAMP working group documents:</span></font></div>
  <div><font face="Arial" size="2"><span class="147522615-29042008"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="147522615-29042008">-
Framework for WSON</span></font></div>
  <div><font face="Arial" size="2"><span class="147522615-29042008"><a
 moz-do-not-send="true"
 href="http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt">http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt</a></span></font></div>
  <div><font face="Arial" size="2"><span class="147522615-29042008"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="147522615-29042008">-
Lambda Labels</span></font></div>
  <div><font face="Arial" size="2"><span class="147522615-29042008"><a
 moz-do-not-send="true"
 href="http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt">http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt</a></span></font></div>
  <div><font face="Arial" size="2"><span class="147522615-29042008"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="147522615-29042008">Please
express your opinions (authors, we welcome your opinion also).</span></font></div>
  <div><font face="Arial" size="2"><span class="147522615-29042008"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="147522615-29042008">Thanks,</span></font></div>
  <div><font face="Arial" size="2"><span class="147522615-29042008">Adrian
and Deborah</span></font></div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

</pre>
</body>
</html>

--------------030601000304010609010808--

Delivery-date: Tue, 29 Apr 2008 16:14:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Poll for WG Adoption of Two WSON documents
Date: Tue, 29 Apr 2008 18:11:46 +0200
From: <[email-masked]>
To: <[email-masked]>

Hi Deborah.

I support both for WG docs.

Cheers,

Julien

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS

CCAMP,
=20
>From Philadelphia, we had good support for adoption of two of the WSON
documents as CCAMP working group documents:
=20
- Framework for WSON
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi
tched-03.txt
=20
- Lambda Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label
s-02.txt
=20
Please express your opinions (authors, we welcome your opinion also).
=20
Thanks,
Adrian and Deborah

Delivery-date: Tue, 29 Apr 2008 16:09:33 +0000
Content-class: urn:content-classes:message
Subject: RE: Poll for WG Adoption of Two WSON documents
Date: Tue, 29 Apr 2008 18:08:28 +0200
From: "Diego Caviglia" <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8AA13.48B57400
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Deborah,

                  Yes to all.

=20

I'm a contributor/author of both.

=20

BR

=20

Diego

=20

________________________________

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: marted=EC 29 aprile 2008 17.39
To: [email-masked]
Subject: Poll for WG Adoption of Two WSON documents

=20

CCAMP,

=20

>From Philadelphia, we had good support for adoption of two of the WSON =
documents as CCAMP working group documents:

=20

- Framework for WSON

http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swit=
ched-03.txt

=20

- Lambda Labels

http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels=
-02.txt

=20

Please express your opinions (authors, we welcome your opinion also).

=20

Thanks,

Adrian and Deborah

------_=_NextPart_001_01C8AA13.48B57400
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi =
Deborah,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 Yes to all.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I&#8217;m a contributor/author of =
both.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>BR<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Diego<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

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

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>BRUNGARD, DEBORAH A, =
ATTLABS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> marted=EC 29 aprile =
2008 17.39<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Poll for WG =
Adoption of
Two WSON documents</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>CCAMP,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>From <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Philadelphia</st1:place></st1:City>,
we had good support for adoption of two of the WSON documents as CCAMP =
working
group documents:</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>- Framework for WSON</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a
href=3D"http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelen=
gth-switched-03.txt">http://www.ietf.org/internet-drafts/draft-bernstein-=
ccamp-wavelength-switched-03.txt</a></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>- Lambda Labels</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a
href=3D"http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambd=
a-labels-02.txt">http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm=
pls-lambda-labels-02.txt</a></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Please express your opinions (authors, we welcome =
your
opinion also).</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Adrian and Deborah</span></font><o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C8AA13.48B57400--

Delivery-date: Tue, 29 Apr 2008 16:04:04 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt 
Date: Tue, 29 Apr 2008 09:00:01 -0700 (PDT)

--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           : GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
	Author(s)       : L. Berger, et al.
	Filename        : draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt
	Pages           : 14
	Date            : 2008-04-29

This document defines a method for the support of GMPLS Asymmetric
Bandwidth Bidirectional Label Switched Paths (LSPs).  The presented
approach is applicable to any switching technology and builds on the
original RSVP model for the transport of traffic related parameters.
The procedures described in this document are experimental.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Tue, 29 Apr 2008 15:55:15 +0000
Content-class: urn:content-classes:message
Subject: Poll for WG Adoption of Two WSON documents
Date: Tue, 29 Apr 2008 10:38:50 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8AA0F.1F7ABC40
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

CCAMP,
=20
>From Philadelphia, we had good support for adoption of two of the WSON
documents as CCAMP working group documents:
=20
- Framework for WSON
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi
tched-03.txt
=20
- Lambda Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label
s-02.txt
=20
Please express your opinions (authors, we welcome your opinion also).
=20
Thanks,
Adrian and Deborah

------_=_NextPart_001_01C8AA0F.1F7ABC40
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008>CCAMP,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>From =
Philadelphia,=20
we had good support for adoption of two of the WSON documents as CCAMP =
working=20
group documents:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>- =
Framework for=20
WSON</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelen=
gth-switched-03.txt">http://www.ietf.org/internet-drafts/draft-bernstein-=
ccamp-wavelength-switched-03.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>- =
Lambda=20
Labels</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambd=
a-labels-02.txt">http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm=
pls-lambda-labels-02.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>Please =
express your=20
opinions (authors, we welcome your opinion also).</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D147522615-29042008>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D147522615-29042008>Adrian =
and=20
Deborah</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C8AA0F.1F7ABC40--

Delivery-date: Mon, 28 Apr 2008 21:31:09 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Working group last calls complete
Date: Mon, 28 Apr 2008 22:27:53 +0100

Hi,

We completed the last calls on draft-ietf-ccamp-rfc4420bis-02.txt and 
draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt

As I see it, there is no need for an update to 
draft-ietf-ccamp-rfc4420bis-02.txt.

Lou has agreed the necessary changes to 
draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt so we just need to see a revised 
version and we can proceed.

As I am an author of one of these I-Ds, Deborah will do the document 
shepherding.

Cheers,
Adrian 

Delivery-date: Sun, 27 Apr 2008 12:28:09 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Thoughts on draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt
Date: Sun, 27 Apr 2008 13:24:35 +0100

Hi,

Here are some thoughts on your draft.

Cheers,
Adrian

===
Title/document name
You have the broad title "GMPLS control of Ethernet" yet the document is 
named draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt.
I think that, as per the Abstract, you are limiting yourselves to 802.1Qay, 
and that is fine.
So you should retitle the document "GMPLS Control of 802.1Qay Ethernet 
Networks" or something like that.
===
Author list
Before this goes to become an RFC you will have to reduse the front page 
listing to no more than 4 names.
I suggest that you do this by placing only the editors on the front page, 
but continuing to list all of the authors in the "Authors' Addresses" 
section.
===
Abstract
s/the standard IEEE data/the standard IEEE data plane/
===
Document History
I think you could delete this now.
Or move it to an Appendix if it is important to you.
===
Section 1
s/by a another/by another/
s/aligned with GMPLS/aligned with the GMPLS/
s/plane and the PBB-TE forwarding/plane and PBB-TE forwarding/
===
You might add a sentence or two to the Introduction explaining why GMPLS is 
relevant. Something like...

Generalized MPLS (GMPLS) [RFC3945] is a family of control plane protocols 
designed to operate in connection oriented and traffic engineering transport 
networks. GMPLS is applicable to a range of network technologies including 
Layer 2 Switching capable networks (L2SC).
===
Section 1
You have:
   Appendix A summarized the rational for this data plane
   technology until the IEEE specification is more mature.
It is your intention that Appendix A will be removed becuase 802.1Qay 
explains the facts in enough detail? I would support that. We do not need to 
redocument IEEE work.
Do you think that the work in IEEE is there yet?
===
Section 2
s/Ethernet Label switched Path/Ethernet Label Switched Path/
===
Section 2.1
ESP:
You have "between two or more CBPs" People will understand "between two 
CBPs" but may need help to understand "more".
s/Ports(CBPs)/Ports (CBPs)/
s/(MSTI)(A set/(MSTI). (A set/
s/of MSTIs)./of MSTIs.)/
s/an GMPLS/a GMPLS/
===
Section 2.1
PBB-TE Region
Not sure I like this term. RFC 3945, RFC 4206, and the MLN Requirements I-D 
have a definition of region.
Is "PBB-TE Region" an IEEE term?
Does it map to layer or domain in GMPLS?
===
Section 2.1
Point-to-Multipoint PBB-TE service instance
s/multipoint ESP/point-to-multipoint ESP/

s/leaves/branches/ ... or ...
You might prefer to say that the n P2P ESPs are co-routed but in the oposite 
direction from the source-to-leaf sub-ESPs comprising the P2MP ESP.

There is no such thing as a P2MP GMPLS bidirectional tree until you define 
one later. So this terminology at least needs a forward pointer.
===
Section 3
Please capitalise the section heading
===
Section 3
Suggest you replace "[see Appendix A]" with "see [IEEE 802.1Qay]". You could 
also retain a reference to Appendix A, but see the previous discussion.
===
Section 4.1
s/Ip_Source_Sddr/Ip_Source_Addr/

  "From a GMPLS control plane point of view
   an Ethernet LSP MAY also be identified as any other LSP"
What do you mean "MAY"? Surely this is "is".
===
Section 5.1
"This may be any switch along the path."
This may be *originated by* any switch along the path?
===
Section 5.2
s/then node/the node/
Don't you need to be able to distinguish whether it is a source or dest 
address that has caused the problem?
===
Section 5.3 and 5.4
s/discontinuities/discrepencies/   ???
I'm not sure about these error cases, and I don't find a description in the 
body of the text (did I look ahard enough?).
The error codes sounds like you are suggesting that an LSR (i.e. switch) 
that receives a Path message will check the information in the ERO against 
the informaiton in the Upstream-Label and Label-Set objects. But...
- the hop information is stipped from the ERO before the Path is sent
- we shouldn't have duplicate information in our data elements
- the LSR should not "look ahead" in the ERO in any way different from the 
process described in RFC3209.
===
Section 7
I think a good deal of work is needed on this section.
Possibly some more work is needed in 
draft-ietf-ccamp-gmpls-ethernet-arch-01.txt as well.
All you have done here is lift the text from the architecture document.
You need to consider...
- I don't find any reference in the rest of your document to UNI ports
- "Commonly known techniques" should have references
- You should reference draft-ietf-mpls-mpls-and-gmpls-security-framework
- What care should be taken to protect the trusted domain from untrusted 
access?
- What happens if legacy Ethernet control plane techniques are enabled in 
the GMPLS controlled network?
- What happens if Ethernet frames are injected into the network? It would 
appear that PBB-TE has many of the same vulnerabilities in this regard as 
Ethernet and IP. How does the network protect against this? Does GMPLS 
contribute to the protection?
- Do the error codes described in section 5 provide a way to use GMPLS to 
probe the network and discover the configuration of core nodes?
===
Manageability
With the introduction of a new technology to the GMPLS family, I think it 
would be worth your draft discussing the manageability of a GMPLS controlled 
PBB-TE network. What features do you require from GMPLS? How do you debug 
GMPLS established ESPs, and how do you debug the GMPLS control plane itself? 
Some of this may be by reference to existing or soon-to-be-created 
documents. (Notwithstanding section 4.5).
===

Delivery-date: Fri, 25 Apr 2008 18:32:20 +0000
Content-class: urn:content-classes:message
Subject: Working Group Last Call: draft-ietf-ccamp-pc-and-sc-reqs-02
Date: Fri, 25 Apr 2008 13:30:13 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8A702.6735B8E6
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

WG,
=20
To ensure you have weekend reading material (especially here in the NE
with our yet another rainy weekend), we have two more documents which we
discussed in Phila to Last Call. I'll send separate mails.
=20
And don't forget the Last Calls on draft-ietf-rfc4420bis-02.txt and
draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt will end tomorrow.
=20
This is to initiate a Working Group Last Call on:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-02.t
xt
=20
Please send your comments to the mailing list prior to EOB May 9.
=20
Adrian and Deborah

------_=_NextPart_001_01C8A702.6735B8E6
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D812010718-25042008>WG,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D812010718-25042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D812010718-25042008>To =
ensure you have=20
weekend reading material (especially here in the NE with our yet=20
another&nbsp;rainy weekend), we have two more documents which we =
discussed in=20
Phila to Last Call. I'll send separate mails.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D812010718-25042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D812010718-25042008>And =
don't forget the=20
Last Calls on <FONT size=3D2>draft-ietf-rfc4420bis-02.txt and <FONT=20
size=3D2>draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt will end=20
tomorrow.</FONT></FONT></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D812010718-25042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D812010718-25042008>This =
is to initiate=20
a Working Group Last Call on:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D812010718-25042008><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-re=
qs-02.txt">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc=
-reqs-02.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D812010718-25042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D812010718-25042008>Please =
send your=20
comments to the mailing list prior to EOB May 9.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D812010718-25042008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D812010718-25042008>Adrian =
and=20
Deborah</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C8A702.6735B8E6--

Delivery-date: Fri, 25 Apr 2008 14:03:10 +0000
Date: Fri, 25 Apr 2008 10:00:55 -0400
To: "Adrian Farrel" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Two more working group last calls
Cc: "Lou Berger" <[email-masked]>,<[email-masked]>

Adrian,

Not sure how this is an AD issue, to me it's one of 
aesthetics/style.  As this is an issue of style and personal 
preference, the choice is 100% the author's (i.e., yours).  In other 
words, please feel free to ignore my suggestion!

Lou

At 06:43 AM 4/25/2008, Adrian Farrel wrote:
>Hi Lou,
>
>I just consulted with our AD on the "correct" way of doing this. He 
>suggested...
>
>- The abstract and introduction should very clearly state that this
>  document is an update to the previous document.
>- The introduction should point to a section somewhere in the
>  document (possibly an annex) that describes the differences in
>  some detail.
>- Otherwise, the new document can stand on its own.
>
>I think that is what we currently have.
>
>Do you feel strongly about your suggested change?
>
>Cheers,
>Adrian
>----- Original Message ----- From: "Lou Berger" <[email-masked]>
>To: "Adrian Farrel" <[email-masked]>
>Cc: <[email-masked]>
>Sent: Thursday, April 17, 2008 10:23 PM
>Subject: Re: Two more working group last calls
>
>
>>Adrian,
>>         See below for minor comments:
>>
>>At 11:12 AM 4/11/2008, Adrian Farrel wrote:
>>>Hi,
>>>
>>>Sorry for the continued bombardment with reviewing activity.
>>>
>>>Here are two drafts that were discussed in Philadelphia with the 
>>>intention to go to WG last call as soon as possible.
>>>
>>>draft-ietf-rfc4420-bis-02.txt
>>
>>I assume that you mean draft-ietf-ccamp-rfc4420bis-02.txt.
>>
>>
>>>This is the revision to RFC 4420 to fix the TLV encoding to be 
>>>consistent with the previous RSVP-TE RFCs. The fix is to the 
>>>interpretation of the Length field.
>>>Although we might not expect much in the way of review comments 
>>>for this I-D, it would be very helpful if you could read the I-D, 
>>>point out any typos, and send a note to say that you have read the 
>>>document and believe it is ready for publication.
>>
>>Only a minor suggestion here:
>>
>>I suggest moving the rational for the updated provided from section 
>>14 to section 1.  Specifically:
>>
>>- drop section 14
>>- section 1, 1st paragraph: drop "See Section 14 for a summary of 
>>changes." and add:
>>    Prior to the change, the Length field indicated the length of the
>>    Value field only. After the change, as described in Section 3, the
>>    Length field indicates the length of the whole TLV. This change means
>>    that this document is consistent with the subobject format defined in
>>    [RFC3209] and the TLV format defined in [RFC3471].
>>
>>Lou
>
>
>

Delivery-date: Fri, 25 Apr 2008 10:45:34 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lou Berger" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Two more working group last calls
Date: Fri, 25 Apr 2008 11:43:24 +0100

Hi Lou,

I just consulted with our AD on the "correct" way of doing this. He 
suggested...

- The abstract and introduction should very clearly state that this
  document is an update to the previous document.
- The introduction should point to a section somewhere in the
  document (possibly an annex) that describes the differences in
  some detail.
- Otherwise, the new document can stand on its own.

I think that is what we currently have.

Do you feel strongly about your suggested change?

Cheers,
Adrian
----- Original Message ----- 
From: "Lou Berger" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 17, 2008 10:23 PM
Subject: Re: Two more working group last calls

> Adrian,
>         See below for minor comments:
>
> At 11:12 AM 4/11/2008, Adrian Farrel wrote:
>>Hi,
>>
>>Sorry for the continued bombardment with reviewing activity.
>>
>>Here are two drafts that were discussed in Philadelphia with the intention 
>>to go to WG last call as soon as possible.
>>
>>draft-ietf-rfc4420-bis-02.txt
>
> I assume that you mean draft-ietf-ccamp-rfc4420bis-02.txt.
>
>
>>This is the revision to RFC 4420 to fix the TLV encoding to be consistent 
>>with the previous RSVP-TE RFCs. The fix is to the interpretation of the 
>>Length field.
>>Although we might not expect much in the way of review comments for this 
>>I-D, it would be very helpful if you could read the I-D, point out any 
>>typos, and send a note to say that you have read the document and believe 
>>it is ready for publication.
>
> Only a minor suggestion here:
>
> I suggest moving the rational for the updated provided from section 14 to 
> section 1.  Specifically:
>
> - drop section 14
> - section 1, 1st paragraph: drop "See Section 14 for a summary of 
> changes." and add:
>    Prior to the change, the Length field indicated the length of the
>    Value field only. After the change, as described in Section 3, the
>    Length field indicates the length of the whole TLV. This change means
>    that this document is consistent with the subobject format defined in
>    [RFC3209] and the TLV format defined in [RFC3471].
>
> Lou

Delivery-date: Thu, 24 Apr 2008 20:36:38 +0000
Date: Thu, 24 Apr 2008 16:35:55 -0400
To: "Adrian Farrel" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Last call review of  draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt
Cc: "Lou Berger" <[email-masked]>,<[email-masked]>, "Attila Takacs \(IJ/ETH\)" <[email-masked]>, "Diego Caviglia \(GO/MCI\)" <[email-masked]>, "Don Fedyk" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" <[email-masked]>

Adrian,
         Please see below.

At 03:58 PM 4/24/2008, Adrian Farrel wrote:
>Hi Lou,
>
>>>===
>>>I struggled to see the utility of the Upstream_TSpec and 
>>>Upstream_Adspec objects. By the time these objects are used (on 
>>>the Resv) the reservation has already been made using the 
>>>Upstream_Flowspec (on the Path message).
>
>[SNIP]
>
>I think I found the "exactly the same" description a little strong. 
>But given our discussion (snipped) I think we are agreed on the usage.
>
>The only thing I find missing from the I-D might be expressed as...
>
>"When an egress receives an Upstream-Flowspec object, it responds 
>with an Upstream-TSpec for describe the traffic flow that it will 
>originate. When that Upstream-TSpec is received by the ingress, it 
>may determine that the original reservation is not sufficient to 
>satisfy the traffic flow. In this case it will issue a new Path 
>message with an updated Upstream-Flowspec object to mnodify the 
>resources reserved for the upstream traffic flow. This might also 
>require that the LSP is re-routed, and in extreme cases might result 
>in the LSP being torn down if sufficient resources are not available."

Added to section 2.2.1.

>>>===
>>>I believe it would be helpful to indicate in the Abstract that 
>>>this is an Experimental approach, and in the Introduction to 
>>>include a whole paragraph on why this is positioned as an Experimental RFC.
>>
>>Okay have added:
>>
>>         NOTE: THIS IS AN EXPERIMENTAL RFC.
>>
>>Let us know if you'd to see anything additional.
>
>In the abstract it would be fine to simply say:
>
>"The procedures described in this document are experimental."

done

>In the Introduction, you might say:
>
>"The usage of asymmetrical bidirectional LSPs is not well developed 
>and no products have been developed yet. In consequence, the 
>procedures described in this document are experimental."

added: "the procedures described in this document are experimental."

>>>Section 1.2
>>>You have
>>>   An alternative approach was considered and
>>>   rejected.  For reference purposes only, the rejected approach is
>>>   summarized in Appendix A.
>>>
>>>Looking ahead at Appendix A, it is hard to see that this 
>>>alternative has been rejected. In fact, it says "SHOULD NOT be 
>>>implemented". Nowhere is there a definitive reason why the 
>>>alternative has been rejected (although there are a few hints in 
>>>the introduction to the Appendix).
>>
>>well it does say:
>>     This section is included for historic purposes and SHOULD NOT
>>     be implemented.
>>
>>and
>>     In summary, the "ADSPEC Object" approach presented in this
>>     section SHOULD NOT be implemented.
>>
>>This seems pretty clear to me.  What would you like it to say?
>
>Well, I've just seen an I-D bounced by the IESG because it uses 
>"SHOULD" without explaining why you might actually do it. That is, 
>there is a claim that in 2119 language "SHOULD" implies that there 
>might be good reasons to deviate, so there needs to be text to 
>describe how the deviation is handled and why it might be introduced.
>
>Curiously, NOT RECOMMENDED would mean the same thing, but might be 
>more acceptable.

NOT RECOMMENDED it is.

>[SNIP]
>
>>I've changed the sec. 1.2. text to read "An alternative approach 
>>was considered and rejected in favor of the more generic approach 
>>presented below." and to A.1. "In particular this approach is 
>>technology specific; it uses the ADSPEC object to carry traffic 
>>parameters for upstream data and requires MEF Ethernet Traffic 
>>Parameter while the approach presented above is suitable for use 
>>with any technology."
>
>That's good.
>Thanks.
>
>>>===
>>>Section 2.1.1
>>>You suggest using "Routing problem/MPLS label allocation failure"
>>>Are you sure you do not want to be able to tell whether it was the 
>>>upstream or downstream resources that failed? Since these can be 
>>>varied independently, it would surely be useful to know which failed.
>>
>>I don't have a strong opinion one way or another.
>
>Me neither.
>We could ask the implementers :-)
>
>>>Section 2.3.1
>>>I think you need to clarify whether the Upstream_Adspec reports 
>>>the available upstream resources before or after the reservation 
>>>for the LSP in hand.
>>
>>>  Note that Adspec would apply before the reservation.
>>
>>This may be true on the initial path, but it isn't actually stated 
>>anywhere.  Furthermore, the information may include an LSPs 
>>reservation even in the case where it is not yet made.  e.g., 
>>RFC2212 talks in terms of reporting what the "flow might 
>>experience" which implies that the full Tspec is accounted for in 
>>the initial ADSPEC.
>>
>>So I think, like 2210, this should not be mentioned.
>
>OK
>
>>>===
>>>Section 4
>>>You have...
>>>   The error message
>>>   will propagate to the ingress which can then take action to avoid the
>>>   path with the incompatible node, or may simply terminate the session.
>>>I think you need a little more care with the behavior for unknown 
>>>object on a Resv since that error will propagate to the egress.
>>
>>This can only happen from a non-conformant implementation, i.e., 
>>one that passes a new object in the path but then rejects it in the resv.
>
>Or a node that has to handle a non-conformant node that generates an 
>Upstream-TSpec when it did not receive an Upstream-Flowspec.
>
>But let's leave it.

great.  Thanks for the comments!

Lou

>Thanks for the work.
>Adrian

Delivery-date: Thu, 24 Apr 2008 20:09:52 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Communication to the MEF from the IETF's CCAMP Working Group
Date: Thu, 24 Apr 2008 21:08:52 +0100

Dear Nan, Bob, and Bill,

The IETF's CCAMP working group would like to inform the MEF of work it is
carrying out to apply GMPLS protocols to the requirements of the Ethernet
UNI and Ethernet service spectrum defined by the MEF. GMPLS is a family of
IP-based protocols developed within the IETF and applicable to a range of
technologies from packet switched networks (such as MPLS), through layer 2
networks (such as ATM, Frame Relay, and Ethernet), to optical networks (like
TDM and WDM).

We would like to draw your intention to the following Internet-Drafts that
we are working on. We would welcome any feedback from your members on the
requirements, details of the solutions proposed, or applicability of our
work.

"Ethernet Traffic Parameters"
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-04.txt

"Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011
User-Network Interface (UNI)"
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-00.txt

"Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011
Ethernet Service Switching"
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-00.txt

"GMPLS Ethernet Label Switching Architecture and Framework"
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-01.txt

Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP Working Group Co-Chairs

Delivery-date: Thu, 24 Apr 2008 20:02:23 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lou Berger" <[email-masked]>
Cc: <[email-masked]>, "Attila Takacs \(IJ/ETH\)" <[email-masked]>, "Diego Caviglia \(GO/MCI\)" <[email-masked]>, "Don Fedyk" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Subject: Re: Last call review of  draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt
Date: Thu, 24 Apr 2008 20:58:57 +0100

Hi Lou,

>>===
>>I struggled to see the utility of the Upstream_TSpec and Upstream_Adspec 
>>objects. By the time these objects are used (on the Resv) the reservation 
>>has already been made using the Upstream_Flowspec (on the Path message).

[SNIP]

I think I found the "exactly the same" description a little strong. But 
given our discussion (snipped) I think we are agreed on the usage.

The only thing I find missing from the I-D might be expressed as...

"When an egress receives an Upstream-Flowspec object, it responds with an 
Upstream-TSpec for describe the traffic flow that it will originate. When 
that Upstream-TSpec is received by the ingress, it may determine that the 
original reservation is not sufficient to satisfy the traffic flow. In this 
case it will issue a new Path message with an updated Upstream-Flowspec 
object to mnodify the resources reserved for the upstream traffic flow. This 
might also require that the LSP is re-routed, and in extreme cases might 
result in the LSP being torn down if sufficient resources are not 
available."

>>===
>>I believe it would be helpful to indicate in the Abstract that this is an 
>>Experimental approach, and in the Introduction to include a whole 
>>paragraph on why this is positioned as an Experimental RFC.
>
> Okay have added:
>
>         NOTE: THIS IS AN EXPERIMENTAL RFC.
>
> Let us know if you'd to see anything additional.

In the abstract it would be fine to simply say:

"The procedures described in this document are experimental."

In the Introduction, you might say:

"The usage of asymmetrical bidirectional LSPs is not well developed and no 
products have been developed yet. In consequence, the procedures described 
in this document are experimental."

>>Section 1.2
>>You have
>>   An alternative approach was considered and
>>   rejected.  For reference purposes only, the rejected approach is
>>   summarized in Appendix A.
>>
>>Looking ahead at Appendix A, it is hard to see that this alternative has 
>>been rejected. In fact, it says "SHOULD NOT be implemented". Nowhere is 
>>there a definitive reason why the alternative has been rejected (although 
>>there are a few hints in the introduction to the Appendix).
>
> well it does say:
>     This section is included for historic purposes and SHOULD NOT
>     be implemented.
>
> and
>     In summary, the "ADSPEC Object" approach presented in this
>     section SHOULD NOT be implemented.
>
> This seems pretty clear to me.  What would you like it to say?

Well, I've just seen an I-D bounced by the IESG because it uses "SHOULD" 
without explaining why you might actually do it. That is, there is a claim 
that in 2119 language "SHOULD" implies that there might be good reasons to 
deviate, so there needs to be text to describe how the deviation is handled 
and why it might be introduced.

Curiously, NOT RECOMMENDED would mean the same thing, but might be more 
acceptable.

[SNIP]

> I've changed the sec. 1.2. text to read "An alternative approach was 
> considered and rejected in favor of the more generic approach presented 
> below." and to A.1. "In particular this approach is technology specific; 
> it uses the ADSPEC object to carry traffic parameters for upstream data 
> and requires MEF Ethernet Traffic Parameter while the approach presented 
> above is suitable for use with any technology."

That's good.
Thanks.

>>===
>>Section 2.1.1
>>You suggest using "Routing problem/MPLS label allocation failure"
>>Are you sure you do not want to be able to tell whether it was the 
>>upstream or downstream resources that failed? Since these can be varied 
>>independently, it would surely be useful to know which failed.
>
> I don't have a strong opinion one way or another.

Me neither.
We could ask the implementers :-)

>>Section 2.3.1
>>I think you need to clarify whether the Upstream_Adspec reports the 
>>available upstream resources before or after the reservation for the LSP 
>>in hand.
>
>>  Note that Adspec would apply before the reservation.
>
> This may be true on the initial path, but it isn't actually stated 
> anywhere.  Furthermore, the information may include an LSPs reservation 
> even in the case where it is not yet made.  e.g., RFC2212 talks in terms 
> of reporting what the "flow might experience" which implies that the full 
> Tspec is accounted for in the initial ADSPEC.
>
> So I think, like 2210, this should not be mentioned.

OK

>>===
>>Section 4
>>You have...
>>   The error message
>>   will propagate to the ingress which can then take action to avoid the
>>   path with the incompatible node, or may simply terminate the session.
>>I think you need a little more care with the behavior for unknown object 
>>on a Resv since that error will propagate to the egress.
>
> This can only happen from a non-conformant implementation, i.e., one that 
> passes a new object in the path but then rejects it in the resv.

Or a node that has to handle a non-conformant node that generates an 
Upstream-TSpec when it did not receive an Upstream-Flowspec.

But let's leave it.

Thanks for the work.
Adrian 

Delivery-date: Tue, 22 Apr 2008 14:56:23 +0000
Date: Tue, 22 Apr 2008 10:51:36 -0400
To: "Adrian Farrel" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Last call review of draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt
Cc: <[email-masked]>,"Lou Berger" <[email-masked]>, "Attila Takacs \(IJ/ETH\)" <[email-masked]>, "Diego Caviglia \(GO/MCI\)" <[email-masked]>, "Don Fedyk" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" <[email-masked]>

Adrian,
         Much thanks for the comments.  Please see below for in-line responses.

At 03:25 PM 4/21/2008, Adrian Farrel wrote:
>Hi,
>
>Here are some review comments about this I-D. As is bound to be the 
>case with an experiment that has not been carried out, I think there 
>are a few wrinkles to be ironed.
>
>Cheers,
>Adrian
>
>===
>I struggled to see the utility of the Upstream_TSpec and 
>Upstream_Adspec objects. By the time these objects are used (on the 
>Resv) the reservation has already been made using the 
>Upstream_Flowspec (on the Path message).

The utility here really comes from the support of PSC modes and 
preservation of RSVP/IntServ semantics.  In short we're maintaining 
the object types used in the downstream direction and instantiating 
them for the upstream direction.  To quote 2210:

    From the point of view of RSVP objects, the breakdown is as follows:

       - The RSVP SENDER_TSPEC object carries the traffic specification
       (sender TSpec) generated by each data source within an RSVP
       session.  It is transported unchanged through the network, and
       delivered to both intermediate nodes and receiving applications.

       - The RSVP ADSPEC object carries information which is generated at
       either data sources or intermediate network elements, is flowing
       downstream towards receivers, and may be used and updated inside
       the network before being delivered to receiving applications.
       This information includes both parameters describing the
       properties of the data path, including the availability of
       specific QoS control services, and parameters required by specific
       QoS control services to operate correctly.

       - The RSVP FLOWSPEC object carries reservation request
       (Receiver_TSpec and RSpec) information generated by data
       receivers.  The information in the FLOWSPEC flows upstream towards
       data sources.  It may be used or updated at intermediate network
       elements before arriving at the sending application.

         NOTE: The existence of both SENDER_TSPEC and ADSPEC RSVP objects
         is somewhat historical. Using the message format described in
         this note it would be possible to place all of the service
         control information carried "downstream" by RSVP in the same
         object. However, the distinction between data which is not
         updated within the network (in the SENDER_TSPEC object) and data
         which is updated within the network (in the ADSPEC object) may
         be useful to an implementation in practice, and is therefore
         retained.

>This is strengthen by section 2.2.1 that says that the content is 
>constructed using the same mechanisms as used for creating the 
>content of the Flowspec. If that is so, it is a flowspec not a tspec.

I see this as a reference to semantic construction.  I think this is 
clear in the text, but am open to any specific improvements you can suggest:

    ... The contents of the
    UPSTREAM_TSPEC Object MUST be constructed using a consistent format
    and procedures used to construct the FLOWSPEC object that will be
    used for the LSP, e.g., [RFC2210] or [RFC4328].  The contents of the
    UPSTREAM_TSPEC Object MAY differ from contents of the
    UPSTREAM_FLOWSPEC object based on application data transmission
    requirements.

>I would contest that what you really have is...
>Upstream_Flowspec is used to request a particular reservation as 
>predicted by the ingress.

yes.

>Upstream_TSpec is used to report the intended traffic flow (which 
>might not be the same as the reservation and might require a 
>modification to the reservation).

right.

>Upstream_Adspec reports the available resources in the upstream direction.

right again.

>In this case, the operational use would be...
>Path {TSpec, Adspec, Upstream_Flowspec}
>Resv {Flowspec = fn(TSpec, Adspec), Upstream_TSpec, Upstream_Adspec}
>If necessary
>     Path {TSpec, Adspec, Upstream_Flowspec'}
>     Resv {Flowspec, Upstream_TSpec, Upstream_Adspec}

I think this is what the draft says.

>===
>I believe it would be helpful to indicate in the Abstract that this 
>is an Experimental approach, and in the Introduction to include a 
>whole paragraph on why this is positioned as an Experimental RFC.

Okay have added:

         NOTE: THIS IS AN EXPERIMENTAL RFC.

Let us know if you'd to see anything additional.

>===
>Document title
>s/LSPs/Label Switched Paths/
>===
>Abstract
>s/LSPs/Label Switched Paths (LSPs)/
>===
>Section 1 para 1
>s/LSPs/Label Switched Paths (LSPs)/
>s/TDM/Time Division Multiplexing (TDM)/
>===
>Section 1 para 2
>s/discussion on/discussion of/
>===
>Section 1
>I believe it may be useful to say what an "asymmetric bandwidth LSP" is.
>Perhaps...
>   In this context there
>   has been discussion on the support of bidirectional LSPs with
>   asymmetric bandwidth.
>ADD
>   That is, bidirectional LSPs that have different bandwidth
>   reservations in each direction.
>===

okay.

>Section 1.2
>You have
>   An alternative approach was considered and
>   rejected.  For reference purposes only, the rejected approach is
>   summarized in Appendix A.
>
>Looking ahead at Appendix A, it is hard to see that this alternative 
>has been rejected. In fact, it says "SHOULD NOT be implemented". 
>Nowhere is there a definitive reason why the alternative has been 
>rejected (although there are a few hints in the introduction to the Appendix).

well it does say:
     This section is included for historic purposes and SHOULD NOT
     be implemented.

and
     In summary, the "ADSPEC Object" approach presented in this
     section SHOULD NOT be implemented.

This seems pretty clear to me.  What would you like it to say?

>*If* you wish to retain the rejected approach in the documentation, 
>then you need to give some background about why. What would be the 
>implications of doing the approach that lead you to recommend against it?

>This material could happily go in the appendix leaving the only 
>change to section 1.2 to be...
>s/rejected approach is summarized/rejected approach is summarized 
>with reasons for rejection/

I've changed the sec. 1.2. text to read "An alternative approach was 
considered and rejected in favor of the more generic approach 
presented below." and to A.1. "In particular this approach is 
technology specific; it uses the ADSPEC object to carry traffic 
parameters for upstream data and requires MEF Ethernet Traffic 
Parameter while the approach presented above is suitable for use with 
any technology."

>===
>Section 2
>You have
>   The new upstream objects carry the same information and are used in
>   the same fashion as the existing downstream objects; they only differ
>   in that they relate to traffic flowing in the upstream direction
>   while the existing objects relate to traffic flowing in the
>   downstream direction.
>
>They also differ in that they are used on messages in the opposite directions.

okay.

>===
>Section 2.1.1
>You suggest using "Routing problem/MPLS label allocation failure"
>Are you sure you do not want to be able to tell whether it was the 
>upstream or downstream resources that failed? Since these can be 
>varied independently, it would surely be useful to know which failed.

I don't have a strong opinion one way or another.

>===
>Section 2.3.1
>I think you need to clarify whether the Upstream_Adspec reports the 
>available upstream resources before or after the reservation for the 
>LSP in hand.

>  Note that Adspec would apply before the reservation.

This may be true on the initial path, but it isn't actually stated 
anywhere.  Furthermore, the information may include an LSPs 
reservation even in the case where it is not yet made.  e.g., RFC2212 
talks in terms of reporting what the "flow might experience" which 
implies that the full Tspec is accounted for in the initial ADSPEC.

So I think, like 2210, this should not be mentioned.

>===
>Section 3
>You don't list Upstream_Flowspec as carried on a Notify. But an 
>upstream notify session carries <sender descriptor> and you have 
>defined this to carry Upstream_Flowspec.
>You also don't list ResvErr as able to carry Upstream_TSpec, but 
>ResvErr can carry <error flow descriptor> which presumably can carry 
>the Upstream_TSpec as it also carries the Flowspec.
>Also, you don't list PathTear (can carry <sender descriptor>) and 
>ResvTear (carries <flow descriptor>)
>
>Perhaps your excuse will be that you say "Unmodified formats are not 
>listed." If that is the case, it should be pointed out that the 
>formats of the other messages are not modified either!

nope. just a simple mistake.

>Maybe the best way forward is to show how you modify <sender 
>descriptor>, <flow descriptor> and <error flow descriptor>, and say 
>that the use of these constructs on RSVP messages is not modified. 
>That would be the smallest change to the documentation.

Good catch.  Have changed the text to read:

    Object name            Applicable RSVP messages
    ---------------        ------------------------
    UPSTREAM_FLOWSPEC      Path, PathTear, PathErr and Notify
                               (via sender descriptor)
    UPSTREAM_TSPEC         Resv, ResvConf, ResvTear, ResvErr and
                               Notify (via flow descriptor list)
    UPSTREAM_ADSPEC        Resv, ResvConf, ResvTear, ResvErr and
                               Notify (via flow descriptor list)

>===
>Section 4
>OLD
>   Per [RFC2205], nodes not
>   supporting this extension should not recognize the new class numbers
>   and respond with an "Unknown Object Class" error.
>NEW
>   Per [RFC2205], nodes not
>   supporting this extension will not recognize the new class numbers
>   and SHOULD respond with an "Unknown Object Class" error

okay, the should is lower case as this document cannot dictate 
behavior of non-conforming implementations ;-)

>===
>Section 4
>You have...
>   The error message
>   will propagate to the ingress which can then take action to avoid the
>   path with the incompatible node, or may simply terminate the session.
>I think you need a little more care with the behavior for unknown 
>object on a Resv since that error will propagate to the egress.

This can only happen from a non-conformant implementation, i.e., one 
that passes a new object in the path but then rejects it in the resv.

>===
>Section 5.
>You might need another error code as mentioned above.
>===
>Section 6
>It is always worth referencing 
>draft-ietf-mpls-mpls-and-gmpls-security-framework in GMPLS-related 
>security sections.
>
>Although you have not introduced any new ways to penetrate the 
>security, I wonder whether you have introduced new ways to attack 
>the system once security is penetrated. Upstream_Adspec may be a way 
>to damage the system without leaving immediate evidence of where the 
>attack originated. Upstream_TSpec represents a new way to cause an 
>LSP that has been set up, to be torn down. Of course these issues 
>can be protected against, but you need to point them out so that 
>people understand the increased risk and the potential need to use 
>the existing security mechanisms.

okay have added some words on this.
>===
>Section 7.1
>[MEF-TRAFFIC] has been revised.
>Does it need to be a normative reference? It is only cited as an example.

moved.

>===
>Section 7.2
>[GMPLS-PBBTE] is now a CCAMP I-D
>===
>Section 8
>s/Author's/Authors'/
>===
>All appendix sections
>Section headers need left justify
>===
>Sections A, A.1, A.3, A.4
>s/section/appendix/  (Except "Section 3", "Section 3.1")
>===

isn't an appendix a section of the document?

Thanks for the usual detailed review & comments...

Lou 

Delivery-date: Mon, 21 Apr 2008 19:49:19 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Lou Berger" <[email-masked]>, "Attila Takacs \(IJ/ETH\)" <[email-masked]>, "Diego Caviglia \(GO/MCI\)" <[email-masked]>, "Don Fedyk" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Subject: Last call review of draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt
Date: Mon, 21 Apr 2008 20:25:30 +0100

Hi,

Here are some review comments about this I-D. As is bound to be the case 
with an experiment that has not been carried out, I think there are a few 
wrinkles to be ironed.

Cheers,
Adrian

===
I struggled to see the utility of the Upstream_TSpec and Upstream_Adspec 
objects. By the time these objects are used (on the Resv) the reservation 
has already been made using the Upstream_Flowspec (on the Path message).

This is strengthen by section 2.2.1 that says that the content is 
constructed using the same mechanisms as used for creating the content of 
the Flowspec. If that is so, it is a flowspec not a tspec.

I would contest that what you really have is...
Upstream_Flowspec is used to request a particular reservation as predicted 
by the ingress.
Upstream_TSpec is used to report the intended traffic flow (which might not 
be the same as the reservation and might require a modification to the 
reservation).
Upstream_Adspec reports the available resources in the upstream direction.

In this case, the operational use would be...
Path {TSpec, Adspec, Upstream_Flowspec}
Resv {Flowspec = fn(TSpec, Adspec), Upstream_TSpec, Upstream_Adspec}
If necessary
     Path {TSpec, Adspec, Upstream_Flowspec'}
     Resv {Flowspec, Upstream_TSpec, Upstream_Adspec}
===
I believe it would be helpful to indicate in the Abstract that this is an 
Experimental approach, and in the Introduction to include a whole paragraph 
on why this is positioned as an Experimental RFC.
===
Document title
s/LSPs/Label Switched Paths/
===
Abstract
s/LSPs/Label Switched Paths (LSPs)/
===
Section 1 para 1
s/LSPs/Label Switched Paths (LSPs)/
s/TDM/Time Division Multiplexing (TDM)/
===
Section 1 para 2
s/discussion on/discussion of/
===
Section 1
I believe it may be useful to say what an "asymmetric bandwidth LSP" is.
Perhaps...
   In this context there
   has been discussion on the support of bidirectional LSPs with
   asymmetric bandwidth.
ADD
   That is, bidirectional LSPs that have different bandwidth
   reservations in each direction.
===
Section 1.2
You have
   An alternative approach was considered and
   rejected.  For reference purposes only, the rejected approach is
   summarized in Appendix A.

Looking ahead at Appendix A, it is hard to see that this alternative has 
been rejected. In fact, it says "SHOULD NOT be implemented". Nowhere is 
there a definitive reason why the alternative has been rejected (although 
there are a few hints in the introduction to the Appendix).

*If* you wish to retain the rejected approach in the documentation, then you 
need to give some background about why. What would be the implications of 
doing the approach that lead you to recommend against it?

This material could happily go in the appendix leaving the only change to 
section 1.2 to be...
s/rejected approach is summarized/rejected approach is summarized with 
reasons for rejection/
===
Section 2
You have
   The new upstream objects carry the same information and are used in
   the same fashion as the existing downstream objects; they only differ
   in that they relate to traffic flowing in the upstream direction
   while the existing objects relate to traffic flowing in the
   downstream direction.

They also differ in that they are used on messages in the opposite 
directions.
===
Section 2.1.1
You suggest using "Routing problem/MPLS label allocation failure"
Are you sure you do not want to be able to tell whether it was the upstream 
or downstream resources that failed? Since these can be varied 
independently, it would surely be useful to know which failed.
===
Section 2.3.1
I think you need to clarify whether the Upstream_Adspec reports the 
available upstream resources before or after the reservation for the LSP in 
hand. Note that Adspec would apply before the reservation.
===
Section 3
You don't list Upstream_Flowspec as carried on a Notify. But an upstream 
notify session carries <sender descriptor> and you have defined this to 
carry Upstream_Flowspec.
You also don't list ResvErr as able to carry Upstream_TSpec, but ResvErr can 
carry <error flow descriptor> which presumably can carry the Upstream_TSpec 
as it also carries the Flowspec.
Also, you don't list PathTear (can carry <sender descriptor>) and ResvTear 
(carries <flow descriptor>)

Perhaps your excuse will be that you say "Unmodified formats are not 
listed." If that is the case, it should be pointed out that the formats of 
the other messages are not modified either!

Maybe the best way forward is to show how you modify <sender descriptor>, 
<flow descriptor> and <error flow descriptor>, and say that the use of these 
constructs on RSVP messages is not modified. That would be the smallest 
change to the documentation.
===
Section 4
OLD
   Per [RFC2205], nodes not
   supporting this extension should not recognize the new class numbers
   and respond with an "Unknown Object Class" error.
NEW
   Per [RFC2205], nodes not
   supporting this extension will not recognize the new class numbers
   and SHOULD respond with an "Unknown Object Class" error.
===
Section 4
You have...
   The error message
   will propagate to the ingress which can then take action to avoid the
   path with the incompatible node, or may simply terminate the session.
I think you need a little more care with the behavior for unknown object on 
a Resv since that error will propagate to the egress.
===
Section 5.
You might need another error code as mentioned above.
===
Section 6
It is always worth referencing 
draft-ietf-mpls-mpls-and-gmpls-security-framework in GMPLS-related security 
sections.

Although you have not introduced any new ways to penetrate the security, I 
wonder whether you have introduced new ways to attack the system once 
security is penetrated. Upstream_Adspec may be a way to damage the system 
without leaving immediate evidence of where the attack originated. 
Upstream_TSpec represents a new way to cause an LSP that has been set up, to 
be torn down. Of course these issues can be protected against, but you need 
to point them out so that people understand the increased risk and the 
potential need to use the existing security mechanisms.
===
Section 7.1
[MEF-TRAFFIC] has been revised.
Does it need to be a normative reference? It is only cited as an example.
===
Section 7.2
[GMPLS-PBBTE] is now a CCAMP I-D
===
Section 8
s/Author's/Authors'/
===
All appendix sections
Section headers need left justify
===
Sections A, A.1, A.3, A.4
s/section/appendix/  (Except "Section 3", "Section 3.1")
=== 

Delivery-date: Fri, 18 Apr 2008 17:51:17 +0000
Content-class: urn:content-classes:message
Subject: Please publish draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt
Date: Fri, 18 Apr 2008 12:48:58 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: "Ross Callon" <[email-masked]>
Cc: <[email-masked]>, "David Ward" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8A17C.7B2E2091
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Proto-write-up for
draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt

Intended status : Informational

> (1.a) Who is the Document Shepherd for this document? Has the

> Document Shepherd personally reviewed this version of the

> document and, in particular, does he or she believe this

> version is ready for forwarding to the IESG for publication?

Deborah Brungard is the document shepherd.

She has personally reviewed the I-D and believes it is ready for

forwarding to the IESG for publication.

> (1.b) Has the document had adequate review both from key WG members

> and from key non-WG members? Does the Document Shepherd have

> any concerns about the depth or breadth of the reviews that

> have been performed?

I-D had good review and discussion in the CCAMP working

group doing its development. It has not had review in any wider forums,
but none was deemed

necessary or appropriate.

> (1.c) Does the Document Shepherd have concerns that the document

> needs more review from a particular or broader perspective,

> e.g., security, operational complexity, someone familiar with

> AAA, internationalization or XML?

No concerns.

> (1.d) Does the Document Shepherd have any specific concerns or

> issues with this document that the Responsible Area Director

> and/or the IESG should be aware of? For example, perhaps he

> or she is uncomfortable with certain parts of the document, or

> has concerns whether there really is a need for it. In any

> event, if the WG has discussed those issues and has indicated

> that it still wishes to advance the document, detail those

> concerns here. Has an IPR disclosure related to this document

> been filed? If so, please include a reference to the

> disclosure and summarize the WG discussion and conclusion on

> this issue.

No concerns. No IPR disclosures have been filed.

> (1.e) How solid is the WG consensus behind this document? Does it

> represent the strong concurrence of a few individuals, with

> others being silent, or does the WG as a whole understand and

> agree with it?

Consensus is good.

> (1.f) Has anyone threatened an appeal or otherwise indicated extreme

> discontent? If so, please summarise the areas of conflict in

> separate email messages to the Responsible Area Director. (It

> should be in a separate email because this questionnaire is

> entered into the ID Tracker.)

No threats. No discontent.

> (1.g) Has the Document Shepherd personally verified that the

> document satisfies all ID nits? (See

> http://www.ietf.org/ID-Checklist.html
<http://www.ietf.org/ID-Checklist.html>  and

> http://tools.ietf.org/tools/idnits/
<http://tools.ietf.org/tools/idnits/> ). Boilerplate checks are

> not enough; this check needs to be thorough. Has the document

> met all formal review criteria it needs to, such as the MIB

> Doctor, media type and URI type reviews?

All checks made.

> (1.h) Has the document split its references into normative and

> informative? Are there normative references to documents that

> are not ready for advancement or are otherwise in an unclear

> state? If such normative references exist, what is the

> strategy for their completion? Are there normative references

> that are downward references, as described in [RFC3967]? If

> so, list these downward references to support the Area

> Director in the Last Call procedure for them [RFC3967].

References split. No downward references.

> (1.i) Has the Document Shepherd verified that the document IANA

> consideration section exists and is consistent with the body

> of the document? If the document specifies protocol

> extensions, are reservations requested in appropriate IANA

> registries? Are the IANA registries clearly identified? If

> the document creates a new registry, does it define the

> proposed initial contents of the registry and an allocation

> procedure for future registrations? Does it suggest a

> reasonable name for the new registry? See [RFC2434]. If the

> document describes an Expert Review process has Shepherd

> conferred with the Responsible Area Director so that the IESG

> can appoint the needed Expert during the IESG Evaluation?

The document is informational (no requests for IANA action). Null

IANA section included.

> (1.j) Has the Document Shepherd verified that sections of the

> document that are written in a formal language, such as XML

> code, BNF rules, MIB definitions, etc., validate correctly in

> an automated checker?

No such formal language is used.

> (1.k) The IESG approval announcement includes a Document

> Announcement Write-Up. Please provide such a Document

> Announcement Write-Up. Recent examples can be found in the

> "Action" announcements for approved documents. The approval

> announcement contains the following sections:

> Technical Summary

> Relevant content can frequently be found in the abstract

> and/or introduction of the document. If not, this may be

> an indication that there are deficiencies in the abstract

> or introduction.

Protection and recovery are important features of service offerings in
Multiprotocol Label Switching

(MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and
GMPLS networks

are being extended from single domain scope to multi-domain
environments. Various schemes and

processes have been developed to establish Label Switched Paths (LSPs)
in multi-domain environments.

These are discussed in RFC 4726: A Framework for Inter-Domain
Multiprotocol Label Switching

Traffic Engineering.

This document analyzes the application of these techniques to protection
and recovery in multi-domain

networks. The main focus for this document is on establishing end-to-end
diverse Traffic Engineering (TE)

LSPs in multi-domain networks.

> Working Group Summary

> Was there anything in WG process that is worth noting? For

> example, was there controversy about particular points or

> were there decisions where the consensus was particularly

> rough?

WG had good consensus with no disputes or disagreements.

> Document Quality

> Are there existing implementations of the protocol? Have a

> significant number of vendors indicated their plan to

> implement the specification? Are there any reviewers that

> merit special mention as having done a thorough review,

> e.g., one that resulted in important changes or a

> conclusion that the document had no substantive issues? If

> there was a MIB Doctor, Media Type or other expert review,

> what was its course (briefly)? In the case of a Media Type

> review, on what date was the request posted?

This is an Informational RFC with no protocol specifications.

------_=_NextPart_001_01C8A17C.7B2E2091
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3314" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT size=3D2>
<DIV><FONT size=3D+0><SPAN class=3D090310220-17042008>
<P><FONT size=3D2><FONT face=3DArial>Proto-write-up for draft-ietf<SPAN=20
class=3D090310220-17042008>-ccamp-inter-domain-recovery-analysis-05.txt</=
SPAN></FONT></FONT></P>
<P><FONT size=3D2><FONT face=3DArial>Intended status :&nbsp;<SPAN=20
class=3D090310220-17042008>Informational</SPAN></FONT></FONT></P>
<P><FONT face=3DArial size=3D2>&gt; (1.a) Who is the Document Shepherd =
for this=20
document? Has the</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; Document Shepherd personally =
reviewed this=20
version of the</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; document and, in particular, does he =
or she=20
believe this</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; version is ready for forwarding to =
the IESG for=20
publication?</FONT></P>
<P><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D090310220-17042008>Deborah=20
Brungard</SPAN>&nbsp;is the document shepherd.</FONT></FONT></P>
<P><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D090310220-17042008>She </SPAN>has=20
personally reviewed the I-D and believes it is ready =
for</FONT></FONT></P>
<P><FONT face=3DArial size=3D2>forwarding to the IESG for =
publication.</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; (1.b) Has the document had adequate =
review both=20
from key WG members</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; and from key non-WG members? Does =
the Document=20
Shepherd have</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; any concerns about the depth or =
breadth of the=20
reviews that</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; have been performed?</FONT></P>
<P><FONT face=3DArial size=3D2>I-D had good review&nbsp;<SPAN=20
class=3D090310220-17042008>and discussion </SPAN>in the&nbsp;<SPAN=20
class=3D090310220-17042008>CCAMP</SPAN> working</FONT></P>
<P><FONT face=3DArial size=3D2>group<SPAN class=3D090310220-17042008> =
doing its=20
development. </SPAN>It has not had review in any wider forums, but none =
was=20
deemed</FONT></P>
<P><FONT face=3DArial size=3D2>necessary or appropriate.</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; (1.c) Does the Document Shepherd =
have concerns=20
that the document</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; needs more review from a particular =
or broader=20
perspective,</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; e.g., security, operational =
complexity, someone=20
familiar with</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; AAA, internationalization or =
XML?</FONT></P>
<P><FONT face=3DArial size=3D2>No concerns.</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; (1.d) Does the Document Shepherd =
have any=20
specific concerns or</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; issues with this document that the =
Responsible=20
Area Director</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; and/or the IESG should be aware of? =
For example,=20
perhaps he</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; or she is uncomfortable with certain =
parts of=20
the document, or</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; has concerns whether there really is =
a need for=20
it. In any</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; event, if the WG has discussed those =
issues and=20
has indicated</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; that it still wishes to advance the =
document,=20
detail those</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; concerns here. Has an IPR disclosure =
related to=20
this document</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; been filed? If so, please include a =
reference to=20
the</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; disclosure and summarize the WG =
discussion and=20
conclusion on</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; this issue.</FONT></P>
<P><FONT face=3DArial size=3D2><SPAN class=3D090310220-17042008>No =
concerns. No IPR=20
disclosures have been filed.</SPAN></FONT></P>
<P><FONT face=3DArial size=3D2>&gt; (1.e) How solid is the WG consensus =
behind this=20
document? Does it</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; represent the strong concurrence of =
a few=20
individuals, with</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; others being silent, or does the WG =
as a whole=20
understand and</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; agree with it?</FONT></P>
<P><FONT face=3DArial size=3D2>Consensus is good.</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; (1.f) Has anyone threatened an =
appeal or=20
otherwise indicated extreme</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; discontent? If so, please summarise =
the areas of=20
conflict in</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; separate email messages to the =
Responsible Area=20
Director. (It</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; should be in a separate email =
because this=20
questionnaire is</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; entered into the ID =
Tracker.)</FONT></P>
<P><FONT face=3DArial size=3D2>No threats. No discontent.</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; (1.g) Has the Document Shepherd =
personally=20
verified that the</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; document satisfies all ID nits? =
(See</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; </FONT><A=20
title=3Dhttp://www.ietf.org/ID-Checklist.html=20
href=3D"http://www.ietf.org/ID-Checklist.html"><U=20
title=3Dhttp://www.ietf.org/ID-Checklist.html><FONT=20
title=3Dhttp://www.ietf.org/ID-Checklist.html color=3D#0000ff><FONT=20
title=3Dhttp://www.ietf.org/ID-Checklist.html face=3DArial=20
size=3D2>http://www.ietf.org/ID-Checklist.html</FONT></U></FONT></A><FONT=
=20
face=3DArial size=3D2> and</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; </FONT><A=20
title=3Dhttp://tools.ietf.org/tools/idnits/=20
href=3D"http://tools.ietf.org/tools/idnits/"><U=20
title=3Dhttp://tools.ietf.org/tools/idnits/><FONT=20
title=3Dhttp://tools.ietf.org/tools/idnits/ color=3D#0000ff><FONT=20
title=3Dhttp://tools.ietf.org/tools/idnits/ face=3DArial=20
size=3D2>http://tools.ietf.org/tools/idnits/</FONT></U></FONT></A><FONT =
face=3DArial=20
size=3D2>). Boilerplate checks are</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; not enough; this check needs to be =
thorough. Has=20
the document</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; met all formal review criteria it =
needs to, such=20
as the MIB</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; Doctor, media type and URI type=20
reviews?</FONT></P>
<P><FONT face=3DArial size=3D2>All checks made.</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; (1.h) Has the document split its =
references into=20
normative and</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; informative? Are there normative =
references to=20
documents that</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; are not ready for advancement or are =
otherwise=20
in an unclear</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; state? If such normative references =
exist, what=20
is the</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; strategy for their completion? Are =
there=20
normative references</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; that are downward references, as =
described in=20
[RFC3967]? If</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; so, list these downward references =
to support=20
the Area</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; Director in the Last Call procedure =
for them=20
[RFC3967].</FONT></P>
<P><FONT size=3D2><FONT face=3DArial>References split.<SPAN=20
class=3D090310220-17042008> No downward =
references.</SPAN></FONT></FONT></P>
<P><FONT face=3DArial size=3D2>&gt; (1.i) Has the Document Shepherd =
verified that=20
the document IANA</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; consideration section exists and is =
consistent=20
with the body</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; of the document? If the document =
specifies=20
protocol</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; extensions, are reservations =
requested in=20
appropriate IANA</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; registries? Are the IANA registries =
clearly=20
identified? If</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; the document creates a new registry, =
does it=20
define the</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; proposed initial contents of the =
registry and an=20
allocation</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; procedure for future registrations? =
Does it=20
suggest a</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; reasonable name for the new =
registry? See=20
[RFC2434]. If the</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; document describes an Expert Review =
process has=20
Shepherd</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; conferred with the Responsible Area =
Director so=20
that the IESG</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; can appoint the needed Expert during =
the IESG=20
Evaluation?</FONT></P>
<P><FONT face=3DArial><FONT size=3D2>The document&nbsp;<SPAN=20
class=3D090310220-17042008>is informational (no requests for IANA =
action).<SPAN=20
class=3D984483417-18042008> Null</SPAN></SPAN></FONT></FONT></P>
<P><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D090310220-17042008><SPAN=20
class=3D984483417-18042008>IANA section =
included.</SPAN></SPAN></FONT></FONT></P>
<P><FONT face=3DArial size=3D2>&gt; (1.j) Has the Document Shepherd =
verified that=20
sections of the</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; document that are written in a =
formal language,=20
such as XML</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; code, BNF rules, MIB definitions, =
etc., validate=20
correctly in</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; an automated checker?</FONT></P>
<P><FONT face=3DArial size=3D2>No such formal language is =
used.</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; (1.k) The IESG approval announcement =
includes a=20
Document</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; Announcement Write-Up. Please =
provide such a=20
Document</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; Announcement Write-Up. Recent =
examples can be=20
found in the</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; "Action" announcements for approved =
documents.=20
The approval</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; announcement contains the following=20
sections:</FONT></P>
<P><FONT face=3DArial size=3D2>&gt;</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; Technical Summary</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; Relevant content can frequently be =
found in the=20
abstract</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; and/or introduction of the document. =
If not,=20
this may be</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; an indication that there are =
deficiencies in the=20
abstract</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; or introduction.</FONT></P>
<P align=3Dleft><FONT face=3DArial size=3D2>Protection and recovery are =
important=20
features of service offerings<SPAN class=3D090310220-17042008> </SPAN>in =

Multiprotocol Label Switching</FONT></P>
<P align=3Dleft><FONT face=3DArial size=3D2>(MPLS) and Generalized MPLS =
(GMPLS)<SPAN=20
class=3D090310220-17042008> </SPAN>networks. Increasingly, MPLS and =
GMPLS=20
networks</FONT></P>
<P align=3Dleft><FONT face=3DArial size=3D2>are being extended<SPAN=20
class=3D090310220-17042008> </SPAN>from single domain scope to =
multi-domain=20
environments.<SPAN class=3D090310220-17042008> </SPAN>Various schemes=20
and</FONT></P>
<P align=3Dleft><FONT face=3DArial size=3D2>processes have been =
developed to establish=20
Label<SPAN class=3D090310220-17042008> </SPAN>Switched Paths (LSPs) in=20
multi-domain environments.</FONT></P>
<P align=3Dleft><FONT size=3D+0><FONT face=3DArial size=3D2>These =
are<SPAN=20
class=3D090310220-17042008> </SPAN>discussed in RFC 4726: A Framework =
for=20
Inter-Domain Multiprotocol<SPAN class=3D090310220-17042008> </SPAN>Label =

Switching</FONT></FONT></P>
<P align=3Dleft><FONT face=3DArial><FONT size=3D+0><FONT =
size=3D2>Traffic<SPAN=20
class=3D090310220-17042008> </SPAN></FONT></FONT><FONT=20
size=3D2>Engineering.</FONT></FONT></P>
<P align=3Dleft><FONT face=3DArial size=3D2>This document analyzes the =
application of=20
these techniques to<SPAN class=3D090310220-17042008> </SPAN>protection =
and=20
recovery in multi-domain</FONT></P>
<P align=3Dleft><FONT face=3DArial size=3D2>networks. The main focus =
for&nbsp;this=20
document is on establishing end-to-end diverse Traffic&nbsp;Engineering=20
(TE)</FONT></P>
<P align=3Dleft><FONT face=3DArial size=3D2>LSPs in multi-domain =
networks.</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; Working Group Summary</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; Was there anything in WG process =
that is worth=20
noting? For</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; example, was there controversy about =
particular=20
points or</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; were there decisions where the =
consensus was=20
particularly</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; rough?</FONT></P>
<P><FONT face=3DArial size=3D2>WG ha<SPAN =
class=3D090310220-17042008>d</SPAN> good=20
consensus with no disputes or disagreements.</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; Document Quality</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; Are there existing implementations =
of the=20
protocol? Have a</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; significant number of vendors =
indicated their=20
plan to</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; implement the specification? Are =
there any=20
reviewers that</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; merit special mention as having done =
a thorough=20
review,</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; e.g., one that resulted in important =
changes or=20
a</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; conclusion that the document had no =
substantive=20
issues? If</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; there was a MIB Doctor, Media Type =
or other=20
expert review,</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; what was its course (briefly)? In =
the case of a=20
Media Type</FONT></P>
<P><FONT face=3DArial size=3D2>&gt; review, on what date was the request =

posted?</FONT></P>
<P><SPAN class=3D090310220-17042008><FONT face=3DArial size=3D2>This is =
an=20
Informational RFC with no protocol=20
specifications.</FONT></SPAN></P></SPAN></FONT></DIV></FONT></DIV></BODY>=
</HTML>

------_=_NextPart_001_01C8A17C.7B2E2091--

Delivery-date: Fri, 18 Apr 2008 12:46:16 +0000
Date: Fri, 18 Apr 2008 08:44:10 -0400
To: "PAPADIMITRIOU Dimitri" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: I-D  Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt 
Cc: "Lou Berger" <[email-masked]>,<[email-masked]>

Works for me.  Thanks!

Lou

At 01:32 AM 4/18/2008, PAPADIMITRIOU Dimitri wrote:
>lou
>
>this version is only to align w/ 4420bis.
>
>changes like below are for the next. revision.
>
>hope this clarifies,
>-d.
> > -----Original Message-----
> > From: Lou Berger [mailto:[email-masked]]
> > Sent: Thursday, April 17, 2008 11:51 PM
> > To: PAPADIMITRIOU Dimitri
> > Cc: [email-masked]
> > Subject: Re: I-D
> > Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt
> >
> > Dimitri,
> >          I think this versions missed an updated that we previously
> > discussed.  Specifically it should define 0 value for Switching
> > Granularity (SG), i.e.:
> >       Value   Switching Granularity
> >       -----   ---------------------
> >         0     Provided in signaling.  See [GMPLS-ESVCS]
> >
> > I'll update [GMPLS-ESVCS] to explicitly say that the 0 value
> > MUST be used.
> >
> > Can you make sure this gets into the next rev?
> >
> > Much thanks,
> > Lou
> >
> > At 08:00 AM 4/14/2008, [email-masked] wrote:
> > >A New Internet-Draft is available from the on-line Internet-Drafts
> > >directories.
> > >This draft is a work item of the Common Control and Measurement
> > >Plane Working Group of the IETF.
> > >
> > >
> > >         Title           : Ethernet Traffic Parameters
> > >         Author(s)       : D. Papadimitriou, I. Property
> > >         Filename        :
> > draft-ietf-ccamp-ethernet-traffic-parameters-04.txt
> > >         Pages           : 13
> > >         Date            : 2008-04-13
> > >
> > >This document describes the Metro Ethernet Forum (MEF) - specific
> > >Ethernet Traffic Parameters as described in MEF10.1 when using
> > >Generalized Multi-Protocol Label Switching (GMPLS) Resource
> > >ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling.
> > >
> > >A URL for this Internet-Draft is:
> > >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet
>-traffic-parameters-04.txt
> > >
> > >Internet-Drafts are also available by anonymous FTP at:
> > >ftp://ftp.ietf.org/internet-drafts/
> > >
> > >Below is the data which will enable a MIME compliant mail reader
> > >implementation to automatically retrieve the ASCII version of the
> > >Internet-Draft.
> > >
> > >
> > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet
>-traffic-parameters-04.txt>
> >
> >

Delivery-date: Fri, 18 Apr 2008 09:42:48 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: New mailing list for ASON Routing Discussions
Date: Fri, 18 Apr 2008 10:40:32 +0100

Hi,

As previously promised, we have set up an IETF mailing list for discussions 
of the ASON Routing Requirements and the production of a bis to RFC 4258.

Our hope is that the Design Team will bring issues and discussions and early 
versions of their text to this list for wider discussion by the community.

When their draft is ready for adoption by CCAMP (we hope around Dublin) this 
list will be closed, and discussion will move to the CCAMP list.

Subscribe to the list at https://www.ietf.org/mailman/listinfo/ason-routing

Regards,
Adrian 

Delivery-date: Fri, 18 Apr 2008 05:37:05 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D  Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt 
Date: Fri, 18 Apr 2008 07:32:21 +0200
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Lou Berger" <[email-masked]>
Cc: <[email-masked]>

lou=20

this version is only to align w/ 4420bis.

changes like below are for the next. revision.

hope this clarifies,
-d.
> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]=20
> Sent: Thursday, April 17, 2008 11:51 PM
> To: PAPADIMITRIOU Dimitri
> Cc: [email-masked]
> Subject: Re: I-D=20
> Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt=20
>=20
> Dimitri,
>          I think this versions missed an updated that we previously=20
> discussed.  Specifically it should define 0 value for Switching=20
> Granularity (SG), i.e.:
>       Value   Switching Granularity
>       -----   ---------------------
>         0     Provided in signaling.  See [GMPLS-ESVCS]
>=20
> I'll update [GMPLS-ESVCS] to explicitly say that the 0 value=20
> MUST be used.
>=20
> Can you make sure this gets into the next rev?
>=20
> Much thanks,
> Lou
>=20
> At 08:00 AM 4/14/2008, [email-masked] wrote:
> >A New Internet-Draft is available from the on-line Internet-Drafts=20
> >directories.
> >This draft is a work item of the Common Control and Measurement=20
> >Plane Working Group of the IETF.
> >
> >
> >         Title           : Ethernet Traffic Parameters
> >         Author(s)       : D. Papadimitriou, I. Property
> >         Filename        :=20
> draft-ietf-ccamp-ethernet-traffic-parameters-04.txt
> >         Pages           : 13
> >         Date            : 2008-04-13
> >
> >This document describes the Metro Ethernet Forum (MEF) - specific
> >Ethernet Traffic Parameters as described in MEF10.1 when using
> >Generalized Multi-Protocol Label Switching (GMPLS) Resource
> >ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet
-traffic-parameters-04.txt
> >
> >Internet-Drafts are also available by anonymous FTP at:
> >ftp://ftp.ietf.org/internet-drafts/
> >
> >Below is the data which will enable a MIME compliant mail reader
> >implementation to automatically retrieve the ASCII version of the
> >Internet-Draft.
> >
> >
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet
-traffic-parameters-04.txt>
>=20
>=20

Delivery-date: Thu, 17 Apr 2008 21:51:14 +0000
Date: Thu, 17 Apr 2008 17:50:31 -0400
To: "Dimiri Papadimitriou" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: I-D Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt 
Cc: [email-masked]

Dimitri,
         I think this versions missed an updated that we previously 
discussed.  Specifically it should define 0 value for Switching 
Granularity (SG), i.e.:
      Value   Switching Granularity
      -----   ---------------------
        0     Provided in signaling.  See [GMPLS-ESVCS]

I'll update [GMPLS-ESVCS] to explicitly say that the 0 value MUST be used.

Can you make sure this gets into the next rev?

Much thanks,
Lou

At 08:00 AM 4/14/2008, [email-masked] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Common Control and Measurement 
>Plane Working Group of the IETF.
>
>
>         Title           : Ethernet Traffic Parameters
>         Author(s)       : D. Papadimitriou, I. Property
>         Filename        : draft-ietf-ccamp-ethernet-traffic-parameters-04.txt
>         Pages           : 13
>         Date            : 2008-04-13
>
>This document describes the Metro Ethernet Forum (MEF) - specific
>Ethernet Traffic Parameters as described in MEF10.1 when using
>Generalized Multi-Protocol Label Switching (GMPLS) Resource
>ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-04.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-04.txt>

Delivery-date: Thu, 17 Apr 2008 21:25:45 +0000
Date: Thu, 17 Apr 2008 17:23:49 -0400
To: "Adrian Farrel" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Two more working group last calls
Cc: <[email-masked]>

Adrian,
         See below for minor comments:

At 11:12 AM 4/11/2008, Adrian Farrel wrote:
>Hi,
>
>Sorry for the continued bombardment with reviewing activity.
>
>Here are two drafts that were discussed in Philadelphia with the 
>intention to go to WG last call as soon as possible.
>
>draft-ietf-rfc4420-bis-02.txt

I assume that you mean draft-ietf-ccamp-rfc4420bis-02.txt.

>This is the revision to RFC 4420 to fix the TLV encoding to be 
>consistent with the previous RSVP-TE RFCs. The fix is to the 
>interpretation of the Length field.
>Although we might not expect much in the way of review comments for 
>this I-D, it would be very helpful if you could read the I-D, point 
>out any typos, and send a note to say that you have read the 
>document and believe it is ready for publication.

Only a minor suggestion here:

I suggest moving the rational for the updated provided from section 
14 to section 1.  Specifically:

- drop section 14
- section 1, 1st paragraph: drop "See Section 14 for a summary of 
changes." and add:
    Prior to the change, the Length field indicated the length of the
    Value field only. After the change, as described in Section 3, the
    Length field indicates the length of the whole TLV. This change means
    that this document is consistent with the subobject format defined in
    [RFC3209] and the TLV format defined in [RFC3471].

Lou

>Please send your reviews to the list by 12 noon GMT, April 26, 2008.
>
>Thanks,
>Adrian
>
>PS, I'll be notifying the MPLS mailing list of these two last calls.
>
>
>

Delivery-date: Thu, 17 Apr 2008 18:14:40 +0000
Cc: OSPF List <[email-masked]>, Alan Davey <[email-masked]>, Vishwas Manral <[email-masked]>, David Ward <[email-masked]>, Ross Callon <[email-masked]>, CCAMP List <[email-masked]>
From: Acee Lindem <[email-masked]>
Subject: Re: OSPF WG Last Call for Traffic Engineering Extensions to OSPF version 3 - draft-ietf-ospf-ospfv3-traffic-10.txt 
Date: Thu, 17 Apr 2008 14:13:19 -0400
To: Acee Lindem <[email-masked]>

The WG last call has completed and I've posted a new version  
incorporating Adrian's comments. We'll move on to AD review with this  
draft.
Thanks,
Acee
On Mar 31, 2008, at 1:36 PM, Acee Lindem wrote:

> We've WG last called this draft in the past and we're going to do  
> it again now. After some deliberations we've made the decision to  
> go forward with this document with the two existing implementations  
> and forgo the request for interoperability testing. The WG last  
> call will be begin today and end April 15, 2008 at 12:00 AM EDT.
> Thanks,
> Acee

Delivery-date: Thu, 17 Apr 2008 15:26:29 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Draft communication to the MEF
Date: Thu, 17 Apr 2008 16:14:33 +0100

Hi,

Deborah and I took an action to send a communication to the MEF about our 
work with Ethernet to address their UNI and Service requirements. Now that 
we have WG drafts on the topics, we have prepared the attached.

Please let me know if you have any comments.

Thanks,
Deborah and Adrian

===
Communication to the MEF from the IETF's CCAMP Working Group

The IETF's CCAMP working group would like to inform the MEF of work it is 
carrying out to apply GMPLS protocols to the requirements of the Ethernet 
UNI and Ethernet service spectrum defined by the MEF. GMPLS is a family of 
IP-based protocols developed within the IETF and applicable to a range of 
technologies from packet switched networks (such as MPLS), through layer 2 
networks (such as ATM, Frame Relay, and Ethernet), to optical networks (like 
TDM and WDM).

We would like to draw your intention to the following Internet-Drafts that 
we are working on. We would welcome any feedback from your members on the 
requirements, details of the solutions proposed, or applicability of our 
work.

"Ethernet Traffic Parameters"
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-04.txt

"Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011
User-Network Interface (UNI)"
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-00.txt

"Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011
Ethernet Service Switching"
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-00.txt

"GMPLS Ethernet Label Switching Architecture and Framework"
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-01.txt

Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP Working Group Co-Chairs

Delivery-date: Thu, 17 Apr 2008 09:13:53 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt 
Date: Thu, 17 Apr 2008 10:01:24 +0100

More editorial nits thanks to Deborah.

Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 16, 2008 11:30 PM
Subject: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-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           : Analysis of Inter-domain Label Switched Path (LSP) 
> Recovery
> Author(s)       : T. Takeda, et al.
> Filename        : draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt
> Pages           : 25
> Date            : 2008-04-16
>
> Protection and recovery are important features of service offerings
> in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
> networks. Increasingly, MPLS and GMPLS networks are being extended
> from single domain scope to multi-domain environments.
>
> Various schemes and processes have been developed to establish Label
> Switched Paths (LSPs) in multi-domain environments. These are
> discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol
> Label Switching Traffic Engineering.
>
> This document analyzes the application of these techniques to
> protection and recovery in multi-domain networks. The main focus for
> this document is on establishing end-to-end diverse Traffic
> Engineering (TE) LSPs in multi-domain networks.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt

Delivery-date: Wed, 16 Apr 2008 22:32:49 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D  Action:draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt 
Date: Wed, 16 Apr 2008 15:30:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Analysis of Inter-domain Label Switched Path (LSP) Recovery
	Author(s)       : T. Takeda, et al.
	Filename        : draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt
	Pages           : 25
	Date            : 2008-04-16

Protection and recovery are important features of service offerings
in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
networks. Increasingly, MPLS and GMPLS networks are being extended
from single domain scope to multi-domain environments.

Various schemes and processes have been developed to establish Label
Switched Paths (LSPs) in multi-domain environments. These are
discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol
Label Switching Traffic Engineering.

This document analyzes the application of these techniques to
protection and recovery in multi-domain networks. The main focus for
this document is on establishing end-to-end diverse Traffic
Engineering (TE) LSPs in multi-domain networks.

Takeda et al.

Expires October 2008

 [page 1]

draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt

  April 2008

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Wed, 16 Apr 2008 22:32:41 +0000
Date: Thu, 17 Apr 2008 07:28:40 +0900
From: Kohei Shiomoto <[email-masked]>
To: "Ccamp (E-mail)" <[email-masked]>
Subject: MPLS2008 - CALL FOR PRESENTATIONS

MPLS 2008 INTERNATIONAL CONFERENCE
http://www.mpls2008.com
OCTOBER 19-22, 2008, WASHINGTON, DC
For detailed CFP visit: http://www.isocore.com/mpls2008/call_for_papers/cfp.htm
On line Submissions: http://www.isocore.com/mpls2008/call_for_papers/submissions.htm
Deadline for submission of presentation proposals: May 2, 2008

CALL FOR PRESENTATION
===========================

MPLS 2008 International Conference (http://www.mpls2008.com), the 11th Annual International Conference on MPLS and Related Technologies, will be held October 19 - 22, 2008, in Washington, DC. The Program Committee of MPLS2008 is soliciting presentation proposals for the conference. The committee seeks original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations addressing new technologies and operational experience are solicited from network equipment vendors, service providers, the research community, government agencies, and enterprise users. 

The deadline for submission of presentation proposals has been extended to May 2, 2008.

Submissions in the form of extended summaries (200-500 words) are solicited. In your summary, please state succinctly what the original contribution of your presentation is. 

Please submit the proposals to the Submissions page: http://www.isocore.com/mpls2008/call_for_papers/submissions.htm

This year's conference will include, but will not be limited to the following topics:

MPLS Transport Profiles
MPLS in multi-area and multi-AS networks
Carrier/Metro Ethernet services
Wireless and Mobility Backhauling
Ethernet Operations, Administration, and Maintenance
Multicast Enterprise / Next Generation MVPN
Point-to-multipoint MPLS and applications 
Multicast in MPLS Pseudowires and VPLS 
Single and Multi-hop Pseudowire placement, setup, and management 
Providing QoS in MPLS networks 
OAM and network management for MPLS networks 
Voice over IP/MPLS 
IMS and IPTV over MPLS 
Triple-play applications on MPLS 
MPLS-enabled Advanced services and converged networks 
Interworking and migration for MPLS and GMPLS 
Multi-layer networks and integration with non-packet technologies 
Deploying, interworking, and operating L2 and L3 MPLS VPNs 
MPLS deployment experience: scaling, performance, and security 
Testing: MPLS test tools and certification experience 
Protection, restoration, and reliability for MPLS and Psuedowires 
Network processors for MPLS and GMPLS 
MPLS/GMPLS control plane resilience, scaling and robustness 
MPLS TE applications of the Path Computation Element (PCE) 
MPLS applications in the access network 
MPLS and IPv6 
MPLS in the Enterprise Arena 
MPLS Support for Ethernet Services and VPLS 
GMPLS Applications (L1 VPNs, ASON, Optical Internetworking, NNI/UNI) 
Fast IP Routing Convergence versus MPLS Loop free networking 
High Availability (Graceful Restart, Non-Stop Routing, In-Service Software Upgrades, etc) 
MPLS in the Mobile Trunking Space 
MPLS Applications for Mobile Access Optimization 
MPLS Experience in Government Networks 
MPLS Experience in Research Networks 
Security features for MPLS and Pseudowires 
Congestion Notification and processing for MPLS and Pseudowires 
(G)MPLS interaction with routing protocols

Delivery-date: Tue, 15 Apr 2008 01:45:11 +0000
Reply-To: <[email-masked]>
From: "Weiqiang Sun" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-dppm-01.txt 
Date: Tue, 15 Apr 2008 09:41:42 +0800
Organization: Shanghai Jiao Tong University

Hi Adrian and all,

We have fixed the editorial issues pointed out by Adrian. Further comments
will be highly appreciated.

Cheers,
Weiqiang

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Tuesday, April 15, 2008 1:00 AM
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lsp-dppm-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane
Working Group of the IETF.

	Title		: Label Switched Path (LSP) Dynamical Provisioning
Performance Metrics in Generalized MPLS Networks
	Author(s)	: W. Sun, G. Zhang, J. Gao, G. Xie, R. Papneja, B.
Gu, X. Wei
	Filename	: draft-ietf-ccamp-lsp-dppm-01.txt
	Pages		: 39
	Date		: 2008-4-14
	
Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
promising candidate technologies for the future data transmission
network.  The GMPLS has been developed to control and cooperate
different kinds of network elements, such as conventional routers,
switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-
Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical
cross-connects (OXCs), etc.  Dynamic provisioning ability of these
physically diverse devices differs from each other drastically.  At
the same time, the need for dynamically provisioned connections is
increasing because optical networks are being deployed in metro area.
As different applications have varied requirements in the
provisioning performance of optical networks, it is imperative to
define standardized metrics and procedures such that the performance
of networks and application needs can be mapped to each other.

This document provides a series of performance metrics to evaluate
the dynamic LSP provisioning performance in GMPLS networks,
specifically the dynamical LSP setup/release performance.  These
metrics can depict the features of the GMPLS network in LSP dynamic
provisioning.  They can also be used in operational networks for
carriers to monitor the control plane performance in realtime.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Delivery-date: Mon, 14 Apr 2008 22:33:45 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-mef-uni-00.txt 
Date: Mon, 14 Apr 2008 15:30:01 -0700 (PDT)

--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 MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)
	Author(s)       : L. Berger, et al.
	Filename        : draft-ietf-ccamp-gmpls-mef-uni-00.txt
	Pages           : 11
	Date            : 2008-04-14

This document describes a method for controlling two specific types
of Ethernet switching via a Generalized Multi-Protocol Label
Switching (GMPLS) based User-Network Interface (UNI).  This document
supports the types of switching required to implied by the Ethernet
services that have been defined in the context of the Metro Ethernet
Forum (MEF) and International Telecommunication Union (ITU) G.8011.
This document is the UNI companion to "Generalized MPLS (GMPLS)
Support For Metro Ethernet Forum and G.8011 Ethernet Service
Switching".  This document does not define or limit the underlying
intra-domain or Internal NNI (I-NNI) technology used to support the
UNI.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-ccamp-gmpls-mef-uni-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Mon, 14 Apr 2008 22:33:37 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-00.txt 
Date: Mon, 14 Apr 2008 15:30:01 -0700 (PDT)

--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 MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching
	Author(s)       : L. Berger, et al.
	Filename        : draft-ietf-ccamp-gmpls-ether-svcs-00.txt
	Pages           : 22
	Date            : 2008-04-14

This document describes a method for controlling two specific types
of Ethernet switching via Generalized Multi-Protocol Label Switching
(GMPLS).  This document supports the types of switching required to
implied by the Ethernet services that have been defined in the
context of the Metro Ethernet Forum (MEF) and International
Telecommunication Union (ITU) G.8011.  Specifically, switching in
support of Ethernet private line service and Ethernet virtual private
line service.  Support for MEF and ITU defined parameters are also
covered.  Some of the extensions defined in this document are generic
in nature and not specific to Ethernet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ether-svcs-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Mon, 14 Apr 2008 19:02:40 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt 
Date: Mon, 14 Apr 2008 12:00:01 -0700 (PDT)

--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		: GMPLS control of Ethernet 
	Author(s)	: D. Fedyk, D. Allan, H. Shah, N. Bitar, A. Takacs
	Filename	: draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt
	Pages		: 27
	Date		: 2008-4-14
	
This memo is complementary to [ARCH] and describes how a GMPLS 
   control plane may be applied to the Provider Backbone Bridges Traffic 
   Engineering (PBB-TE) [IEEE 802.1Qay] amendment to 802.1Q and how 
   GMPLS can be used to configure VLAN-aware Ethernet switches in order 
   to establish Ethernet point to point (P2P) and P2MP MAC switched                                
   paths and P2P/P2MP VID based trees.  This document supports, but does 
   not modify, the standard IEEE data. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--NextPart--

Delivery-date: Mon, 14 Apr 2008 17:03:14 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lsp-dppm-01.txt 
Date: Mon, 14 Apr 2008 10:00:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in Generalized MPLS Networks
	Author(s)	: W. Sun, G. Zhang, J. Gao, G. Xie, R. Papneja, B. Gu, X. Wei
	Filename	: draft-ietf-ccamp-lsp-dppm-01.txt
	Pages		: 39
	Date		: 2008-4-14
	
Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
promising candidate technologies for the future data transmission
network.  The GMPLS has been developed to control and cooperate
different kinds of network elements, such as conventional routers,
switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-
Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical
cross-connects (OXCs), etc.  Dynamic provisioning ability of these
physically diverse devices differs from each other drastically.  At
the same time, the need for dynamically provisioned connections is
increasing because optical networks are being deployed in metro area.
As different applications have varied requirements in the
provisioning performance of optical networks, it is imperative to
define standardized metrics and procedures such that the performance
of networks and application needs can be mapped to each other.

This document provides a series of performance metrics to evaluate
the dynamic LSP provisioning performance in GMPLS networks,
specifically the dynamical LSP setup/release performance.  These
metrics can depict the features of the GMPLS network in LSP dynamic
provisioning.  They can also be used in operational networks for
carriers to monitor the control plane performance in realtime.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-ccamp-lsp-dppm-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--NextPart--

Delivery-date: Mon, 14 Apr 2008 12:02:59 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt 
Date: Mon, 14 Apr 2008 05:00:01 -0700 (PDT)

--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           : Ethernet Traffic Parameters
	Author(s)       : D. Papadimitriou, I. Property
	Filename        : draft-ietf-ccamp-ethernet-traffic-parameters-04.txt
	Pages           : 13
	Date            : 2008-04-13

This document describes the Metro Ethernet Forum (MEF) - specific
Ethernet Traffic Parameters as described in MEF10.1 when using
Generalized Multi-Protocol Label Switching (GMPLS) Resource
ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-ccamp-ethernet-traffic-parameters-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Mon, 14 Apr 2008 10:58:11 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Ross Callon" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Please publish draft-ietf-ccamp-isis-interas-te-extension-02.txt
Date: Mon, 14 Apr 2008 11:57:10 +0100

Proto-write-up for draft-ietf-ccamp-isis-interas-te-extension-02.txt

Intended status : Standards Track

This draft may be considered in parallel with draft-ietf-ccamp-ospf-
interas-te-extension-05.txt, but it is *not* required to process the
I-Ds in parallel.

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

Adrian Farrel is the document shepherd.
He has personally reviewed the I-D and believes it is ready for
forwarding to the IESG for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

I-D has had a good level of discussions and review in CCAMP and in the
ISIS working group. In particular, it received considerable input from
IS-IS experts in its early stages.

Document Shepherd believes reviews to have been adequate.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

No concerns.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

The document is sound.

> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

Consensus is good.

> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director.  (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)

No threats. No discontent.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

All checks made.

> (1.h)  Has the document split its references into normative and
>        informative?  Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state?  If such normative references exist, what is the
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

References split.
No downrefs.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

IANA section checked.

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

No such formal language is used.

> (1.k)  The IESG approval announcement includes a Document
>        Announcement Write-Up.  Please provide such a Document
>        Announcement Write-Up.  Recent examples can be found in the
>        "Action" announcements for approved documents.  The approval
>        announcement contains the following sections:
>
>        Technical Summary
>           Relevant content can frequently be found in the abstract
>           and/or introduction of the document.  If not, this may be
>           an indication that there are deficiencies in the abstract
>           or introduction.
                     
Traffic engineering extensions to IS-IS have been defined and are used
in support of MPLS-TE and GMPLS. The extensions provide a way of
encoding the TE information for TE-enabled links within the network and
flooding this information within an IS-IS area.

When establishing inter-AS MPLS-TE or GMPLS Label Switched Paths (LSPs)
a path is computed one AS at a time. This path may be computed using
conventional techniques at the first ASBR of each AS, or by using
Path Computation Elements (PCEs) as specified by the PCE working group.
In either case, if two ASes are connected by more than one inter-AS TE
link, it is helpful for the computation point to know the capabilities
of the available TE links in order to select a suitable path.

This document describes extensions to IS-IS to flood TE information
about inter-AS links. A new IS-IS top-level TLV is defined for this 
purpose in order to support transparent backward compatibility and to
support the potential use of separate IS-IS flooding instances.

This document does not propose or define any mechanisms to advertise
any other extra-AS TE information. This means that there is no proposal
to distribute TE information from one AS within another AS. Nor is there
any mechanism proposed to define or distribute "TE reachability" 
information.

>        Working Group Summary
>           Was there anything in WG process that is worth noting?  For
>           example, was there controversy about particular points or
>           were there decisions where the consensus was particularly
>           rough?

WG has good consensus.

Two points arose during working group discussions that are worth 
noting. Both points were resolved satisfactorily.

1. Separate IS-IS Instances
The original proposal in this I-D used extensions to the existing IS-IS
top-level TLV used for TE information distribution. This has been 
changed after requests from the ISIS working group to use a different
top-level TLV enabling easier backward compatibility and more flexible 
transition to multi-instance IS-IS in the future.

2. No Change to Scaling/Flooding Paradigm
Many people within CCAMP expressed a concern that the I-D might indicate
the intention to distribute TE information from one AS into another AS.
This would obviously break the as-based scaling and confidentiality 
paradigms of IGP routing. The authors were very clear that this was not
the intention and have added a specific section to cover non-objectives.

>        Document Quality
>           Are there existing implementations of the protocol?  Have a
>           significant number of vendors indicated their plan to
>           implement the specification?  Are there any reviewers that
>           merit special mention as having done a thorough review,
>           e.g., one that resulted in important changes or a
>           conclusion that the document had no substantive issues?  If
>           there was a MIB Doctor, Media Type or other expert review,
>           what was its course (briefly)?  In the case of a Media Type
>           review, on what date was the request posted?

There is a known implementation of the extensions. There was also
good support for the work from other vendors with the same objectives.

Document review by the IS-IS working group deserves special mention for
its care and thoroughness.

Delivery-date: Mon, 14 Apr 2008 10:30:56 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-isis-interas-te-extension-02.txt 
Date: Mon, 14 Apr 2008 03:30:01 -0700 (PDT)

--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           : ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
	Author(s)       : M. Chen, et al.
	Filename        : draft-ietf-ccamp-isis-interas-te-extension-02.txt
	Pages           : 18
	Date            : 2008-04-14

This document describes extensions to the ISIS (ISIS) protocol to
support Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems
(ASes). It defines ISIS-TE extensions for the flooding of TE
information about inter-AS links which can be used to perform inter-
AS TE path computation.

No support for flooding TE information from outside the AS is
proposed or defined in this document.Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-ccamp-isis-interas-te-extension-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Mon, 14 Apr 2008 10:24:13 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Ross Callon" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Please publish draft-ietf-ccamp-ospf-interas-te-extension-05.txt
Date: Mon, 14 Apr 2008 11:22:49 +0100

Proto-write-up for draft-ietf-ccamp-ospf-interas-te-extension-05.txt

Intended status : Standards Track

This draft may be considered in parallel with draft-ietf-ccamp-isis-
interas-te-extension-02.txt, but it is *not* required to process the
I-Ds in parallel.

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

Adrian Farrel is the document shepherd.
He has personally reviewed the I-D and believes it is ready for
forwarding to the IESG for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

I-D has had a good level of discussions and review in CCAMP and in the
OSPF working group. In particular, it received considerable input from
OSPF experts in its early stages.

Document Shepherd believes reviews to have been adequate.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

No concerns.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

The document is sound.

> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

Consensus is good.

> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director.  (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)

No threats. No discontent.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

All checks made.

> (1.h)  Has the document split its references into normative and
>        informative?  Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state?  If such normative references exist, what is the
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

References split.
No downrefs.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

IANA section checked.

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

No such formal language is used.

> (1.k)  The IESG approval announcement includes a Document
>        Announcement Write-Up.  Please provide such a Document
>        Announcement Write-Up.  Recent examples can be found in the
>        "Action" announcements for approved documents.  The approval
>        announcement contains the following sections:
>
>        Technical Summary
>           Relevant content can frequently be found in the abstract
>           and/or introduction of the document.  If not, this may be
>           an indication that there are deficiencies in the abstract
>           or introduction.
                     
Traffic engineering extensions to OSPFv2 and OSPFv3 have been defined
and are used in support of MPLS-TE and GMPLS. The extensions provide a
way of encoding the TE information for TE-enabled links within the
network and flooding this information within an OSPF area.

When establishing inter-AS MPLS-TE or GMPLS Label Switched Paths (LSPs)
a path is computed one AS at a time. This path may be computed using
conventional techniques at the first ASBR of each AS, or by using
Path Computation Elements (PCEs) as specified by the PCE working group.
In either case, if two ASes are connected by more than one inter-AS TE
link, it is helpful for the computation point to know the capabilities
of the available TE links in order to select a suitable path.

This document describes extensions to OSPFv2 and OSPFv3 to flood TE
information about inter-AS links. New LSAs are defined for this purpose
in order to support transparent backward compatibility and to support
the potential use of separate OSPF flooding instances.

This document does not propose or define any mechanisms to advertise
any other extra-AS TE information. This means that there is no proposal
to distribute TE information from one AS within another AS. Nor is there
any mechanism proposed to define or distribute "TE reachability" 
information.

>        Working Group Summary
>           Was there anything in WG process that is worth noting?  For
>           example, was there controversy about particular points or
>           were there decisions where the consensus was particularly
>           rough?

WG has good consensus.

Three points arose during working group discussions that are worth 
noting. All points were resolved satisfactorily.

1. OSPFv3 Support
The OSPF working group requested that this I-D consider OSPFv3 as well
as the OSPFv2 extensions that it was originally limited to. In return,
the OSPF working group is last calling the OSPFv3-TE extensions that
are a pre-requisite.

2. OSPFv2 Separate Opaque LSA
The original proposal in this I-D used extensions to the OSPFv2 opaque
LSA used from flooding information about intra-domain TE links. This
has been changed after requests from the OSPF working group to use a
different opaque LSA enabling easier backward compatibility and more
flexible transition to multi-instance OSPF in the future.

3. No Change to Scaling/Flooding Paradigm
Many people within CCAMP expressed a concern that the I-D might indicate
the intention to distribute TE information from one AS into another AS.
This would obviously break the as-based scaling and confidentiality 
paradigms of IGP routing. The authors were very clear that this was not
the intention and have added a specific section to cover non-objectives.

>        Document Quality
>           Are there existing implementations of the protocol?  Have a
>           significant number of vendors indicated their plan to
>           implement the specification?  Are there any reviewers that
>           merit special mention as having done a thorough review,
>           e.g., one that resulted in important changes or a
>           conclusion that the document had no substantive issues?  If
>           there was a MIB Doctor, Media Type or other expert review,
>           what was its course (briefly)?  In the case of a Media Type
>           review, on what date was the request posted?

There is a known implementation of the OSPFv2 extensions. There was also
good support for the work from other vendors with the same objectives.

There is no known implementation of the OSPFv3 extensions.

Document review by Acee Lindem deserves special mention for its care
and thoroughness.

Delivery-date: Mon, 14 Apr 2008 09:18:41 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-05.txt 
Date: Mon, 14 Apr 2008 02:15:02 -0700 (PDT)

--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           : OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
	Author(s)       : M. Chen, et al.
	Filename        : draft-ietf-ccamp-ospf-interas-te-extension-05.txt
	Pages           : 17
	Date            : 2008-04-14

This document describes extensions to the OSPF version 2 and 3
protocols to support Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple
Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined
for the flooding of TE information about inter-AS links which can be
used to perform inter-AS TE path computation.

No support for flooding TE information from outside the AS is
proposed or defined in this document.Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-ccamp-ospf-interas-te-extension-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Sun, 13 Apr 2008 11:50:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt 
Date: Sun, 13 Apr 2008 12:50:36 +0100

Hi,

Changes are all editorial. We made some re-works to make the text clearer 
and easier to read.

Cheers,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, April 13, 2008 12:45 PM
Subject: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
> This draft is a work item of the Common Control and Measurement Plane 
> Working Group of the IETF.
>
>
> Title           : Analysis of Inter-domain Label Switched Path (LSP) 
> Recovery
> Author(s)       : T. Takeda, et al.
> Filename        : draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt
> Pages           : 25
> Date            : 2008-04-13
>
> Protection and recovery are important features of service provision
> in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
> networks. Increasingly, MPLS and GMPLS networking is being widened
> from single domain scope to operate in multi-domain environments.
>
> Various schemes and processes have been developed to establish Label
> Switched Paths (LSPs) in multi-domain environments. These are
> discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol
> Label Switching Traffic Engineering.
>
> This document analyzes the application of these techniques to
> protection and recovery in multi-domain networks. The main focus for
> this document is on establishing end-to-end diverse Traffic
> Engineering (TE) LSPs in multi-domain networks.
>
> Takeda et al.
>
>
>
>
> Expires October 2008
>
>
>
>
> [page 1]
>
> draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt
>
>  March 2008
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

--------------------------------------------------------------------------------

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

Delivery-date: Sun, 13 Apr 2008 11:48:25 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D  Action:draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt 
Date: Sun, 13 Apr 2008 04:45:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Analysis of Inter-domain Label Switched Path (LSP) Recovery
	Author(s)       : T. Takeda, et al.
	Filename        : draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt
	Pages           : 25
	Date            : 2008-04-13

Protection and recovery are important features of service provision
in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
networks. Increasingly, MPLS and GMPLS networking is being widened
from single domain scope to operate in multi-domain environments.

Various schemes and processes have been developed to establish Label
Switched Paths (LSPs) in multi-domain environments. These are
discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol
Label Switching Traffic Engineering.

This document analyzes the application of these techniques to
protection and recovery in multi-domain networks. The main focus for
this document is on establishing end-to-end diverse Traffic
Engineering (TE) LSPs in multi-domain networks.

Takeda et al.

Expires October 2008

 [page 1]

draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt

  March 2008

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Fri, 11 Apr 2008 18:44:18 +0000
Content-class: urn:content-classes:message
Subject: RE: Two more working group last calls
Date: Fri, 11 Apr 2008 14:41:24 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi Adrian,

I've looked over draft-ietf-rfc4420-bis-02.txt and did not notice any
typos.  The new
Length description looks like the equivalent text in RFC 3471, which we
support.  It
looks ready for publication.

Request that other editors check to make sure that their drafts are
updated to have the
same interpretation of the Length field as well.

Cheers,

Lyndon

 =20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Friday, April 11, 2008 8:13 AM
To: [email-masked]
Subject: Two more working group last calls

Hi,

Sorry for the continued bombardment with reviewing activity.

Here are two drafts that were discussed in Philadelphia with the
intention to go to WG last call as soon as possible.

draft-ietf-rfc4420-bis-02.txt
This is the revision to RFC 4420 to fix the TLV encoding to be
consistent with the previous RSVP-TE RFCs. The fix is to the
interpretation of the Length field.
Although we might not expect much in the way of review comments for this
I-D, it would be very helpful if you could read the I-D, point out any
typos, and send a note to say that you have read the document and
believe it is ready for publication.

draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt
This I-D for asymmetrical bandwidth allocations on bidirectional LSPs
has been moved into the WG from being an individual submission, and has
been marked as "Experimental". The reasoning was:
- This is clearly a draft that CCAMP needs to review, so it might as
well
  be a CCAMP draft.
- This is a "stake in the ground" for how this problem would be solved
  within RSVP-TE, but at this stage there are no known implementations
  and no-one considering implementation.

Please send your reviews to the list by 12 noon GMT, April 26, 2008.

Thanks,
Adrian

PS, I'll be notifying the MPLS mailing list of these two last calls.=20

Delivery-date: Fri, 11 Apr 2008 15:20:11 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Two more working group last calls
Date: Fri, 11 Apr 2008 16:12:56 +0100

Hi,

Sorry for the continued bombardment with reviewing activity.

Here are two drafts that were discussed in Philadelphia with the intention 
to go to WG last call as soon as possible.

draft-ietf-rfc4420-bis-02.txt
This is the revision to RFC 4420 to fix the TLV encoding to be consistent 
with the previous RSVP-TE RFCs. The fix is to the interpretation of the 
Length field.
Although we might not expect much in the way of review comments for this 
I-D, it would be very helpful if you could read the I-D, point out any 
typos, and send a note to say that you have read the document and believe it 
is ready for publication.

draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt
This I-D for asymmetrical bandwidth allocations on bidirectional LSPs has 
been moved into the WG from being an individual submission, and has been 
marked as "Experimental". The reasoning was:
- This is clearly a draft that CCAMP needs to review, so it might as well
  be a CCAMP draft.
- This is a "stake in the ground" for how this problem would be solved
  within RSVP-TE, but at this stage there are no known implementations
  and no-one considering implementation.

Please send your reviews to the list by 12 noon GMT, April 26, 2008.

Thanks,
Adrian

PS, I'll be notifying the MPLS mailing list of these two last calls. 

Delivery-date: Fri, 11 Apr 2008 12:01:16 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-04.txt 
Date: Fri, 11 Apr 2008 05:00:01 -0700 (PDT)

--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           : OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
	Author(s)       : M. Chen, R. Zhang
	Filename        : draft-ietf-ccamp-ospf-interas-te-extension-04.txt
	Pages           : 18
	Date            : 2008-04-11

This document describes extensions to the OSPF version 2 and 3 
protocols to support Multiprotocol Label Switching (MPLS) and 
Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple 
Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined 
for the flooding of TE information about inter-AS links which can be 
used to perform inter-AS TE path computation. 

 
 No support for flooding TE information from outside the AS is 
proposed or defined in this document. 

Conventions used in this document 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC-2119 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-ccamp-ospf-interas-te-extension-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Fri, 11 Apr 2008 11:55:59 +0000
Cc: CCAMP List <[email-masked]>, OSPF List <[email-masked]>
From: Acee Lindem <[email-masked]>
Subject: Re: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-03.txt
Date: Fri, 11 Apr 2008 07:55:12 -0400
To: Mach Chen <[email-masked]>

Hi Mach,

On Apr 11, 2008, at 1:16 AM, Mach Chen wrote:

> Hi Acee,
>
> On 2008-04-11, at 03:42:09 Acee Lindem wrote:
>> Hi Mach,
>> My comments have been addressed to my satisfaction. Depending on who
>> reviews it, you may get requests to expand some more of the acronyms
>> on first use during the Gen-ART review.
>
> OK, I will try again.

I'm happy with it as it is. I'd wait until the Gen-ART review since  
you may get additional comments.

Thanks,
Acee

>
> Thanks,
>
> Mach
>
>> Thanks,
>> Acee
>> On Apr 10, 2008, at 3:00 AM, [email-masked] wrote:
>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Common Control and Measurement
>>> Plane Working Group of the IETF.
>>>
>>>
>>> 	Title           : OSPF Extensions in Support of Inter-AS
>>> Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
>>> Traffic Engineering
>>> 	Author(s)       : M. Chen, R. Zhang
>>> 	Filename        : draft-ietf-ccamp-ospf-interas-te-extension-03.txt
>>> 	Pages           : 18
>>> 	Date            : 2008-04-09
>>>
>>> This document describes extensions to the OSPF version 2 and 3
>>> protocols to support Multiprotocol Label Switching (MPLS) and
>>> Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple
>>> Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined
>>> for the flooding of TE information about inter-AS links which can be
>>> used to perform inter-AS TE path computation.
>>>
>>>
>>>
>>>
>>>  No support for flooding TE information from outside the AS is
>>> proposed or defined in this document.
>>>
>>> Conventions used in this document
>>>
>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>> document are to be interpreted as described in RFC-2119 [RFC2119].
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-
>>> te-extension-03.txt
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>> Content-Type: text/plain
>>> Content-ID:     <[email-masked]>
>>
>
>

Delivery-date: Fri, 11 Apr 2008 11:07:38 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Conclusion on Ethernet I-Ds
Date: Fri, 11 Apr 2008 12:04:18 +0100

Hi,

I think we are there.

Authors, please submit your I-Ds with the name changes shown below.
In this first submission as WG I-Ds, please don't make any other changes 
except for dates, filenames, and anything needed to pass idnits 
(http://tools.ietf.org/tools/idnits/).

Some of you have received comments during the polling process that you will 
want to address in subsequent revisions.

draft-imajuku-ccamp-ethernet-gmpls-req-01.txt
--->draft-ietf-ccamp-ethernet-gmpls-provider-reqs-00.txt

draft-fedyk-gmpls-ethernet-pbb-te-02.txt
--->draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt

draft-berger-ccamp-gmpls-mef-uni-02.txt
--->draft-ietf-ccamp-gmpls-mef-uni-00.txt

draft-berger-ccamp-gmpls-ether-svcs-01.txt
--->draft-ietf-ccamp-gmpls-ether-svcs-00.txt

Thanks,
Adrian 

Delivery-date: Fri, 11 Apr 2008 05:18:39 +0000
Date: Fri, 11 Apr 2008 13:16:26 +0800
From: Mach Chen <[email-masked]>
Subject: Re: Re: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-03.txt
To: Acee Lindem <[email-masked]>
Cc: CCAMP List <[email-masked]>, OSPF List <[email-masked]>
Organization: Huawei

Hi Acee,
  
On 2008-04-11, at 03:42:09 Acee Lindem wrote:
>Hi Mach,
>My comments have been addressed to my satisfaction. Depending on who  
>reviews it, you may get requests to expand some more of the acronyms  
>on first use during the Gen-ART review.

OK, I will try again.

Thanks,

Mach 

>Thanks,
>Acee
>On Apr 10, 2008, at 3:00 AM, [email-masked] wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts  
>> directories.
>> This draft is a work item of the Common Control and Measurement  
>> Plane Working Group of the IETF.
>>
>>
>> 	Title           : OSPF Extensions in Support of Inter-AS  
>> Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)  
>> Traffic Engineering
>> 	Author(s)       : M. Chen, R. Zhang
>> 	Filename        : draft-ietf-ccamp-ospf-interas-te-extension-03.txt
>> 	Pages           : 18
>> 	Date            : 2008-04-09
>>
>> This document describes extensions to the OSPF version 2 and 3
>> protocols to support Multiprotocol Label Switching (MPLS) and
>> Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple
>> Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined
>> for the flooding of TE information about inter-AS links which can be
>> used to perform inter-AS TE path computation.
>>
>>
>>
>>
>>  No support for flooding TE information from outside the AS is
>> proposed or defined in this document.
>>
>> Conventions used in this document
>>
>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>> document are to be interpreted as described in RFC-2119 [RFC2119].
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- 
>> te-extension-03.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> Content-Type: text/plain
>> Content-ID:     <[email-masked]>
>

Delivery-date: Thu, 10 Apr 2008 20:56:45 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds
Date: Thu, 10 Apr 2008 23:54:44 +0300
From: "Nurit Sprecher" <[email-masked]>
To: "ext Igor Bryskin" <[email-masked]>, "Attila Takacs" <[email-masked]>, "Don Fedyk" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C89B4D.2792BC99
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I am not sure any more how we got into this discussion, but I am pretty
much convinced that this does not relate to the GMPLS context.=20

The question was on the adoption of the draft on GMPLS for a data plane
that is defined by the IEEE (802.1Qay). This is the way it is defined by
the IEEE and we provide a control plane to control it. I am pretty sure
that the use of the control plane for PBB-TE will ensure a consistent
behavior of the PBB-TE network.=20

Personally I am in favor of making this draft an IETF one, and I hope
you are all as well.

Best regards,

Nurit

=20

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Igor Bryskin
Sent: Thursday, April 10, 2008 18:13
To: Attila Takacs; Don Fedyk; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Continued Poll for Adoption of Ethernet I-Ds

=20

Hi Attila,

Please, see in line.

----- Original Message ----
From: Attila Takacs <[email-masked]>
To: Igor Bryskin <[email-masked]>; Don Fedyk <[email-masked]>;
[email-masked]; [email-masked]; [email-masked]
Sent: Thursday, April 10, 2008 2:54:21 AM
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

Hi Igor,

=20

	But how the separation of VLAN ID space would help in this case?
If PBB packets are leaked into PBB-TE they will be immediately dropped
because there will be no PBB-TE connections configured for such packets.
If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing
about PBB-TE anyway the packets will be flooded across the PBB domain. =20

	=20

Unfortunately, leaking from PBB to PBB-TE does not necessarily means
immediate discarding of PBB frames. Due to the VLAN separation between
PBB and PBB-TE, there is no clear layering here. Hence leaking can
essentially mean that the VID of a bridged (PBB) frame is changed to a
VID used for explicitly routed connections (PBB-TE). This does not
necessarily means that the frame will be dropped. It is a valid
assumption that the MAC address of the PBB frame is configured in the
PBB-TE region as well and as such leakig PBB traffic will be forwarded
as if it would belong to an explicitly routed connection.

IB>> In order for a packet, leaking from PBB to PBB_TE not be dropped,
it is necessary for the triplet from PBB MAC header (SA-DA-VID) to match
one of configured on the node PBB-TE connections. Even if one assumes
that this is possible, it is highly unlikely to be the case on the next
along the connection PBB-TE node. Hence the packet will be dropped
either immediately or on the next PBB-TE node.

Cheers,
Igor=20

	Note that what I just wrote is true regardless whether PBB-TE
uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there
is no architectural need for the VLANID space separation.
	 =20

I think this is not necessary true, if one allocates the whole VLAN
space to PBB-TE then there will be no bridged traffic in the network. As
a consequence no leaking and no other cross effects is to be expected.

=20

Best regards,

Attila

=20

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around=20
http://mail.yahoo.com=20

------_=_NextPart_001_01C89B4D.2792BC99
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1 dir=3DRTL>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></s=
pan></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I am not sure =
any more
how we got into this discussion, but I am pretty much convinced that =
this does
not relate to the GMPLS context. <o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>The question was =
on the
adoption of the draft on GMPLS for a data plane that is defined by the =
IEEE
(802.1Qay). This is the way it is defined by the IEEE and we provide a =
control
plane to control it. I am pretty sure that the use of the control plane =
for
PBB-TE will ensure a consistent behavior of the PBB-TE network. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Personally I am =
in favor
of making this draft an IETF one, and I hope you are all as =
well.<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Best =
regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Nurit<o:p></o:p><=
/span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter dir=3DLTR =
style=3D'text-align:center'><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal dir=3DLTR><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> owner-<st1:PersonName
w:st=3D"on">[email-masked]</st1:PersonName> =
[mailto:owner-<st1:PersonName
w:st=3D"on">[email-masked]</st1:PersonName>] <b><span =
style=3D'font-weight:
bold'>On Behalf Of </span></b>ext Igor Bryskin<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, April 10, =
2008
18:13<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Attila Takacs; Don =
Fedyk;
[email-masked]; [email-masked]; <st1:PersonName =
w:st=3D"on">[email-masked]</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Continued =
Poll for
Adoption of Ethernet I-Ds</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<p class=3DMsoNormal dir=3DLTR style=3D'margin-bottom:12.0pt'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Hi Attila,<br>
<br>
Please, see in line.<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal dir=3DLTR style=3D'margin-bottom:12.0pt'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>----- Original =
Message ----<br>
From: Attila Takacs &lt;[email-masked]&gt;<br>
To: Igor Bryskin &lt;[email-masked]&gt;; Don Fedyk
&lt;[email-masked]&gt;; [email-masked]; [email-masked]; =
<st1:PersonName
w:st=3D"on">[email-masked]</st1:PersonName><br>
Sent: Thursday, April 10, 2008 2:54:21 AM<br>
Subject: RE: Continued Poll for Adoption of Ethernet =
I-Ds<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Hi =
Igor,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:4.2pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>=

<div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>But how the separation of VLAN ID space would =
help in
this case? If PBB packets are leaked into PBB-TE they will be =
immediately
dropped because there will be no PBB-TE connections configured for such
packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows =
nothing
about PBB-TE anyway the packets will be flooded across the PBB =
domain.&nbsp;</span></font><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</blockquote>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Unfortunately, =
leaking
from PBB to PBB-TE does not necessarily means immediate discarding of =
PBB
frames.&nbsp;Due to the VLAN separation between PBB and PBB-TE, there is =
no
clear layering here. Hence leaking can essentially mean that the VID =
of&nbsp;a
bridged (PBB) frame is changed to a VID used for&nbsp;explicitly
routed&nbsp;connections (PBB-TE). This does not necessarily means that =
the
frame will be dropped. It is a valid assumption that the MAC address of =
the PBB
frame is configured in the PBB-TE region as well and as such leakig PBB =
traffic
will be forwarded as if it would belong to&nbsp;an explicitly routed
connection.<br>
<br>
IB&gt;&gt; In order for a packet, leaking from PBB to PBB_TE not be =
dropped, it
is necessary for the triplet from PBB MAC header (SA-DA-VID) to match =
one of
configured on the node PBB-TE connections. Even if one assumes that this =
is
possible, it is highly unlikely to be the case on the next along the =
connection
PBB-TE node. Hence the packet will be dropped either immediately or on =
the next
PBB-TE node.<br>
<br>
Cheers,<br>
Igor </span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:4.2pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>=

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Note that what I just wrote is true =
regardless whether
PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence =
there
is no architectural need for the VLANID space separation.<br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>&nbsp;</span></font>&nbsp;<o:p></o:p></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>I think this is =
not
necessary true, if one allocates the whole VLAN space to PBB-TE then =
there will
be no bridged traffic in the network. As a consequence no leaking and no =
other
cross effects is to be expected.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Best =
regards,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Attila</span></fo=
nt><o:p></o:p></p>

</div>

</div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><br>
__________________________________________________<br>
Do You Yahoo!?<br>
Tired of spam? Yahoo! Mail has the best spam protection around <br>
http://mail.yahoo.com <o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C89B4D.2792BC99--

Delivery-date: Thu, 10 Apr 2008 19:44:52 +0000
Cc: CCAMP List <[email-masked]>, OSPF List <[email-masked]>
From: Acee Lindem <[email-masked]>
Subject: Re: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-03.txt 
Date: Thu, 10 Apr 2008 15:42:05 -0400
To: Mach Chen <[email-masked]>

Hi Mach,
My comments have been addressed to my satisfaction. Depending on who  
reviews it, you may get requests to expand some more of the acronyms  
on first use during the Gen-ART review.
Thanks,
Acee
On Apr 10, 2008, at 3:00 AM, [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Common Control and Measurement  
> Plane Working Group of the IETF.
>
>
> 	Title           : OSPF Extensions in Support of Inter-AS  
> Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)  
> Traffic Engineering
> 	Author(s)       : M. Chen, R. Zhang
> 	Filename        : draft-ietf-ccamp-ospf-interas-te-extension-03.txt
> 	Pages           : 18
> 	Date            : 2008-04-09
>
> This document describes extensions to the OSPF version 2 and 3
> protocols to support Multiprotocol Label Switching (MPLS) and
> Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple
> Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined
> for the flooding of TE information about inter-AS links which can be
> used to perform inter-AS TE path computation.
>
>
>
>
>  No support for flooding TE information from outside the AS is
> proposed or defined in this document.
>
> Conventions used in this document
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC-2119 [RFC2119].
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- 
> te-extension-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID:     <[email-masked]>

Delivery-date: Thu, 10 Apr 2008 15:16:17 +0000
Date: Thu, 10 Apr 2008 08:13:09 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: Continued Poll for Adoption of Ethernet I-Ds
To: Attila Takacs <[email-masked]>, Don Fedyk <[email-masked]>, [email-masked], [email-masked], [email-masked]

--0-608773676-1207840389=:46599
Content-Type: text/plain; charset=us-ascii

Hi Attila,

Please, see in line.

----- Original Message ----
From: Attila Takacs <[email-masked]>
To: Igor Bryskin <[email-masked]>; Don Fedyk <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Sent: Thursday, April 10, 2008 2:54:21 AM
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

 DIV {
MARGIN:0px;}
Hi 
Igor,
 
    But   how the separation of VLAN ID space would help in this case? If PBB packets   are leaked into PBB-TE they will be immediately dropped because there will be   no PBB-TE connections configured for such packets. If PBB-TE packets are   leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the   packets will be flooded across the PBB domain.  

Unfortunately, leaking from PBB to PBB-TE does not necessarily means immediate discarding of PBB frames. Due to the VLAN separation between PBB and PBB-TE, there is no clear layering here. Hence leaking can essentially mean that the VID of a bridged (PBB) frame is changed to a VID used for explicitly routed connections (PBB-TE). This does not necessarily means that the frame will be dropped. It is a valid assumption that the MAC address of the PBB frame is configured in the PBB-TE region as well and as such leakig PBB traffic will be forwarded as if it would belong to an explicitly routed connection.

IB>> In order for a packet, leaking from PBB to PBB_TE not be dropped, it is necessary for the triplet from PBB MAC header (SA-DA-VID) to match one of configured on the node PBB-TE connections. Even if one assumes that this is possible, it is highly unlikely to be the case on the next along the connection PBB-TE node. Hence the packet will be dropped either immediately or on the next PBB-TE node.

Cheers,
Igor 
  Note   that what I just wrote is true regardless whether PBB-TE uses specially   allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural   need for the VLANID space separation.
  
I think this is 
not necessary true, if one allocates the whole VLAN space to PBB-TE then there 
will be no bridged traffic in the network. As a consequence no leaking and no 
other cross effects is to be expected.
 
Best 
regards,
Attila

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
--0-608773676-1207840389=:46599
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Hi Attila,<br><br>Please, see in line.<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Attila Takacs &lt;[email-masked]&gt;<br>To: Igor Bryskin &lt;[email-masked]&gt;; Don Fedyk &lt;[email-masked]&gt;; [email-masked]; [email-masked]; [email-masked]<br>Sent: Thursday, April 10, 2008 2:54:21 AM<br>Subject: RE: Continued Poll for Adoption of Ethernet I-Ds<br><br>

<style type="text/css">DIV {
MARGIN:0px;}
</style>

<div><span class="067382706-10042008"><font color="#0000ff" face="Arial" size="2">Hi 
Igor,</font></span></div>
<div><span class="067382706-10042008"><font color="#0000ff" face="Arial" size="2"></font></span>&nbsp;</div>
<blockquote style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
  <div style="font-size: 12pt; font-family: times new roman,new york,times,serif;">
  <div style="font-size: 12pt; font-family: times new roman,new york,times,serif;">But 
  how the separation of VLAN ID space would help in this case? If PBB packets 
  are leaked into PBB-TE they will be immediately dropped because there will be 
  no PBB-TE connections configured for such packets. If PBB-TE packets are 
  leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the 
  packets will be flooded across the PBB domain.&nbsp;<span class="067382706-10042008"><font color="#0000ff" face="Arial" size="2">&nbsp;</font></span></div>
  <div style="font-size: 12pt; font-family: times new roman,new york,times,serif;"><span class="067382706-10042008"><font color="#0000ff" face="Arial" size="2"></font></span>&nbsp;</div></div></blockquote>
<div style="font-size: 12pt; font-family: times new roman,new york,times,serif;"><span class="067382706-10042008"><font color="#0000ff" face="Arial" size="2">Unfortunately, 
leaking from PBB to PBB-TE does not necessarily means immediate discarding of 
PBB frames.&nbsp;Due to the VLAN separation between PBB and PBB-TE, there is no 
clear layering here. Hence leaking can essentially mean that the VID of&nbsp;a 
bridged (PBB) frame is changed to a VID used for&nbsp;explicitly 
routed&nbsp;connections (PBB-TE). This does not necessarily means that the frame 
will be dropped. It is a valid assumption that the MAC address of the PBB frame 
is configured in the PBB-TE region as well and as such leakig PBB traffic will 
be forwarded as if it would belong to&nbsp;an explicitly routed connection.<br><br>IB&gt;&gt; In order for a packet, leaking from PBB to PBB_TE not be dropped, it is necessary for the triplet from PBB MAC header (SA-DA-VID) to match one of configured on the node PBB-TE connections. Even if one assumes that this is possible, it is highly unlikely to be the case on the next along the connection PBB-TE node. Hence the packet will be dropped either immediately or on the next PBB-TE node.<br><br>Cheers,<br>Igor </font></span><span class="067382706-10042008"></span></div>
<blockquote style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
  <div style="font-size: 12pt; font-family: times new roman,new york,times,serif;">Note 
  that what I just wrote is true regardless whether PBB-TE uses specially 
  allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural 
  need for the VLANID space separation.<br><span class="067382706-10042008"><font color="#0000ff" face="Arial" size="2">&nbsp;</font></span><span class="067382706-10042008">&nbsp;</span></div></blockquote>
<div style="font-size: 12pt; font-family: times new roman,new york,times,serif;"><span class="067382706-10042008"><font color="#0000ff" face="Arial" size="2">I think this is 
not necessary true, if one allocates the whole VLAN space to PBB-TE then there 
will be no bridged traffic in the network. As a consequence no leaking and no 
other cross effects is to be expected.</font></span></div>
<div style="font-size: 12pt; font-family: times new roman,new york,times,serif;"><span class="067382706-10042008"><font color="#0000ff" face="Arial" size="2"></font></span>&nbsp;</div>
<div style="font-size: 12pt; font-family: times new roman,new york,times,serif;"><span class="067382706-10042008"><font color="#0000ff" face="Arial" size="2">Best 
regards,</font></span></div>
<div style="font-size: 12pt; font-family: times new roman,new york,times,serif;"><span class="067382706-10042008"><font color="#0000ff" face="Arial" size="2">Attila</font></span></div></div><br></div></div><br>__________________________________________________<br>Do You Yahoo!?<br>Tired of spam?  Yahoo! Mail has the best spam protection around <br>http://mail.yahoo.com </body></html>
--0-608773676-1207840389=:46599--

Delivery-date: Thu, 10 Apr 2008 08:46:08 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds
Date: Thu, 10 Apr 2008 09:43:02 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C89AE7.032223C2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Agreed Attila.....let's not get this out of proportion......the key
thing is to understand that we are dealing with different layer networks
in PBB (cl-ps) and PBB-TE (co-ps) networks and getting this right is
then largely a matter of good design and implementation.  If we want to
throw stones at the underlying arch issue I can think of another
technology close to home that provides a far richer set of problems in
this respect ;-)
=20
regards, Neil

-----Original Message-----
From: Attila Takacs [mailto:[email-masked]]=20
Sent: 10 April 2008 07:55
To: Nurit Sprecher; ext Don Fedyk; Harrison,N,Neil,DMF R;
[email-masked]; [email-masked]; [email-masked]
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

Hi all,
=20
I do agree that a clear/single network operation mode is desirable in
practice, however, as Nurit pointed out, IEEE 802.1Qay is more
permissive in this regard.=20
However, if every VLAN is allocated for PBB-TE, which is a valid
configuration in 802.1Qay, then the network will operate in a clear
co-ps mode without side effects due to parallel PBB operation.
=20
On the other hand, I can imagine that in some cases having a PBB bridged
VLAN used, e.g.,to create connectivity for control traffic, would be
desirable and I do not see a problem with this until it does not carry
customer traffic.
=20
I think we do not need to do anything in here; the level of permitted
coexistence of PBB and PBB-TE is a network operational issue, and it
does not really affect the GMPLS extensions much more than probably
adding support to ensure that the VLANs configured for PBB-TE are the
same throughout the network.
=20
Best regards,
Attila
=20

  _____ =20

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Nurit Sprecher
Sent: Wednesday, April 09, 2008 10:02 PM
To: ext Don Fedyk; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

Hi all,

So maybe this is something to be commented to the IEEE........they
operate hybrid PBB/PBB-TE networks.=20

In this draft we provide a control plane to the dataplane that is
defined by the IEEE, and specifically we define a control plane for
PBB-TE as defined by the IEEE 802.1Qay.=20

Nurit

=20

  _____ =20

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Don Fedyk
Sent: Wednesday, April 09, 2008 17:38
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

=20

Hi Igor and Neil

=20

See below,

IB>> I agree with what you are saying. What confuses me, though, is that
802.1ay prescribes allocating of certain range(s) of VLANIDs for the
PBB-TE use, while allowing use of other VLANIDs for their native
Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs
are available for the PBB-TE use. If what you are saying is correct
(which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say,
PBB) are completely separate layer network, than VLANIDs are not shared
between the two.=20

What am I missing here?

Thanks,
Igor=20

=20

NH=3D> Excellent question.  I have made exactly this same observation in
the past.  In principle there is no reason why you cannot re-use all the
codepoints of each/every field in the traffic unit because, as stated,
although the traffic units look identical they do belong to quite
different layer networks.  I think there are 2 reasons for this:

=20

-    Firstly, most IEEE folks are not familiar with, and therefore do
not use, functional architecture techniques to describe layer networks.
So this issue may not be so obvious to many folks in IEEE.  Further,
when we have QinQ techniques these are a form of sublayering (like we
find in nested LSPs in MPLS) and so we don't have distinct layer
networks here......and although folks may not describe it as such they
do recognise that one of the consequences of this (ie still a single
layer network) is that it affects scaling.  However, once we have the
.1ah stuff and MACinMAC (ie true client/server) then everyone
intuitively recognises we have quite disjoint layer networks.  So what I
am saying here is that for folks who don't have a strong background in
functional architecture, the observation you have made may not be so
obvious even though it is architecturally true.

=20

-    Secondly, there could be practical/implementation reasons for doing
this (ie creating a split in VID codepoints) when dealing with COTS
Ethernet hardware.  Maybe some of the Ethernet hardware experts can
provide further clarification here.  =20

=20

Disclaimer I'm not a hardware expert but Neil is correct there is
currently no "context" within an Ethernet Frame that could separate the
PBB B-VID space and the PBB-TE B-VID space. If  these spaces used
overlapping B-VID values there would be know way to know by looking at
the Frame.  In fact one of the attractions of PBB-TE is that it can
reuse the existing forwarding HW because it essentially forwards on
(B-VID+MAC DA).  A result is a switch cannot tell the context
implicitly.=20

One thing this does provide however is a clear way to 'know' when
looking at a traffic unit in isolation exactly which layer network it
belongs to.=20

=20

Between the PBB B-MAC (server) and the PBB C-MAC  (client) it is clear
looking at a frame.   Between PBB and PBB-TE the B-VID space
partitioning in the management (and control plane) is the only thing
that separates the behavior. =20

=20

Regards,

Don=20

=20

regards, Neil

------_=_NextPart_001_01C89AE7.032223C2
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2769" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"PersonName"></o:SmartTagType><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: Comic Sans MS;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 1.0in 1.25in 1.0in =
1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV>
<DIV><SPAN class=3D646082608-10042008><FONT face=3D"Comic Sans MS"><FONT =

color=3D#800000><FONT size=3D2>Agreed<SPAN class=3D288583908-10042008>=20
Attila</SPAN>.....let's not get this out of proportion......the key =
thing is to=20
understand that we are dealing with different layer networks in PBB =
(cl-ps) and=20
PBB-TE (co-ps) networks and getting this right is then largely a matter =
of good=20
design and implementation.&nbsp; If we want to throw stones at th<SPAN=20
class=3D288583908-10042008>e underlying arch issue </SPAN>I can think of =
another=20
technology close to home that&nbsp;<SPAN =
class=3D288583908-10042008>provides a far=20
richer set of </SPAN>problems in this respect<SPAN =
class=3D288583908-10042008>=20
;-)</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D646082608-10042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D646082608-10042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></DIV></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Attila Takacs=20
  [mailto:[email-masked]] <BR><B>Sent:</B> 10 April 2008=20
  07:55<BR><B>To:</B> Nurit Sprecher; ext Don Fedyk; Harrison,N,Neil,DMF =
R;=20
  [email-masked]; [email-masked];=20
  [email-masked]<BR><B>Subject:</B> RE: Continued Poll for Adoption =
of=20
  Ethernet I-Ds<BR><BR></FONT></DIV>
  <DIV>
  <DIV><SPAN class=3D192262106-10042008><FONT face=3DArial =
color=3D#0000ff size=3D2>Hi=20
  all,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D192262106-10042008><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D192262106-10042008><FONT face=3DArial =
color=3D#0000ff size=3D2>I do=20
  agree that a clear/single network operation mode is desirable in =
practice,=20
  however, as Nurit pointed out, IEEE 802.1Qay is more =
permissive&nbsp;i<SPAN=20
  class=3D770074106-10042008>n</SPAN> this regard. </FONT></SPAN></DIV>
  <DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN class=3D770074106-10042008>However, if every VLAN is =
allocated for=20
  PBB-TE, which is a valid configuration in 802.1Qay,&nbsp;then the =
network will=20
  operate in a clear co-ps mode without side effects due to parallel PBB =

  operation.</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN=20
  =
class=3D770074106-10042008></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
  <DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN class=3D770074106-10042008>On the other hand, I can =
imagine that in=20
  some cases having a PBB bridged VLAN used, e.g.,to create connectivity =
for=20
  control traffic, would be desirable and I do not see a =
problem&nbsp;with this=20
  until it does not carry customer=20
  traffic.</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN=20
  =
class=3D770074106-10042008></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
  <DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN class=3D770074106-10042008>I think we do not need to do =
anything in=20
  here; the level of permitted coexistence of PBB and PBB-TE is a =
network=20
  operational issue, and it does not really affect the GMPLS extensions =
much=20
  more than probably adding support to ensure that the VLANs configured =
for=20
  PBB-TE are the same throughout the=20
  network.</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN=20
  =
class=3D770074106-10042008></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
  <DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN class=3D770074106-10042008>Best=20
  regards,</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN=20
  =
class=3D770074106-10042008>Attila</SPAN></FONT></FONT></FONT></SPAN></DIV=
  <DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN=20
  =
class=3D770074106-10042008></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
></DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
    [mailto:[email-masked]] <B>On Behalf Of </B>Nurit=20
    Sprecher<BR><B>Sent:</B> Wednesday, April 09, 2008 10:02 =
PM<BR><B>To:</B>=20
    ext Don Fedyk; [email-masked]; [email-masked];=20
    [email-masked]; [email-masked]<BR><B>Subject:</B> RE: =
Continued=20
    Poll for Adoption of Ethernet I-Ds<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV class=3DSection1 dir=3Drtl>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
    all,<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">So maybe =
this is=20
    something to be commented to the IEEE&#8230;&#8230;..they operate =
hybrid PBB/PBB-TE=20
    networks. <o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">In this =
draft we=20
    provide a control plane to the dataplane that is defined by the =
IEEE, and=20
    specifically we define a control plane for PBB-TE as defined by the =
IEEE=20
    802.1Qay. <o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Nurit<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <DIV>
    <DIV class=3DMsoNormal dir=3Dltr style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
    <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
    </SPAN></FONT></DIV>
    <P class=3DMsoNormal dir=3Dltr><B><FONT face=3DTahoma size=3D2><SPAN =

    style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
    face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
    owner-<st1:PersonName=20
    style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
    tabIndex=3D0 w:st=3D"on">[email-masked]</st1:PersonName>=20
    [mailto:owner-<st1:PersonName=20
    style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
    tabIndex=3D0 w:st=3D"on">[email-masked]</st1:PersonName>] =
<B><SPAN=20
    style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>ext Don =
Fedyk<BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Wednesday, April 09, =
2008=20
    17:38<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
    [email-masked]; [email-masked]; [email-masked];=20
    <st1:PersonName=20
    style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
    tabIndex=3D0 =
w:st=3D"on">[email-masked]</st1:PersonName><BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: Continued Poll =
for=20
    Adoption of Ethernet I-Ds</SPAN></FONT><o:p></o:p></P></DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi Igor =
and=20
    Neil</SPAN></FONT><o:p></o:p></P>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">See=20
    below,</SPAN></FONT><o:p></o:p></P>
    <BLOCKQUOTE=20
    style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: =
medium none">
      <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><BR>IB&gt;&gt; I agree with what you are =
saying.=20
      What confuses me, though, is that 802.1ay prescribes allocating of =
certain=20
      range(s) of VLANIDs for the PBB-TE use, while allowing use of =
other=20
      VLANIDs for their native Ethernet purposes. I wonder why is that? =
Why not=20
      to say that all VLANIDs are available for the PBB-TE use. If what =
you are=20
      saying is correct (which, again, I believe you are), that is, =
PBB-TE and=20
      non-PBB-TE (say, PBB) are completely separate layer network, than =
VLANIDs=20
      are not shared between the two. <BR><BR>What am I missing=20
      here?<BR><BR>Thanks,<BR>Igor</SPAN></FONT><FONT face=3D"Comic Sans =
MS"=20
      color=3Dmaroon size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">&nbsp;</SPAN></FONT><o:p></o:p></P>
      <DIV>
      <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Comic Sans MS" =
color=3Dmaroon=20
      size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">NH=3D&gt;=20
      Excellent question.&nbsp; I have made exactly this same =
observation in the=20
      past.&nbsp; In principle there is no reason why you cannot re-use =
all the=20
      codepoints of each/every field in the traffic unit because, as =
stated,=20
      although the traffic units look identical they do belong to quite=20
      different layer networks.&nbsp; I think there are 2 reasons for=20
      this:</SPAN></FONT><o:p></o:p></P></DIV>
      <DIV>
      <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Comic Sans MS" =
color=3Dmaroon=20
      size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">-&nbsp;&nbsp;&nbsp;=20
      Firstly, most IEEE folks are not familiar with, and therefore do =
not use,=20
      functional architecture techniques to describe layer =
networks.&nbsp; So=20
      this issue may not be so obvious to many folks in IEEE.&nbsp; =
Further,=20
      when we have QinQ techniques these are a form of sublayering (like =
we find=20
      in nested LSPs in MPLS) and so we don't have distinct layer =
networks=20
      here......and although folks may not describe it as such they do =
recognise=20
      that one of the consequences of this (ie still a single layer =
network) is=20
      that it affects scaling.&nbsp; However, once we have the .1ah =
stuff and=20
      MACinMAC (ie true client/server) then everyone intuitively =
recognises we=20
      have quite disjoint layer networks.&nbsp; So what I am saying here =
is that=20
      for folks who don't have a strong background in functional =
architecture,=20
      the observation you have made may not be so obvious even though it =
is=20
      architecturally true.</SPAN></FONT><o:p></o:p></P></DIV>
      <DIV>
      <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Comic Sans MS" =
color=3Dmaroon=20
      size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">-&nbsp;&nbsp;&nbsp;=20
      Secondly, there could be practical/implementation reasons for =
doing this=20
      (ie creating a split in VID codepoints) when dealing with COTS =
Ethernet=20
      hardware.&nbsp; Maybe some of the Ethernet hardware experts can =
provide=20
      further clarification here.&nbsp;&nbsp;</SPAN></FONT><FONT =
face=3DArial=20
      color=3Dblue size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">&nbsp;</SPAN></FONT><o:p></o:p></P></DIV>
      <DIV>
      <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE>
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Disclaimer I'm not=20
    a hardware expert but Neil is correct there is currently no =
"context" within=20
    an Ethernet Frame that could separate the PBB B-VID space and the =
PBB-TE=20
    B-VID space. If&nbsp; these spaces used overlapping B-VID values =
there would=20
    be know way to know by looking at the Frame.&nbsp; In fact one of =
the=20
    attractions of PBB-TE is that it can reuse the existing forwarding =
HW=20
    because it essentially forwards on (B-VID+MAC DA).&nbsp;&nbsp;A =
result=20
    is&nbsp;a switch cannot tell the context implicitly.=20
    </SPAN></FONT><o:p></o:p></P></DIV>
    <BLOCKQUOTE=20
    style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: =
medium none">
      <DIV>
      <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Comic Sans MS" =
color=3Dmaroon=20
      size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">One=20
      thing this does provide however is a clear way to 'know' when =
looking at a=20
      traffic unit in isolation exactly which layer network it belongs=20
      to.</SPAN></FONT><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">&nbsp;</SPAN></FONT><o:p></o:p></P></DIV>
      <DIV>
      <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE>
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Between =
the PBB=20
    B-MAC (server) and the PBB C-MAC </SPAN></FONT><FONT face=3D"Comic =
Sans MS"=20
    color=3Dmaroon size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">&nbsp;</SPAN></FONT><FONT=20
    face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">(client) =
it is=20
    clear looking at a frame.&nbsp;&nbsp; Between PBB and PBB-TE the =
B-VID space=20
    partitioning in the management (and control plane) is the only thing =
that=20
    separates the behavior.&nbsp; </SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Regards,</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Don=20
    </SPAN></FONT><o:p></o:p></P></DIV>
    <BLOCKQUOTE=20
    style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: =
medium none">
      <DIV>
      <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Comic Sans MS" =
color=3Dmaroon=20
      size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">regards,=20
      =
Neil</SPAN></FONT><o:p></o:p></P></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE></=
BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C89AE7.032223C2--

Delivery-date: Thu, 10 Apr 2008 07:01:43 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-03.txt 
Date: Thu, 10 Apr 2008 00:00:02 -0700 (PDT)

--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           : OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
	Author(s)       : M. Chen, R. Zhang
	Filename        : draft-ietf-ccamp-ospf-interas-te-extension-03.txt
	Pages           : 18
	Date            : 2008-04-09

This document describes extensions to the OSPF version 2 and 3 
protocols to support Multiprotocol Label Switching (MPLS) and 
Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple 
Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined 
for the flooding of TE information about inter-AS links which can be 
used to perform inter-AS TE path computation. 

 
 No support for flooding TE information from outside the AS is 
proposed or defined in this document. 

Conventions used in this document 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC-2119 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-ccamp-ospf-interas-te-extension-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Thu, 10 Apr 2008 07:01:33 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-isis-interas-te-extension-01.txt 
Date: Thu, 10 Apr 2008 00:00:02 -0700 (PDT)

--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           : ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
	Author(s)       : M. Chen, R. Zhang
	Filename        : draft-ietf-ccamp-isis-interas-te-extension-01.txt
	Pages           : 19
	Date            : 2008-04-09

This document describes extensions to the ISIS (ISIS) protocol to 
support Multiprotocol Label Switching (MPLS) and Generalized MPLS 
(GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems 
(ASes). It defines ISIS-TE extensions for the flooding of TE 
information about inter-AS links which can be used to perform inter-
AS TE path computation. 

 
 No support for flooding TE information from outside the AS is 
proposed or defined in this document. 

Conventions used in this document 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC-2119 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-ccamp-isis-interas-te-extension-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Delivery-date: Thu, 10 Apr 2008 06:57:02 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds
Date: Thu, 10 Apr 2008 08:54:21 +0200
From: "Attila Takacs" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Don Fedyk" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C89AD7.B41BBF70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Igor,
=20

	But how the separation of VLAN ID space would help in this case?
If PBB packets are leaked into PBB-TE they will be immediately dropped
because there will be no PBB-TE connections configured for such packets.
If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing
about PBB-TE anyway the packets will be flooded across the PBB domain. =20
	=20

Unfortunately, leaking from PBB to PBB-TE does not necessarily means
immediate discarding of PBB frames. Due to the VLAN separation between
PBB and PBB-TE, there is no clear layering here. Hence leaking can
essentially mean that the VID of a bridged (PBB) frame is changed to a
VID used for explicitly routed connections (PBB-TE). This does not
necessarily means that the frame will be dropped. It is a valid
assumption that the MAC address of the PBB frame is configured in the
PBB-TE region as well and as such leakig PBB traffic will be forwarded
as if it would belong to an explicitly routed connection.=20

	Note that what I just wrote is true regardless whether PBB-TE
uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there
is no architectural need for the VLANID space separation.
	 =20

I think this is not necessary true, if one allocates the whole VLAN
space to PBB-TE then there will be no bridged traffic in the network. As
a consequence no leaking and no other cross effects is to be expected.
=20
Best regards,
Attila

------_=_NextPart_001_01C89AD7.B41BBF70
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE type=3Dtext/css>DIV {
	MARGIN: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2800.1589" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D067382706-10042008><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Igor,</FONT></SPAN></DIV>
<DIV><SPAN class=3D067382706-10042008><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, =
times, serif">
  <DIV=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif">But=20
  how the separation of VLAN ID space would help in this case? If PBB =
packets=20
  are leaked into PBB-TE they will be immediately dropped because there =
will be=20
  no PBB-TE connections configured for such packets. If PBB-TE packets =
are=20
  leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway =
the=20
  packets will be flooded across the PBB domain.&nbsp;<SPAN=20
  class=3D067382706-10042008><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif"><SPAN=20
  class=3D067382706-10042008><FONT face=3DArial color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV></DIV></BLOCKQUOTE>
<DIV=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif"><SPAN=20
class=3D067382706-10042008><FONT face=3DArial color=3D#0000ff =
size=3D2>Unfortunately,=20
leaking from PBB to PBB-TE does not necessarily means immediate =
discarding of=20
PBB frames.&nbsp;Due to the VLAN separation between PBB and PBB-TE, =
there is no=20
clear layering here. Hence leaking can essentially mean that the VID =
of&nbsp;a=20
bridged (PBB) frame is changed to a VID used for&nbsp;explicitly=20
routed&nbsp;connections (PBB-TE). This does not necessarily means that =
the frame=20
will be dropped. It is a valid assumption that the MAC address of the =
PBB frame=20
is configured in the PBB-TE region as well and as such leakig PBB =
traffic will=20
be forwarded as if it would belong to&nbsp;an explicitly routed =
connection.=20
</FONT></SPAN><SPAN class=3D067382706-10042008><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif">Note=20
  that what I just wrote is true regardless whether PBB-TE uses =
specially=20
  allocated ranges of VLANIDs or all VLANIDs. Hence there is no =
architectural=20
  need for the VLANID space separation.<BR><SPAN =
class=3D067382706-10042008><FONT=20
  face=3DArial color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN><SPAN=20
  class=3D067382706-10042008>&nbsp;</SPAN></DIV></BLOCKQUOTE>
<DIV=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif"><SPAN=20
class=3D067382706-10042008><FONT face=3DArial color=3D#0000ff size=3D2>I =
think this is=20
not necessary true, if one allocates the whole VLAN space to PBB-TE then =
there=20
will be no bridged traffic in the network. As a consequence no leaking =
and no=20
other cross effects is to be expected.</FONT></SPAN></DIV>
<DIV=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif"><SPAN=20
class=3D067382706-10042008><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif"><SPAN=20
class=3D067382706-10042008><FONT face=3DArial color=3D#0000ff =
size=3D2>Best=20
regards,</FONT></SPAN></DIV>
<DIV=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif"><SPAN=20
class=3D067382706-10042008><FONT face=3DArial color=3D#0000ff=20
size=3D2>Attila</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C89AD7.B41BBF70--

Delivery-date: Thu, 10 Apr 2008 06:57:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds
Date: Thu, 10 Apr 2008 08:54:47 +0200
From: "Attila Takacs" <[email-masked]>
To: "Nurit Sprecher" <[email-masked]>, "ext Don Fedyk" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C89AD7.C4196512
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,
=20
I do agree that a clear/single network operation mode is desirable in
practice, however, as Nurit pointed out, IEEE 802.1Qay is more
permissive in this regard.=20
However, if every VLAN is allocated for PBB-TE, which is a valid
configuration in 802.1Qay, then the network will operate in a clear
co-ps mode without side effects due to parallel PBB operation.
=20
On the other hand, I can imagine that in some cases having a PBB bridged
VLAN used, e.g.,to create connectivity for control traffic, would be
desirable and I do not see a problem with this until it does not carry
customer traffic.
=20
I think we do not need to do anything in here; the level of permitted
coexistence of PBB and PBB-TE is a network operational issue, and it
does not really affect the GMPLS extensions much more than probably
adding support to ensure that the VLANs configured for PBB-TE are the
same throughout the network.
=20
Best regards,
Attila
=20

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Nurit Sprecher
	Sent: Wednesday, April 09, 2008 10:02 PM
	To: ext Don Fedyk; [email-masked]; [email-masked];
[email-masked]; [email-masked]
	Subject: RE: Continued Poll for Adoption of Ethernet I-Ds
=09
=09

	Hi all,

	So maybe this is something to be commented to the
IEEE........they operate hybrid PBB/PBB-TE networks.=20

	In this draft we provide a control plane to the dataplane that
is defined by the IEEE, and specifically we define a control plane for
PBB-TE as defined by the IEEE 802.1Qay.=20

	Nurit

	=20

=09
________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Don Fedyk
	Sent: Wednesday, April 09, 2008 17:38
	To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
	Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

	=20

	Hi Igor and Neil

	=20

	See below,

	=09
		IB>> I agree with what you are saying. What confuses me,
though, is that 802.1ay prescribes allocating of certain range(s) of
VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for
their native Ethernet purposes. I wonder why is that? Why not to say
that all VLANIDs are available for the PBB-TE use. If what you are
saying is correct (which, again, I believe you are), that is, PBB-TE and
non-PBB-TE (say, PBB) are completely separate layer network, than
VLANIDs are not shared between the two.=20
	=09
		What am I missing here?
	=09
		Thanks,
		Igor=20

		=20

		NH=3D> Excellent question.  I have made exactly this same
observation in the past.  In principle there is no reason why you cannot
re-use all the codepoints of each/every field in the traffic unit
because, as stated, although the traffic units look identical they do
belong to quite different layer networks.  I think there are 2 reasons
for this:

		=20

		-    Firstly, most IEEE folks are not familiar with, and
therefore do not use, functional architecture techniques to describe
layer networks.  So this issue may not be so obvious to many folks in
IEEE.  Further, when we have QinQ techniques these are a form of
sublayering (like we find in nested LSPs in MPLS) and so we don't have
distinct layer networks here......and although folks may not describe it
as such they do recognise that one of the consequences of this (ie still
a single layer network) is that it affects scaling.  However, once we
have the .1ah stuff and MACinMAC (ie true client/server) then everyone
intuitively recognises we have quite disjoint layer networks.  So what I
am saying here is that for folks who don't have a strong background in
functional architecture, the observation you have made may not be so
obvious even though it is architecturally true.

		=20

		-    Secondly, there could be practical/implementation
reasons for doing this (ie creating a split in VID codepoints) when
dealing with COTS Ethernet hardware.  Maybe some of the Ethernet
hardware experts can provide further clarification here.  =20

		=20

	Disclaimer I'm not a hardware expert but Neil is correct there
is currently no "context" within an Ethernet Frame that could separate
the PBB B-VID space and the PBB-TE B-VID space. If  these spaces used
overlapping B-VID values there would be know way to know by looking at
the Frame.  In fact one of the attractions of PBB-TE is that it can
reuse the existing forwarding HW because it essentially forwards on
(B-VID+MAC DA).  A result is a switch cannot tell the context
implicitly.=20

		One thing this does provide however is a clear way to
'know' when looking at a traffic unit in isolation exactly which layer
network it belongs to.=20

		=20

	Between the PBB B-MAC (server) and the PBB C-MAC  (client) it is
clear looking at a frame.   Between PBB and PBB-TE the B-VID space
partitioning in the management (and control plane) is the only thing
that separates the behavior. =20

	=20

	Regards,

	Don=20

		=20

		regards, Neil

------_=_NextPart_001_01C89AD7.C4196512
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>Message</TITLE>=

<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1589" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: Comic Sans MS;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 1.0in 1.25in 1.0in =
1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV>
<DIV><SPAN class=3D192262106-10042008><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
all,</FONT></SPAN></DIV>
<DIV><SPAN class=3D192262106-10042008><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D192262106-10042008><FONT face=3DArial color=3D#0000ff =
size=3D2>I do=20
agree that a clear/single network operation mode is desirable in =
practice,=20
however, as Nurit pointed out, IEEE 802.1Qay is more =
permissive&nbsp;i<SPAN=20
class=3D770074106-10042008>n</SPAN> this regard. </FONT></SPAN></DIV>
<DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN class=3D770074106-10042008>However, if every VLAN is =
allocated for=20
PBB-TE, which is a valid configuration in 802.1Qay,&nbsp;then the =
network will=20
operate in a clear co-ps mode without side effects due to parallel PBB=20
operation.</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN=20
class=3D770074106-10042008></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
<DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN class=3D770074106-10042008>On the other hand, I can =
imagine that in=20
some cases having a PBB bridged VLAN used, e.g.,to create connectivity =
for=20
control traffic, would be desirable and I do not see a problem&nbsp;with =
this=20
until it does not carry customer=20
traffic.</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN=20
class=3D770074106-10042008></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
<DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN class=3D770074106-10042008>I think we do not need to do =
anything in=20
here; the level of permitted coexistence of PBB and PBB-TE is a network=20
operational issue, and it does not really affect the GMPLS extensions =
much more=20
than probably adding support to ensure that the VLANs configured for =
PBB-TE are=20
the same throughout the =
network.</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN=20
class=3D770074106-10042008></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
<DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN class=3D770074106-10042008>Best=20
regards,</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN=20
class=3D770074106-10042008>Attila</SPAN></FONT></FONT></FONT></SPAN></DIV=
<DIV><SPAN class=3D192262106-10042008><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN=20
class=3D770074106-10042008></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Nurit=20
  Sprecher<BR><B>Sent:</B> Wednesday, April 09, 2008 10:02 =
PM<BR><B>To:</B> ext=20
  Don Fedyk; [email-masked]; [email-masked]; =
[email-masked];=20
  [email-masked]<BR><B>Subject:</B> RE: Continued Poll for Adoption =
of=20
  Ethernet I-Ds<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1 dir=3Drtl>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
  all,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">So maybe =
this is=20
  something to be commented to the IEEE&#8230;&#8230;..they operate =
hybrid PBB/PBB-TE=20
  networks. <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">In this =
draft we=20
  provide a control plane to the dataplane that is defined by the IEEE, =
and=20
  specifically we define a control plane for PBB-TE as defined by the =
IEEE=20
  802.1Qay. <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Nurit<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal dir=3Dltr style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal dir=3Dltr><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
  owner-<st1:PersonName=20
  style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
  tabIndex=3D0 w:st=3D"on">[email-masked]</st1:PersonName>=20
  [mailto:owner-<st1:PersonName=20
  style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
  tabIndex=3D0 w:st=3D"on">[email-masked]</st1:PersonName>] <B><SPAN =

  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>ext Don =
Fedyk<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Wednesday, April 09, 2008 =

  17:38<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
  [email-masked]; [email-masked]; [email-masked];=20
  <st1:PersonName=20
  style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
  tabIndex=3D0 =
w:st=3D"on">[email-masked]</st1:PersonName><BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: Continued Poll for =
Adoption=20
  of Ethernet I-Ds</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi Igor and =

  Neil</SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">See=20
  below,</SPAN></FONT><o:p></o:p></P>
  <BLOCKQUOTE=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: =
medium none">
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><BR>IB&gt;&gt; I agree with what you are =
saying.=20
    What confuses me, though, is that 802.1ay prescribes allocating of =
certain=20
    range(s) of VLANIDs for the PBB-TE use, while allowing use of other =
VLANIDs=20
    for their native Ethernet purposes. I wonder why is that? Why not to =
say=20
    that all VLANIDs are available for the PBB-TE use. If what you are =
saying is=20
    correct (which, again, I believe you are), that is, PBB-TE and =
non-PBB-TE=20
    (say, PBB) are completely separate layer network, than VLANIDs are =
not=20
    shared between the two. <BR><BR>What am I missing=20
    here?<BR><BR>Thanks,<BR>Igor</SPAN></FONT><FONT face=3D"Comic Sans =
MS"=20
    color=3Dmaroon size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">&nbsp;</SPAN></FONT><o:p></o:p></P>
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Comic Sans MS" =
color=3Dmaroon=20
    size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">NH=3D&gt;=20
    Excellent question.&nbsp; I have made exactly this same observation =
in the=20
    past.&nbsp; In principle there is no reason why you cannot re-use =
all the=20
    codepoints of each/every field in the traffic unit because, as =
stated,=20
    although the traffic units look identical they do belong to quite =
different=20
    layer networks.&nbsp; I think there are 2 reasons for=20
    this:</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Comic Sans MS" =
color=3Dmaroon=20
    size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">-&nbsp;&nbsp;&nbsp;=20
    Firstly, most IEEE folks are not familiar with, and therefore do not =
use,=20
    functional architecture techniques to describe layer networks.&nbsp; =
So this=20
    issue may not be so obvious to many folks in IEEE.&nbsp; Further, =
when we=20
    have QinQ techniques these are a form of sublayering (like we find =
in nested=20
    LSPs in MPLS) and so we don't have distinct layer networks =
here......and=20
    although folks may not describe it as such they do recognise that =
one of the=20
    consequences of this (ie still a single layer network) is that it =
affects=20
    scaling.&nbsp; However, once we have the .1ah stuff and MACinMAC (ie =
true=20
    client/server) then everyone intuitively recognises we have quite =
disjoint=20
    layer networks.&nbsp; So what I am saying here is that for folks who =
don't=20
    have a strong background in functional architecture, the observation =
you=20
    have made may not be so obvious even though it is architecturally=20
    true.</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Comic Sans MS" =
color=3Dmaroon=20
    size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">-&nbsp;&nbsp;&nbsp;=20
    Secondly, there could be practical/implementation reasons for doing =
this (ie=20
    creating a split in VID codepoints) when dealing with COTS Ethernet=20
    hardware.&nbsp; Maybe some of the Ethernet hardware experts can =
provide=20
    further clarification here.&nbsp;&nbsp;</SPAN></FONT><FONT =
face=3DArial=20
    color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">&nbsp;</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE>
  <DIV>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Disclaimer =
I'm not a=20
  hardware expert but Neil is correct there is currently no "context" =
within an=20
  Ethernet Frame that could separate the PBB B-VID space and the PBB-TE =
B-VID=20
  space. If&nbsp; these spaces used overlapping B-VID values there would =
be know=20
  way to know by looking at the Frame.&nbsp; In fact one of the =
attractions of=20
  PBB-TE is that it can reuse the existing forwarding HW because it =
essentially=20
  forwards on (B-VID+MAC DA).&nbsp;&nbsp;A result is&nbsp;a switch =
cannot tell=20
  the context implicitly. </SPAN></FONT><o:p></o:p></P></DIV>
  <BLOCKQUOTE=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: =
medium none">
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Comic Sans MS" =
color=3Dmaroon=20
    size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">One=20
    thing this does provide however is a clear way to 'know' when =
looking at a=20
    traffic unit in isolation exactly which layer network it belongs=20
    to.</SPAN></FONT><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">&nbsp;</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE>
  <DIV>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Between the =
PBB B-MAC=20
  (server) and the PBB C-MAC </SPAN></FONT><FONT face=3D"Comic Sans MS"=20
  color=3Dmaroon size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">&nbsp;</SPAN></FONT><FONT=20
  face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">(client) it =
is clear=20
  looking at a frame.&nbsp;&nbsp; Between PBB and PBB-TE the B-VID space =

  partitioning in the management (and control plane) is the only thing =
that=20
  separates the behavior.&nbsp; </SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Regards,</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Don=20
  </SPAN></FONT><o:p></o:p></P></DIV>
  <BLOCKQUOTE=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: =
medium none">
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal dir=3Dltr><FONT face=3D"Comic Sans MS" =
color=3Dmaroon=20
    size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">regards,=20
    =
Neil</SPAN></FONT><o:p></o:p></P></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE></=
BODY></HTML>

------_=_NextPart_001_01C89AD7.C4196512--

Delivery-date: Thu, 10 Apr 2008 01:33:41 +0000
Date: Thu, 10 Apr 2008 09:31:06 +0800
From: Mach Chen <[email-masked]>
Subject: Re: Last call complete on Advertisement of inter-AS TE links
To: Adrian Farrel <[email-masked]>
Cc: CCAMP List <[email-masked]>
Organization: Huawei

Hi Adrian and all,

Thanks for the review and comment.

I will update and resubmit the I-Ds ASAP.

Best regards,			
Mach Chen
  
On 2008-04-10, at 00:06:32 Adrian Farrel wrote:

>Hi,
>
>The last call completed. Given the high level of review and discussion in 
>the past and the relatively small size of the I-Ds, I'm not surprised that 
>we only got a couple of comments during last call.
>
>Mach, can you make the changes to the I-D to satisfy Acee's comments on the 
>OSPF draft, and check to see if there is any similar language in the IS-IS 
>draft? One point...
>
>Where he suggests alternative text for "TE Router ID", I think this is fine, 
>but it would be helpful if you retained "TE Router ID" in brackets to give 
>the extra information.
>
>Thanks,
>Adrian
>----- Original Message ----- 
>From: "Acee Lindem" <[email-masked]>
>To: "Adrian Farrel" <[email-masked]>
>Cc: "OSPF List" <[email-masked]>; "CCAMP List" <[email-masked]>
>Sent: Friday, April 04, 2008 3:46 PM
>Subject: Re: [OSPF] CCAMP last call on advertisement of inter-AS TE links
>
>
>>I can't speak for the OSPF WG as a whole, but I have reviewed the  subject 
>>document and am very happy to see that the suggestion to use  separate 
>>inter-AS LSA types has been incorporated. I have no further  technical 
>>comments on the document and trust that the ccamp WG has  verified that 
>>this information encoding meets the TE requirements.  The usage described 
>>in sections 2.2 and 2.3 seem reasonable to me.
>>
>> I have the following editorial comments:
>>
>>   1. Sections 3.3.2 and 3.3.2 - Both of these say "Use of the TE  Router 
>> ID is RECOMMENDED." I believe these should be respectively  replaced by 
>> "Use of the TE Router Address as specified in the Router  Address TLV 
>> [OSPF-TE] is RECOMMENDED." and "Use of the TE Router IPv6  Address as 
>> specified in the IPv6 Router Address as specified in the  IPv6 Router 
>> Address TLV [OSPF-V3-TE] is RECOMMENDED."
>>   2. Section 3.2.1 states "This is because... that may operate in a 
>> different address space;". If they are using a different address  space on 
>> the link between the ASes, then I'd expect there to be  problems with BGP 
>> as well :^) I'd suggest:
>>       "Given that OSPF is an IGP and should only be utilized between 
>> routers in the same routing domain, the OSPF specific Link ID and 
>> Neighbor ID sub-TLVs are not applicable to inter-AS links.".
>>   3. You may want to expand some acronyms on their first use. For 
>> example, "AS Boundary Router (ASBR)", "Link State Advertisement  (LSA)" 
>> and
>>      "Path Computation Element (PCE)".
>>   4. [OSPFV3] is listed to as both a Normative and Informative  reference.
>>
>> Thanks,
>> Acee
>>
>> On Mar 19, 2008, at 2:06 PM, Adrian Farrel wrote:
>>
>>> Hi,
>>>
>>> You may recall providing useful review and feedback on
>>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- 
>>> te-extension-02.txt
>>>
>>> The authors believe that they have taken on board all the comments 
>>> received
>>> from the OSPF working group and have updated the draft accordingly.
>>>
>>>
>>> CCAMP is holding a three week working group last call on this I-D  along 
>>> with
>>> its IS-IS partner document:
>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas- 
>>> te-extension-00.txt
>>>
>>> These documents describe how to advertise the TE links that connect  an 
>>> AS to
>>> the outside world within the AS's IGP. As the drafts are at pains  to 
>>> point
>>> out, there is no proposal to advertise the TE information more  widely 
>>> (such
>>> as to other ASes).
>>>
>>> The last call will end at 12 noon BST on April 9th 2008.
>>>
>>> Please send your comments to the CCAMP list or direct to the CCAMP 
>>> chairs.
>>>
>>> Thanks,
>>> Adrian and Deborah
>>>
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ospf
>>
>> 
>
>
>

Delivery-date: Wed, 09 Apr 2008 20:09:23 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds
Date: Wed, 9 Apr 2008 23:02:01 +0300
From: "Nurit Sprecher" <[email-masked]>
To: "ext Don Fedyk" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C89A7D.440F47C9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

So maybe this is something to be commented to the IEEE........they
operate hybrid PBB/PBB-TE networks.=20

In this draft we provide a control plane to the dataplane that is
defined by the IEEE, and specifically we define a control plane for
PBB-TE as defined by the IEEE 802.1Qay.=20

Nurit

=20

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Don Fedyk
Sent: Wednesday, April 09, 2008 17:38
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

=20

Hi Igor and Neil

=20

See below,

=09
	IB>> I agree with what you are saying. What confuses me, though,
is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for
the PBB-TE use, while allowing use of other VLANIDs for their native
Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs
are available for the PBB-TE use. If what you are saying is correct
(which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say,
PBB) are completely separate layer network, than VLANIDs are not shared
between the two.=20
=09
	What am I missing here?
=09
	Thanks,
	Igor=20

	=20

	NH=3D> Excellent question.  I have made exactly this same
observation in the past.  In principle there is no reason why you cannot
re-use all the codepoints of each/every field in the traffic unit
because, as stated, although the traffic units look identical they do
belong to quite different layer networks.  I think there are 2 reasons
for this:

	=20

	-    Firstly, most IEEE folks are not familiar with, and
therefore do not use, functional architecture techniques to describe
layer networks.  So this issue may not be so obvious to many folks in
IEEE.  Further, when we have QinQ techniques these are a form of
sublayering (like we find in nested LSPs in MPLS) and so we don't have
distinct layer networks here......and although folks may not describe it
as such they do recognise that one of the consequences of this (ie still
a single layer network) is that it affects scaling.  However, once we
have the .1ah stuff and MACinMAC (ie true client/server) then everyone
intuitively recognises we have quite disjoint layer networks.  So what I
am saying here is that for folks who don't have a strong background in
functional architecture, the observation you have made may not be so
obvious even though it is architecturally true.

	=20

	-    Secondly, there could be practical/implementation reasons
for doing this (ie creating a split in VID codepoints) when dealing with
COTS Ethernet hardware.  Maybe some of the Ethernet hardware experts can
provide further clarification here.  =20

	=20

Disclaimer I'm not a hardware expert but Neil is correct there is
currently no "context" within an Ethernet Frame that could separate the
PBB B-VID space and the PBB-TE B-VID space. If  these spaces used
overlapping B-VID values there would be know way to know by looking at
the Frame.  In fact one of the attractions of PBB-TE is that it can
reuse the existing forwarding HW because it essentially forwards on
(B-VID+MAC DA).  A result is a switch cannot tell the context
implicitly.=20

	One thing this does provide however is a clear way to 'know'
when looking at a traffic unit in isolation exactly which layer network
it belongs to.=20

	=20

Between the PBB B-MAC (server) and the PBB C-MAC  (client) it is clear
looking at a frame.   Between PBB and PBB-TE the B-VID space
partitioning in the management (and control plane) is the only thing
that separates the behavior. =20

=20

Regards,

Don=20

	=20

	regards, Neil

------_=_NextPart_001_01C89A7D.440F47C9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Message</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1 dir=3DRTL>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Hi =
all,<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>So maybe this is
something to be commented to the IEEE&#8230;&#8230;..they operate hybrid =
PBB/PBB-TE
networks. <o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>In this draft we =
provide
a control plane to the dataplane that is defined by the IEEE, and =
specifically
we define a control plane for PBB-TE as defined by the IEEE 802.1Qay. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Nurit<o:p></o:p><=
/span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter dir=3DLTR =
style=3D'text-align:center'><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal dir=3DLTR><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> owner-<st1:PersonName
w:st=3D"on">[email-masked]</st1:PersonName> =
[mailto:owner-<st1:PersonName
w:st=3D"on">[email-masked]</st1:PersonName>] <b><span =
style=3D'font-weight:
bold'>On Behalf Of </span></b>ext Don Fedyk<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, April =
09, 2008
17:38<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked];
[email-masked]; [email-masked]; <st1:PersonName =
w:st=3D"on">[email-masked]</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Continued =
Poll for
Adoption of Ethernet I-Ds</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Hi Igor and =
Neil</span></font><o:p></o:p></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>See =
below,</span></font><o:p></o:p></p>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><br>
IB&gt;&gt; I agree with what you are saying. What confuses me, though, =
is that
802.1ay prescribes allocating of certain range(s) of VLANIDs for the =
PBB-TE
use, while allowing use of other VLANIDs for their native Ethernet =
purposes. I
wonder why is that? Why not to say that all VLANIDs are available for =
the
PBB-TE use. If what you are saying is correct (which, again, I believe =
you
are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate =
layer
network, than VLANIDs are not shared between the two. <br>
<br>
What am I missing here?<br>
<br>
Thanks,<br>
Igor</span></font><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>&nbsp;</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dmaroon =
face=3D"Comic Sans MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>NH=3D&gt;
Excellent question.&nbsp; I have made exactly this same observation in =
the
past.&nbsp; In principle there is no reason why you cannot re-use all =
the
codepoints of each/every field in the traffic unit because, as stated, =
although
the traffic units look identical they do belong to quite different layer
networks.&nbsp; I think there are 2 reasons for =
this:</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dmaroon =
face=3D"Comic Sans MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>-&nbsp;&nbsp;&nbsp;
Firstly, most IEEE folks are not familiar with, and therefore do not =
use,
functional architecture techniques to describe layer networks.&nbsp; So =
this
issue may not be so obvious to many folks in IEEE.&nbsp; Further, when =
we have
QinQ techniques these are a form of sublayering (like we find in nested =
LSPs in
MPLS) and so we don't have distinct layer networks here......and =
although folks
may not describe it as such they do recognise that one of the =
consequences of
this (ie still a single layer network) is that it affects scaling.&nbsp;
However, once we have the .1ah stuff and MACinMAC (ie true =
client/server) then
everyone intuitively recognises we have quite disjoint layer =
networks.&nbsp; So
what I am saying here is that for folks who don't have a strong =
background in
functional architecture, the observation you have made may not be so =
obvious
even though it is architecturally true.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dmaroon =
face=3D"Comic Sans MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>-&nbsp;&nbsp;&nbsp;
Secondly, there could be practical/implementation reasons for doing this =
(ie
creating a split in VID codepoints) when dealing with COTS Ethernet
hardware.&nbsp; Maybe some of the Ethernet hardware experts can provide =
further
clarification here.&nbsp;&nbsp;</span></font><font size=3D2 color=3Dblue
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>&nbsp;</span></fo=
nt><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Disclaimer I'm =
not a
hardware expert but Neil is correct there is currently no =
&quot;context&quot;
within an Ethernet Frame that could separate the PBB B-VID space and the =
PBB-TE
B-VID space. If&nbsp; these spaces used overlapping B-VID values there =
would be
know way to know by looking at the Frame.&nbsp; In fact one of the =
attractions
of PBB-TE is that it can reuse the existing forwarding HW because it
essentially forwards on (B-VID+MAC DA).&nbsp;&nbsp;A result is&nbsp;a =
switch
cannot tell the context implicitly. </span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dmaroon =
face=3D"Comic Sans MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>One =
thing
this does provide however is a clear way to 'know' when looking at a =
traffic
unit in isolation exactly which layer network it belongs =
to.</span></font><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Between the PBB =
B-MAC
(server) and the PBB C-MAC </span></font><font size=3D2 color=3Dmaroon
face=3D"Comic Sans MS"><span =
style=3D'font-size:10.0pt;font-family:"Comic Sans MS";
color:maroon'>&nbsp;</span></font><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>(client) it is =
clear
looking at a frame.&nbsp;&nbsp; Between PBB and PBB-TE the B-VID space
partitioning in the management (and control plane) is the only thing =
that
separates the behavior.&nbsp; </span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Regards,</span></=
font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Don =
</span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dmaroon =
face=3D"Comic Sans MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>regards, Neil</span></font><o:p></o:p></p>

</div>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C89A7D.440F47C9--

Delivery-date: Wed, 09 Apr 2008 16:04:36 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "CCAMP List" <[email-masked]>
Subject: Last call complete on Advertisement of inter-AS TE links
Date: Wed, 9 Apr 2008 16:57:56 +0100

Hi,

The last call completed. Given the high level of review and discussion in 
the past and the relatively small size of the I-Ds, I'm not surprised that 
we only got a couple of comments during last call.

Mach, can you make the changes to the I-D to satisfy Acee's comments on the 
OSPF draft, and check to see if there is any similar language in the IS-IS 
draft? One point...

Where he suggests alternative text for "TE Router ID", I think this is fine, 
but it would be helpful if you retained "TE Router ID" in brackets to give 
the extra information.

Thanks,
Adrian
----- Original Message ----- 
From: "Acee Lindem" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "OSPF List" <[email-masked]>; "CCAMP List" <[email-masked]>
Sent: Friday, April 04, 2008 3:46 PM
Subject: Re: [OSPF] CCAMP last call on advertisement of inter-AS TE links

>I can't speak for the OSPF WG as a whole, but I have reviewed the  subject 
>document and am very happy to see that the suggestion to use  separate 
>inter-AS LSA types has been incorporated. I have no further  technical 
>comments on the document and trust that the ccamp WG has  verified that 
>this information encoding meets the TE requirements.  The usage described 
>in sections 2.2 and 2.3 seem reasonable to me.
>
> I have the following editorial comments:
>
>   1. Sections 3.3.2 and 3.3.2 - Both of these say "Use of the TE  Router 
> ID is RECOMMENDED." I believe these should be respectively  replaced by 
> "Use of the TE Router Address as specified in the Router  Address TLV 
> [OSPF-TE] is RECOMMENDED." and "Use of the TE Router IPv6  Address as 
> specified in the IPv6 Router Address as specified in the  IPv6 Router 
> Address TLV [OSPF-V3-TE] is RECOMMENDED."
>   2. Section 3.2.1 states "This is because... that may operate in a 
> different address space;". If they are using a different address  space on 
> the link between the ASes, then I'd expect there to be  problems with BGP 
> as well :^) I'd suggest:
>       "Given that OSPF is an IGP and should only be utilized between 
> routers in the same routing domain, the OSPF specific Link ID and 
> Neighbor ID sub-TLVs are not applicable to inter-AS links.".
>   3. You may want to expand some acronyms on their first use. For 
> example, "AS Boundary Router (ASBR)", "Link State Advertisement  (LSA)" 
> and
>      "Path Computation Element (PCE)".
>   4. [OSPFV3] is listed to as both a Normative and Informative  reference.
>
> Thanks,
> Acee
>
> On Mar 19, 2008, at 2:06 PM, Adrian Farrel wrote:
>
>> Hi,
>>
>> You may recall providing useful review and feedback on
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- 
>> te-extension-02.txt
>>
>> The authors believe that they have taken on board all the comments 
>> received
>> from the OSPF working group and have updated the draft accordingly.
>>
>>
>> CCAMP is holding a three week working group last call on this I-D  along 
>> with
>> its IS-IS partner document:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas- 
>> te-extension-00.txt
>>
>> These documents describe how to advertise the TE links that connect  an 
>> AS to
>> the outside world within the AS's IGP. As the drafts are at pains  to 
>> point
>> out, there is no proposal to advertise the TE information more  widely 
>> (such
>> as to other ASes).
>>
>> The last call will end at 12 noon BST on April 9th 2008.
>>
>> Please send your comments to the CCAMP list or direct to the CCAMP 
>> chairs.
>>
>> Thanks,
>> Adrian and Deborah
>>
>>
>> _______________________________________________
>> OSPF mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ospf
>
> 

Delivery-date: Wed, 09 Apr 2008 15:32:09 +0000
Date: Wed, 9 Apr 2008 08:31:03 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: Continued Poll for Adoption of Ethernet I-Ds
To: Don Fedyk <[email-masked]>, [email-masked], [email-masked], [email-masked]

--0-1949939702-1207755063=:64983
Content-Type: text/plain; charset=us-ascii

Hi Don,

IB>> I agree with what you are saying.   What confuses me, though, is that 802.1ay prescribes allocating of certain   range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs   for their native Ethernet purposes. I wonder why is that? Why not to say that   all VLANIDs are available for the PBB-TE use. If what you are saying is   correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE   (say, PBB) are completely separate layer network, than VLANIDs are not shared   between the two. 

What am I missing here?

Thanks,
Igor 
   
  NH=> Excellent question.  I have made exactly this same 
  observation in the past.  In principle there is no reason why you cannot 
  re-use all the codepoints of each/every field in the traffic unit because, as 
  stated, although the traffic units look identical they do belong to quite 
  different layer networks.  I think there are 2 reasons for 
  this:
   
  -    Firstly, most IEEE folks are not familiar with, and 
  therefore do not use, functional architecture techniques to describe layer 
  networks.  So this issue may not be so obvious to many folks in 
  IEEE.  Further, when we have QinQ techniques these are a form of 
  sublayering (like we find in nested LSPs in MPLS) and so we don't have 
  distinct layer networks here......and although folks may not describe it as 
  such they do recognise that one of the consequences of this (ie still a single 
  layer network) is that it affects scaling.  However, once we have the 
  .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively 
  recognises we have quite disjoint layer networks.  So what I am saying 
  here is that for folks who don't have a strong background in functional 
  architecture, the observation you have made may not be so obvious even though 
  it is architecturally true.
   
  -    Secondly, there could be   practical/implementation reasons for doing this (ie creating a split in VID   codepoints) when dealing with COTS Ethernet hardware.  Maybe some of the   Ethernet hardware experts can provide further clarification   here.   
   
Disclaimer I'm not a hardware expert but Neil is correct there is 
currently no "context" within an Ethernet Frame that could separate the PBB 
B-VID space and the PBB-TE B-VID space. If  these spaces used overlapping 
B-VID values there would be know way to know by looking at the Frame.  In 
fact one of the attractions of PBB-TE is that it can reuse the existing 
forwarding HW because it essentially forwards on (B-VID+MAC DA).  A 
result is a switch cannot tell the context implicitly. 

  One thing this does provide however is a clear way   to 'know' when looking at a traffic unit in isolation exactly which layer   network it belongs to. 
   
Between the PBB B-MAC (server) and the PBB C-MAC 
 (client) it is clear looking at a 
frame.   Between PBB and PBB-TE the B-VID space partitioning in the 
management (and control plane) is the only thing that separates the 
behavior.  

IB>> I think you are missing the point here. When it is said that PBB-TE and PBB (or any other native Ethernet) are different layer networks it means that what happens in one layer is transparent/irrelevant for the other  even when the two layers have identical LI overhead. In other words this means that one layer does not get to analyze the LI (MAC header in this case) of the other layer unless there is some kind of misconfiguration and packets from one layer are leaking into another. But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain. Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence
 there is no architectural need for the VLANID space separation.

Cheers,
Igor

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
--0-1949939702-1207755063=:64983
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Hi Don,<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><blockquote dir="ltr" style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;"><div class="OutlookMessageHeader" dir="ltr" align="left" lang="en-us"><br>IB&gt;&gt; I agree with what you are saying. 
  What confuses me, though, is that 802.1ay prescribes allocating of certain 
  range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs 
  for their native Ethernet purposes. I wonder why is that? Why not to say that 
  all VLANIDs are available for the PBB-TE use. If what you are saying is 
  correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE 
  (say, PBB) are completely separate layer network, than VLANIDs are not shared 
  between the two. <br><br>What am I missing here?<br><br>Thanks,<br>Igor<span class="590360707-09042008"><font color="#800000" face="Comic Sans MS" size="2">&nbsp;</font></span></div>
  <div><span class="590360707-09042008"></span>&nbsp;</div>
  <div><span class="590360707-09042008"><font color="#800000" face="Comic Sans MS" size="2">NH=&gt; Excellent question.&nbsp; I have made exactly this same 
  observation in the past.&nbsp; In principle there is no reason why you cannot 
  re-use all the codepoints of each/every field in the traffic unit because, as 
  stated, although the traffic units look identical they do belong to quite 
  different layer networks.&nbsp; I think there are 2 reasons for 
  this:</font></span></div>
  <div><span class="590360707-09042008"><font color="#800000" face="Comic Sans MS" size="2"></font></span>&nbsp;</div>
  <div><span class="590360707-09042008"><font color="#800000" face="Comic Sans MS" size="2">-&nbsp;&nbsp;&nbsp; Firstly, most IEEE folks are not familiar with, and 
  therefore do not use, functional architecture techniques to describe layer 
  networks.&nbsp; So this issue may not be so obvious to many folks in 
  IEEE.&nbsp; Further, when we have QinQ techniques these are a form of 
  sublayering (like we find in nested LSPs in MPLS) and so we don't have 
  distinct layer networks here......and although folks may not describe it as 
  such they do recognise that one of the consequences of this (ie still a single 
  layer network) is that it affects scaling.&nbsp; However, once we have the 
  .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively 
  recognises we have quite disjoint layer networks.&nbsp; So what I am saying 
  here is that for folks who don't have a strong background in functional 
  architecture, the observation you have made may not be so obvious even though 
  it is architecturally true.</font></span></div>
  <div><span class="590360707-09042008"><font color="#800000" face="Comic Sans MS" size="2"></font></span>&nbsp;</div>
  <div><span class="590360707-09042008"><font color="#800000" face="Comic Sans MS"><font size="2">-&nbsp;&nbsp;&nbsp; Secondly, there could be 
  practical/implementation reasons for doing this (ie creating a split in VID 
  codepoints) when dealing with COTS Ethernet hardware.&nbsp; Maybe some of the 
  Ethernet hardware experts can provide further clarification 
  here.&nbsp;&nbsp;<span class="088343713-09042008"><font color="#0000ff" face="Arial">&nbsp;</font></span></font></font></span></div>
  <div><span class="590360707-09042008"><font color="#800000" face="Comic Sans MS"><font size="2"><span class="088343713-09042008"></span></font></font></span>&nbsp;</div></blockquote>
<div dir="ltr"><span class="590360707-09042008"><font color="#800000" face="Comic Sans MS"><font size="2"><span class="088343713-09042008"><font color="#0000ff" face="Arial">Disclaimer I'm not a hardware expert but Neil is correct there is 
currently no "context" within an Ethernet Frame that could separate the PBB 
B-VID space and the PBB-TE B-VID space. If&nbsp; these spaces used overlapping 
B-VID values there would be know way to know by looking at the Frame.&nbsp; In 
fact one of the attractions of PBB-TE is that it can reuse the existing 
forwarding HW because it essentially forwards on (B-VID+MAC DA).&nbsp;&nbsp;A 
result is&nbsp;a switch cannot tell the context implicitly. 
</font></span></font></font></span></div>
<blockquote dir="ltr" style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
  <div><span class="590360707-09042008"><font color="#800000" face="Comic Sans MS"><font size="2">One thing this does provide however is a clear way 
  to 'know' when looking at a traffic unit in isolation exactly which layer 
  network it belongs to.<span class="088343713-09042008"><font color="#0000ff" face="Arial">&nbsp;</font></span></font></font></span></div>
  <div><span class="590360707-09042008"><font color="#800000" face="Comic Sans MS"><font size="2"><span class="088343713-09042008"></span></font></font></span>&nbsp;</div></blockquote>
<div dir="ltr"><span class="590360707-09042008"><font color="#800000" face="Comic Sans MS"><font size="2"><span class="088343713-09042008"><font color="#0000ff" face="Arial">Between the PBB B-MAC (server) and the PBB C-MAC 
</font>&nbsp;<font color="#0000ff" face="Arial">(client) it is clear looking at a 
frame.&nbsp;&nbsp; Between PBB and PBB-TE the B-VID space partitioning in the 
management (and control plane) is the only thing that separates the 
behavior.&nbsp; </font></span></font></font></span></div>
<div dir="ltr"><span class="590360707-09042008"><font color="#800000" face="Comic Sans MS"><font color="#0000ff" face="Arial" size="2"><span class="088343713-09042008"></span></font></font></span>&nbsp;</div></div>IB&gt;&gt; I think you are missing the point here. When it is said that PBB-TE and PBB (or any other native Ethernet) are different layer networks it means that what happens in one layer is transparent/irrelevant for the other&nbsp; even when the two layers have identical LI overhead. In other words this means that one layer does not get to analyze the LI (MAC header in this case) of the other layer unless there is some kind of misconfiguration and packets from one layer are leaking into another. But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB,
 than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain. Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural need for the VLANID space separation.<br><br>Cheers,<br>Igor<br></div></div><br>__________________________________________________<br>Do You Yahoo!?<br>Tired of spam?  Yahoo! Mail has the best spam protection around <br>http://mail.yahoo.com </body></html>
--0-1949939702-1207755063=:64983--

Delivery-date: Wed, 09 Apr 2008 14:51:59 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds
Date: Wed, 9 Apr 2008 10:38:15 -0400
From: "Don Fedyk" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C89A4F.58ECE102
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Igor and Neil
=20
See below,

=09
	IB>> I agree with what you are saying. What confuses me, though,
is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for
the PBB-TE use, while allowing use of other VLANIDs for their native
Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs
are available for the PBB-TE use. If what you are saying is correct
(which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say,
PBB) are completely separate layer network, than VLANIDs are not shared
between the two.=20
=09
	What am I missing here?
=09
	Thanks,
	Igor=20
	=20
	NH=3D> Excellent question.  I have made exactly this same
observation in the past.  In principle there is no reason why you cannot
re-use all the codepoints of each/every field in the traffic unit
because, as stated, although the traffic units look identical they do
belong to quite different layer networks.  I think there are 2 reasons
for this:
	=20
	-    Firstly, most IEEE folks are not familiar with, and
therefore do not use, functional architecture techniques to describe
layer networks.  So this issue may not be so obvious to many folks in
IEEE.  Further, when we have QinQ techniques these are a form of
sublayering (like we find in nested LSPs in MPLS) and so we don't have
distinct layer networks here......and although folks may not describe it
as such they do recognise that one of the consequences of this (ie still
a single layer network) is that it affects scaling.  However, once we
have the .1ah stuff and MACinMAC (ie true client/server) then everyone
intuitively recognises we have quite disjoint layer networks.  So what I
am saying here is that for folks who don't have a strong background in
functional architecture, the observation you have made may not be so
obvious even though it is architecturally true.
	=20
	-    Secondly, there could be practical/implementation reasons
for doing this (ie creating a split in VID codepoints) when dealing with
COTS Ethernet hardware.  Maybe some of the Ethernet hardware experts can
provide further clarification here.  =20
	=20

Disclaimer I'm not a hardware expert but Neil is correct there is
currently no "context" within an Ethernet Frame that could separate the
PBB B-VID space and the PBB-TE B-VID space. If  these spaces used
overlapping B-VID values there would be know way to know by looking at
the Frame.  In fact one of the attractions of PBB-TE is that it can
reuse the existing forwarding HW because it essentially forwards on
(B-VID+MAC DA).  A result is a switch cannot tell the context
implicitly.=20

	One thing this does provide however is a clear way to 'know'
when looking at a traffic unit in isolation exactly which layer network
it belongs to.=20
	=20

Between the PBB B-MAC (server) and the PBB C-MAC  (client) it is clear
looking at a frame.   Between PBB and PBB-TE the B-VID space
partitioning in the management (and control plane) is the only thing
that separates the behavior. =20
=20
Regards,
Don=20

	=20
	regards, Neil

------_=_NextPart_001_01C89A4F.58ECE102
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE type=3Dtext/css>DIV {
	MARGIN: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D088343713-09042008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Igor and Neil</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D088343713-09042008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D088343713-09042008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>See below,</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT><BR>IB&gt;&gt; I agree with what you =
are saying.=20
  What confuses me, though, is that 802.1ay prescribes allocating of =
certain=20
  range(s) of VLANIDs for the PBB-TE use, while allowing use of other =
VLANIDs=20
  for their native Ethernet purposes. I wonder why is that? Why not to =
say that=20
  all VLANIDs are available for the PBB-TE use. If what you are saying =
is=20
  correct (which, again, I believe you are), that is, PBB-TE and =
non-PBB-TE=20
  (say, PBB) are completely separate layer network, than VLANIDs are not =
shared=20
  between the two. <BR><BR>What am I missing =
here?<BR><BR>Thanks,<BR>Igor<SPAN=20
  class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D590360707-09042008></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2>NH=3D&gt; Excellent question.&nbsp; I have made exactly this =
same=20
  observation in the past.&nbsp; In principle there is no reason why you =
cannot=20
  re-use all the codepoints of each/every field in the traffic unit =
because, as=20
  stated, although the traffic units look identical they do belong to =
quite=20
  different layer networks.&nbsp; I think there are 2 reasons for=20
  this:</FONT></SPAN></DIV>
  <DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2>-&nbsp;&nbsp;&nbsp; Firstly, most IEEE folks are not familiar =
with, and=20
  therefore do not use, functional architecture techniques to describe =
layer=20
  networks.&nbsp; So this issue may not be so obvious to many folks in=20
  IEEE.&nbsp; Further, when we have QinQ techniques these are a form of=20
  sublayering (like we find in nested LSPs in MPLS) and so we don't have =

  distinct layer networks here......and although folks may not describe =
it as=20
  such they do recognise that one of the consequences of this (ie still =
a single=20
  layer network) is that it affects scaling.&nbsp; However, once we have =
the=20
  .1ah stuff and MACinMAC (ie true client/server) then everyone =
intuitively=20
  recognises we have quite disjoint layer networks.&nbsp; So what I am =
saying=20
  here is that for folks who don't have a strong background in =
functional=20
  architecture, the observation you have made may not be so obvious even =
though=20
  it is architecturally true.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS"=20
  color=3D#800000><FONT size=3D2>-&nbsp;&nbsp;&nbsp; Secondly, there =
could be=20
  practical/implementation reasons for doing this (ie creating a split =
in VID=20
  codepoints) when dealing with COTS Ethernet hardware.&nbsp; Maybe some =
of the=20
  Ethernet hardware experts can provide further clarification=20
  here.&nbsp;&nbsp;<SPAN class=3D088343713-09042008><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS"=20
  color=3D#800000><FONT size=3D2><SPAN=20
  =
class=3D088343713-09042008></SPAN></FONT></FONT></SPAN>&nbsp;</DIV></BLOC=
KQUOTE>
<DIV dir=3Dltr><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans =
MS"=20
color=3D#800000><FONT size=3D2><SPAN class=3D088343713-09042008><FONT =
face=3DArial=20
color=3D#0000ff>Disclaimer I'm not a hardware expert but Neil is correct =
there is=20
currently no "context" within an Ethernet Frame that could separate the =
PBB=20
B-VID space and the PBB-TE B-VID space. If&nbsp; these spaces used =
overlapping=20
B-VID values there would be know way to know by looking at the =
Frame.&nbsp; In=20
fact one of the attractions of PBB-TE is that it can reuse the existing=20
forwarding HW because it essentially forwards on (B-VID+MAC =
DA).&nbsp;&nbsp;A=20
result is&nbsp;a switch cannot tell the context implicitly.=20
</FONT></SPAN></FONT></FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS"=20
  color=3D#800000><FONT size=3D2>One thing this does provide however is =
a clear way=20
  to 'know' when looking at a traffic unit in isolation exactly which =
layer=20
  network it belongs to.<SPAN class=3D088343713-09042008><FONT =
face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS"=20
  color=3D#800000><FONT size=3D2><SPAN=20
  =
class=3D088343713-09042008></SPAN></FONT></FONT></SPAN>&nbsp;</DIV></BLOC=
KQUOTE>
<DIV dir=3Dltr><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans =
MS"=20
color=3D#800000><FONT size=3D2><SPAN class=3D088343713-09042008><FONT =
face=3DArial=20
color=3D#0000ff>Between the PBB B-MAC (server) and the PBB C-MAC=20
</FONT>&nbsp;<FONT face=3DArial color=3D#0000ff>(client) it is clear =
looking at a=20
frame.&nbsp;&nbsp; Between PBB and PBB-TE the B-VID space partitioning =
in the=20
management (and control plane) is the only thing that separates the=20
behavior.&nbsp; </FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans =
MS"=20
color=3D#800000><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D088343713-09042008></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans =
MS"=20
color=3D#800000><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D088343713-09042008>Regards,</SPAN></FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans =
MS"=20
color=3D#800000><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D088343713-09042008>Don </SPAN></FONT></FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2>regards, Neil</FONT></SPAN></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C89A4F.58ECE102--

Delivery-date: Wed, 09 Apr 2008 07:52:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds
Date: Wed, 9 Apr 2008 08:48:29 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C89A16.66948A36
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Igor....please see in-line (have snipped mail to your question only)
=20
Igor Bryskin  wrote 08 April 2008 22:17

> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt

Notionally support.  One concern I have revolves around the implications
of this para:

"4.1.3 Hybrid operation with legacy Ethernet

  The solution should take into consideration the operational scenario
  that GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet
  hybrid networks. This morphs of network architecture is possible
  considering evolution scenario of Ethernet. In such networks, legacy
  Ethernet functionality such as Spanning Tree Protocol (SPT),
  Link Aggregation [IEEE802.3], and so on must co-exist with PBB-TE
  functionality.

  The solution must not prevent the simultaneous existence of GMPLS
  controlled Eth-LSPs and PBB[IEE802.1ah] or PB[IEE802.1ad] with
  native Ethernet Layer2 control protocols on same node and interface."

We must avoid the mistake that different network modes (ie cl-ps or
co-ps or co-cs) can somehow 'co-exist' in the same DP layer network (and
also have the same CP).  More specifically, native Ethernet is cl-ps and
PBB-TE is co-ps....so even though the base DP traffic unit of these 2
different network modes looks the same they MUST exist in their own
layer network space.  This requires that some (lower) server layer
network should create *different resource partitions* (in either space,
freq or time dimensions) for each client layer network mode type.

IB>> I agree with what you are saying. What confuses me, though, is that
802.1ay prescribes allocating of certain range(s) of VLANIDs for the
PBB-TE use, while allowing use of other VLANIDs for their native
Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs
are available for the PBB-TE use. If what you are saying is correct
(which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say,
PBB) are completely separate layer network, than VLANIDs are not shared
between the two.=20

What am I missing here?

Thanks,
Igor=20
=20
NH=3D> Excellent question.  I have made exactly this same observation in
the past.  In principle there is no reason why you cannot re-use all the
codepoints of each/every field in the traffic unit because, as stated,
although the traffic units look identical they do belong to quite
different layer networks.  I think there are 2 reasons for this:
=20
-    Firstly, most IEEE folks are not familiar with, and therefore do
not use, functional architecture techniques to describe layer networks.
So this issue may not be so obvious to many folks in IEEE.  Further,
when we have QinQ techniques these are a form of sublayering (like we
find in nested LSPs in MPLS) and so we don't have distinct layer
networks here......and although folks may not describe it as such they
do recognise that one of the consequences of this (ie still a single
layer network) is that it affects scaling.  However, once we have the
.1ah stuff and MACinMAC (ie true client/server) then everyone
intuitively recognises we have quite disjoint layer networks.  So what I
am saying here is that for folks who don't have a strong background in
functional architecture, the observation you have made may not be so
obvious even though it is architecturally true.
=20
-    Secondly, there could be practical/implementation reasons for doing
this (ie creating a split in VID codepoints) when dealing with COTS
Ethernet hardware.  Maybe some of the Ethernet hardware experts can
provide further clarification here. =20
=20
One thing this does provide however is a clear way to 'know' when
looking at a traffic unit in isolation exactly which layer network it
belongs to.
=20
regards, Neil

------_=_NextPart_001_01C89A16.66948A36
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<STYLE type=3Dtext/css><!-- DIV {margin:0px;} --></STYLE>

<META content=3D"MSHTML 6.00.2900.2769" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Hi Igor....please see in-line (have snipped mail to your =
question=20
only)</FONT></SPAN></DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN =
class=3D590360707-09042008><FONT=20
face=3D"Comic Sans MS" =
color=3D#800000></FONT></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2>Igor Bryskin&nbsp;<SPAN=20
class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000>&nbsp;wrote=20
</FONT></SPAN>08 April 2008 22:17<BR></FONT></FONT><BR>&gt;=20
draft-imajuku-ccamp-ethernet-gmpls-req-01.txt<BR><BR>Notionally =
support.&nbsp;=20
One concern I have revolves around the implications<BR>of this=20
para:<BR><BR>"4.1.3 Hybrid operation with legacy Ethernet<BR><BR>&nbsp; =
The=20
solution should take into consideration the operational =
scenario<BR>&nbsp; that=20
GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet<BR>&nbsp; =
hybrid=20
networks. This morphs of network architecture is possible<BR>&nbsp; =
considering=20
evolution scenario of Ethernet. In such networks, legacy<BR>&nbsp; =
Ethernet=20
functionality such as Spanning Tree Protocol (SPT),<BR>&nbsp; Link =
Aggregation=20
[IEEE802.3], and so on must co-exist with PBB-TE<BR>&nbsp;=20
functionality.<BR><BR>&nbsp; The solution must not prevent the =
simultaneous=20
existence of GMPLS<BR>&nbsp; controlled Eth-LSPs and PBB[IEE802.1ah] or=20
PB[IEE802.1ad] with<BR>&nbsp; native Ethernet Layer2 control protocols =
on same=20
node and interface."<BR><BR>We must avoid the mistake that different =
network=20
modes (ie cl-ps or<BR>co-ps or co-cs) can somehow 'co-exist' in the same =
DP=20
layer network (and<BR>also have the same CP).&nbsp; More specifically, =
native=20
Ethernet is cl-ps and<BR>PBB-TE is co-ps....so even though the base DP =
traffic=20
unit of these 2<BR>different network modes looks the same they MUST =
exist in=20
their own<BR>layer network space.&nbsp; This requires that some (lower) =
server=20
layer<BR>network should create *different resource partitions* (in =
either=20
space,<BR>freq or time dimensions) for each client layer network mode=20
type.<BR><BR>IB&gt;&gt; I agree with what you are saying. What confuses =
me,=20
though, is that 802.1ay prescribes allocating of certain range(s) of =
VLANIDs for=20
the PBB-TE use, while allowing use of other VLANIDs for their native =
Ethernet=20
purposes. I wonder why is that? Why not to say that all VLANIDs are =
available=20
for the PBB-TE use. If what you are saying is correct (which, again, I =
believe=20
you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely =
separate=20
layer network, than VLANIDs are not shared between the two. <BR><BR>What =
am I=20
missing here?<BR><BR>Thanks,<BR>Igor<SPAN =
class=3D590360707-09042008><FONT=20
face=3D"Comic Sans MS" color=3D#800000 =
size=3D2>&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D590360707-09042008></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>NH=3D&gt; Excellent question.&nbsp; I have made exactly this =
same=20
observation in the past.&nbsp; In principle there is no reason why you =
cannot=20
re-use all the codepoints of each/every field in the traffic unit =
because, as=20
stated, although the traffic units look identical they do belong to =
quite=20
different layer networks.&nbsp; I think there are 2 reasons for=20
this:</FONT></SPAN></DIV>
<DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>-&nbsp;&nbsp;&nbsp; Firstly, most IEEE folks are not familiar =
with, and=20
therefore do not use, functional architecture techniques to describe =
layer=20
networks.&nbsp; So this issue may not be so obvious to many folks in =
IEEE.&nbsp;=20
Further, when we have QinQ techniques these are a form of sublayering =
(like we=20
find in nested LSPs in MPLS) and so we don't have distinct layer =
networks=20
here......and although folks may not describe it as such they do =
recognise that=20
one of the consequences of this (ie still a single layer network) is =
that it=20
affects scaling.&nbsp; However, once we have the .1ah stuff and MACinMAC =
(ie=20
true client/server) then everyone intuitively recognises we have quite =
disjoint=20
layer networks.&nbsp; So what I am saying here is that for folks who =
don't have=20
a strong background in functional architecture, the observation you have =
made=20
may not be so obvious even though it is architecturally=20
true.</FONT></SPAN></DIV>
<DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>-&nbsp;&nbsp;&nbsp; Secondly, there could be =
practical/implementation=20
reasons for doing this (ie creating a split in VID codepoints) when =
dealing with=20
COTS Ethernet hardware.&nbsp; Maybe some of the Ethernet hardware =
experts can=20
provide further clarification here.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>One thing this does provide however is a clear way to 'know' =
when looking=20
at a traffic unit in isolation exactly which layer network it belongs=20
to.</FONT></SPAN></DIV>
<DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D590360707-09042008><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C89A16.66948A36--

Delivery-date: Wed, 09 Apr 2008 02:43:53 +0000
Reply-To: <[email-masked]>
From: "Weiqiang Sun" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Editorial comment about draft-ietf-ccamp-lsp-dppm-00.txt
Date: Wed, 9 Apr 2008 10:41:56 +0800
Organization: Shanghai Jiao Tong University

Hi Adrian,

Many thanks for the thorough comments. We will get them fixed one by one and
post it again.

Best regards,

Weiqiang

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, April 09, 2008 4:08 AM
To: [email-masked]
Cc: [email-masked]
Subject: Editorial comment about draft-ietf-ccamp-lsp-dppm-00.txt

Hi,

Here are some editorial comments for your draft. These changes will help 
your draft through the IETF process and will make it easier to review for 
others.

Cheers,
Adrian

===
Document header

s/ccamp/Network Working Group/
(This is for obscure historic reasons :-)

===
Author list

You need to reduce to a list of no more than four authors listed on the
front page. Others can continue to be listed in the section at the end
of the draft. There are two ways to handle this:
1. If some of the authros are doing most of the work, keep them on the
   front page, but remove the others.
2. If one or two people are editing the work done by the rest of the
   team, leave them on the frint page and mark them as "(Editor)".

===
Document title

s/Dynamical/Dynamic/

===
Abstract

s/for the future data transmission/for future data transmission/
s/The GMPLS/GMPLS/
s/cooperate/operate/
s/in metro area/in metro areas/

===

1.  Introduction
s/cooperate/operate/
s/This draft intends to define/This document defines/
s/The metrics defined in this draft/The metrics defined in this document/

===
1.  Introduction

   For example, an new object can be added to
   the GMPLS TE STD MIB [RFC4802] such that the current and past control
   plane performance can be monitored through network management
   systems.  The extension of TE-MIB to support the metrics defined is
   out the scope of this document.
I think that technically you cannot add objects to a defined MIB module,
but you can define extensions to a MIB module to contain new objects.

===
2.  Conventions Used in This Document

I don't think you need this text as you do not use any of the formal
language.

===
3.  Overview of Performance Metrics

I would like to see a little more introduction to what we are going to
get in sections 4 to 8, and then 9 through 12. in other words, an
overview of what is coming later so that I can navigate the rest of the
document a little more easily.

===
4.  A Singleton Definition for single unidirectional LSP Setup Delay

Can you make all section headings use captials. For example,

4.  A Singleton Definition for Single Unidirectional LSP Setup Delay

===
14.  Discussion
s/But in the draft/But in this document/

===
15.  Security Considerations

This section is a little thin!

Could the information you propose to collect be used to facilitate
attacks? For example by identifying weak spots in the network.

Could the collection of information impact the operation of the
network? If this is the case, requesting that performance behavior
is monitored and reported could be used to attack the network.

===
You are missing an IANA section.

This can simply say...

X. IANA Considerations

   This document makes no requests for IANA action.

===
17.  Normative References

[RFC2119]
You might not need this any more if you delete Section 2.

[RFC2330] This is an Informational RFC. If you can, you should make
it an Informative Reference. This is not absolutely required - if you
believe it really is normative (i.e., your document cannot be read
without reference to this RFC) then it is OK to keep it as a
Normative Reference.

Delivery-date: Wed, 09 Apr 2008 00:45:00 +0000
Date: Wed, 09 Apr 2008 09:47:31 +0900
To: <[email-masked]>
From: Wataru Imajuku <[email-masked]>
Subject: Re: Polling for Adoption of Ethernet I-Ds

Hi,

 Yes to all.

Best Regards
Wataru

At 05:23 08/03/28, Adrian Farrel wrote:
>Hi,
>
>From Philadelphia, we have four candidate I-Ds for adoption as CCAMP working group documents.
>
>Please express your opinions.
>
>Note that acceptance of these I-Ds does not mean that the discussion about the architecture is done. I think we made some progress on that topic in Philadelphia, and I think the authors took on the task of making some updates of semantics and for clarity, but I expect the discussion may go on for a while.
>
>draft-imajuku-ccamp-ethernet-gmpls-req-01.txt
>draft-fedyk-gmpls-ethernet-pbb-te-02.txt
>draft-berger-ccamp-gmpls-mef-uni-02.txt
>draft-berger-ccamp-gmpls-ether-svcs-01.txt
>
>Thanks,
>Adrian 
>
>

-------------------------------------
Wataru Imajuku@NTT Network Innovation Labs
TEL: +81-46-859-4315
FAX: +81-46-859-5541

Delivery-date: Tue, 08 Apr 2008 21:20:12 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds
Date: Tue, 8 Apr 2008 17:19:54 -0400
From: "Pandian, Vijay" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Yes to all.

Vijay=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Monday, April 07, 2008 12:54 PM
To: [email-masked]
Subject: Continued Poll for Adoption of Ethernet I-Ds

Hi,

We have seen some good support for these I-Ds and no objections, but I
don't think we have seen anything like the level of support that was
evident in the room in Philadelphia. We haven't seen support from more
than half of the authors of the documents.

So, please, if you haven't already done so, give an indication of
whether or not you support each of these four documents becoming working
group drafts.=20
Remember, you can be in favor of some and not other if you like.

Thanks,
Adrian

----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 27, 2008 9:23 PM
Subject: Polling for Adoption of Ethernet I-Ds

> Hi,
>
> From Philadelphia, we have four candidate I-Ds for adoption as CCAMP=20
> working group documents.
>
> Please express your opinions.
>
> Note that acceptance of these I-Ds does not mean that the discussion
about=20
> the architecture is done. I think we made some progress on that topic
in=20
> Philadelphia, and I think the authors took on the task of making some=20
> updates of semantics and for clarity, but I expect the discussion may
go=20
> on for a while.
>
> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt
> draft-fedyk-gmpls-ethernet-pbb-te-02.txt
> draft-berger-ccamp-gmpls-mef-uni-02.txt
> draft-berger-ccamp-gmpls-ether-svcs-01.txt
>
> Thanks,
> Adrian
>
>
>=20

Delivery-date: Tue, 08 Apr 2008 21:18:13 +0000
Date: Tue, 8 Apr 2008 14:16:35 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: Continued Poll for Adoption of Ethernet I-Ds
To: [email-masked], [email-masked], [email-masked]

--0-1744815800-1207689395=:29318
Content-Type: text/plain; charset=us-ascii

Hi Neil. Please, see my question in-line.
Regards,
Igor

----- Original Message ----
From: "[email-masked]" <[email-masked]>
To: [email-masked]; [email-masked]
Sent: Monday, April 7, 2008 4:57:57 PM
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

Adrian,  Here is my view (with some brief rationale):

> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt

Notionally support.  One concern I have revolves around the implications
of this para:

"4.1.3 Hybrid operation with legacy Ethernet

   The solution should take into consideration the operational scenario
   that GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet
   hybrid networks. This morphs of network architecture is possible
   considering evolution scenario of Ethernet. In such networks, legacy
   Ethernet functionality such as Spanning Tree Protocol (SPT),
   Link Aggregation [IEEE802.3], and so on must co-exist with PBB-TE
   functionality.

   The solution must not prevent the simultaneous existence of GMPLS
   controlled Eth-LSPs and PBB[IEE802.1ah] or PB[IEE802.1ad] with
   native Ethernet Layer2 control protocols on same node and interface."

We must avoid the mistake that different network modes (ie cl-ps or
co-ps or co-cs) can somehow 'co-exist' in the same DP layer network (and
also have the same CP).  More specifically, native Ethernet is cl-ps and
PBB-TE is co-ps....so even though the base DP traffic unit of these 2
different network modes looks the same they MUST exist in their own
layer network space.  This requires that some (lower) server layer
network should create *different resource partitions* (in either space,
freq or time dimensions) for each client layer network mode type.

IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two. 

What am I missing here?

Thanks,
Igor

Aside=> For the case of private network services (which also includes
'network builder' transport services, ie how one creates client layer
network topology) we are ultimately dealing with a time varying
aggregate of message/file/stream applications.....these may not even be
supported in the immediate client layer network, but there will
ultimately be a 'very top' layer network that does support these.  So in
the server layer network what we have to deal with are (latent)
abstractions of such time varying application aggregates.  In such cases
the key behaviour that the server network must provide to the client
network is one of transparency, ie a client/server layer network
relationship must provide full functional decoupling of the client and
server layer networks.  This is not simply a technically driven
requirement but it also has commercial and (in some cases) regulatory
drivers.  Although this is a necessary condition (at least for
reachability isolation of different client service instances) it is not
generally sufficient for client service cases which require resource
isolation (ie the traffic behaviour of client service instance X cannot
impact the traffic behaviour experienced by client service instance Y).
To satisfy the latter requirement the server layer network (i) must
provide connections (ie only p2p or p2mp constructs allowed - which is
also a necessary condition) and (ii) the server layer resources should
not be overbooked (for a full sufficiency condition).  Although not all
client cases need this (strong resource isolation) service from the
server layer network, the server layer network must nevertheless have
the capability of providing it.

All these requirements are forced to be met when the server layer
technology belongs to the co-cs mode.  However, care is required when
the server layer network belongs to the co-ps mode (eg PBB-TE), eg don't
violate the rules of a connection.  And of course these requirements
cannot be assured in the cl-ps mode as this does not, by definition,
provide connections.

> draft-fedyk-gmpls-ethernet-pbb-te-02.txt

Support.  Couple of small points:
-    OAM activation/deactivation (ie CV flow) needs to be
synchronised to whatever CP or MP mechanism sets-up/tears-down ESPs for
obvious operational reasons.  Further, the CP (if ESP signalled) or MP
(if ESP provisioned) needs to tell ESP DP sink trail termination point
of the expected B-MAC SA.
-    Although IDs major on security from the perspective of malicious
attacks (on the DP/CP/MP) there is also an aspect of security related to
defects, ie customer traffic leaking from one connection into another
connection under misconnectivity defects.  A major advantage for
operators and their customers of using domain-unique (non-swapped)
labels is that misconnectivity defects are very unlikely to propagate,
and in any case are always detectable at a connection trail termination
point due to the B-MAC SA in each traffic unit. This benefit exists
without running any OAM at all.....indeed, one only requires a CV OAM
flow in PBB-TE to detect simple breaks such that they can be
distinguished from a quiescent traffic case.  This results in a
significant opex benefit since it means operators only need to run OAM
on important connections and not all connections (which is the case for
label-swapping if misconnectivity defects must be detected).  Maybe this
'security benefit' should be mentioned in the security section?

> draft-berger-ccamp-gmpls-mef-uni-02.txt
> draft-berger-ccamp-gmpls-ether-svcs-01.txt

No problems with the IDs themselves, as they are only attempting to
satisfy externally perceived requirements....but I do have a concern
with the external requirements.

When we talk about UNIs (and E-NNIs) we should be clear that we are
actually dealing with public network services and the horizontal
peer-partitioning of a single layer network between different operator
and customer parties, ie this is NOT the same as the private 'network
builder' case (briefly discussed previously) since that is based on a
vertical client/server relationship between different layer networks.  A
critical issue (usually overlooked in my experience) here is the
importance in being clear about the 'end-system message/file/stream
application to first layer network adaptation functions'.  Ethernet does
not currently define such adaptation functions for message/file/stream
applications (IP does of course with UDP, TCP and RTP respectively).  I
don't really want to go into all the detail here, but I simply want to
make the point that before folks get too carried away defining UNIs/NNIs
(for any network technology) they should be clear that this signifies a
clear intention to develop public network services and requires careful
attention to the end-system to first layer network adaptation
functions.....so it's not simply about defining interworking between CP
signalling or routing functions, or even DP OAM functions say.
Therefore, as you might guess, whilst we in IETF/CCAMPs may quite easily
define UNIs/E-NNIs for the DP (OAM) and CP say, we should also be
cognizant of the ultimate implications of the direction MEF and ITU are
taking here.

Aside=> A slight twist on the above is where folks have considered E-NNI
peer interworking between *different* technologies.  This recently came
up in the ITU wrt T-MPLS OAM in draft G.8114 which was undergoing AAP.
G.8114 contained a proposal to peer interwork T-MPLS and Ethernet
networks simply because they had both been 'bestowed' with similar, and
IMO far too complex, DP OAM.  It should be self-evident that it is not
sensible to try and interwork 2 technologies that belong to different
network modes (simply because there will be significant functional
component mismatch across the DP and CP), but in any case there are no
end-system application to first layer network adaptations functions
defined for either of these technologies (noting that if these were
defined they would be required to either (i) pass transparently between
the 2 network peer partitions at the interworking point if common or
(ii) there would have to be interworking cases defined if not common).
It was quite evident that no thought had been given to these matters
whatsoever in G.8114 and so we requested that the interworking proposal
was removed.  Later, and as most folks probably know by now, the AAP
progress of G.8114 was stopped anyway due to larger concerns that IETF
had on T-MPLS in general. 

regards, Neil 

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 07 April 2008 17:54
> To: [email-masked]
> Subject: Continued Poll for Adoption of Ethernet I-Ds
> 
> 
> Hi,
> 
> We have seen some good support for these I-Ds and no
> objections, but I don't 
> think we have seen anything like the level of support that 
> was evident in 
> the room in Philadelphia. We haven't seen support from more 
> than half of the 
> authors of the documents.
> 
> So, please, if you haven't already done so, give an
> indication of whether or 
> not you support each of these four documents becoming working 
> group drafts. 
> Remember, you can be in favor of some and not other if you like.
> 
> Thanks,
> Adrian
> 
> ----- Original Message -----
> From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, March 27, 2008 9:23 PM
> Subject: Polling for Adoption of Ethernet I-Ds
> 
> 
> > Hi,
> >
> > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP

> > working group documents.
> >
> > Please express your opinions.
> >
> > Note that acceptance of these I-Ds does not mean that the
> discussion
> > about
> > the architecture is done. I think we made some progress on
> that topic in
> > Philadelphia, and I think the authors took on the task of
> making some
> > updates of semantics and for clarity, but I expect the
> discussion may go
> > on for a while.
> >
> > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt
> > draft-fedyk-gmpls-ethernet-pbb-te-02.txt
> > draft-berger-ccamp-gmpls-mef-uni-02.txt
> > draft-berger-ccamp-gmpls-ether-svcs-01.txt
> >
> > Thanks,
> > Adrian
> >
> >
> > 
> 
> 
> 
> 

      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
--0-1744815800-1207689395=:29318
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Hi Neil. Please, see my question in-line.<br>Regards,<br>Igor<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: "[email-masked]" &lt;[email-masked]&gt;<br>To: [email-masked]; [email-masked]<br>Sent: Monday, April 7, 2008 4:57:57 PM<br>Subject: RE: Continued Poll for Adoption of Ethernet I-Ds<br><br>
Adrian,&nbsp; Here is my view (with some brief rationale):<br><br>&gt; draft-imajuku-ccamp-ethernet-gmpls-req-01.txt<br><br>Notionally support.&nbsp; One concern I have revolves around the implications<br>of this para:<br><br>"4.1.3 Hybrid operation with legacy Ethernet<br><br>&nbsp;  The solution should take into consideration the operational scenario<br>&nbsp;  that GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet<br>&nbsp;  hybrid networks. This morphs of network architecture is possible<br>&nbsp;  considering evolution scenario of Ethernet. In such networks, legacy<br>&nbsp;  Ethernet functionality such as Spanning Tree Protocol (SPT),<br>&nbsp;  Link Aggregation [IEEE802.3], and so on must co-exist with PBB-TE<br>&nbsp;  functionality.<br><br>&nbsp;  The solution must not prevent the simultaneous existence of GMPLS<br>&nbsp;  controlled Eth-LSPs and PBB[IEE802.1ah] or PB[IEE802.1ad] with<br>&nbsp;  native Ethernet Layer2 control
 protocols on same node and interface."<br><br>We must avoid the mistake that different network modes (ie cl-ps or<br>co-ps or co-cs) can somehow 'co-exist' in the same DP layer network (and<br>also have the same CP).&nbsp; More specifically, native Ethernet is cl-ps and<br>PBB-TE is co-ps....so even though the base DP traffic unit of these 2<br>different network modes looks the same they MUST exist in their own<br>layer network space.&nbsp; This requires that some (lower) server layer<br>network should create *different resource partitions* (in either space,<br>freq or time dimensions) for each client layer network mode type.<br><br>IB&gt;&gt; I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If
 what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two. <br><br>What am I missing here?<br><br>Thanks,<br>Igor<br><br>Aside=&gt; For the case of private network services (which also includes<br>'network builder' transport services, ie how one creates client layer<br>network topology) we are ultimately dealing with a time varying<br>aggregate of message/file/stream applications.....these may not even be<br>supported in the immediate client layer network, but there will<br>ultimately be a 'very top' layer network that does support these.&nbsp; So in<br>the server layer network what we have to deal with are (latent)<br>abstractions of such time varying application aggregates.&nbsp; In such cases<br>the key behaviour that the server network must provide to the client<br>network is one of transparency, ie a client/server
 layer network<br>relationship must provide full functional decoupling of the client and<br>server layer networks.&nbsp; This is not simply a technically driven<br>requirement but it also has commercial and (in some cases) regulatory<br>drivers.&nbsp; Although this is a necessary condition (at least for<br>reachability isolation of different client service instances) it is not<br>generally sufficient for client service cases which require resource<br>isolation (ie the traffic behaviour of client service instance X cannot<br>impact the traffic behaviour experienced by client service instance Y).<br>To satisfy the latter requirement the server layer network (i) must<br>provide connections (ie only p2p or p2mp constructs allowed - which is<br>also a necessary condition) and (ii) the server layer resources should<br>not be overbooked (for a full sufficiency condition).&nbsp; Although not all<br>client cases need this (strong resource isolation) service from
 the<br>server layer network, the server layer network must nevertheless have<br>the capability of providing it.<br><br>All these requirements are forced to be met when the server layer<br>technology belongs to the co-cs mode.&nbsp; However, care is required when<br>the server layer network belongs to the co-ps mode (eg PBB-TE), eg don't<br>violate the rules of a connection.&nbsp; And of course these requirements<br>cannot be assured in the cl-ps mode as this does not, by definition,<br>provide connections.<br><br><br>&gt; draft-fedyk-gmpls-ethernet-pbb-te-02.txt<br><br>Support.&nbsp; Couple of small points:<br>-&nbsp;&nbsp;&nbsp; OAM activation/deactivation (ie CV flow) needs to be<br>synchronised to whatever CP or MP mechanism sets-up/tears-down ESPs for<br>obvious operational reasons.&nbsp; Further, the CP (if ESP signalled) or MP<br>(if ESP provisioned) needs to tell ESP DP sink trail termination point<br>of the expected B-MAC
 SA.<br>-&nbsp;&nbsp;&nbsp; Although IDs major on security from the perspective of malicious<br>attacks (on the DP/CP/MP) there is also an aspect of security related to<br>defects, ie customer traffic leaking from one connection into another<br>connection under misconnectivity defects.&nbsp; A major advantage for<br>operators and their customers of using domain-unique (non-swapped)<br>labels is that misconnectivity defects are very unlikely to propagate,<br>and in any case are always detectable at a connection trail termination<br>point due to the B-MAC SA in each traffic unit. This benefit exists<br>without running any OAM at all.....indeed, one only requires a CV OAM<br>flow in PBB-TE to detect simple breaks such that they can be<br>distinguished from a quiescent traffic case.&nbsp; This results in a<br>significant opex benefit since it means operators only need to run OAM<br>on important connections and not all connections (which is the case
 for<br>label-swapping if misconnectivity defects must be detected).&nbsp; Maybe this<br>'security benefit' should be mentioned in the security section?<br><br><br>&gt; draft-berger-ccamp-gmpls-mef-uni-02.txt<br>&gt; draft-berger-ccamp-gmpls-ether-svcs-01.txt<br><br>No problems with the IDs themselves, as they are only attempting to<br>satisfy externally perceived requirements....but I do have a concern<br>with the external requirements.<br><br>When we talk about UNIs (and E-NNIs) we should be clear that we are<br>actually dealing with public network services and the horizontal<br>peer-partitioning of a single layer network between different operator<br>and customer parties, ie this is NOT the same as the private 'network<br>builder' case (briefly discussed previously) since that is based on a<br>vertical client/server relationship between different layer networks.&nbsp; A<br>critical issue (usually overlooked in my experience) here is the<br>importance
 in being clear about the 'end-system message/file/stream<br>application to first layer network adaptation functions'.&nbsp; Ethernet does<br>not currently define such adaptation functions for message/file/stream<br>applications (IP does of course with UDP, TCP and RTP respectively).&nbsp; I<br>don't really want to go into all the detail here, but I simply want to<br>make the point that before folks get too carried away defining UNIs/NNIs<br>(for any network technology) they should be clear that this signifies a<br>clear intention to develop public network services and requires careful<br>attention to the end-system to first layer network adaptation<br>functions.....so it's not simply about defining interworking between CP<br>signalling or routing functions, or even DP OAM functions say.<br>Therefore, as you might guess, whilst we in IETF/CCAMPs may quite easily<br>define UNIs/E-NNIs for the DP (OAM) and CP say, we should also be<br>cognizant of the
 ultimate implications of the direction MEF and ITU are<br>taking here.<br><br>Aside=&gt; A slight twist on the above is where folks have considered E-NNI<br>peer interworking between *different* technologies.&nbsp; This recently came<br>up in the ITU wrt T-MPLS OAM in draft G.8114 which was undergoing AAP.<br>G.8114 contained a proposal to peer interwork T-MPLS and Ethernet<br>networks simply because they had both been 'bestowed' with similar, and<br>IMO far too complex, DP OAM.&nbsp; It should be self-evident that it is not<br>sensible to try and interwork 2 technologies that belong to different<br>network modes (simply because there will be significant functional<br>component mismatch across the DP and CP), but in any case there are no<br>end-system application to first layer network adaptations functions<br>defined for either of these technologies (noting that if these were<br>defined they would be required to either (i) pass transparently
 between<br>the 2 network peer partitions at the interworking point if common or<br>(ii) there would have to be interworking cases defined if not common).<br>It was quite evident that no thought had been given to these matters<br>whatsoever in G.8114 and so we requested that the interworking proposal<br>was removed.&nbsp; Later, and as most folks probably know by now, the AAP<br>progress of G.8114 was stopped anyway due to larger concerns that IETF<br>had on T-MPLS in general. <br><br>regards, Neil <br><br><br><br>&gt; -----Original Message-----<br>&gt; From: <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>] On Behalf Of Adrian Farrel<br>&gt; Sent: 07 April 2008 17:54<br>&gt; To: <a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a><br>&gt; Subject: Continued Poll for Adoption of Ethernet I-Ds<br>&gt; <br>&gt; <br>&gt; Hi,<br>&gt; <br>&gt; We have seen some good support for these I-Ds and no<br>&gt; objections, but I don't <br>&gt; think we have seen anything like the level of support that <br>&gt; was evident in <br>&gt; the room in Philadelphia. We haven't seen support from more <br>&gt; than half of the <br>&gt; authors of the documents.<br>&gt; <br>&gt; So, please, if you haven't already done so, give an<br>&gt; indication of whether or <br>&gt; not you support each of these four documents becoming working <br>&gt; group drafts. <br>&gt; Remember, you can be in favor of some and not other if you like.<br>&gt; <br>&gt; Thanks,<br>&gt; Adrian<br>&gt; <br>&gt; ----- Original Message -----<br>&gt; From: "Adrian Farrel" &lt;<a ymailto="mailto:[email-masked]"
 href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; To: &lt;<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>&gt;<br>&gt; Sent: Thursday, March 27, 2008 9:23 PM<br>&gt; Subject: Polling for Adoption of Ethernet I-Ds<br>&gt; <br>&gt; <br>&gt; &gt; Hi,<br>&gt; &gt;<br>&gt; &gt; From Philadelphia, we have four candidate I-Ds for adoption as CCAMP<br><br>&gt; &gt; working group documents.<br>&gt; &gt;<br>&gt; &gt; Please express your opinions.<br>&gt; &gt;<br>&gt; &gt; Note that acceptance of these I-Ds does not mean that the<br>&gt; discussion<br>&gt; &gt; about<br>&gt; &gt; the architecture is done. I think we made some progress on<br>&gt; that topic in<br>&gt; &gt; Philadelphia, and I think the authors took on the task of<br>&gt; making some<br>&gt; &gt; updates of semantics and for clarity, but I expect the<br>&gt; discussion may go<br>&gt; &gt; on for a while.<br>&gt; &gt;<br>&gt; &gt;
 draft-imajuku-ccamp-ethernet-gmpls-req-01.txt<br>&gt; &gt; draft-fedyk-gmpls-ethernet-pbb-te-02.txt<br>&gt; &gt; draft-berger-ccamp-gmpls-mef-uni-02.txt<br>&gt; &gt; draft-berger-ccamp-gmpls-ether-svcs-01.txt<br>&gt; &gt;<br>&gt; &gt; Thanks,<br>&gt; &gt; Adrian<br>&gt; &gt;<br>&gt; &gt;<br>&gt; &gt; <br>&gt; <br>&gt; <br>&gt; <br>&gt; <br><br></div><br></div></div><br>

      <hr size=1>You rock. That's why Blockbuster's offering you <a href="http://us.rd.yahoo.com/evt=47523/*http://tc.deals.yahoo.com/tc/blockbuster/text5.com">one month of Blockbuster Total Access</a>, No Cost.</body></html>
--0-1744815800-1207689395=:29318--

Delivery-date: Tue, 08 Apr 2008 20:10:25 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Editorial comment about draft-ietf-ccamp-lsp-dppm-00.txt
Date: Tue, 8 Apr 2008 21:08:11 +0100

Hi,

Here are some editorial comments for your draft. These changes will help 
your draft through the IETF process and will make it easier to review for 
others.

Cheers,
Adrian

===
Document header

s/ccamp/Network Working Group/
(This is for obscure historic reasons :-)

===
Author list

You need to reduce to a list of no more than four authors listed on the
front page. Others can continue to be listed in the section at the end
of the draft. There are two ways to handle this:
1. If some of the authros are doing most of the work, keep them on the
   front page, but remove the others.
2. If one or two people are editing the work done by the rest of the
   team, leave them on the frint page and mark them as "(Editor)".

===
Document title

s/Dynamical/Dynamic/

===
Abstract

s/for the future data transmission/for future data transmission/
s/The GMPLS/GMPLS/
s/cooperate/operate/
s/in metro area/in metro areas/

===

1.  Introduction
s/cooperate/operate/
s/This draft intends to define/This document defines/
s/The metrics defined in this draft/The metrics defined in this document/

===
1.  Introduction

   For example, an new object can be added to
   the GMPLS TE STD MIB [RFC4802] such that the current and past control
   plane performance can be monitored through network management
   systems.  The extension of TE-MIB to support the metrics defined is
   out the scope of this document.
I think that technically you cannot add objects to a defined MIB module,
but you can define extensions to a MIB module to contain new objects.

===
2.  Conventions Used in This Document

I don't think you need this text as you do not use any of the formal
language.

===
3.  Overview of Performance Metrics

I would like to see a little more introduction to what we are going to
get in sections 4 to 8, and then 9 through 12. in other words, an
overview of what is coming later so that I can navigate the rest of the
document a little more easily.

===
4.  A Singleton Definition for single unidirectional LSP Setup Delay

Can you make all section headings use captials. For example,

4.  A Singleton Definition for Single Unidirectional LSP Setup Delay

===
14.  Discussion
s/But in the draft/But in this document/

===
15.  Security Considerations

This section is a little thin!

Could the information you propose to collect be used to facilitate
attacks? For example by identifying weak spots in the network.

Could the collection of information impact the operation of the
network? If this is the case, requesting that performance behavior
is monitored and reported could be used to attack the network.

===
You are missing an IANA section.

This can simply say...

X. IANA Considerations

   This document makes no requests for IANA action.

===
17.  Normative References

[RFC2119]
You might not need this any more if you delete Section 2.

[RFC2330] This is an Informational RFC. If you can, you should make
it an Informative Reference. This is not absolutely required - if you
believe it really is normative (i.e., your document cannot be read
without reference to this RFC) then it is OK to keep it as a
Normative Reference.

Delivery-date: Tue, 08 Apr 2008 14:37:08 +0000
Date: Tue, 08 Apr 2008 23:35:17 +0900
From: "Ogaki, Kenichi" <[email-masked]>
To: [email-masked]
Subject: Re: Continued Poll for Adoption of Ethernet I-Ds

Hi,

Yes to all.

Best regards,
Kenichi

Adrian Farrel wrote:

> Hi,
>
> We have seen some good support for these I-Ds and no objections, but I 
> don't think we have seen anything like the level of support that was 
> evident in the room in Philadelphia. We haven't seen support from more 
> than half of the authors of the documents.
>
> So, please, if you haven't already done so, give an indication of 
> whether or not you support each of these four documents becoming 
> working group drafts. Remember, you can be in favor of some and not 
> other if you like.
>
> Thanks,
> Adrian
>
> ----- Original Message ----- From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, March 27, 2008 9:23 PM
> Subject: Polling for Adoption of Ethernet I-Ds
>
>
>> Hi,
>>
>> >From Philadelphia, we have four candidate I-Ds for adoption as CCAMP 
>> working group documents.
>>
>> Please express your opinions.
>>
>> Note that acceptance of these I-Ds does not mean that the discussion 
>> about the architecture is done. I think we made some progress on that 
>> topic in Philadelphia, and I think the authors took on the task of 
>> making some updates of semantics and for clarity, but I expect the 
>> discussion may go on for a while.
>>
>> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt
>> draft-fedyk-gmpls-ethernet-pbb-te-02.txt
>> draft-berger-ccamp-gmpls-mef-uni-02.txt
>> draft-berger-ccamp-gmpls-ether-svcs-01.txt
>>
>> Thanks,
>> Adrian
>>
>>
>>
>
>
>
>
>

Delivery-date: Tue, 08 Apr 2008 13:52:41 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Last Call: draft-ietf-tsvwg-rsvp-user-error-spec (User-Defined Errors for RSVP) to Proposed Standard 
Date: Tue, 8 Apr 2008 14:51:32 +0100

Note well.
Adrian
----- Original Message ----- 
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 07, 2008 2:41 PM
Subject: Last Call: draft-ietf-tsvwg-rsvp-user-error-spec (User-Defined 
Errors for RSVP) to Proposed Standard

> The IESG has received a request from the Transport Area Working Group WG
> (tsvwg) to consider the following document:
>
> - 'User-Defined Errors for RSVP '
>   <draft-ietf-tsvwg-rsvp-user-error-spec-06.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2008-04-21. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-06.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15932&rfc_flag=0
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> 

Delivery-date: Tue, 08 Apr 2008 13:13:11 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: draft-dasgupta-ccamp-path-comp-analysis-01
Date: Tue, 8 Apr 2008 14:12:17 +0100

Forwarded on behalf of Sukrit who has some posting problems...

----- Original Message ----- 
From: "Sukrit Dasgupta" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, April 07, 2008 6:43 PM
Subject: [Pce] draft-dasgupta-ccamp-path-comp-analysis-01

> Hi CCAMP and PCE
> 
> We have an ID: draft-dasgupta-ccamp-path-comp-analysis-01.txt that  
> was presented in IETF 69 at Chicago. This draft captures a  
> performance comparison of the per-domain path computation technique  
> and PCE based path computation for computing inter-domain paths. The  
> goal of this document is not to pick a winner but to shed some light  
> on a few performance metrics with simulations carried out on two  
> representative scenarios.
> 
> During the presentation at IETF69, we had positive comments and  
> support for this draft. A few comments made on the CCAMP list have  
> been incorporated.
> 
> ------------------------------------------------------------------------ 
> -----------------------------------------------------------------------
>    Abstract:
>    This document presents a performance comparison between the per-
>    domain path computation method and the Path Computation Element  
> (PCE)
>    Architecture based Backward Recursive Path Computation (BRPC)
>    procedure.  Metrics to capture the significant performance aspects
>    are identified and detailed simulations are carried out on realistic
>    scenarios.  A performance analysis for each of the path computation
>    methods is then undertaken.
> ------------------------------------------------------------------------ 
> -----------------------------------------------------------------------
> 
> ASCII version: http://www.ietf.org/internet-drafts/draft-dasgupta- 
> ccamp-path-comp-analysis-01.txt
> PDF version: http://www.ietf.org/internet-drafts/draft-dasgupta-ccamp- 
> path-comp-analysis-01.pdf
> 
> 
> It would be great if we could get some input/comments/suggestions on  
> this work from the lists so we could proceed.
> 
> Thanks and Regards,
> Sukrit

Delivery-date: Tue, 08 Apr 2008 12:55:33 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds
Date: Tue, 8 Apr 2008 13:53:22 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Yes to all
Alan=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: 07 April 2008 17:54
To: [email-masked]
Subject: Continued Poll for Adoption of Ethernet I-Ds

Hi,

We have seen some good support for these I-Ds and no objections, but I
don't think we have seen anything like the level of support that was
evident in the room in Philadelphia. We haven't seen support from more
than half of the authors of the documents.

So, please, if you haven't already done so, give an indication of
whether or not you support each of these four documents becoming working
group drafts.=20
Remember, you can be in favor of some and not other if you like.

Thanks,
Adrian

----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 27, 2008 9:23 PM
Subject: Polling for Adoption of Ethernet I-Ds

> Hi,
>
> From Philadelphia, we have four candidate I-Ds for adoption as CCAMP=20
> working group documents.
>
> Please express your opinions.
>
> Note that acceptance of these I-Ds does not mean that the discussion
about=20
> the architecture is done. I think we made some progress on that topic
in=20
> Philadelphia, and I think the authors took on the task of making some=20
> updates of semantics and for clarity, but I expect the discussion may
go=20
> on for a while.
>
> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt
> draft-fedyk-gmpls-ethernet-pbb-te-02.txt
> draft-berger-ccamp-gmpls-mef-uni-02.txt
> draft-berger-ccamp-gmpls-ether-svcs-01.txt
>
> Thanks,
> Adrian
>
>
>=20

Delivery-date: Tue, 08 Apr 2008 09:14:34 +0000
Date: Tue, 8 Apr 2008 05:11:29 -0400
From: "Andrew G. Malis" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Subject: Re: Continued Poll for Adoption of Ethernet I-Ds
Cc: [email-masked]

Adrian,

Yes to all.

Cheers,
Andy

On Mon, Apr 7, 2008 at 12:53 PM, Adrian Farrel <[email-masked]> wrote:
> Hi,
>
> We have seen some good support for these I-Ds and no objections, but I don't
> think we have seen anything like the level of support that was evident in
> the room in Philadelphia. We haven't seen support from more than half of the
> authors of the documents.
>
> So, please, if you haven't already done so, give an indication of whether or
> not you support each of these four documents becoming working group drafts.
> Remember, you can be in favor of some and not other if you like.
>
> Thanks,
> Adrian
>
> ----- Original Message ----- From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, March 27, 2008 9:23 PM
> Subject: Polling for Adoption of Ethernet I-Ds
>
>
> > Hi,
> >
> > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP
> working group documents.
> >
> > Please express your opinions.
> >
> > Note that acceptance of these I-Ds does not mean that the discussion about
> the architecture is done. I think we made some progress on that topic in
> Philadelphia, and I think the authors took on the task of making some
> updates of semantics and for clarity, but I expect the discussion may go on
> for a while.
> >
> > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt
> > draft-fedyk-gmpls-ethernet-pbb-te-02.txt
> > draft-berger-ccamp-gmpls-mef-uni-02.txt
> > draft-berger-ccamp-gmpls-ether-svcs-01.txt
> >
> > Thanks,
> > Adrian
> >
> >
> >
> >
>
>
>
>

Delivery-date: Mon, 07 Apr 2008 20:59:49 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds
Date: Mon, 7 Apr 2008 21:57:57 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Adrian,  Here is my view (with some brief rationale):

> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt

Notionally support.  One concern I have revolves around the implications
of this para:

"4.1.3 Hybrid operation with legacy Ethernet

   The solution should take into consideration the operational scenario
   that GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet
   hybrid networks. This morphs of network architecture is possible
   considering evolution scenario of Ethernet. In such networks, legacy
   Ethernet functionality such as Spanning Tree Protocol (SPT),
   Link Aggregation [IEEE802.3], and so on must co-exist with PBB-TE
   functionality.

   The solution must not prevent the simultaneous existence of GMPLS
   controlled Eth-LSPs and PBB[IEE802.1ah] or PB[IEE802.1ad] with
   native Ethernet Layer2 control protocols on same node and interface."

We must avoid the mistake that different network modes (ie cl-ps or
co-ps or co-cs) can somehow 'co-exist' in the same DP layer network (and
also have the same CP).  More specifically, native Ethernet is cl-ps and
PBB-TE is co-ps....so even though the base DP traffic unit of these 2
different network modes looks the same they MUST exist in their own
layer network space.  This requires that some (lower) server layer
network should create *different resource partitions* (in either space,
freq or time dimensions) for each client layer network mode type.

Aside=3D> For the case of private network services (which also includes
'network builder' transport services, ie how one creates client layer
network topology) we are ultimately dealing with a time varying
aggregate of message/file/stream applications.....these may not even be
supported in the immediate client layer network, but there will
ultimately be a 'very top' layer network that does support these.  So in
the server layer network what we have to deal with are (latent)
abstractions of such time varying application aggregates.  In such cases
the key behaviour that the server network must provide to the client
network is one of transparency, ie a client/server layer network
relationship must provide full functional decoupling of the client and
server layer networks.  This is not simply a technically driven
requirement but it also has commercial and (in some cases) regulatory
drivers.  Although this is a necessary condition (at least for
reachability isolation of different client service instances) it is not
generally sufficient for client service cases which require resource
isolation (ie the traffic behaviour of client service instance X cannot
impact the traffic behaviour experienced by client service instance Y).
To satisfy the latter requirement the server layer network (i) must
provide connections (ie only p2p or p2mp constructs allowed - which is
also a necessary condition) and (ii) the server layer resources should
not be overbooked (for a full sufficiency condition).  Although not all
client cases need this (strong resource isolation) service from the
server layer network, the server layer network must nevertheless have
the capability of providing it.

All these requirements are forced to be met when the server layer
technology belongs to the co-cs mode.  However, care is required when
the server layer network belongs to the co-ps mode (eg PBB-TE), eg don't
violate the rules of a connection.  And of course these requirements
cannot be assured in the cl-ps mode as this does not, by definition,
provide connections.

> draft-fedyk-gmpls-ethernet-pbb-te-02.txt

Support.  Couple of small points:
-	OAM activation/deactivation (ie CV flow) needs to be
synchronised to whatever CP or MP mechanism sets-up/tears-down ESPs for
obvious operational reasons.  Further, the CP (if ESP signalled) or MP
(if ESP provisioned) needs to tell ESP DP sink trail termination point
of the expected B-MAC SA.
-	Although IDs major on security from the perspective of malicious
attacks (on the DP/CP/MP) there is also an aspect of security related to
defects, ie customer traffic leaking from one connection into another
connection under misconnectivity defects.  A major advantage for
operators and their customers of using domain-unique (non-swapped)
labels is that misconnectivity defects are very unlikely to propagate,
and in any case are always detectable at a connection trail termination
point due to the B-MAC SA in each traffic unit. This benefit exists
without running any OAM at all.....indeed, one only requires a CV OAM
flow in PBB-TE to detect simple breaks such that they can be
distinguished from a quiescent traffic case.  This results in a
significant opex benefit since it means operators only need to run OAM
on important connections and not all connections (which is the case for
label-swapping if misconnectivity defects must be detected).  Maybe this
'security benefit' should be mentioned in the security section?

> draft-berger-ccamp-gmpls-mef-uni-02.txt
> draft-berger-ccamp-gmpls-ether-svcs-01.txt

No problems with the IDs themselves, as they are only attempting to
satisfy externally perceived requirements....but I do have a concern
with the external requirements.

When we talk about UNIs (and E-NNIs) we should be clear that we are
actually dealing with public network services and the horizontal
peer-partitioning of a single layer network between different operator
and customer parties, ie this is NOT the same as the private 'network
builder' case (briefly discussed previously) since that is based on a
vertical client/server relationship between different layer networks.  A
critical issue (usually overlooked in my experience) here is the
importance in being clear about the 'end-system message/file/stream
application to first layer network adaptation functions'.  Ethernet does
not currently define such adaptation functions for message/file/stream
applications (IP does of course with UDP, TCP and RTP respectively).  I
don't really want to go into all the detail here, but I simply want to
make the point that before folks get too carried away defining UNIs/NNIs
(for any network technology) they should be clear that this signifies a
clear intention to develop public network services and requires careful
attention to the end-system to first layer network adaptation
functions.....so it's not simply about defining interworking between CP
signalling or routing functions, or even DP OAM functions say.
Therefore, as you might guess, whilst we in IETF/CCAMPs may quite easily
define UNIs/E-NNIs for the DP (OAM) and CP say, we should also be
cognizant of the ultimate implications of the direction MEF and ITU are
taking here.

Aside=3D> A slight twist on the above is where folks have considered =
E-NNI
peer interworking between *different* technologies.  This recently came
up in the ITU wrt T-MPLS OAM in draft G.8114 which was undergoing AAP.
G.8114 contained a proposal to peer interwork T-MPLS and Ethernet
networks simply because they had both been 'bestowed' with similar, and
IMO far too complex, DP OAM.  It should be self-evident that it is not
sensible to try and interwork 2 technologies that belong to different
network modes (simply because there will be significant functional
component mismatch across the DP and CP), but in any case there are no
end-system application to first layer network adaptations functions
defined for either of these technologies (noting that if these were
defined they would be required to either (i) pass transparently between
the 2 network peer partitions at the interworking point if common or
(ii) there would have to be interworking cases defined if not common).
It was quite evident that no thought had been given to these matters
whatsoever in G.8114 and so we requested that the interworking proposal
was removed.  Later, and as most folks probably know by now, the AAP
progress of G.8114 was stopped anyway due to larger concerns that IETF
had on T-MPLS in general.=20

regards, Neil=20

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 07 April 2008 17:54
> To: [email-masked]
> Subject: Continued Poll for Adoption of Ethernet I-Ds
>=20
>=20
> Hi,
>=20
> We have seen some good support for these I-Ds and no
> objections, but I don't=20
> think we have seen anything like the level of support that=20
> was evident in=20
> the room in Philadelphia. We haven't seen support from more=20
> than half of the=20
> authors of the documents.
>=20
> So, please, if you haven't already done so, give an
> indication of whether or=20
> not you support each of these four documents becoming working=20
> group drafts.=20
> Remember, you can be in favor of some and not other if you like.
>=20
> Thanks,
> Adrian
>=20
> ----- Original Message -----
> From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, March 27, 2008 9:23 PM
> Subject: Polling for Adoption of Ethernet I-Ds
>=20
>=20
> > Hi,
> >
> > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP

> > working group documents.
> >
> > Please express your opinions.
> >
> > Note that acceptance of these I-Ds does not mean that the
> discussion
> > about
> > the architecture is done. I think we made some progress on
> that topic in
> > Philadelphia, and I think the authors took on the task of
> making some
> > updates of semantics and for clarity, but I expect the
> discussion may go
> > on for a while.
> >
> > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt
> > draft-fedyk-gmpls-ethernet-pbb-te-02.txt
> > draft-berger-ccamp-gmpls-mef-uni-02.txt
> > draft-berger-ccamp-gmpls-ether-svcs-01.txt
> >
> > Thanks,
> > Adrian
> >
> >
> >=20
>=20
>=20
>=20
>=20

Delivery-date: Mon, 07 Apr 2008 18:51:57 +0000
Content-class: urn:content-classes:message
Subject: RE: Polling for Adoption of Ethernet I-Ds
Date: Mon, 7 Apr 2008 14:49:49 -0400
From: "Hamid Ould-Brahim" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Yes to all.

Hamid.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Thursday, March 27, 2008 4:23 PM
> To: [email-masked]
> Subject: Polling for Adoption of Ethernet I-Ds
>=20
> Hi,
>=20
> From Philadelphia, we have four candidate I-Ds for adoption=20
> as CCAMP working group documents.
>=20
> Please express your opinions.
>=20
> Note that acceptance of these I-Ds does not mean that the=20
> discussion about the architecture is done. I think we made=20
> some progress on that topic in Philadelphia, and I think the=20
> authors took on the task of making some updates of semantics=20
> and for clarity, but I expect the discussion may go on for a while.
>=20
> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt
> draft-fedyk-gmpls-ethernet-pbb-te-02.txt
> draft-berger-ccamp-gmpls-mef-uni-02.txt
> draft-berger-ccamp-gmpls-ether-svcs-01.txt
>=20
> Thanks,
> Adrian=20
>=20
>=20
>=20
>=20

Delivery-date: Mon, 07 Apr 2008 16:55:22 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Continued Poll for Adoption of Ethernet I-Ds
Date: Mon, 7 Apr 2008 17:53:38 +0100

Hi,

We have seen some good support for these I-Ds and no objections, but I don't 
think we have seen anything like the level of support that was evident in 
the room in Philadelphia. We haven't seen support from more than half of the 
authors of the documents.

So, please, if you haven't already done so, give an indication of whether or 
not you support each of these four documents becoming working group drafts. 
Remember, you can be in favor of some and not other if you like.

Thanks,
Adrian

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 27, 2008 9:23 PM
Subject: Polling for Adoption of Ethernet I-Ds

> Hi,
>
> From Philadelphia, we have four candidate I-Ds for adoption as CCAMP 
> working group documents.
>
> Please express your opinions.
>
> Note that acceptance of these I-Ds does not mean that the discussion about 
> the architecture is done. I think we made some progress on that topic in 
> Philadelphia, and I think the authors took on the task of making some 
> updates of semantics and for clarity, but I expect the discussion may go 
> on for a while.
>
> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt
> draft-fedyk-gmpls-ethernet-pbb-te-02.txt
> draft-berger-ccamp-gmpls-mef-uni-02.txt
> draft-berger-ccamp-gmpls-ether-svcs-01.txt
>
> Thanks,
> Adrian
>
>
> 

Delivery-date: Mon, 07 Apr 2008 12:59:09 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Acee Lindem" <[email-masked]>
Cc: "CCAMP List" <[email-masked]>, "OSPF List" <[email-masked]>
Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions toOSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt
Date: Mon, 7 Apr 2008 13:56:08 +0100

Thanks Acee,

That does the job.

Adrian
----- Original Message ----- 
From: "Acee Lindem" <[email-masked]>
Cc: "CCAMP List" <[email-masked]>; "OSPF List" <[email-masked]>
Sent: Sunday, April 06, 2008 12:15 PM
Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions 
toOSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt

> Alan Davey pointed out that I was missing the word "is" in my text. I
> went ahead with a more verbose explanation of the protocol differences.
>
> ***************
> *** 342,348 ****
>      The Link TLV describes a single link and consists of a set of sub-
>      TLVs [TE].  All of the sub-TLVs in [TE] other than the Link ID
> sub-
>      TLV are applicable to OSPFv3.  The Link ID sub-TLV can't be
> used in
> !    OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3.
>
>      Three new sub-TLVs for the Link TLV are defined:
>
> --- 342,356 ----
>      The Link TLV describes a single link and consists of a set of sub-
>      TLVs [TE].  All of the sub-TLVs in [TE] other than the Link ID
> sub-
>      TLV are applicable to OSPFv3.  The Link ID sub-TLV can't be
> used in
> !    OSPFv3 since it is defined to use the OSPFv2 identification for the
> !    Designated Router (DR) on multi-access networks.  In OSPFv2,
> !    neighbors on point-to-point networks and virtual links are
> identified
> !    by their Router IDs while neighbors on broadcast, Non-Broadcast
> !    Multi-Access (NBMA), and Point-to-Multipoint links are
> identified by
> !    their IPv4 interface addresses (Refer to section 8.2 in [OSPFV2]).
> !    The IPv4 interface address is not known to OSPFv3.  In contrast to
> !    OSPFv2, OSPFv3 always identifies neighboring routers by their
> Router
> !    IDs (Refer to section 2.11 in [OSPFV3]).
>
>      Three new sub-TLVs for the Link TLV are defined:
>
> ***************
>
>
> On Apr 5, 2008, at 12:51 PM, Acee Lindem wrote:
>
>> Adrian,
>>
>> How's this:
>>
>> ***************
>> *** 342,348 ****
>>       The Link TLV describes a single link and consists of a set of
>> sub-
>>       TLVs [TE].  All of the sub-TLVs in [TE] other than the Link ID
>> sub-
>>       TLV are applicable to OSPFv3.  The Link ID sub-TLV can't be
>> used in
>> !    OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3.
>>
>>       Three new sub-TLVs for the Link TLV are defined:
>>
>> --- 342,351 ----
>>       The Link TLV describes a single link and consists of a set of
>> sub-
>>       TLVs [TE].  All of the sub-TLVs in [TE] other than the Link ID
>> sub-
>>       TLV are applicable to OSPFv3.  The Link ID sub-TLV can't be
>> used in
>> !    OSPFv3 since it defined to contain the IPv4 address of the
>> Designated
>> !    Router (DR) for multi-access interfaces.  In contrast to OSPFv2,
>> !    OSPFv3 always identifies a neighboring router by the Router ID
>> (Refer
>> !    to section 2.11 in [OSPFV3]).
>>
>>       Three new sub-TLVs for the Link TLV are defined:
>>
>> ***************
>>
>> I plan to wait until the WG last call has completed to submit the
>> update.
>> Thanks,
>> Acee
>>
>> On Apr 5, 2008, at 11:50 AM, Acee Lindem wrote:
>>
>>> Hi Adrian,
>>>
>>> Thanks for the review.
>>>
>>> On Apr 4, 2008, at 3:56 PM, Adrian Farrel wrote:
>>>
>>>> Hi,
>>>>
>>>> Just a couple of comments...
>>>>
>>>> ===
>>>> Section 1
>>>> s/proposes the addition of/defines/
>>>
>>> Changed.
>>>
>>>
>>>> ===
>>>> Section 4
>>>> Forgive me for not remembering this discussion...
>>>> The draft says that we cannot use the Link ID sub-TLV "due to the
>>>> protocol
>>>> differences."
>>>
>>> The link-ID is cannot be used since, in the case of multi-access
>>> network, it contains the IPv4 address of the Designated Router (DR).
>>> OSPFv3 doesn't have this information.
>>>
>>>
>>>> It then says that the Link ID sub-TLV SHOULD NOT be included
>>>> (implying that
>>>> it MAY be included under certain circumstances) but MUST be ignored.
>>>
>>> This is the spirit of being conservative in what one sends and
>>> liberal in what one excepts.
>>>
>>>
>>>
>>>> 1. Does ignored mean "continue to be flooded" or "stripped from the
>>>> LSA"?
>>>
>>> In OSPF, only the originator should modify an LSA. So, it means
>>> neither.
>>>
>>>
>>>
>>>> 2. Is it not possible to consider operating a GMPLS control plane
>>>> in an IPv6
>>>> network where the routers use IPv6 addresses to communicate (so all
>>>> control
>>>> plane messages will be addressed using IPv6, and the router address
>>>> will be
>>>> IPv6 as described in Section 3) but where the data channel
>>>> identifiers are
>>>> assigned from an IPv4 address space? Recall that in GMPLS the
>>>> interfaces
>>>> used for OSPF exchange are not those used for data exchange.
>>>
>>> I believe it is probable that IPv4 and IPv6 will coexist. However,
>>> OSPFv3 doesn't know the IPv4 address of the DR (at least it is not
>>> standardized). Hence, this isn't the right sub-TLV to reflect this
>>> topology.
>>>
>>>
>>>
>>>>
>>>> Whatever the answers, I think it would help if the reasons were
>>>> clarified
>>>> beyond "protocol differences."
>>>
>>> I'll expand this to describe the multi-access network case. Sound
>>> good?
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>>
>>>> ===
>>>>
>>>> Cheers,
>>>> Adrian
>>>>
>>>> PS I wouldn't mind if you spelled my name right in the acks
>>>> section :-)
>>>>
>>>>
>>>> _______________________________________________
>>>> OSPF mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ospf
>>
>> _______________________________________________
>> OSPF mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
> 

Delivery-date: Mon, 07 Apr 2008 02:14:14 +0000
Date: Mon, 07 Apr 2008 10:11:00 +0800
From: Mach Chen <[email-masked]>
Subject: Re: Re: [OSPF] CCAMP last call on advertisement of inter-AS TE links
To: Acee Lindem <[email-masked]>, Adrian Farrel <[email-masked]>
Cc: OSPF List <[email-masked]>, CCAMP List <[email-masked]>
Organization: Huawei

Hi Acee,

Thanks for your review and comments! 

Since there are no technical issues, I will update the I-D until the end of the WG last call.
  
On 2008-04-04, at 22:49:13 Acee Lindem wrote:

>I can't speak for the OSPF WG as a whole, but I have reviewed the  
>subject document and am very happy to see that the suggestion to use  
>separate inter-AS LSA types has been incorporated. I have no further  
>technical comments on the document and trust that the ccamp WG has  
>verified that this information encoding meets the TE requirements.  
>The usage described in sections 2.2 and 2.3 seem reasonable to me.
>
>I have the following editorial comments:
>
>   1. Sections 3.3.2 and 3.3.2 - Both of these say "Use of the TE  
>Router ID is RECOMMENDED." I believe these should be respectively  
>replaced by "Use of the TE Router Address as specified in the Router  
>Address TLV [OSPF-TE] is RECOMMENDED." and "Use of the TE Router IPv6  
>Address as specified in the IPv6 Router Address as specified in the  
>IPv6 Router Address TLV [OSPF-V3-TE] is RECOMMENDED."
>   2. Section 3.2.1 states "This is because... that may operate in a  
>different address space;". If they are using a different address  
>space on the link between the ASes, then I'd expect there to be  
>problems with BGP as well :^) I'd suggest:
>       "Given that OSPF is an IGP and should only be utilized between  
>routers in the same routing domain, the OSPF specific Link ID and  
>Neighbor ID sub-TLVs are not applicable to inter-AS links.".
>   3. You may want to expand some acronyms on their first use. For  
>example, "AS Boundary Router (ASBR)", "Link State Advertisement  
>(LSA)" and
>      "Path Computation Element (PCE)".
>   4. [OSPFV3] is listed to as both a Normative and Informative  
>reference.
>
>Thanks,
>Acee
>
>On Mar 19, 2008, at 2:06 PM, Adrian Farrel wrote:
>
>> Hi,
>>
>> You may recall providing useful review and feedback on
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- 
>> te-extension-02.txt
>>
>> The authors believe that they have taken on board all the comments  
>> received
>> from the OSPF working group and have updated the draft accordingly.
>>
>>
>> CCAMP is holding a three week working group last call on this I-D  
>> along with
>> its IS-IS partner document:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas- 
>> te-extension-00.txt
>>
>> These documents describe how to advertise the TE links that connect  
>> an AS to
>> the outside world within the AS's IGP. As the drafts are at pains  
>> to point
>> out, there is no proposal to advertise the TE information more  
>> widely (such
>> as to other ASes).
>>
>> The last call will end at 12 noon BST on April 9th 2008.
>>
>> Please send your comments to the CCAMP list or direct to the CCAMP  
>> chairs.
>>
>> Thanks,
>> Adrian and Deborah
>>
>>
>> _______________________________________________
>> OSPF mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ospf
>
>

Best regards,			
Mach Chen

Delivery-date: Sun, 06 Apr 2008 11:17:33 +0000
Cc: CCAMP List <[email-masked]>, OSPF List <[email-masked]>
From: Acee Lindem <[email-masked]>
Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions to OSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt
Date: Sun, 6 Apr 2008 07:15:18 -0400

Alan Davey pointed out that I was missing the word "is" in my text. I  
went ahead with a more verbose explanation of the protocol differences.

***************
*** 342,348 ****
      The Link TLV describes a single link and consists of a set of sub-
      TLVs [TE].  All of the sub-TLVs in [TE] other than the Link ID  
sub-
      TLV are applicable to OSPFv3.  The Link ID sub-TLV can't be  
used in
!    OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3.

      Three new sub-TLVs for the Link TLV are defined:

--- 342,356 ----
      The Link TLV describes a single link and consists of a set of sub-
      TLVs [TE].  All of the sub-TLVs in [TE] other than the Link ID  
sub-
      TLV are applicable to OSPFv3.  The Link ID sub-TLV can't be  
used in
!    OSPFv3 since it is defined to use the OSPFv2 identification for the
!    Designated Router (DR) on multi-access networks.  In OSPFv2,
!    neighbors on point-to-point networks and virtual links are  
identified
!    by their Router IDs while neighbors on broadcast, Non-Broadcast
!    Multi-Access (NBMA), and Point-to-Multipoint links are  
identified by
!    their IPv4 interface addresses (Refer to section 8.2 in [OSPFV2]).
!    The IPv4 interface address is not known to OSPFv3.  In contrast to
!    OSPFv2, OSPFv3 always identifies neighboring routers by their  
Router
!    IDs (Refer to section 2.11 in [OSPFV3]).

      Three new sub-TLVs for the Link TLV are defined:

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

On Apr 5, 2008, at 12:51 PM, Acee Lindem wrote:

> Adrian,
>
> How's this:
>
> ***************
> *** 342,348 ****
>       The Link TLV describes a single link and consists of a set of  
> sub-
>       TLVs [TE].  All of the sub-TLVs in [TE] other than the Link ID
> sub-
>       TLV are applicable to OSPFv3.  The Link ID sub-TLV can't be
> used in
> !    OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3.
>
>       Three new sub-TLVs for the Link TLV are defined:
>
> --- 342,351 ----
>       The Link TLV describes a single link and consists of a set of  
> sub-
>       TLVs [TE].  All of the sub-TLVs in [TE] other than the Link ID
> sub-
>       TLV are applicable to OSPFv3.  The Link ID sub-TLV can't be
> used in
> !    OSPFv3 since it defined to contain the IPv4 address of the
> Designated
> !    Router (DR) for multi-access interfaces.  In contrast to OSPFv2,
> !    OSPFv3 always identifies a neighboring router by the Router ID
> (Refer
> !    to section 2.11 in [OSPFV3]).
>
>       Three new sub-TLVs for the Link TLV are defined:
>
> ***************
>
> I plan to wait until the WG last call has completed to submit the
> update.
> Thanks,
> Acee
>
> On Apr 5, 2008, at 11:50 AM, Acee Lindem wrote:
>
>> Hi Adrian,
>>
>> Thanks for the review.
>>
>> On Apr 4, 2008, at 3:56 PM, Adrian Farrel wrote:
>>
>>> Hi,
>>>
>>> Just a couple of comments...
>>>
>>> ===
>>> Section 1
>>> s/proposes the addition of/defines/
>>
>> Changed.
>>
>>
>>> ===
>>> Section 4
>>> Forgive me for not remembering this discussion...
>>> The draft says that we cannot use the Link ID sub-TLV "due to the
>>> protocol
>>> differences."
>>
>> The link-ID is cannot be used since, in the case of multi-access
>> network, it contains the IPv4 address of the Designated Router (DR).
>> OSPFv3 doesn't have this information.
>>
>>
>>> It then says that the Link ID sub-TLV SHOULD NOT be included
>>> (implying that
>>> it MAY be included under certain circumstances) but MUST be ignored.
>>
>> This is the spirit of being conservative in what one sends and
>> liberal in what one excepts.
>>
>>
>>
>>> 1. Does ignored mean "continue to be flooded" or "stripped from the
>>> LSA"?
>>
>> In OSPF, only the originator should modify an LSA. So, it means
>> neither.
>>
>>
>>
>>> 2. Is it not possible to consider operating a GMPLS control plane
>>> in an IPv6
>>> network where the routers use IPv6 addresses to communicate (so all
>>> control
>>> plane messages will be addressed using IPv6, and the router address
>>> will be
>>> IPv6 as described in Section 3) but where the data channel
>>> identifiers are
>>> assigned from an IPv4 address space? Recall that in GMPLS the
>>> interfaces
>>> used for OSPF exchange are not those used for data exchange.
>>
>> I believe it is probable that IPv4 and IPv6 will coexist. However,
>> OSPFv3 doesn't know the IPv4 address of the DR (at least it is not
>> standardized). Hence, this isn't the right sub-TLV to reflect this
>> topology.
>>
>>
>>
>>>
>>> Whatever the answers, I think it would help if the reasons were
>>> clarified
>>> beyond "protocol differences."
>>
>> I'll expand this to describe the multi-access network case. Sound
>> good?
>>
>> Thanks,
>> Acee
>>
>>
>>
>>> ===
>>>
>>> Cheers,
>>> Adrian
>>>
>>> PS I wouldn't mind if you spelled my name right in the acks
>>> section :-)
>>>
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ospf
>>
>> _______________________________________________
>> OSPF mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

Delivery-date: Sat, 05 Apr 2008 16:51:55 +0000
Cc: Adrian Farrel <[email-masked]>, CCAMP List <[email-masked]>, OSPF List <[email-masked]>
From: Acee Lindem <[email-masked]>
Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions to OSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt
Date: Sat, 5 Apr 2008 12:51:00 -0400

Adrian,

How's this:

***************
*** 342,348 ****
      The Link TLV describes a single link and consists of a set of sub-
      TLVs [TE].  All of the sub-TLVs in [TE] other than the Link ID  
sub-
      TLV are applicable to OSPFv3.  The Link ID sub-TLV can't be  
used in
!    OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3.

      Three new sub-TLVs for the Link TLV are defined:

--- 342,351 ----
      The Link TLV describes a single link and consists of a set of sub-
      TLVs [TE].  All of the sub-TLVs in [TE] other than the Link ID  
sub-
      TLV are applicable to OSPFv3.  The Link ID sub-TLV can't be  
used in
!    OSPFv3 since it defined to contain the IPv4 address of the  
Designated
!    Router (DR) for multi-access interfaces.  In contrast to OSPFv2,
!    OSPFv3 always identifies a neighboring router by the Router ID  
(Refer
!    to section 2.11 in [OSPFV3]).

      Three new sub-TLVs for the Link TLV are defined:

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

I plan to wait until the WG last call has completed to submit the  
update.
Thanks,
Acee

On Apr 5, 2008, at 11:50 AM, Acee Lindem wrote:

> Hi Adrian,
>
> Thanks for the review.
>
> On Apr 4, 2008, at 3:56 PM, Adrian Farrel wrote:
>
>> Hi,
>>
>> Just a couple of comments...
>>
>> ===
>> Section 1
>> s/proposes the addition of/defines/
>
> Changed.
>
>
>> ===
>> Section 4
>> Forgive me for not remembering this discussion...
>> The draft says that we cannot use the Link ID sub-TLV "due to the
>> protocol
>> differences."
>
> The link-ID is cannot be used since, in the case of multi-access
> network, it contains the IPv4 address of the Designated Router (DR).
> OSPFv3 doesn't have this information.
>
>
>> It then says that the Link ID sub-TLV SHOULD NOT be included
>> (implying that
>> it MAY be included under certain circumstances) but MUST be ignored.
>
> This is the spirit of being conservative in what one sends and
> liberal in what one excepts.
>
>
>
>> 1. Does ignored mean "continue to be flooded" or "stripped from the
>> LSA"?
>
> In OSPF, only the originator should modify an LSA. So, it means  
> neither.
>
>
>
>> 2. Is it not possible to consider operating a GMPLS control plane
>> in an IPv6
>> network where the routers use IPv6 addresses to communicate (so all
>> control
>> plane messages will be addressed using IPv6, and the router address
>> will be
>> IPv6 as described in Section 3) but where the data channel
>> identifiers are
>> assigned from an IPv4 address space? Recall that in GMPLS the
>> interfaces
>> used for OSPF exchange are not those used for data exchange.
>
> I believe it is probable that IPv4 and IPv6 will coexist. However,
> OSPFv3 doesn't know the IPv4 address of the DR (at least it is not
> standardized). Hence, this isn't the right sub-TLV to reflect this
> topology.
>
>
>
>>
>> Whatever the answers, I think it would help if the reasons were
>> clarified
>> beyond "protocol differences."
>
> I'll expand this to describe the multi-access network case. Sound  
> good?
>
> Thanks,
> Acee
>
>
>
>> ===
>>
>> Cheers,
>> Adrian
>>
>> PS I wouldn't mind if you spelled my name right in the acks
>> section :-)
>>
>>
>> _______________________________________________
>> OSPF mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

Delivery-date: Sat, 05 Apr 2008 15:53:26 +0000
Cc: "OSPF List" <[email-masked]>, CCAMP List <[email-masked]>
From: Acee Lindem <[email-masked]>
Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions to OSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt
Date: Sat, 5 Apr 2008 11:50:25 -0400
To: Adrian Farrel <[email-masked]>

Hi Adrian,

Thanks for the review.

On Apr 4, 2008, at 3:56 PM, Adrian Farrel wrote:

> Hi,
>
> Just a couple of comments...
>
> ===
> Section 1
> s/proposes the addition of/defines/

Changed.

> ===
> Section 4
> Forgive me for not remembering this discussion...
> The draft says that we cannot use the Link ID sub-TLV "due to the  
> protocol
> differences."

The link-ID is cannot be used since, in the case of multi-access  
network, it contains the IPv4 address of the Designated Router (DR).  
OSPFv3 doesn't have this information.

> It then says that the Link ID sub-TLV SHOULD NOT be included  
> (implying that
> it MAY be included under certain circumstances) but MUST be ignored.

This is the spirit of being conservative in what one sends and  
liberal in what one excepts.

> 1. Does ignored mean "continue to be flooded" or "stripped from the  
> LSA"?

In OSPF, only the originator should modify an LSA. So, it means neither.

> 2. Is it not possible to consider operating a GMPLS control plane  
> in an IPv6
> network where the routers use IPv6 addresses to communicate (so all  
> control
> plane messages will be addressed using IPv6, and the router address  
> will be
> IPv6 as described in Section 3) but where the data channel  
> identifiers are
> assigned from an IPv4 address space? Recall that in GMPLS the  
> interfaces
> used for OSPF exchange are not those used for data exchange.

I believe it is probable that IPv4 and IPv6 will coexist. However,  
OSPFv3 doesn't know the IPv4 address of the DR (at least it is not  
standardized). Hence, this isn't the right sub-TLV to reflect this  
topology.

>
> Whatever the answers, I think it would help if the reasons were  
> clarified
> beyond "protocol differences."

I'll expand this to describe the multi-access network case. Sound good?

Thanks,
Acee

> ===
>
> Cheers,
> Adrian
>
> PS I wouldn't mind if you spelled my name right in the acks  
> section :-)
>
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

Delivery-date: Fri, 04 Apr 2008 19:58:45 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "OSPF List" <[email-masked]>
Cc: "CCAMP List" <[email-masked]>
Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions to OSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt
Date: Fri, 4 Apr 2008 20:56:01 +0100

Hi,

Just a couple of comments...

===
Section 1
s/proposes the addition of/defines/
===
Section 4
Forgive me for not remembering this discussion...
The draft says that we cannot use the Link ID sub-TLV "due to the protocol 
differences."
It then says that the Link ID sub-TLV SHOULD NOT be included (implying that 
it MAY be included under certain circumstances) but MUST be ignored.
1. Does ignored mean "continue to be flooded" or "stripped from the LSA"?
2. Is it not possible to consider operating a GMPLS control plane in an IPv6 
network where the routers use IPv6 addresses to communicate (so all control 
plane messages will be addressed using IPv6, and the router address will be 
IPv6 as described in Section 3) but where the data channel identifiers are 
assigned from an IPv4 address space? Recall that in GMPLS the interfaces 
used for OSPF exchange are not those used for data exchange.

Whatever the answers, I think it would help if the reasons were clarified 
beyond "protocol differences."
===

Cheers,
Adrian

PS I wouldn't mind if you spelled my name right in the acks section :-) 

Delivery-date: Fri, 04 Apr 2008 14:48:41 +0000
Cc: OSPF List <[email-masked]>, CCAMP List <[email-masked]>
From: Acee Lindem <[email-masked]>
Subject: Re: [OSPF] CCAMP last call on advertisement of inter-AS TE links
Date: Fri, 4 Apr 2008 10:46:16 -0400
To: Adrian Farrel <[email-masked]>

I can't speak for the OSPF WG as a whole, but I have reviewed the  
subject document and am very happy to see that the suggestion to use  
separate inter-AS LSA types has been incorporated. I have no further  
technical comments on the document and trust that the ccamp WG has  
verified that this information encoding meets the TE requirements.  
The usage described in sections 2.2 and 2.3 seem reasonable to me.

I have the following editorial comments:

   1. Sections 3.3.2 and 3.3.2 - Both of these say "Use of the TE  
Router ID is RECOMMENDED." I believe these should be respectively  
replaced by "Use of the TE Router Address as specified in the Router  
Address TLV [OSPF-TE] is RECOMMENDED." and "Use of the TE Router IPv6  
Address as specified in the IPv6 Router Address as specified in the  
IPv6 Router Address TLV [OSPF-V3-TE] is RECOMMENDED."
   2. Section 3.2.1 states "This is because... that may operate in a  
different address space;". If they are using a different address  
space on the link between the ASes, then I'd expect there to be  
problems with BGP as well :^) I'd suggest:
       "Given that OSPF is an IGP and should only be utilized between  
routers in the same routing domain, the OSPF specific Link ID and  
Neighbor ID sub-TLVs are not applicable to inter-AS links.".
   3. You may want to expand some acronyms on their first use. For  
example, "AS Boundary Router (ASBR)", "Link State Advertisement  
(LSA)" and
      "Path Computation Element (PCE)".
   4. [OSPFV3] is listed to as both a Normative and Informative  
reference.

Thanks,
Acee

On Mar 19, 2008, at 2:06 PM, Adrian Farrel wrote:

> Hi,
>
> You may recall providing useful review and feedback on
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- 
> te-extension-02.txt
>
> The authors believe that they have taken on board all the comments  
> received
> from the OSPF working group and have updated the draft accordingly.
>
>
> CCAMP is holding a three week working group last call on this I-D  
> along with
> its IS-IS partner document:
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas- 
> te-extension-00.txt
>
> These documents describe how to advertise the TE links that connect  
> an AS to
> the outside world within the AS's IGP. As the drafts are at pains  
> to point
> out, there is no proposal to advertise the TE information more  
> widely (such
> as to other ASes).
>
> The last call will end at 12 noon BST on April 9th 2008.
>
> Please send your comments to the CCAMP list or direct to the CCAMP  
> chairs.
>
> Thanks,
> Adrian and Deborah
>
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

Delivery-date: Fri, 04 Apr 2008 09:45:33 +0000
Date: Fri, 04 Apr 2008 11:42:07 +0200
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: [email-masked], ccamp <[email-masked]>, [email-masked],  pwe3 <[email-masked]>, L2VPN <[email-masked]>
CC: David Ward <[email-masked]>, Ross Callon <[email-masked]>,  George Swallow <[email-masked]>
Subject: conclusion on the status of Y.1711 and RFC3429

All,

on March 28 the MPLS WG chairs polled the several working
group mailing lists about the state of Y.1711 and RFC3429
implementations and deployments.

Our conclusion is that there is enough implementations and
deployments of Y.1711 and hence it is not possible to, for
time being, deprecate label 14 or obsolete RFC3429.

This conclusion however leaves with the issue of investigating
if Y.1711, other ITU-T documents and RFC3429 is well enough
aligned or if updates is needed.

Loa and George

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Delivery-date: Thu, 03 Apr 2008 11:40:49 +0000
Content-Class: urn:content-classes:message
Subject: RE: Question on the status of Y.1711 and RFC3429
Date: Thu, 3 Apr 2008 14:38:30 +0300
From: Alexander Vainshtein <[email-masked]>
To: "Loa Andersson" <[email-masked]>, <[email-masked]>, <[email-masked]>
CC: "Ross Callon" <[email-masked]>, "David Ward" <[email-masked]>, "pwe3" <[email-masked]>, <[email-masked]>, "L2VPN" <[email-masked]>, "ccamp" <[email-masked]>

Loa, George and all,
ECI Telecom has implemented ITU-T recommendation Y.1711 using=20
Label 14 as defined in RFC 3429 in its XDM (TM) products family.=20

The corresponding products have been deployed in live=20
networks, and their Y.1711-related functionality is now in=20
operational use.

Based on this, we (ECI) object to deprecation of the Label 14=20
allocation that is currently defined in RFC 3429 and suggests using
a different reserved label value for T-MPLS needs.

Regards,
                   Sasha=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> On Behalf Of Loa Andersson
> Sent: Friday, March 28, 2008 11:50 AM
> To: [email-masked]; pwe3; [email-masked]; L2VPN; ccamp
> Cc: Ross Callon; David Ward
> Subject: Question on the status of Y.1711 and RFC3429
>=20
> All,
>=20
> In the discussions the IETF and the ITU-T have had on T-MPLS we have
> discussed the intended use for label 14 and the different documents
> where this has been specified.
>=20
> As a side effect we've also started to ask ourselves if there are any
> implementations and/or deployments that uses label 14.
>=20
> A quick survey among known implementers of MPLS has not shown any
> implementations/deployments.
>=20
> Since one of the approaches discussed in the Joint Working Team
> context is a solution that requires the allocation of a reserved
> label and reserved labels are a scarce resource we'd like to know
> if it possible to redefine label 14 for that particular use.
>=20
> There are still technical issues to be sorted out with the suggested
> approach, but in the mean time we would like to know if it is possible
> to deprecate RFC3429 and redefine the OAM Alert Label.
>=20
> The questions is: "Are there any implementations/deployments of Y.1711
> or the OAM Alert label as it is allocated in RFC3429; and is there
> objection to deprecating the protocol as it stands today?"
>=20
> ITU-T has sent out a question along the same lines, see the included
> mail below.
>=20
> Please respond to the mpls working group mailing list or to the mpls
> working chairs directly. As usual non-responses will be counted as
> that there is no implementation/deployment.
>=20
> Loa and George
>=20
>=20
> ------------------- included mail ------------------------------------
>=20
> All users/implementers of recommendation Y.1711,
>=20
> Currently the Joint Working Team of ITU-T and IETF experts is
> considering the options of using IETF mechanisms to provide
> OAM for T-MPLS.
>=20
> One possibility is the following mechanism:
> -------------------------------------------
> Push/pop a label at the MEP/domain boundary.
>=20
> This makes the OAM alert label directly visible at the
> sink MEP.
>=20
> To make the OAM label visible to a MIP the TTL in the server
> (lower) layer is set by the MEP to expire when the OAM frame
> reaches the intended MIP.
>=20
> The OAM alert label will point to an "opcode" at the bottom
> of the stack.
> ------------------------------------------
>=20
> This behaviour (when the OAM alert label is received) is not
> consistent with the behaviour currently defined in Y.1711 when
> label 14 is received.
>=20
> *QUESTION* are there any users/implementers of the current Y.1711
> concerned with this change in behaviour?
>=20
> If there are no concerns then recommendation Y.1711 can be
> withdrawn or revised to describe the desired behaviour (described
> above).
>=20
> Please send me (or this list) your response ASAP.
>=20
> Kind regards, Huub van Helvoort, your rapporteur.
>=20
> --=20
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  [email-masked]
>                                             [email-masked]
>=20

Delivery-date: Tue, 01 Apr 2008 00:59:26 +0000
Date: Tue, 01 Apr 2008 09:57:15 +0900
From: Tomohiro Otani <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: Re: Polling for Adoption of Ethernet I-Ds

Hello everyone,

I support these documents for adoption as WG documents in ccamp WG.

Regards,

Tomo

Adrian Farrel =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=
=97=E3=81=9F:
> Hi,
>
>> From Philadelphia, we have four candidate I-Ds for adoption as CCAMP=20
>> working=20
> group documents.
>
> Please express your opinions.
>
> Note that acceptance of these I-Ds does not mean that the discussion=20
> about the architecture is done. I think we made some progress on that=20
> topic in Philadelphia, and I think the authors took on the task of=20
> making some updates of semantics and for clarity, but I expect the=20
> discussion may go on for a while.
>
> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt
> draft-fedyk-gmpls-ethernet-pbb-te-02.txt
> draft-berger-ccamp-gmpls-mef-uni-02.txt
> draft-berger-ccamp-gmpls-ether-svcs-01.txt
>
> Thanks,
> Adrian
>
>
>
>