Re: Polling for Adoption of Ethernet I-Ds

[Tomohiro Otani <[e-mail]>]

Hello everyone,

I support these documents for adoption as WG documents in ccamp WG.

Regards,

Tomo


Adrian Farrel さんは書きました:
> 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
>
>
>
>






Envelope-to: [e-mail]
Delivery-date: Mon, 31 Mar 2008 19:45:36 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Polling for Adoption of Ethernet I-Ds
Date: Mon, 31 Mar 2008 15:43:36 -0400
Message-ID: <[e-mail]>
Thread-Topic: Polling for Adoption of Ethernet I-Ds
Thread-Index: AciQSRghVH2dZFb6QgGijAbZ0S2Z5ADHmCLA
From: "Shah, Himanshu" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

support all..

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Thursday, March 27, 2008 4:23 PM
> To: [e-mail]
> 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 
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Mon, 31 Mar 2008 17:38:32 +0000
Mime-Version: 1.0 (Apple Message framework v753)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: Alan Davey <[e-mail]>, Vishwas Manral <[e-mail]>, David Ward <[e-mail]>, Ross Callon <[e-mail]>, CCAMP List <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Acee Lindem <[e-mail]>
Subject: OSPF WG Last Call for Traffic Engineering Extensions to OSPF version 3 - draft-ietf-ospf-ospfv3-traffic-10.txt 
Date: Mon, 31 Mar 2008 13:36:31 -0400
To: OSPF List <[e-mail]>

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



Envelope-to: [e-mail]
Delivery-date: Mon, 31 Mar 2008 07:39:51 +0000
Message-ID: <[e-mail]>
Date: Mon, 31 Mar 2008 08:36:53 +0200
From: Gino Carrozzo <[e-mail]>
User-Agent: Thunderbird 2.0.0.5 (X11/20070730)
MIME-Version: 1.0
CC:  [e-mail]
Subject: Re: Polling for Adoption of Ethernet I-Ds
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Yes to all

best regards

Gino

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
> 
> 



Envelope-to: [e-mail]
Delivery-date: Mon, 31 Mar 2008 01:26:31 +0000
Date: Mon, 31 Mar 2008 09:24:04 +0800
From: Dan Li <[e-mail]>
Subject: Re: Polling for Adoption of Ethernet I-Ds
To: Adrian Farrel <[e-mail]>, [e-mail]
Message-id: <006701c892cd$e8a4e210$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Yes to all.

Dan

----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Friday, March 28, 2008 4:23 AM
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 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Mar 2008 18:48:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Polling for Adoption of Ethernet I-Ds
Date: Fri, 28 Mar 2008 19:35:43 +0100
Message-ID: <[e-mail]>
Thread-Topic: Polling for Adoption of Ethernet I-Ds
Thread-Index: AciQSkqo3/m834qYTA6Sent4V47bhAAuASQQ
From: "Attila Takacs" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Yes to all.

Best regards,
Attila 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Thursday, March 27, 2008 9:23 PM
> To: [e-mail]
> 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 
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Mar 2008 16:53:20 +0000
Message-ID: <[e-mail]>
Date: Fri, 28 Mar 2008 09:51:53 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail]
Subject: Re: Polling for Adoption of Ethernet I-Ds
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Yes to all.

Greg B.

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
>
>
>

-- 
=========================Dr Greg Bernstein, Grotto Networking [phone]





Envelope-to: [e-mail]
Delivery-date: Fri, 28 Mar 2008 15:29:54 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Polling for Adoption of Ethernet I-Ds
Date: Fri, 28 Mar 2008 11:29:24 -0400
Message-ID: <[e-mail]>
Thread-Topic: Polling for Adoption of Ethernet I-Ds
Thread-Index: AciQSzgUEvzHhLaRSmmeexaI37kphgAnTgGA
From: "Don Fedyk" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Yes, support for all,

Don  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Thursday, March 27, 2008 4:23 PM
> To: [e-mail]
> 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 
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Mar 2008 15:25:13 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Polling for Adoption of Ethernet I-Ds
Date: Fri, 28 Mar 2008 15:57:43 +0100
Message-ID: <[e-mail]>
Thread-Topic: Polling for Adoption of Ethernet I-Ds
thread-index: AciQSksYi90YiUO+TDKHZRbx29AHfgAmcMzg
From: "Diego Caviglia" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Hi yes to all.

BR

Diego 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: giovedì 27 marzo 2008 21.23
> To: [e-mail]
> 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 
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Mar 2008 14:59:33 +0000
Date: Fri, 28 Mar 2008 10:58:37 -0400
To: "Adrian Farrel" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: Polling for Adoption of Ethernet I-Ds
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <[e-mail]>

I support adoption of all (no surprise here).

Lou

At 04:23 PM 3/27/2008, 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
>
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 28 Mar 2008 14:50:26 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Polling for Adoption of Ethernet I-Ds
Date: Fri, 28 Mar 2008 10:48:13 -0400
Message-ID: <[e-mail]>
Thread-Topic: Polling for Adoption of Ethernet I-Ds
thread-index: AciQSRVcK0EYNZACS2yQceVzV3XhvwAmZHwg
From: "Ong, Lyndon" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Yes on all four drafts.

Lyndon 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Thursday, March 27, 2008 1:23 PM
To: [e-mail]
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 






Envelope-to: [e-mail]
Delivery-date: Fri, 28 Mar 2008 11:57:25 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Polling for Adoption of Ethernet I-Ds
Date: Fri, 28 Mar 2008 07:37:33 -0400
Message-ID: <[e-mail]>
Thread-Topic: Polling for Adoption of Ethernet I-Ds
Thread-Index: AciQuBMPl9X0yh+zREeGt30G4Q9d9gAD/qOg
From: "David Allan" <[e-mail]>
To: "Loa Andersson" <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>

Agreed....

Dave 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Loa Andersson
Sent: Friday, March 28, 2008 5:33 AM
To: Adrian Farrel
Cc: [e-mail]
Subject: Re: Polling for Adoption of Ethernet I-Ds

yes - to all!

/Loa

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
> 
> 
> 
> 


--
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]




Envelope-to: [e-mail]
Delivery-date: Fri, 28 Mar 2008 09:47:34 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Polling for Adoption of Ethernet I-Ds
Date: Fri, 28 Mar 2008 12:46:55 +0300
Message-ID: <[e-mail]>
Thread-Topic: Polling for Adoption of Ethernet I-Ds
Thread-Index: AciQS+Dn4FeclqsxRk+VpIQmVeG+ZQAZyNrw
From: "Nurit Sprecher" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>

I am in favor of all four documents to become IETF drafts. 
Nurit

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of ext Adrian Farrel
Sent: Thursday, March 27, 2008 22:23
To: [e-mail]
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 






Envelope-to: [e-mail]
Delivery-date: Fri, 28 Mar 2008 09:34:15 +0000
Message-ID: <[e-mail]>
Date: Fri, 28 Mar 2008 10:33:17 +0100
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail]
Subject: Re: Polling for Adoption of Ethernet I-Ds
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

yes - to all!

/Loa

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
> 
> 
> 
> 


-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Mar 2008 09:01:21 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-pc-spc-rsvpte-ext-00.txt 
Message-Id: <[e-mail]>
Date: Fri, 28 Mar 2008 02: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           : draft-ietf-ccamp-pc-spc-rsvpte-ext-00.txt
	Author(s)       : D. Caviglia, et al.
	Filename        : draft-ietf-ccamp-pc-spc-rsvpte-ext-00.txt
	Pages           : 16
	Date            : 2008-03-28

In a transport network scenario, where Data Plane connections  
controlled either by GMPLS (Soft Permanent Connections - SPC) or by  
Management System (Permanent Connections - PC) may independently  
coexist, the ability of transforming an existing PC into a SPC and  
vice versa - without actually affecting Data Plane traffic being  
carried over it - is a valuable option. This applies especially when  
a GMPLS based Control Plane is first introduced into an existing  
network and there may be the need, from a Carrier point of view, to  
pass under GMPLS control existing connections already set up over  
Data Plane. In other terms, such operation could be seen as a way of  
transferring the ownership and control of an existing and in-use Data 
Plane connection between the Management Plane and the Control Plane,  
leaving its Data Plane state untouched.  
This memo provides a minor extension to RSVP-TE signaling protocol,  
within GMPLS architecture, to enable such connection ownership  
transfer and describes the proposed procedures.  
  



  
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 RFC2119 [1].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-spc-rsvpte-ext-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-pc-spc-rsvpte-ext-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Mar 2008 08:53:04 +0000
Message-ID: <[e-mail]>
Date: Fri, 28 Mar 2008 09:49:54 +0100
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: [e-mail], pwe3 <[e-mail]>, [e-mail],  L2VPN <[e-mail]>, ccamp <[e-mail]>
CC: George Swallow <[e-mail]>, Ross Callon <[e-mail]>,  David Ward <[e-mail]>
Subject: Question on the status of Y.1711 and RFC3429
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

All,

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.

As a side effect we've also started to ask ourselves if there are any
implementations and/or deployments that uses label 14.

A quick survey among known implementers of MPLS has not shown any
implementations/deployments.

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.

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.

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?"

ITU-T has sent out a question along the same lines, see the included
mail below.

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.

Loa and George


------------------- included mail ------------------------------------

All users/implementers of recommendation Y.1711,

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.

One possibility is the following mechanism:
-------------------------------------------
Push/pop a label at the MEP/domain boundary.

This makes the OAM alert label directly visible at the
sink MEP.

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.

The OAM alert label will point to an “opcode” at the bottom
of the stack.
------------------------------------------

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.

*QUESTION* are there any users/implementers of the current Y.1711
concerned with this change in behaviour?

If there are no concerns then recommendation Y.1711 can be
withdrawn or revised to describe the desired behaviour (described
above).

Please send me (or this list) your response ASAP.

Kind regards, Huub van Helvoort, your rapporteur.

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Thu, 27 Mar 2008 20:25:49 +0000
Message-ID: <03cc01c89048$6717b0b0$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Polling for Adoption of Ethernet I-Ds
Date: Thu, 27 Mar 2008 20:23:19 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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 





Envelope-to: [e-mail]
Delivery-date: Thu, 27 Mar 2008 16:59:54 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-path-key-ero-00.txt 
Message-Id: <[e-mail]>
Date: Thu, 27 Mar 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           : RSVP Extensions for Path Key Support
	Author(s)       : R. Bradford, et al.
	Filename        : draft-ietf-ccamp-path-key-ero-00.txt
	Pages           : 8
	Date            : 2008-03-27

Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineering (TE) Label Switched Paths (LSPs) may be
computed by Path Computation Elements (PCEs). Where the TE LSP
crosses multiple domains, such as Autonomous Systems (ASes), the
path may be computed by multiple PCEs that cooperate, with each
responsible for computing a segment of the path. To preserve
confidentiality of topology with each AS, the PCE supports a
mechanism to hide the contents of a segment of a path, called the
Confidential Path Segment (CPS), by encoding the contents as a
Path Key Subobject (PKS). This document describes the addition of
this information to Resource Reservation Protocol (RSVP) signaling
by inclusion in the Explicit Route Object (ERO) and Record Route
Object (RRO).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-path-key-ero-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-path-key-ero-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Thu, 27 Mar 2008 15:16:23 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-confirm-data-channel-status-00.txt 
Message-Id: <[e-mail]>
Date: Thu, 27 Mar 2008 08: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           : Data Channel Status Confirmation Extensions for the Link Management Protocol
	Author(s)       : D. Li, et al.
	Filename        : draft-ietf-ccamp-confirm-data-channel-status-00.txt
	Pages           : 15
	Date            : 2008-03-27

This document defines simple additions to the Link Management
Protocol (LMP) to provide a control plane tool that can assist in the
location of stranded resources by allowing adjacent LSRs to confirm


Li






Expires September 2008





[page 1]

draft-ietf-ccamp-confirm-data-channel-status-00.txt


 March 2008


data channel statuses, and provides triggers for notifying the
management plane if any discrepancies are found.

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 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-confirm-data-channel-status-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-confirm-data-channel-status-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Thu, 27 Mar 2008 00:45:17 +0000
Message-ID: <[e-mail]>
Date: Thu, 27 Mar 2008 09:42:52 +0900
From: Tomohiro Otani <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
Cc: Masanori Miyazawa <[e-mail]>, Tom Nadeau <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-ietf-ccamp-gmpls-ted-mib-03.txt
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Adrian,

Thank you for your comments. We will work for it and update the draft 
shortly.

Regards,

tomo


Adrian Farrel さんは書きました:
> Hi,
> In Philadelphia we discussed the next steps for this document and 
> agreed that it is probably ready for a MIB Doctor review. I thought 
> that I should have another look at it before we send it off.
>
> Major issues
> 1. Need to pick up boilerpate sections as per RFC 4181
> In particular, the security sections are needed.
> 2. I *think* that index values should be "not-accessible"
> rather than "read-only".
> 3. Need to check the MIB with smilint using
> smilint -m -s -l 6 -i namelength-32
> See http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/
> I get the following errors:
> mibs/ted.my:43: [3] {revision-missing} revision for last update is 
> missing
> mibs/ted.my:43: [2] {object-identifier-not-prefix} Object identifier 
> element `xxx' name only allowed as first element
> mibs/ted.my:101: [5] {index-element-accessible} warning: index element 
> `teAreaId' of row `tedEntry' should be not-accessible in SMIv2 MIB
> mibs/ted.my:101: [5] {index-element-accessible} warning: index element 
> `teRouterId' of row `tedEntry' should be not-accessible in SMIv2 MIB
> mibs/ted.my:101: [5] {index-element-accessible} warning: index element 
> `teLinkStateId' of row `tedEntry' should be not-accessible in SMIv2 MIB
> mibs/ted.my:851: [5] {group-unref} warning: current group 
> `tedNotificationGroup' is not referenced in this module
> 4. Should we have two conformance statements? One for
> MPLS-TE and one for GMPLS?
> 5. I believe you should use InetAddress and InetAddressType
> from RFC 4001 instead of IpAddress. We need to support
> IPv6
> 6. Looks like the whole MIB module is read-only. Does that
> mean that "manually configured" table entries cannot be
> configured through the MIB? If that is your intention (i.e.
> that configuration is made only through other mechanisms)
> I think you should discuss this in the text.
> 7. I think that teSwitchingType and teEncoding need to be
> extensible. And it would be useful to be consistent
> between routing and signaling. Please consider using
> IANAGmplsSwitchingTypeTC and
> IANAGmplsLSPEncodingTypeTC from
> IANA-GMPLS-TC-MIB. See
> http://www.iana.org/assignments/ianagmplstc-mib
>
>
>
> Less major points
> - Title needs to be updated to include MPLS-TE
> - I wonder if it is worth also including the IGP metric
> in this table. I know it is a duplication of information,
> but it is useful for TE processing
> - It would be nice to include a simple example
> - teIndication could use a reference to help people
> understand the usage.
> Actually, it wouldn't hurt to include more references
> for all objects.
> - You should also reference and think about OSPFv3
> http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-mib-12.txt
>
> There are some nits...
> - Tom is now with BT
> - In teLinkStateId s/jndicates/indicates/
> - [RFC2119] only needs to appear in section 9 once
> - You shouldn't list RFC1850. It is obsolete.
>
>
> You should also clean up the nits shown by idnits 
> (http://tools.ietf.org/tools/idnits/)
> I see the following errors:
> Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
> ---------------------------------------------------------------------------- 
>
>
> ** Found boilerplate matching RFC 3978 Section 5.4 paragraph 1 updated by
> RFC 4748 (on line 1204), which is fine, but *also* found old RFC 3978
> Section 5.4 paragraph 1 text on line 231.
>
>
> Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
> ---------------------------------------------------------------------------- 
>
>
> ** There is 1 instance of lines with non-ascii characters in the 
> document.
>
>
> Checking nits according to http://www.ietf.org/ID-Checklist.html:
> ---------------------------------------------------------------------------- 
>
>
> ** There are 2 instances of too long lines in the document, the 
> longest one
> being 1 character in excess of 72.
>
>
> Miscellaneous warnings:
> ---------------------------------------------------------------------------- 
>
>
> No issues found here.
>
> Checking references for intended status:
> ---------------------------------------------------------------------------- 
>
>
> == Missing Reference: 'RFC3410' is mentioned on line 75, but not defined
>
> == Missing Reference: 'OSPF-MIB' is mentioned on line 389, but not 
> defined
>
> == Missing Reference: 'ISIS-MIB' is mentioned on line 393, but not 
> defined
>
> == Unused Reference: 'MPLS OAM' is defined on line 1130, but no explicit
> reference was found in the text
>
> == Unused Reference: 'RFC3945' is defined on line 1134, but no explicit
> reference was found in the text
>
> -- Obsolete informational reference (is this intentional?): RFC 1850
> (Obsoleted by RFC 4750)
>
> == Outdated reference: draft-ietf-mpls-oam-requirements has been 
> published
> as RFC 4377
>
>
>
> If you can work on these issues, we'll take the I-D to the MIB Doctor.
>
> Thanks,
> Adrian
>
>
>
>
>
>





Envelope-to: [e-mail]
Delivery-date: Wed, 26 Mar 2008 17:46:09 +0000
Message-ID: <01e801c88f68$d67d3640$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Mach Chen" <[e-mail]>, <[e-mail]>
Subject: Update: WG last call comments on draft-ietf-ccamp-ospf-interas-te-extension-02.txt
Date: Wed, 26 Mar 2008 17:42:59 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="GB2312"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi all,

Just to give you an update on the dependency on OSPFv3-TE.

The ADs and OSPF working group chairs have agreed to re-submit the OSPFv3-TE 
draft and to last call it in the OSPF working group.

We can expect this to happen fairly soon (the I-D is already re-submitted) 
so it is OK for this CCAMP draft to keep its normative reference to the 
OSPFv3-TE draft.

The worst that will happen is that our draft will be held up in the RFC 
Editor's queue for a few extra weeks.

Adrian

>>OSPFv3-TE
>> I am currently trying to close an issue down
>> with the OSPF WG chairs and the ADs.
>> Your I-D includes extensions to OSPFv3-TE as
>> requested by the OSPF working group.
>> This means that you are correct to have the
>> OSPFv3-TE draft as a Normative reference.
>> However, the OSPFv3-TE draft is stalled in
>> the OSPF working group where:
>> - the draft has just expired
>> - there is more than one implementation
>> - there are no known deployments
>> - no interop testing has been done
>> This means that the OSPFv3-TE draft might not
>> advance for some time and might leave your
>> draft stalled in the RFC Editor queue.
>> I will update the working group as we make
>> progress on this issue.





Envelope-to: [e-mail]
Delivery-date: Wed, 26 Mar 2008 09:00:58 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-lsp-dppm-00.txt 
Message-Id: <[e-mail]>
Date: Wed, 26 Mar 2008 00:45:01 -0700 (PDT)
Cc: [e-mail]
Reply-To: [e-mail]

--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, et al.
	Filename        : draft-ietf-ccamp-lsp-dppm-00.txt
	Pages           : 39
	Date            : 2008-03-26

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-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-lsp-dppm-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
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

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Wed, 26 Mar 2008 07:44:43 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-lsp-dppm-00.txt 
Message-Id: <[e-mail]>
Date: Wed, 26 Mar 2008 00: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           : Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in Generalized MPLS Networks
	Author(s)       : W. Sun, et al.
	Filename        : draft-ietf-ccamp-lsp-dppm-00.txt
	Pages           : 39
	Date            : 2008-03-26

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-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-lsp-dppm-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Wed, 26 Mar 2008 01:44:21 +0000
Date: Wed, 26 Mar 2008 09:41:51 +0800
From: Mach Chen <[e-mail]>
Subject: Re: WG last call comments ondraft-ietf-ccamp-ospf-interas-te-extension-02.txt
To: Adrian Farrel <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Message-id: <[e-mail]>
Organization: Huawei
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi Adrian,

Thanks for your useful comments, the next revision will be updated according to your comments ASAP.

Best regards,
Mach
  
On 2008-03-26, at 02:28:09 Adrian Farrel wrote:

>Hi,
>
>Here are a few very minor review comments.
>It is probable that similar comments apply to the ISIS draft. Can you check?
>
>Thanks,
>Adrian
>=>Header
>s/Network work group/Network working group/
>Please show names as "M. Chen"
>=>Abstract
>s/Engineering(TE)/Engineering (TE)/
>s/information from other outside the AS/information from outside the AS/
>=>OSPFv3-TE
>I am currently trying to close an issue down with the OSPF WG chairs and the 
>ADs.
>Your I-D includes extensions to OSPFv3-TE as requested by the OSPF working 
>group.
>This means that you are correct to have the OSPFv3-TE draft as a Normative 
>reference.
>However, the OSPFv3-TE draft is stalled in the OSPF working group where:
>- the draft has just expired
>- there is more than one implementation
>- there are no known deployments
>- no interop testing has been done
>This means that the OSPFv3-TE draft might not advance for some time and 
>might leave your draft stalled in the RFC Editor queue.
>I will update the working group as we make progress on this issue.
>=>Section 2.1
>s/excluded.:/excluded:/
>=>Section 2.2
>s/PATH/Path/ x2
>s/Section 4.0/Section 4./
>=>Section 2.3
>s/TE link is particular/TE link is particularly/
>=>Section 3.1.1
>s/network-wide policy choice/AS-wide policy choice/
>=>Section 3.2
>s/Both/Both the/
>=>Sections 3.3.1, 3.3.2, and 3.3.3
>Please include a forward reference to Section 6.2 when you discuss the TLV 
>type assignment and mention IANA.
>=>Section 4
>s/link , the ASBR/link, the ASBR/
>s/consequently , an/consequently, an/
>s/considering here(i.e.,/considering here (i.e.,/
>=>Section 6.1
>Please separate the OSPFv2 and OSPFv3 assignments into separate paragraphs 
>(or sections).
>Please reference the IANA registries by name "Opaque Link-State 
>Advertisements (LSA) Option Types" for OSPFv2, and "Open Shortest Path First 
>v3 (OSPFv3) Parameters" with sub-registry "OSPFv3 LSA Function Codes" for 
>OSPFv3.
>=>Section 8.2
>[PD-PATH] is now RFC 5152
>== 
>
>
>





Envelope-to: [e-mail]
Delivery-date: Tue, 25 Mar 2008 18:27:10 +0000
Message-ID: <00d301c88ea5$776e6250$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Mach Chen" <[e-mail]>
Subject: WG last call comments on draft-ietf-ccamp-ospf-interas-te-extension-02.txt
Date: Tue, 25 Mar 2008 18:24:17 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Here are a few very minor review comments.
It is probable that similar comments apply to the ISIS draft. Can you check?

Thanks,
Adrian
=Header
s/Network work group/Network working group/
Please show names as "M. Chen"
=Abstract
s/Engineering(TE)/Engineering (TE)/
s/information from other outside the AS/information from outside the AS/
=OSPFv3-TE
I am currently trying to close an issue down with the OSPF WG chairs and the 
ADs.
Your I-D includes extensions to OSPFv3-TE as requested by the OSPF working 
group.
This means that you are correct to have the OSPFv3-TE draft as a Normative 
reference.
However, the OSPFv3-TE draft is stalled in the OSPF working group where:
- the draft has just expired
- there is more than one implementation
- there are no known deployments
- no interop testing has been done
This means that the OSPFv3-TE draft might not advance for some time and 
might leave your draft stalled in the RFC Editor queue.
I will update the working group as we make progress on this issue.
=Section 2.1
s/excluded.:/excluded:/
=Section 2.2
s/PATH/Path/ x2
s/Section 4.0/Section 4./
=Section 2.3
s/TE link is particular/TE link is particularly/
=Section 3.1.1
s/network-wide policy choice/AS-wide policy choice/
=Section 3.2
s/Both/Both the/
=Sections 3.3.1, 3.3.2, and 3.3.3
Please include a forward reference to Section 6.2 when you discuss the TLV 
type assignment and mention IANA.
=Section 4
s/link , the ASBR/link, the ASBR/
s/consequently , an/consequently, an/
s/considering here(i.e.,/considering here (i.e.,/
=Section 6.1
Please separate the OSPFv2 and OSPFv3 assignments into separate paragraphs 
(or sections).
Please reference the IANA registries by name "Opaque Link-State 
Advertisements (LSA) Option Types" for OSPFv2, and "Open Shortest Path First 
v3 (OSPFv3) Parameters" with sub-registry "OSPFv3 LSA Function Codes" for 
OSPFv3.
=Section 8.2
[PD-PATH] is now RFC 5152
== 





Envelope-to: [e-mail]
Delivery-date: Tue, 25 Mar 2008 11:58:32 +0000
Message-ID: <0eec01c88e6f$0b88d510$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: New CCAMP I-Ds Approved
Date: Tue, 25 Mar 2008 11:52:18 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Looks like we have enough support and no objections for the following I-Ds.

Authors: please submit the drafts.
Please don't forget to use idnits (http://tools.ietf.org/tools/idnits/) to 
check that your I-Ds are formatted OK.

> draft-xie-ccamp-lsp-dppm-02.txt
Becomes draft-ietf-ccamp-lsp-dppm-00.txt

> draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
Becomes draft-ietf-ccamp-pc-spc-rsvpte-ext-00.txt
(Note the "g" is deleted)

> draft-bradford-ccamp-path-key-ero-01.txt
Becomes draft-ietf-ccamp-path-key-ero-00.txt

> draft-li-ccamp-confirm-data-channel-status-03.txt
Becomes draft-ietf-ccamp-confirm-data-channel-status-00.txt

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Tue, 25 Mar 2008 11:29:10 +0000
Message-ID: <0ed601c88e6b$0db72390$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Jonathan Sadler" <[e-mail]>, "Lyndon Ong" <[e-mail]>, "Stephen Shew" <[e-mail]>, <[e-mail]>, "Ross Callon" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>
Subject: RFC 4258 bis Design Team Formed
Date: Tue, 25 Mar 2008 11:26:19 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Hi CCAMP,

We have three volunteers to do the heavy lifting for the proposed revision 
of RFC 4258. They are:

Jonathan Sadler <[e-mail]>
Stephen Shew <[e-mail]>
Lyndon Ong <[e-mail]>

Thanks to them for taking this on.

Below is a rough charter for their work.
A dedicated IETF mailing list will be set up soon for the discussion of this 
work, and we will circulate the subscription details.

 1. An IETF design team is just a group of people working
   together with a common goal. People may join or leave
   the team. You are encouraged to limit the team to the
   people who actively contribute text to the Internet-
   Draft you are producing. Review and discussion of
   your work should be held in a wider forum. Other teams
   may be set up with the same or similar objectives.

 2. Your objective is to produce a revision of RFC 4258
   in an Internet-Draft called draft-xxxx-ccamp-rfc4258bis-00.txt.
   You may entirely rewrite RFC 4258 or re-use text as appropriate.
   Your output, if eventually published as an RFC, will obsolete
   RFC 4258.

 3. The purpose of the revision is to fully capture all of the ASON
   routing requirements expressed in current ITU-T Recommendations
   and express them in IETF routing terminology such that they can
   be understood and implemented within the IETF. Each requirement
   must be shown with full traceability back to its statement in an ITU-T
   Recommendation.

 4. You should take care to fully credit the original authors of RFC 4258.

 5. At this stage, your charter does not extend beyond the ASON
   routing requirements (i.e. the revision of RFC 4258). If this work is
   successful and demonstrates a need, future work may be chartered to
   revise RFC 4652 to examine how existing IETF routing protocols can
   be used to meet the requirements expressed in your new work.

 6. You should use Adrian Farrel as your IETF process adviser.

 7. A dedicated IETF mailing list will be established for public discussion
   of your work. You do not need to hold all discussions of your draft on
   this list, but you are encouraged to have as many debates (even
   between yourselves) in this forum.

 8. You should work to the following timeline.

   March 2008
   Design Team formed

   May 2008
   Publish the -00 revision of your I-D
   Initiate discussions on your mailing list

   June 2008
   Publish the -01 revision of your I-D
   Continue discussions on your mailing list

   July 2008
   Present the -01 revision (or later) of your I-D at the CCAMP
      session of the Dublin IETF meeting

   August 2008
   Adopt draft as a CCAMP working group draft
   Discuss on CCAMP mailing list
   Move rapidly to CCAMP working group last call

We wish them well.
Adrian 





Envelope-to: [e-mail]
Delivery-date: Tue, 25 Mar 2008 08:12:27 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New CCAMP I-Ds
Date: Tue, 25 Mar 2008 09:01:54 +0100
Message-ID: <[e-mail]>
Thread-Topic: New CCAMP I-Ds
thread-index: AciI+J8LhLIA2XAcQPe76lWZc4WD3QClDL4AALBmsHAFrom: "Diego Caviglia" <[e-mail]>
To: "ext Don Fedyk" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>

Hi Don,
       I'll remove the g in the next version of the ID.

BR

Diego 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of ext Don Fedyk
> Sent: venerdì 21 marzo 2008 21.10
> To: Adrian Farrel; [e-mail]
> Subject: RE: New CCAMP I-Ds
> 
> Hi Adrian
> 
> <snip>
> 
> > ===
> > 
> > draft-xie-ccamp-lsp-dppm-02.txt
> OK Informational
> > draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
> OK but where did GRSVP-TE acronym come from? Don who can't find a
> definition.   
> > draft-bradford-ccamp-path-key-ero-01.txt
> yes
> > draft-li-ccamp-confirm-data-channel-status-03.txt
> yes
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Mon, 24 Mar 2008 22:30:37 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D  ACTION:draft-ietf-ccamp-inter-domain-recovery-analysis-03.txt 
Message-Id: <[e-mail]>
Date: Mon, 24 Mar 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
	Filename	: draft-ietf-ccamp-inter-domain-recovery-analysis-03.txt
	Pages		: 23
	Date		: 2008-3-24
	
This document analyzes various schemes to realize Multiprotocol Label 
   Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path 
   (LSP) recovery in multi-domain networks based on the existing 
   framework for multi-domain LSPs. 
    
   The main focus for this document is on establishing end-to-end 
   diverse Traffic Engineering (TE) LSPs in multi-domain networks. It 
   presents various diverse LSP setup schemes based on existing 
   functional elements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-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-inter-domain-recovery-analysis-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Sun, 23 Mar 2008 12:27:26 +0000
Message-ID: <0c8e01c88ce0$e17df370$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Draft minutes posted
Date: Sun, 23 Mar 2008 12:23:53 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Draft minutes are posted at 
http://www.ietf.org/proceedings/08mar/minutes/ccamp.htm

Many thanks to note takers:
- Greg Bernstein
- Lyndon Ong
- Martin Vigoureux

Please send in any comments or updates.

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Sat, 22 Mar 2008 13:12:55 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New CCAMP I-Ds
Date: Fri, 21 Mar 2008 16:09:53 -0400
Message-ID: <[e-mail]>
Thread-Topic: New CCAMP I-Ds
Thread-Index: AciI+J8LhLIA2XAcQPe76lWZc4WD3QClDL4A
From: "ext Don Fedyk" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Hi Adrian

<snip>

> ===
> 
> draft-xie-ccamp-lsp-dppm-02.txt
OK Informational
> draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
OK but where did GRSVP-TE acronym come from? Don who can't find a
definition.   
> draft-bradford-ccamp-path-key-ero-01.txt
yes
> draft-li-ccamp-confirm-data-channel-status-03.txt
yes




Envelope-to: [e-mail]
Delivery-date: Fri, 21 Mar 2008 23:34:39 +0000
To: [e-mail], [e-mail]
Subject: RFC 5146 on Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Date: Fri, 21 Mar 2008 16:33:25 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5146

        Title:      Interworking Requirements to Support Operation 
                    of MPLS-TE over GMPLS Networks 
        Author:     K. Kumaki, Ed.
        Status:     Informational
        Date:       March 2008
        Mailbox:    [e-mail]
        Pages:      15
        Characters: 31624
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5146.txt

Operation of a Multiprotocol Label Switching (MPLS) traffic
engineering (TE) network as a client network to a Generalized MPLS
(GMPLS) network has enhanced operational capabilities compared to
those provided by a coexistent protocol model (i.e., operation of
MPLS-TE over an independently managed transport layer).

The GMPLS network may be a packet or a non-packet network, and may
itself be a multi-layer network supporting both packet and non-packet
technologies.  An MPLS-TE Label Switched Path (LSP) originates and
terminates on an MPLS Label Switching Router (LSR).  The GMPLS network
provides transparent transport for the end-to-end MPLS-TE LSP.

This document describes a framework and Service Provider requirements
for operating MPLS-TE networks over GMPLS networks.  This memo provides information for the Internet community.

This document is a product of the Common Control and Measurement Plane Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...





Envelope-to: [e-mail]
Delivery-date: Fri, 21 Mar 2008 23:34:32 +0000
To: [e-mail], [e-mail]
Subject: RFC 5145 on Framework for MPLS-TE to GMPLS Migration
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Date: Fri, 21 Mar 2008 16:33:00 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5145

        Title:      Framework for MPLS-TE to GMPLS 
                    Migration 
        Author:     K. Shiomoto, Ed.
        Status:     Informational
        Date:       March 2008
        Mailbox:    [e-mail]
        Pages:      19
        Characters: 44646
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5145.txt

The migration from Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) to Generalized MPLS (GMPLS) is the process of
evolving an MPLS-TE control plane to a GMPLS control plane.  An
appropriate migration strategy will be selected based on various
factors including the service provider's network deployment plan,
customer demand, and operational policy.

This document presents several migration models and strategies for
migrating from MPLS-TE to GMPLS.  In the course of migration, MPLS-TE
and GMPLS devices, or networks, may coexist that may require
interworking between MPLS-TE and GMPLS protocols.  Aspects of the
required interworking are discussed as it will influence the choice
of a migration strategy.  This framework document provides a migration
toolkit to aid the operator in selection of an appropriate strategy.

This framework document also lists a set of solutions that may aid in
interworking, and highlights a set of potential issues.  This memo provides information for the Internet community.

This document is a product of the Common Control and Measurement Plane Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...





Envelope-to: [e-mail]
Delivery-date: Fri, 21 Mar 2008 20:12:54 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New CCAMP I-Ds
Date: Fri, 21 Mar 2008 16:09:53 -0400
Message-ID: <[e-mail]>
Thread-Topic: New CCAMP I-Ds
Thread-Index: AciI+J8LhLIA2XAcQPe76lWZc4WD3QClDL4A
From: "Don Fedyk" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Hi Adrian

<snip>

> ===
> 
> draft-xie-ccamp-lsp-dppm-02.txt
OK Informational
> draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
OK but where did GRSVP-TE acronym come from? Don who can't find a
definition.   
> draft-bradford-ccamp-path-key-ero-01.txt
yes
> draft-li-ccamp-confirm-data-channel-status-03.txt
yes



Envelope-to: [e-mail]
Delivery-date: Thu, 20 Mar 2008 14:07:33 +0000
Message-ID: <08ec01c88a93$7c7f1cf0$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Tomohiro Otani" <[e-mail]>, "Masanori Miyazawa" <[e-mail]>, "Tom Nadeau" <[e-mail]>
Cc: <[e-mail]>
Subject: Comments on draft-ietf-ccamp-gmpls-ted-mib-03.txt 
Date: Thu, 20 Mar 2008 14:05:39 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,
In Philadelphia we discussed the next steps for this document and agreed 
that it is probably ready for a MIB Doctor review. I thought that I should 
have another look at it before we send it off.

Major issues
1. Need to pick up boilerpate sections as per RFC 4181
   In particular, the security sections are needed.
2. I *think* that index values should be "not-accessible"
   rather than "read-only".
3. Need to check the MIB with smilint using
   smilint -m -s -l 6 -i namelength-32
   See http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/
   I get the following errors:
mibs/ted.my:43: [3] {revision-missing} revision for last update is missing
mibs/ted.my:43: [2] {object-identifier-not-prefix} Object identifier element 
`xxx' name only allowed as first element
mibs/ted.my:101: [5] {index-element-accessible} warning: index element 
`teAreaId' of row `tedEntry' should be not-accessible in SMIv2 MIB
mibs/ted.my:101: [5] {index-element-accessible} warning: index element 
`teRouterId' of row `tedEntry' should be not-accessible in SMIv2 MIB
mibs/ted.my:101: [5] {index-element-accessible} warning: index element 
`teLinkStateId' of row `tedEntry' should be not-accessible in SMIv2 MIB
mibs/ted.my:851: [5] {group-unref} warning: current group 
`tedNotificationGroup' is not referenced in this module
4. Should we have two conformance statements? One for
   MPLS-TE and one for GMPLS?
5. I believe you should use InetAddress and InetAddressType
    from RFC 4001 instead of IpAddress. We need to support
    IPv6
6. Looks like the whole MIB module is read-only. Does that
   mean that "manually configured" table entries cannot be
   configured through the MIB? If that is your intention (i.e.
   that configuration is made only through other mechanisms)
   I think you should discuss this in the text.
7. I think that teSwitchingType and teEncoding need to be
   extensible. And it would be useful to be consistent
   between routing and signaling. Please consider using
   IANAGmplsSwitchingTypeTC and
   IANAGmplsLSPEncodingTypeTC from
   IANA-GMPLS-TC-MIB. See
   http://www.iana.org/assignments/ianagmplstc-mib



Less major points
- Title needs to be updated to include MPLS-TE
- I wonder if it is worth also including the IGP metric
   in this table. I know it is a duplication of information,
   but it is useful for TE processing
- It would be nice to include a simple example
- teIndication could use a reference to help people
   understand the usage.
   Actually, it wouldn't hurt to include more references
   for all objects.
- You should also reference and think about OSPFv3
   http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-mib-12.txt

There are some nits...
- Tom is now with BT
- In teLinkStateId s/jndicates/indicates/
- [RFC2119] only needs to appear in section 9 once
- You shouldn't list RFC1850. It is obsolete.


You should also clean up the nits shown by idnits 
(http://tools.ietf.org/tools/idnits/)
I see the following errors:
  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
  ----------------------------------------------------------------------------

  ** Found boilerplate matching RFC 3978 Section 5.4 paragraph 1 updated by
     RFC 4748 (on line 1204), which is fine, but *also* found old RFC 3978
     Section 5.4 paragraph 1 text on line 231.


  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  ** There is 1 instance of lines with non-ascii characters in the document.


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

  ** There are 2 instances of too long lines in the document, the longest 
one
     being 1 character in excess of 72.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking references for intended status:
  ----------------------------------------------------------------------------

  = Missing Reference: 'RFC3410' is mentioned on line 75, but not defined

  = Missing Reference: 'OSPF-MIB' is mentioned on line 389, but not defined

  = Missing Reference: 'ISIS-MIB' is mentioned on line 393, but not defined

  = Unused Reference: 'MPLS OAM' is defined on line 1130, but no explicit
     reference was found in the text

  = Unused Reference: 'RFC3945' is defined on line 1134, but no explicit
     reference was found in the text

  -- Obsolete informational reference (is this intentional?): RFC 1850
     (Obsoleted by RFC 4750)

  = Outdated reference: draft-ietf-mpls-oam-requirements has been published
     as RFC 4377



If you can work on these issues, we'll take the I-D to the MIB Doctor.

Thanks,
Adrian






Envelope-to: [e-mail]
Delivery-date: Thu, 20 Mar 2008 06:24:37 +0000
Reply-To: <[e-mail]>
From: "Weiqiang Sun" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, "'Attila Takacs'" <[e-mail]>, <[e-mail]>
Subject: RE: DPPM [was: New CCAMP I-Ds]
Date: Thu, 20 Mar 2008 14:22:48 +0800
Organization: Shanghai Jiao Tong University
Message-ID: <000d01c88a52$d1b5e7d0$7521b770$@edu.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciJ31eSBenm1irJQ3CtD5d4hhRqKwAWljrw
Content-Language: zh-cn

Hi Attila and Adrian,

Thanks for the comments.
Our knowledge of the performance metrics and related methodologies has
largely come from existing and ongoing documents, as well as some
discussions in a discussion group.
For your reference, I listed below a few examples that put the PM docs in
the standard category:
http://www.ietf.org/rfc/rfc2679.txt
http://www.ietf.org/internet-drafts/draft-ietf-ippm-duplicate-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-pmol-sip-perf-metrics-00.txt

Also, there are a few other similar ones developed as informational docs:
http://www.ietf.org/internet-drafts/draft-ietf-ippm-multimetrics-06.txt

Personally, I think it is more appropriate to put the doc in the standard
track, since it proposes not only the metrics and motivations, but the
methodologies as well. The methodologies can be implementation references
for certain users of the metrics, such as online measurement entities and
testing devices.

So far this doc has been developing in a discussion group and also in an
offline manner. We expect to receive more feedbacks from the WG as we are
settling down with the motivations, and can thus be more focused on metrics
and methodologies. Also, we will try to solicit comments from other related
WGs such as PMOL, BMWG and IPPM. It is indeed a wonderful idea to develop
this document under the guidance of CCAMP experts and also with the support
from performance metrics experts.

Cheers,
Weiqiang

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Adrian Farrel
Sent: Thursday, March 20, 2008 12:24 AM
To: Attila Takacs; [e-mail]
Subject: DPPM [was: New CCAMP I-Ds]

Attila wrote

>> draft-xie-ccamp-lsp-dppm-02.txt
> Yes. However, I'm not sure if this needs to be a standard, shouldn't it
> be just informational?

Yse, I agree.
Actually, there are one or two IETF-culture things to tweak in this I-D, and

I prpose to give the authors a little help if we agree to take it into 
CCAMP.

Cheers,
Adrian








Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 18:00:55 +0000
Message-ID: <078801c889eb$159a4210$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Working group last calls: Inter-AS TE link advertisement
Date: Wed, 19 Mar 2008 18:00:11 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

This email begins a three week working group last call on:

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-02.txt

and

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-00.txt

This last call will be advertised to the MPLS working group and to the OSPF 
and ISIS working groups as appropriate.

The last call will end at 12 noon BST on April 9th 2008.

Please send your comments to the list.

Thanks,
Adrian and Deborah 





Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 17:31:21 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New CCAMP I-Ds
Date: Wed, 19 Mar 2008 18:29:28 +0100
Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02605689418@ftrdmel2>
Thread-Topic: New CCAMP I-Ds
Thread-Index: AciI9/9FdAK4C8JARcWe4Wy59GG61wA7hBlQ
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>

Hi all.

draft-xie-ccamp-lsp-dppm-02.txt
-> Yes, this work is interesting.

draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
-> Yes, this is an appropriate answer to the requirements.

draft-bradford-ccamp-path-key-ero-01.txt
-> Yes, this is a key feature.

draft-li-ccamp-confirm-data-channel-status-03.txt
-> Yes, I confirm this is useful (but I'm co-author).

Cheers,

Julien


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Adrian Farrel

Hi,

We took an action in Philadelphia to poll you on a long list of potential 
new working group I-Ds.

We are splitting this list into three largely for our own sanity. Don't 
worry if your favorite I-D is not in the first (or second) batch. We will 
get to it by the end of the month.

Can you please answer yes or no for the following I-Ds. You are encouraged 
to give reasons especially for negative responses).

Thanks,
Adrian and Deborah

===

draft-xie-ccamp-lsp-dppm-02.txt
draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
draft-bradford-ccamp-path-key-ero-01.txt
draft-li-ccamp-confirm-data-channel-status-03.txt







Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 16:25:38 +0000
Message-ID: <073c01c889dd$aa511f40$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Attila Takacs" <[e-mail]>, <[e-mail]>
Subject: DPPM [was: New CCAMP I-Ds]
Date: Wed, 19 Mar 2008 16:24:05 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Attila wrote

>> draft-xie-ccamp-lsp-dppm-02.txt
> Yes. However, I'm not sure if this needs to be a standard, shouldn't it
> be just informational?

Yse, I agree.
Actually, there are one or two IETF-culture things to tweak in this I-D, and 
I prpose to give the authors a little help if we agree to take it into 
CCAMP.

Cheers,
Adrian





Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 14:23:44 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New CCAMP I-Ds
Date: Wed, 19 Mar 2008 09:21:13 -0500
Message-ID: <[e-mail]>
Thread-Topic: New CCAMP I-Ds
Thread-Index: AciI9vl3091Hvip4TcqR06KgfiiDIgA1WT4A
From: "Bardalai, Snigdho" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

In favour of:

draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt (co-author)
draft-li-ccamp-confirm-data-channel-status-03.txt (co-author)



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Adrian Farrel
Sent: Tuesday, March 18, 2008 7:43 AM
To: [e-mail]
Subject: New CCAMP I-Ds


Hi,

We took an action in Philadelphia to poll you on a long list of potential 
new working group I-Ds.

We are splitting this list into three largely for our own sanity. Don't 
worry if your favorite I-D is not in the first (or second) batch. We will 
get to it by the end of the month.

Can you please answer yes or no for the following I-Ds. You are encouraged 
to give reasons especially for negative responses).

Thanks,
Adrian and Deborah

===

draft-xie-ccamp-lsp-dppm-02.txt
draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
draft-bradford-ccamp-path-key-ero-01.txt
draft-li-ccamp-confirm-data-channel-status-03.txt




Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 12:55:34 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New CCAMP I-Ds
Date: Wed, 19 Mar 2008 08:54:33 -0400
Message-ID: <[e-mail]>
Thread-Topic: New CCAMP I-Ds
Thread-Index: AciI9o985CEXojQETo6MztmTfrpWFgAybl6g
From: "Rich Bradford (rbradfor)" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; lf; t05931275; x06795275; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From: "Rich Bradford (rbradfor)" <rbradfor@cis co.com> |Subject: RE: New CCAMP I-Ds |Sender: ; bh=ZjXfq7TWeGsf4jFn4FHztP/yj8057XcZVEBfLp431oA=; båbA267ysKuXjrh8hPVex9NPqXCw9hgwwF2oF/m7FtuBJdIAfcOJFz1mAg VncEtNHPTlG6MYtG+Zpd+PIIs+CrLuEUNT27N29ChsA9iKM/Ik33QfpB8nOc ziJq9/xjdq5Kl7XJvLci6O7WdAsyzxs6BPZQml2dHy5fhmMCobP4M=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );

> draft-bradford-ccamp-path-key-ero-01.txt
In Favor, co-author.




Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 12:30:17 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New CCAMP I-Ds
Date: Wed, 19 Mar 2008 13:28:21 +0100
Message-ID: <[e-mail]>
Thread-Topic: New CCAMP I-Ds
Thread-Index: AciI+b3zw4Uj8M4JTOGHGlY3jKcg+wAwk2Lg
From: "Attila Takacs" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Hi all,

> draft-xie-ccamp-lsp-dppm-02.txt
Yes. However, I'm not sure if this needs to be a standard, shouldn't it
be just informational?

> draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
Yes.

> draft-bradford-ccamp-path-key-ero-01.txt
Yes.

> draft-li-ccamp-confirm-data-channel-status-03.txt
Yes.

Best regards,
Attila



Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 08:59:42 +0000
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New CCAMP I-Ds
Date: Wed, 19 Mar 2008 09:59:00 +0100
Message-ID: <[e-mail]>
Thread-Topic: New CCAMP I-Ds
thread-index: AciI+PTpUCOMMgwSTwuMbrCWqOFLyAApYzDQ
From: "Capello Alessandro" <[e-mail]>
To: <[e-mail]>

Hi all,

> draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
Yes

> draft-bradford-ccamp-path-key-ero-01.txt
Yes

> draft-li-ccamp-confirm-data-channel-status-03.txt
Yes

Regards,
Alessandro
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [e-mail].

        Thank you

                                        www.telecomitalia.it

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



Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 08:44:08 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New CCAMP I-Ds
Date: Wed, 19 Mar 2008 09:43:21 +0100
Message-ID: <[e-mail]>
Thread-Topic: New CCAMP I-Ds
Thread-Index: AciI+b1IMLdlVtvmTPOyZmq7LDNEPQAo29sw
From: "Howard Green" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

In favour for all 4 
Howard

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: 18 March 2008 13:43
> To: [e-mail]
> Subject: New CCAMP I-Ds
> 
> Hi,
> 
> We took an action in Philadelphia to poll you on a long list 
> of potential new working group I-Ds.
> 
> We are splitting this list into three largely for our own 
> sanity. Don't worry if your favorite I-D is not in the first 
> (or second) batch. We will get to it by the end of the month.
> 
> Can you please answer yes or no for the following I-Ds. You 
> are encouraged to give reasons especially for negative responses).
> 
> Thanks,
> Adrian and Deborah
> 
> ===
> 
> draft-xie-ccamp-lsp-dppm-02.txt
> draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
> draft-bradford-ccamp-path-key-ero-01.txt
> draft-li-ccamp-confirm-data-channel-status-03.txt
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 08:29:44 +0000
Message-ID: <[e-mail]>
Date: Wed, 19 Mar 2008 09:28:10 +0100
From: Gino Carrozzo <[e-mail]>
User-Agent: Thunderbird 2.0.0.5 (X11/20070730)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail]
Subject: Re: New CCAMP I-Ds
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

> 
> draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
Yes.



Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 04:03:56 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Signaling client layer LSP over VCAT server layer LSP
Date: Tue, 18 Mar 2008 23:02:44 -0500
Message-ID: <[e-mail]>
Thread-Topic: Signaling client layer LSP over VCAT server layer LSP
Thread-Index: AciJCNan2r/h3YvLThO+vyJjGH1AaQAAENSA
From: "Bardalai, Snigdho" <[e-mail]>
To: "Kohei Shiomoto" <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: "Greg Bernstein (E-mail)" <[e-mail]>, "Ccamp (E-mail)" <[e-mail]>

Hi Adrian and Kohei,

Thanks for your response. 

So I believe we have a couple of alternatives to establish the client layer interface:
1. Extend the VCAT layer call mechanism
2. Signal a VCAT layer LSP to trigger the creation of an LSP_TUNNEL_INTERFACE

So either way we have a single client layer interface which represents a set of inversely multiplexed server layer LSPs.

I am not sure if this aspect is described in the VCAT ID, does it make sense to add this type of information?

Regards,
Snigdho


-----Original Message-----
From: Kohei Shiomoto [mailto:[e-mail]]
Sent: Tuesday, March 18, 2008 9:59 AM
To: Adrian Farrel
Cc: Bardalai, Snigdho; Greg Bernstein (E-mail); Ccamp (E-mail)
Subject: Re: Signaling client layer LSP over VCAT server layer LSP


Hi, Snigdho

Thank you for your question.

I agree with Adrian.

Hierarchy bis describes, when a LSP is dynamically created, the ingress 
LSP may indicates the LSP is advertised or used to carry traffic. We 
consider the bundling link composed of component links in this draft.But 
VCAT connection is not a bundled link.

Call concept are used to a VCAT connection, which is composed of 
multiple co-signaled member sets.How to advertise a link composed of the 
VCG can be developed in the context of call concept to avoid 
intermediate layer. But we do not have to exclude use of the same 
mechanism defined in hierarchy-bis for this purpose.

Best regards,
Kohei
> Hi,
>
> IMHO the two drafts are not so closely related.
>
> Hierarchy bis describes how, when an LSP is set up, the ingress may 
> indicate to the egress that the LSP is to be advertised or used as a 
> link in some specific network layer.
>
> LSPs set up for VCAT are not used in that way. They are grouped 
> together and the whole group is used as a link in another network layer.
>
> So, for VCAT, one might use the call as the mechanism to exchange 
> information about how to use the entire VCG as a link in the client 
> layer. Alternatively (if one is implementing strictly according to the 
> architecture) one might have three layers to consider...
>
> - The server layer where a call coordinates multiple TDM LSPs
> - The VCAT layer where a single hop LSP is requested between
>   VCG end points resulting in the server layer call. The VCAT
>   layer LSP would use hierarchy bis to determine that it should
>   be advertised as a TE link in the client layer.
> - The client layer where a magic TE link appears as the result of
>   the VCAT layer LSP.
>
> Depending on the deployment, the use of a VCAT layer LSP might be 
> considered to be over-engineering. Just because an architecture 
> defines multiple layers, it does not mean you have to implement them 
> explicitly. It might be enough for the server layer call to provide 
> the coordination with the client layer direct.
>
> Cheers,
> Adrian
> ----- Original Message ----- From: "Bardalai, Snigdho" 
> <[e-mail]>
> To: "Kohei Shiomoto (E-mail)" <[e-mail]>; "Greg 
> Bernstein (E-mail)" <[e-mail]>
> Cc: "Ccamp (E-mail)" <[e-mail]>; "Adrian Farrel (E-mail)" 
> <[e-mail]>
> Sent: Saturday, March 15, 2008 7:25 PM
> Subject: Signaling client layer LSP over VCAT server layer LSP
>
>
> Hello Kohei and Greg,
>
> I have a question about client layer LSP signaling (e.g. ethernet) 
> over VCAT server layer resources.
>
>> From reading 'draft-ietf-ccamp-lsp-hierarchy-bis-03.txt' it is not 
>> clear how 
> will this exactly work.
>
> For example, we set up a VCAT group (i.e. by signaling multiple STS1 
> LSPs) as allowed by the VCAT ID. I believe each of these LSPs would 
> appear as LSP_TUNNEL_INTERFACEs in the client layer with bandwidth 
> capacity equivalent to STS1 (i.e. 52mbps). My question is which 
> LSP_TUNNEL_INTERFACE will be used for signaling the ethernet LSP, I 
> think an additional component link with bandwidth capacity equivalent 
> to the aggregate bandwidth will have to be created.
>
> Is there a defined way of handling this situation?
>
> Thanks,
> Snigdho
>
>
>
>
-- 
Kohei Shiomoto, Ph.D
Senior Research Engineer, Supervisor, Group Leader
NTT Network Service Systems Laboratories
http://www.ntt.co.jp/islab/org/ns.html
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone [phone] Fax [phone]
Free online contents of "NTT Technical Review" available at
https://www.ntt-review.jp/



Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 03:17:53 +0000
Date: Wed, 19 Mar 2008 11:16:32 +0800
From: Mach Chen <[e-mail]>
Subject: Re: New CCAMP I-Ds
To: Adrian Farrel <[e-mail]>, "[e-mail]" <[e-mail]>
Message-id: <[e-mail]>
Organization: Huawei
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi,

In favor of all four I-Ds.  
  
On 2008-03-18, at 20:50:23 Adrian Farrel wrote:

>Hi,
>
>We took an action in Philadelphia to poll you on a long list of potential 
>new working group I-Ds.
>
>We are splitting this list into three largely for our own sanity. Don't 
>worry if your favorite I-D is not in the first (or second) batch. We will 
>get to it by the end of the month.
>
>Can you please answer yes or no for the following I-Ds. You are encouraged 
>to give reasons especially for negative responses).
>
>Thanks,
>Adrian and Deborah
>
>=>
>draft-xie-ccamp-lsp-dppm-02.txt
>draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
>draft-bradford-ccamp-path-key-ero-01.txt
>draft-li-ccamp-confirm-data-channel-status-03.txt
>
>
>


Best regards,			
Mach Chen





Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 02:00:34 +0000
Date: Wed, 19 Mar 2008 09:59:26 +0800
From: "gyzhang" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: New CCAMP I-Ds
Mime-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Message-Id: <[e-mail]>

SGkgYWxsLA0KDQpkcmFmdC14aWUtY2NhbXAtbHNwLWRwcG0tMDIudHh0DQpZZXMsIGluIGZhdm9y
IGFzIGNvLWF1dGhvci4gUGVyZm9ybWFuY2UgbWV0cmljcyBuZWVkIGJlIGRlZmluZWQuDQoNCmRy
YWZ0LWNhdmlnbGlhLWNjYW1wLXBjLXNwYy1ncnN2cHRlLWV4dC0wMi50eHQNClllcywgcGMgdG8g
c3BjIGNvbnZlcnRpb24gaXMgbmVlZGVkIGZvciBtYW55IENoaW5lc2UgY2FycmllcnMuDQoNCmRy
YWZ0LWJyYWRmb3JkLWNjYW1wLXBhdGgta2V5LWVyby0wMS50eHQNClllcy4NCg0KZHJhZnQtbGkt
Y2NhbXAtY29uZmlybS1kYXRhLWNoYW5uZWwtc3RhdHVzLTAzLnR4dA0KWWVzLgkNCg0KR3VveWlu
ZyBaaGFuZw0KPT09PT09PSAyMDA4LTAzLTE4IDIwOjQzOjEwIMT61NrAtNDF1tDQtLXAo7o9PT09
PT09DQoNCj5IaSwNCj4NCj5XZSB0b29rIGFuIGFjdGlvbiBpbiBQaGlsYWRlbHBoaWEgdG8gcG9s
bCB5b3Ugb24gYSBsb25nIGxpc3Qgb2YgcG90ZW50aWFsIA0KPm5ldyB3b3JraW5nIGdyb3VwIEkt
RHMuDQo+DQo+V2UgYXJlIHNwbGl0dGluZyB0aGlzIGxpc3QgaW50byB0aHJlZSBsYXJnZWx5IGZv
ciBvdXIgb3duIHNhbml0eS4gRG9uJ3QgDQo+d29ycnkgaWYgeW91ciBmYXZvcml0ZSBJLUQgaXMg
bm90IGluIHRoZSBmaXJzdCAob3Igc2Vjb25kKSBiYXRjaC4gV2Ugd2lsbCANCj5nZXQgdG8gaXQg
YnkgdGhlIGVuZCBvZiB0aGUgbW9udGguDQo+DQo+Q2FuIHlvdSBwbGVhc2UgYW5zd2VyIHllcyBv
ciBubyBmb3IgdGhlIGZvbGxvd2luZyBJLURzLiBZb3UgYXJlIGVuY291cmFnZWQgDQo+dG8gZ2l2
ZSByZWFzb25zIGVzcGVjaWFsbHkgZm9yIG5lZ2F0aXZlIHJlc3BvbnNlcykuDQo+DQo+VGhhbmtz
LA0KPkFkcmlhbiBhbmQgRGVib3JhaA0KPg0KPj09PQ0KPg0KPmRyYWZ0LXhpZS1jY2FtcC1sc3At
ZHBwbS0wMi50eHQNCj5kcmFmdC1jYXZpZ2xpYS1jY2FtcC1wYy1zcGMtZ3JzdnB0ZS1leHQtMDIu
dHh0DQo+ZHJhZnQtYnJhZGZvcmQtY2NhbXAtcGF0aC1rZXktZXJvLTAxLnR4dA0KPmRyYWZ0LWxp
LWNjYW1wLWNvbmZpcm0tZGF0YS1jaGFubmVsLXN0YXR1cy0wMy50eHQNCj4NCj4NCj4NCj4NCg0K
PSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9DQoJCQkNCg0KoaGhoaGhoaGh
oaGhoaGhodbCDQrA8aOhDQogDQoJCQkJIA0KoaGhoaGhoaGhoaGhoaGhoWd5emhhbmcNCqGhoaGh
oaGhoaGhoaGhoaFneXpoYW5nQHNpbmEuY29tDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDgtMDMt
MTkNCg0K




Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 01:53:05 +0000
Message-ID: <[e-mail]>
Date: Wed, 19 Mar 2008 10:52:07 +0900
From: Kenji Kumaki <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: New CCAMP I-Ds
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

 > draft-bradford-ccamp-path-key-ero-01.txt

I support it.

Thanks,
Kenji

Adrian Farrel wrote:
> Hi,
> 
> We took an action in Philadelphia to poll you on a long list of 
> potential new working group I-Ds.
> 
> We are splitting this list into three largely for our own sanity. Don't 
> worry if your favorite I-D is not in the first (or second) batch. We 
> will get to it by the end of the month.
> 
> Can you please answer yes or no for the following I-Ds. You are 
> encouraged to give reasons especially for negative responses).
> 
> Thanks,
> Adrian and Deborah
> 
> => 
> draft-xie-ccamp-lsp-dppm-02.txt
> draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
> draft-bradford-ccamp-path-key-ero-01.txt
> draft-li-ccamp-confirm-data-channel-status-03.txt
> 
> 
> 
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 01:39:40 +0000
Reply-To: <[e-mail]>
From: "Weiqiang Sun" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: RE: New CCAMP I-Ds
Date: Wed, 19 Mar 2008 09:36:20 +0800
Organization: Shanghai Jiao Tong University
Message-ID: <000001c88961$a3c30840$eb4918c0$@edu.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciI+OoMoL0jDaTIQUK/fE1xtYFTBgAaG/tA
Content-Language: zh-cn

Hi all,

>draft-xie-ccamp-lsp-dppm-02.txt
Yes in favor as co-author.

>draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
Yes in favor.

>draft-bradford-ccamp-path-key-ero-01.txt
Yes in favor.

draft-li-ccamp-confirm-data-channel-status-03.txt
Yes in favor.

Thanks,
Weiqiang

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Adrian Farrel
Sent: Tuesday, March 18, 2008 8:43 PM
To: [e-mail]
Subject: New CCAMP I-Ds

Hi,

We took an action in Philadelphia to poll you on a long list of potential 
new working group I-Ds.

We are splitting this list into three largely for our own sanity. Don't 
worry if your favorite I-D is not in the first (or second) batch. We will 
get to it by the end of the month.

Can you please answer yes or no for the following I-Ds. You are encouraged 
to give reasons especially for negative responses).

Thanks,
Adrian and Deborah

=
draft-xie-ccamp-lsp-dppm-02.txt
draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
draft-bradford-ccamp-path-key-ero-01.txt
draft-li-ccamp-confirm-data-channel-status-03.txt








Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 00:53:21 +0000
Date: Wed, 19 Mar 2008 08:50:17 +0800
From: Dan Li <[e-mail]>
Subject: Re: New CCAMP I-Ds
To: Adrian Farrel <[e-mail]>, [e-mail]
Message-id: <015901c8895b$3353fa70$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

> draft-xie-ccamp-lsp-dppm-02.txt
Yes!

> draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
Yes!

> draft-bradford-ccamp-path-key-ero-01.txt
Yes!

> draft-li-ccamp-confirm-data-channel-status-03.txt
Yes!


----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, March 18, 2008 8:43 PM
Subject: New CCAMP I-Ds


> Hi,
> 
> We took an action in Philadelphia to poll you on a long list of potential 
> new working group I-Ds.
> 
> We are splitting this list into three largely for our own sanity. Don't 
> worry if your favorite I-D is not in the first (or second) batch. We will 
> get to it by the end of the month.
> 
> Can you please answer yes or no for the following I-Ds. You are encouraged 
> to give reasons especially for negative responses).
> 
> Thanks,
> Adrian and Deborah
> 
> => 
> draft-xie-ccamp-lsp-dppm-02.txt
> draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
> draft-bradford-ccamp-path-key-ero-01.txt
> draft-li-ccamp-confirm-data-channel-status-03.txt
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 18 Mar 2008 18:21:31 +0000
Date: Tue, 18 Mar 2008 12:20:33 -0600
From: Young Lee <[e-mail]>
Subject: RE: New CCAMP I-Ds
To: 'Adrian Farrel' <[e-mail]>, [e-mail]
Message-id: <000f01c88924$c2062630$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Thread-index: AciI9qTnueK1/nOeR/2D6Wd9mRLpawALgaug

 
Yes for all four. 

draft-xie-ccamp-lsp-dppm-02.txt
draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
draft-bradford-ccamp-path-key-ero-01.txt
draft-li-ccamp-confirm-data-channel-status-03.txt

Young
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Adrian Farrel
Sent: Tuesday, March 18, 2008 6:43 AM
To: [e-mail]
Subject: New CCAMP I-Ds

Hi,

We took an action in Philadelphia to poll you on a long list of potential
new working group I-Ds.

We are splitting this list into three largely for our own sanity. Don't
worry if your favorite I-D is not in the first (or second) batch. We will
get to it by the end of the month.

Can you please answer yes or no for the following I-Ds. You are encouraged
to give reasons especially for negative responses).

Thanks,
Adrian and Deborah

=
draft-xie-ccamp-lsp-dppm-02.txt
draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
draft-bradford-ccamp-path-key-ero-01.txt
draft-li-ccamp-confirm-data-channel-status-03.txt








Envelope-to: [e-mail]
Delivery-date: Tue, 18 Mar 2008 17:54:45 +0000
Message-ID: <05ed01c88920$9335e240$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Scott Bradner" <[e-mail]>, "Lam, Hing-Kam \(Kam\)" <[e-mail]>, "Stephen Trowbridge" <[e-mail]>, "Yoichi Maeda" <[e-mail]>, <[e-mail]>, "Ross Callon" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>
Subject: ASON Routing
Date: Tue, 18 Mar 2008 17:50:10 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Hi,

You may have noticed the liaison we received from the ITU-T at the end of 
February on ASON routing.

This was a detailed review of RFC 4258 and RFC 4652 against the latest 
requirements documented in ITU-T Recommendations and arose in response to 
our request for exactly such a review after we heard that Study Group 15 was 
not happy with our analysis.

You can see the liaison at https://datatracker.ietf.org/liaison/424/ and the 
output of the review at 
https://datatracker.ietf.org/documents/LIAISON/file531.pdf

We held an ad hoc meeting in Philadelphia with many of the concerned parties 
(thanks to the ITU folk who travelled specially, and to the IETF GMPLS and 
routing experts who gave up their evening) to discuss the issues raised, to 
try to understand and scope the differences, and to agree the way forward.

We decided that the best approach will be to revise RFC 4258 as a bis, and 
to then consider whether any further work is needed to RFC 4652. At the same 
time, we will freeze work on draft-ietf-ccamp-gmpls-ason-routing-ospf-04.txt 
until we know whether it also needs to be modified - we expect that by the 
time of our next meeting (July 2008) we will know whether modifications are 
required.

The new work will lead to draft-ietf-ccamp-rfc4258-bis-00.txt. But may get 
there through multiple revisions of an individual submission. The draft may 
reuse substantial text from RFC 4258, but it was agreed that every 
requirement in the document will show full traceability back to the ITU-T 
recommendations.

At the moment, I am looking to put together a "compact" team of editors for 
this work. People in the team must be prepared to make significant textual 
contributions. Please contact me if you wish to be in this team (please also 
assume that I have not heard from you unless you receive a response from 
me).

Once the team is in place, we will also set up an IETF mailing list for open 
community discussions of the work.

When the work is complete it will we discussed and last called on the CCAMP 
mailing list, and will be liaised to the ITU-T as appropriate.

We will also liaise this information to the ITU-T to solicit contributors 
from there.

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Tue, 18 Mar 2008 15:37:34 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New CCAMP I-Ds
Date: Tue, 18 Mar 2008 11:37:30 -0400
Message-ID: <[e-mail]>
Thread-Topic: New CCAMP I-Ds
Thread-Index: AciI9o+SiFnOvK1mSA6PknTy0TfBKQAEkJig
From: "Zafar Ali (zali)" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l3; t05854639; x06718639; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From: "Zafar Ali (zali)" <[e-mail]> |Subject: RE: New CCAMP I-Ds |Sender:  |To: "Adrian Farrel" <[e-mail]>, <cc [e-mail]>; bh=wJxJUkX2JOTlJREFSjO2IhrwM8xwm9/7d9P5jmVZVs0=; b=NUK7KfmQtQUxndwSZd1GceeewDAD7g8xtqMMTVZQDRtiD65jNNhQtABDS2 IsOFWT0O8dhpmsoTK5T87xIsifnAb1XyWA1PV469u6He+PgmDIRtDq/ClGSt UQ8I8ddcKe;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );

> draft-bradford-ccamp-path-key-ero-01.txt

In favor 

Thanks

Regards... Zafar  

<snip>



Envelope-to: [e-mail]
Delivery-date: Tue, 18 Mar 2008 15:35:21 +0000
Message-ID: <[e-mail]>
Date: Tue, 18 Mar 2008 08:34:07 -0700
From: Greg Bernstein <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: [e-mail]
Subject: Re: New CCAMP I-Ds
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

>
>
> draft-xie-ccamp-lsp-dppm-02.txt
Yes. Good to have metrics.
> draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
Yes. Good to be able to convert between SPCs and PCs
> draft-bradford-ccamp-path-key-ero-01.txt
Yes. Need this to work with same mechanism as PCE.
> draft-li-ccamp-confirm-data-channel-status-03.txt
Yes. Good to locate and identify stranded resources.
>
>
>
>

-- 
=========================Dr Greg Bernstein, Grotto Networking [phone]






Envelope-to: [e-mail]
Delivery-date: Tue, 18 Mar 2008 15:01:31 +0000
Message-ID: <[e-mail]>
Date: Tue, 18 Mar 2008 23:58:49 +0900
From: Kohei Shiomoto <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: "Bardalai, Snigdho" <[e-mail]>, "Greg Bernstein (E-mail)" <[e-mail]>, "Ccamp (E-mail)" <[e-mail]>
Subject: Re: Signaling client layer LSP over VCAT server layer LSP
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Snigdho

Thank you for your question.

I agree with Adrian.

Hierarchy bis describes, when a LSP is dynamically created, the ingress 
LSP may indicates the LSP is advertised or used to carry traffic. We 
consider the bundling link composed of component links in this draft.But 
VCAT connection is not a bundled link.

Call concept are used to a VCAT connection, which is composed of 
multiple co-signaled member sets.How to advertise a link composed of the 
VCG can be developed in the context of call concept to avoid 
intermediate layer. But we do not have to exclude use of the same 
mechanism defined in hierarchy-bis for this purpose.

Best regards,
Kohei
> Hi,
>
> IMHO the two drafts are not so closely related.
>
> Hierarchy bis describes how, when an LSP is set up, the ingress may 
> indicate to the egress that the LSP is to be advertised or used as a 
> link in some specific network layer.
>
> LSPs set up for VCAT are not used in that way. They are grouped 
> together and the whole group is used as a link in another network layer.
>
> So, for VCAT, one might use the call as the mechanism to exchange 
> information about how to use the entire VCG as a link in the client 
> layer. Alternatively (if one is implementing strictly according to the 
> architecture) one might have three layers to consider...
>
> - The server layer where a call coordinates multiple TDM LSPs
> - The VCAT layer where a single hop LSP is requested between
>   VCG end points resulting in the server layer call. The VCAT
>   layer LSP would use hierarchy bis to determine that it should
>   be advertised as a TE link in the client layer.
> - The client layer where a magic TE link appears as the result of
>   the VCAT layer LSP.
>
> Depending on the deployment, the use of a VCAT layer LSP might be 
> considered to be over-engineering. Just because an architecture 
> defines multiple layers, it does not mean you have to implement them 
> explicitly. It might be enough for the server layer call to provide 
> the coordination with the client layer direct.
>
> Cheers,
> Adrian
> ----- Original Message ----- From: "Bardalai, Snigdho" 
> <[e-mail]>
> To: "Kohei Shiomoto (E-mail)" <[e-mail]>; "Greg 
> Bernstein (E-mail)" <[e-mail]>
> Cc: "Ccamp (E-mail)" <[e-mail]>; "Adrian Farrel (E-mail)" 
> <[e-mail]>
> Sent: Saturday, March 15, 2008 7:25 PM
> Subject: Signaling client layer LSP over VCAT server layer LSP
>
>
> Hello Kohei and Greg,
>
> I have a question about client layer LSP signaling (e.g. ethernet) 
> over VCAT server layer resources.
>
>> From reading 'draft-ietf-ccamp-lsp-hierarchy-bis-03.txt' it is not 
>> clear how 
> will this exactly work.
>
> For example, we set up a VCAT group (i.e. by signaling multiple STS1 
> LSPs) as allowed by the VCAT ID. I believe each of these LSPs would 
> appear as LSP_TUNNEL_INTERFACEs in the client layer with bandwidth 
> capacity equivalent to STS1 (i.e. 52mbps). My question is which 
> LSP_TUNNEL_INTERFACE will be used for signaling the ethernet LSP, I 
> think an additional component link with bandwidth capacity equivalent 
> to the aggregate bandwidth will have to be created.
>
> Is there a defined way of handling this situation?
>
> Thanks,
> Snigdho
>
>
>
>
-- 
Kohei Shiomoto, Ph.D
Senior Research Engineer, Supervisor, Group Leader
NTT Network Service Systems Laboratories
http://www.ntt.co.jp/islab/org/ns.html
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone [phone] Fax [phone]
Free online contents of "NTT Technical Review" available at
https://www.ntt-review.jp/





Envelope-to: [e-mail]
Delivery-date: Tue, 18 Mar 2008 14:53:18 +0000
User-Agent: Microsoft-Entourage/11.4.0.080122
Date: Tue, 18 Mar 2008 10:52:05 -0400
Subject: Re: New CCAMP I-Ds
From: JP Vasseur <[e-mail]>
To: Adrian Farrel <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: New CCAMP I-Ds
Thread-Index: AciJB6Go4Ce6dPT6EdyNXAANk8WjQA=
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l…; t05851925; x06715925; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From: JP Vasseur <[e-mail]> |Subject: Re: New CCAMP I-Ds |Sender:  |To: Adrian Farrel <[e-mail]>, <ccamp@op s.ietf.org>; bh=Pp4qKNWAKvHCksKMd9m7FrIGvvwh53eC5NCqNnlYxyQ=; b=aGOYsjwGo9jfoEKfYczfs3ljVUTuOMAcmCB7/aihJwL9MhX5wzQhyP/TdT 3QlnT9cE1SF7q+S6Yi4A6Wb8+w7JeiilzcNhUR18Yf7+FwNTXd98rjJRaYcr +QcE0TMKR0;
Authentication-Results: rtp-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );

Hi,



> draft-bradford-ccamp-path-key-ero-01.txt

In favor (I'm a co-author)






Envelope-to: [e-mail]
Delivery-date: Tue, 18 Mar 2008 13:54:48 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New CCAMP I-Ds
Date: Tue, 18 Mar 2008 14:48:55 +0100
Message-ID: <[e-mail]>
Thread-Topic: New CCAMP I-Ds
thread-index: AciI+b1RRNVACLqlQt+6twh0HBU5CAABP1uw
From: "Diego Caviglia" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>

Hi guys,
        in line.

BR

Diego 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: martedì 18 marzo 2008 13.43
> To: [e-mail]
> Subject: New CCAMP I-Ds
> 
> Hi,
> 
> We took an action in Philadelphia to poll you on a long list 
> of potential new working group I-Ds.
> 
> We are splitting this list into three largely for our own 
> sanity. Don't worry if your favorite I-D is not in the first 
> (or second) batch. We will get to it by the end of the month.
> 
> Can you please answer yes or no for the following I-Ds. You 
> are encouraged to give reasons especially for negative responses).
> 
> Thanks,
> Adrian and Deborah
> 
> ===
> 
> draft-xie-ccamp-lsp-dppm-02.txt
> draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
Yes :-)
> draft-bradford-ccamp-path-key-ero-01.txt
> draft-li-ccamp-confirm-data-channel-status-03.txt
Yes
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 18 Mar 2008 12:49:48 +0000
Message-ID: <043e01c888f6$628ab910$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: New CCAMP I-Ds
Date: Tue, 18 Mar 2008 12:43:10 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We took an action in Philadelphia to poll you on a long list of potential 
new working group I-Ds.

We are splitting this list into three largely for our own sanity. Don't 
worry if your favorite I-D is not in the first (or second) batch. We will 
get to it by the end of the month.

Can you please answer yes or no for the following I-Ds. You are encouraged 
to give reasons especially for negative responses).

Thanks,
Adrian and Deborah

=
draft-xie-ccamp-lsp-dppm-02.txt
draft-caviglia-ccamp-pc-spc-grsvpte-ext-02.txt
draft-bradford-ccamp-path-key-ero-01.txt
draft-li-ccamp-confirm-data-channel-status-03.txt





Envelope-to: [e-mail]
Delivery-date: Tue, 18 Mar 2008 11:26:48 +0000
Message-ID: <041d01c888ea$da4a5b10$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Bardalai, Snigdho" <[e-mail]>, "Kohei Shiomoto \(E-mail\)" <[e-mail]>, "Greg Bernstein \(E-mail\)" <[e-mail]>
Cc: "Ccamp \(E-mail\)" <[e-mail]>
Subject: Re: Signaling client layer LSP over VCAT server layer LSP
Date: Tue, 18 Mar 2008 11:25:51 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

IMHO the two drafts are not so closely related.

Hierarchy bis describes how, when an LSP is set up, the ingress may indicate 
to the egress that the LSP is to be advertised or used as a link in some 
specific network layer.

LSPs set up for VCAT are not used in that way. They are grouped together and 
the whole group is used as a link in another network layer.

So, for VCAT, one might use the call as the mechanism to exchange 
information about how to use the entire VCG as a link in the client layer. 
Alternatively (if one is implementing strictly according to the 
architecture) one might have three layers to consider...

- The server layer where a call coordinates multiple TDM LSPs
- The VCAT layer where a single hop LSP is requested between
   VCG end points resulting in the server layer call. The VCAT
   layer LSP would use hierarchy bis to determine that it should
   be advertised as a TE link in the client layer.
- The client layer where a magic TE link appears as the result of
   the VCAT layer LSP.

Depending on the deployment, the use of a VCAT layer LSP might be considered 
to be over-engineering. Just because an architecture defines multiple 
layers, it does not mean you have to implement them explicitly. It might be 
enough for the server layer call to provide the coordination with the client 
layer direct.

Cheers,
Adrian
----- Original Message ----- 
From: "Bardalai, Snigdho" <[e-mail]>
To: "Kohei Shiomoto (E-mail)" <[e-mail]>; "Greg 
Bernstein (E-mail)" <[e-mail]>
Cc: "Ccamp (E-mail)" <[e-mail]>; "Adrian Farrel (E-mail)" 
<[e-mail]>
Sent: Saturday, March 15, 2008 7:25 PM
Subject: Signaling client layer LSP over VCAT server layer LSP


Hello Kohei and Greg,

I have a question about client layer LSP signaling (e.g. ethernet) over VCAT 
server layer resources.

>From reading 'draft-ietf-ccamp-lsp-hierarchy-bis-03.txt' it is not clear how 
will this exactly work.

For example, we set up a VCAT group (i.e. by signaling multiple STS1 LSPs) 
as allowed by the VCAT ID. I believe each of these LSPs would appear as 
LSP_TUNNEL_INTERFACEs in the client layer with bandwidth capacity equivalent 
to STS1 (i.e. 52mbps). My question is which LSP_TUNNEL_INTERFACE will be 
used for signaling the ethernet LSP, I think an additional component link 
with bandwidth capacity equivalent to the aggregate bandwidth will have to 
be created.

Is there a defined way of handling this situation?

Thanks,
Snigdho





Envelope-to: [e-mail]
Delivery-date: Tue, 18 Mar 2008 11:26:40 +0000
Message-ID: <041c01c888ea$a20042b0$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Bardalai, Snigdho" <[e-mail]>, "Ccamp \(E-mail\)" <[e-mail]>
Cc: "Lou Berger \(E-mail\)" <[e-mail]>
Subject: Re: LSPID for Segment Recovery
Date: Tue, 18 Mar 2008 11:18:14 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Snigdho,

No-one else seems willing to answer you, so I'll pick it up...

> I have a doubt on the relationship between LSPID and association
> ID for tunnels with segment recovery. Would appreciate it if
> someone could clarify.
>
> RFC4872 suggests using the working LSP's LSPID as the
> association ID in the ASSOCIATION object for the recovery
> LSP and the reverse for the working LSP and RFC4873
> requires the use of this definition as per the following extract:
>
> 2.  Segment Recovery
>
>   snip ...... snip
>
>   When [RFC4090] isn't being used, the association between segment
>   recovery LSPs with other LSPs is indicated using the ASSOCIATION
>   object defined in [RFC4872]
>
> I would expect this definition includes the way the association
> ID value should be assigned, is my understanding correct?
>
> I can understand how the ASSOCIATION object for the recovery
> LSP can have its association ID set to the working LSP LSPID but
> it may not be possible for the reverse since there could be multiple
> recovery LSP segments.

I think the clue may be in section 3.2.1 of RFC 4873

   Recovery type processing procedures are the same as those defined in
   [RFC4872], but processing and identification occur with respect to
   segment recovery LSPs.  Note that this means that multiple
   ASSOCIATION objects of type recovery may be present on an LSP.

> I would like to understand what should the working LSP association
> ID be in case of segment recovery, should it be set to its own LSPID?
>
> Also, my understanding is that the association ID needs to be unique
> in the context of the association source, if that is the case does it
> mean if LSPID is used as the association ID then the LSPID should
> also be unique in the context of the association source rather than the
> context of a tunnel.

Association only happens between LSPs belonging to the same session. Thus, 
LSP ID is sufficiently unique. See 4872 for a fuller description.

Cheers,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Mon, 17 Mar 2008 13:20:05 +0000
Message-ID: <01d601c88830$efe10b50$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Presentation skipped in Philadelphia
Date: Mon, 17 Mar 2008 13:15:08 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Greg kindly sacrificed one of his slots on the agenda so that we could 
squeeze in everything else. Please don't forget to look at:

   c. Signaling Extensions for WSON
      (Greg - 10 mins [125/150])
      Slides (http://www.ietf.org/proceedings/08mar/slides/ccamp-22.ppt)

      Background reading
      - draft-bernstein-ccamp-wson-signaling-01.txt
     (http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-signaling-01.txt)

...and send your comments to the list.

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Sat, 15 Mar 2008 21:29:07 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-rfc4420bis-02.txt 
Message-Id: <[e-mail]>
Date: Sat, 15 Mar 2008 14: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           : Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE
	Author(s)       : A. Farrel, et al.
	Filename        : draft-ietf-ccamp-rfc4420bis-02.txt
	Pages           : 21
	Date            : 2008-03-15

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may
be established using the Resource Reservation Protocol Traffic
Engineering (RSVP-TE) extensions.  This protocol includes an object
(the SESSION_ATTRIBUTE object) that carries a Flags field used to
indicate options and attributes of the LSP.  That Flags field has
eight bits allowing for eight options to be set.  Recent proposals in
many documents that extend RSVP-TE have suggested uses for each of
the previously unused bits.

This document defines a new object for RSVP-TE messages that allows
the signaling of further attribute bits and also the carriage of
arbitrary attribute parameters to make RSVP-TE easily extensible to
support new requirements.  Additionally, this document defines a way
to record the attributes applied to the LSP on a hop-by-hop basis.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4420bis-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-rfc4420bis-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Sat, 15 Mar 2008 19:28:13 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C886D2.5C8C78CB"
Subject: Signaling client layer LSP over VCAT server layer LSP
Date: Sat, 15 Mar 2008 14:25:43 -0500
Message-ID: <[e-mail]>
Thread-Topic: Signaling client layer LSP over VCAT server layer LSP
Thread-Index: AciG0lx3duJDIC/4Tam/iLirW1e/Rw=
From: "Bardalai, Snigdho" <[e-mail]>
To: "Kohei Shiomoto (E-mail)" <[e-mail]>, "Greg Bernstein (E-mail)" <[e-mail]>
Cc: "Ccamp (E-mail)" <[e-mail]>, "Adrian Farrel (E-mail)" <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C886D2.5C8C78CB
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Kohei and Greg,

I have a question about client layer LSP signaling (e.g. ethernet) over VCAT server layer resources.

>From reading 'draft-ietf-ccamp-lsp-hierarchy-bis-03.txt' it is not clear how will this exactly work.

For example, we set up a VCAT group (i.e. by signaling multiple STS1 LSPs) as allowed by the VCAT ID. I believe each of these LSPs would appear as LSP_TUNNEL_INTERFACEs in the client layer with bandwidth capacity equivalent to STS1 (i.e. 52mbps). My question is which LSP_TUNNEL_INTERFACE will be used for signaling the ethernet LSP, I think an additional component link with bandwidth capacity equivalent to the aggregate bandwidth will have to be created.

Is there a defined way of handling this situation?

Thanks,
Snigdho

------_=_NextPart_001_01C886D2.5C8C78CB
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>Signaling client layer LSP over VCAT server layer LSP</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=2 FACE="Arial">Hello Kohei and Greg,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">I have a question about client layer LSP signaling (e.g. ethernet) over VCAT server layer resources.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">From reading 'draft-ietf-ccamp-lsp-hierarchy-bis-03.txt' it is not clear how will this exactly work.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">For example, we set up a VCAT group (i.e. by signaling multiple STS1 LSPs) as allowed by the VCAT ID. I believe each of these LSPs would appear as LSP_TUNNEL_INTERFACEs in the client layer with bandwidth capacity equivalent to STS1 (i.e. 52mbps). My question is which LSP_TUNNEL_INTERFACE will be used for signaling the ethernet LSP, I think an additional component link with bandwidth capacity equivalent to the aggregate bandwidth will have to be created.</FONT></P>

<P><FONT SIZE=2 FACE="Arial">Is there a defined way of handling this situation?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Thanks,</FONT>

<BR><FONT SIZE=2 FACE="Arial">Snigdho</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C886D2.5C8C78CB--



Envelope-to: [e-mail]
Delivery-date: Thu, 13 Mar 2008 14:38:03 +0000
Message-ID: <020801c88517$ab341b80$8c148182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Fw: I-D Action:draft-ietf-ccamp-rfc4420bis-01.txt 
Date: Thu, 13 Mar 2008 14:36:45 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

CCAMP :

As discussed, we are bis-ing RFC 4420. We will complete this quickly. Please 
raise any other issues you would like to see fixed.

MPLS :

You may have missed this discussion. RFC 4420 had an RSVP-TE TLV format that 
differed from all other RSVP-TE TLV formats. CCAMP felt very strongly that 
this should be fixed very fast before there are any deployment issues.


All :

Please comment on whether we should deprecate any codepoints to avoid b/w 
compatibility issues, or whether you think it is OK to continue with 
existing codepoints?

Thanks,
Adrian
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, March 13, 2008 2:00 PM
Subject: I-D Action:draft-ietf-ccamp-rfc4420bis-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           : Encoding of Attributes for Multiprotocol Label Switching 
> (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE
> Author(s)       : A. Farrel, et al.
> Filename        : draft-ietf-ccamp-rfc4420bis-01.txt
> Pages           : 21
> Date            : 2008-03-13
>
> Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may
> be established using the Resource Reservation Protocol Traffic
> Engineering (RSVP-TE) extensions.  This protocol includes an object
> (the SESSION_ATTRIBUTE object) that carries a Flags field used to
> indicate options and attributes of the LSP.  That Flags field has
> eight bits allowing for eight options to be set.  Recent proposals in
> many documents that extend RSVP-TE have suggested uses for each of
> the previously unused bits.
>
> This document defines a new object for RSVP-TE messages that allows
> the signaling of further attribute bits and also the carriage of
> arbitrary attribute parameters to make RSVP-TE easily extensible to
> support new requirements.  Additionally, this document defines a way
> to record the attributes applied to the LSP on a hop-by-hop basis.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4420bis-01.txt





Envelope-to: [e-mail]
Delivery-date: Thu, 13 Mar 2008 14:00:22 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-rfc4420bis-01.txt 
Message-Id: <[e-mail]>
Date: Thu, 13 Mar 2008 07: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           : Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE
	Author(s)       : A. Farrel, et al.
	Filename        : draft-ietf-ccamp-rfc4420bis-01.txt
	Pages           : 21
	Date            : 2008-03-13

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may
be established using the Resource Reservation Protocol Traffic
Engineering (RSVP-TE) extensions.  This protocol includes an object
(the SESSION_ATTRIBUTE object) that carries a Flags field used to
indicate options and attributes of the LSP.  That Flags field has
eight bits allowing for eight options to be set.  Recent proposals in
many documents that extend RSVP-TE have suggested uses for each of
the previously unused bits.

This document defines a new object for RSVP-TE messages that allows
the signaling of further attribute bits and also the carriage of
arbitrary attribute parameters to make RSVP-TE easily extensible to
support new requirements.  Additionally, this document defines a way
to record the attributes applied to the LSP on a hop-by-hop basis.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4420bis-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-rfc4420bis-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Wed, 12 Mar 2008 20:17:50 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8847E.14931D96"
Subject: RE: Ethernet Control Plane issues slide deck
Date: Wed, 12 Mar 2008 15:17:14 -0500
Message-ID: <[e-mail]>
Thread-Topic: Ethernet Control Plane issues slide deck
Thread-Index: AciEfdokZ6S4I1mPS26eCfJboMt4pwAADXDm
From: "Sadler, Jonathan B." <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8847E.14931D96
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks

________________________________

From: Adrian Farrel [mailto:[e-mail]]
Sent: Wed 3/12/2008 3:14 PM
To: [e-mail]; Sadler, Jonathan B.
Cc: [e-mail]; [e-mail]
Subject: Re: Ethernet Control Plane issues slide deck



Posted

Cheers,
Adrian
----- Original Message -----
From: "dimitri papadimitriou" <[e-mail]>
To: "Sadler, Jonathan B." <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Wednesday, March 12, 2008 7:13 PM
Subject: Re: Ethernet Control Plane issues slide deck


> hi -
>
> i sent the slide set to adrian this morning - so i guess they will be soon
> available on the IETF material website
>
> <https://datatracker.ietf.org/meeting/71/materials.html>
>
> thanks,
> -d.
>
>
> Sadler, Jonathan B. wrote:
>> Hi Dmitiri,
>>  I'm intersted in looking at the remainder of your slides (since we ran
>> out of time and you didn't get a chance to show them all) and I'm certain
>> there are people that were not in the room that would like to see all of
>> the slides. Can you provide the slides you presented in CCAMP this AM to
>> the list and/or Adrian?
>>  Thanks,
>>  Jonathan Sadler
>>  ============================================================
>> The information contained in this message may be privileged
>> and confidential and protected from disclosure. If the reader
>> of this message is not the intended recipient, or an employee
>> or agent responsible for delivering this message to the
>> intended recipient, you are hereby notified that any reproduction,
>> dissemination or distribution of this communication is strictly
>> prohibited. If you have received this communication in error,
>> please notify us immediately by replying to the message and
>> deleting it from your computer. Thank you. Tellabs
>> ============================================================
>>
>
>



============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

------_=_NextPart_001_01C8847E.14931D96
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>

<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>Re: Ethernet Control Plane issues slide deck</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText29273 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Thanks</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Adrian Farrel 
[mailto:[e-mail]]<BR><B>Sent:</B> Wed 3/12/2008 3:14 PM<BR><B>To:</B> 
[e-mail]; Sadler, Jonathan B.<BR><B>Cc:</B> 
[e-mail]; [e-mail]<BR><B>Subject:</B> 
Re: Ethernet Control Plane issues slide deck<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>Posted<BR><BR>Cheers,<BR>Adrian<BR>----- Original Message 
-----<BR>From: "dimitri papadimitriou" &lt;[e-mail]&gt;<BR>To: 
"Sadler, Jonathan B." &lt;[e-mail]&gt;<BR>Cc: 
&lt;[e-mail]&gt;; 
&lt;[e-mail]&gt;<BR>Sent: Wednesday, March 12, 2008 7:13 
PM<BR>Subject: Re: Ethernet Control Plane issues slide deck<BR><BR><BR>&gt; hi 
-<BR>&gt;<BR>&gt; i sent the slide set to adrian this morning - so i guess they 
will be soon<BR>&gt; available on the IETF material website<BR>&gt;<BR>&gt; 
&lt;<A 
href="https://datatracker.ietf.org/meeting/71/materials.html">https://datatracker.ietf.org/meeting/71/materials.html</A>&gt;<BR>&gt;<BR>&gt; 
thanks,<BR>&gt; -d.<BR>&gt;<BR>&gt;<BR>&gt; Sadler, Jonathan B. 
wrote:<BR>&gt;&gt; Hi Dmitiri,<BR>&gt;&gt;&nbsp; I'm intersted in looking at the 
remainder of your slides (since we ran<BR>&gt;&gt; out of time and you didn't 
get a chance to show them all) and I'm certain<BR>&gt;&gt; there are people that 
were not in the room that would like to see all of<BR>&gt;&gt; the slides. Can 
you provide the slides you presented in CCAMP this AM to<BR>&gt;&gt; the list 
and/or Adrian?<BR>&gt;&gt;&nbsp; Thanks,<BR>&gt;&gt;&nbsp; Jonathan 
Sadler<BR>&gt;&gt;&nbsp; 
============================================================<BR>&gt;&gt; The 
information contained in this message may be privileged<BR>&gt;&gt; and 
confidential and protected from disclosure. If the reader<BR>&gt;&gt; of this 
message is not the intended recipient, or an employee<BR>&gt;&gt; or agent 
responsible for delivering this message to the<BR>&gt;&gt; intended recipient, 
you are hereby notified that any reproduction,<BR>&gt;&gt; dissemination or 
distribution of this communication is strictly<BR>&gt;&gt; prohibited. If you 
have received this communication in error,<BR>&gt;&gt; please notify us 
immediately by replying to the message and<BR>&gt;&gt; deleting it from your 
computer. Thank you. Tellabs<BR>&gt;&gt; 
============================================================<BR>&gt;&gt;<BR>&gt;<BR>&gt;<BR><BR></FONT></P></DIV>

<pre>============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
</pre></BODY>
</HTML>
------_=_NextPart_001_01C8847E.14931D96--



Envelope-to: [e-mail]
Delivery-date: Wed, 12 Mar 2008 20:16:46 +0000
Message-ID: <010701c8847d$bdfeccf0$8c148182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Sadler, Jonathan B." <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Ethernet Control Plane issues slide deck
Date: Wed, 12 Mar 2008 20:14:51 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Posted

Cheers,
Adrian
----- Original Message ----- 
From: "dimitri papadimitriou" <[e-mail]>
To: "Sadler, Jonathan B." <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Wednesday, March 12, 2008 7:13 PM
Subject: Re: Ethernet Control Plane issues slide deck


> hi -
>
> i sent the slide set to adrian this morning - so i guess they will be soon 
> available on the IETF material website
>
> <https://datatracker.ietf.org/meeting/71/materials.html>
>
> thanks,
> -d.
>
>
> Sadler, Jonathan B. wrote:
>> Hi Dmitiri,
>>  I'm intersted in looking at the remainder of your slides (since we ran 
>> out of time and you didn't get a chance to show them all) and I'm certain 
>> there are people that were not in the room that would like to see all of 
>> the slides. Can you provide the slides you presented in CCAMP this AM to 
>> the list and/or Adrian?
>>  Thanks,
>>  Jonathan Sadler
>>  ==============================
>> The information contained in this message may be privileged
>> and confidential and protected from disclosure. If the reader
>> of this message is not the intended recipient, or an employee
>> or agent responsible for delivering this message to the
>> intended recipient, you are hereby notified that any reproduction,
>> dissemination or distribution of this communication is strictly
>> prohibited. If you have received this communication in error,
>> please notify us immediately by replying to the message and
>> deleting it from your computer. Thank you. Tellabs
>> ==============================
>>
>
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 12 Mar 2008 19:14:24 +0000
Message-ID: <[e-mail]>
Date: Wed, 12 Mar 2008 20:13:05 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To: [e-mail]
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "Sadler, Jonathan B." <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Ethernet Control Plane issues slide deck
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

hi -

i sent the slide set to adrian this morning - so i guess they will be 
soon available on the IETF material website

<https://datatracker.ietf.org/meeting/71/materials.html>

thanks,
-d.


Sadler, Jonathan B. wrote:
> Hi Dmitiri,
>  
> I'm intersted in looking at the remainder of your slides (since we ran out of time and you didn't get a chance to show them all) and I'm certain there are people that were not in the room that would like to see all of the slides. Can you provide the slides you presented in CCAMP this AM to the list and/or Adrian?
>  
> Thanks,
>  
> Jonathan Sadler
>  
> ==============================
> The information contained in this message may be privileged
> and confidential and protected from disclosure. If the reader
> of this message is not the intended recipient, or an employee
> or agent responsible for delivering this message to the
> intended recipient, you are hereby notified that any reproduction,
> dissemination or distribution of this communication is strictly
> prohibited. If you have received this communication in error,
> please notify us immediately by replying to the message and
> deleting it from your computer. Thank you. Tellabs
> ==============================
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 12 Mar 2008 18:41:02 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88470.6753BD9C"
Subject: Ethernet Control Plane issues slide deck
Date: Wed, 12 Mar 2008 13:36:13 -0500
Message-ID: <[e-mail]>
Thread-Topic: Ethernet Control Plane issues slide deck
Thread-Index: AciEb/MbFNrGNmj3TEyi0nMCpzjlVg=
From: "Sadler, Jonathan B." <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C88470.6753BD9C
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Dmitiri,
 
I'm intersted in looking at the remainder of your slides (since we ran out of time and you didn't get a chance to show them all) and I'm certain there are people that were not in the room that would like to see all of the slides. Can you provide the slides you presented in CCAMP this AM to the list and/or Adrian?
 
Thanks,
 
Jonathan Sadler
 
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

------_=_NextPart_001_01C88470.6753BD9C
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML DIR=ltr><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"></HEAD><BODY><DIV><FONT face='Arial' color=#000000 size=2>Hi Dmitiri,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>I'm intersted in looking&nbsp;at the remainder of 
your slides (since we ran out of time and you didn't get a chance to show them 
all) and I'm certain there are people that were not in the room that would like 
to see all of the slides. Can you&nbsp;provide the&nbsp;slides you presented in 
CCAMP this AM to the list and/or Adrian?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Thanks,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Jonathan Sadler</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV><pre>============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
</pre></BODY></HTML>
------_=_NextPart_001_01C88470.6753BD9C--



Envelope-to: [e-mail]
Delivery-date: Wed, 12 Mar 2008 15:45:15 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt 
Message-Id: <[e-mail]>
Date: Wed, 12 Mar 2008 08: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           : GMPLS Asymmetric Bandwidth Bidirectional LSPs
	Author(s)       : L. Berger, et al.
	Filename        : draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt
	Pages           : 14
	Date            : 2008-03-12

This document defines a method for the support of GMPLS Asymmetric
Bandwidth Bidirectional LSPs.  The presented approach is applicable
to any switching technology and builds on the original RSVP model for
the transport of traffic related parameters.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-asymm-bw-bidir-lsps-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-asymm-bw-bidir-lsps-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Tue, 11 Mar 2008 17:17:06 +0000
Message-ID: <011701c8839b$77dd23d0$8c148182@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Slides for Wednesday
Date: Tue, 11 Mar 2008 17:15:09 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

I only have a few of the slidesets for Wednesday.

Please don't forget.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 11 Mar 2008 14:14:52 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: GMPLS TLV Format
Date: Tue, 11 Mar 2008 15:12:03 +0100
Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02605601189@ftrdmel2>
Thread-Topic: GMPLS TLV Format
Thread-Index: AciC7+ZNBJc8g0w6SfOLNcxz7tBR1wAkVGmA
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

Hi.

Agreed.

But do you think a draft 4420bis "Created: March 11" and dated "03-10"
on the CCAMP status page will be fast enough to progress back to 4420
publishing ages? ;-)

Julien


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Lou Berger

Just to avoid any possible silence:

I think fixing RFC 4420 *quickly* would be best.

Lou

At 04:02 PM 3/10/2008, Adrian Farrel wrote:
>Hi,
>
>In today's meeting, we discussed again the issue of TLV formats in:
>
>- RFC 3209 and RFC 3471
>- RFC 4420
>- draft-ietf-ccamp-ethernet-traffic-parameters-03.txt
>
>The current position is:
>- Base RSVP-TE and GMPLS carry the full length of the
>  TLV in the Length field
>- OSPF carries the length of the Value field only in the
>  TLV
>- RFC 4420 follows the OSPF form. This was an error
>   that was not intended.
>- draft-ietf-ccamp-ethernet-traffic-parameters followed
>   RFC 4420 (assuming that the WG had made a deliberate
>   change)
>
>The bottom line is that it is not helpful to implementers that one 
>protocol has two different ways to encode TLVs.
>
>We must choose between three options.
>1. All TLVs are encoded as per RFC 3209.
>    RFC 4420 would need to be fixed.
>   draft-ietf-ccamp-ethernet-traffic-parameters would
>    need to be changed.
>2. All TLVs *except* those in RFC 4420 use the
>    RFC 3209 format. RFC 4420 remains an anomaly.
>3. All old TLVs remain as per RFC 3209. All new
>    TLVs (starting from RFC 4420) use the RFC 4420
>    format.
>
>The meeting seemed to prefer option 1, but this is contingent on 
>existing implementations. If there are too many existing and 
>deployed implementations (too many == 1 ?) we may have to pick to
option 2.
>
>So...
>
>How would you feel if we did an update to RFC 4420 that fixed the 
>TLV encoding to be conformant with RFC 3209? Would this cause any of 
>you a problem?
>
>Reply on-list or to me in private if there is a confidentiality issue.
>
>It would be helpful to have opinions on both sides. Please don't 
>leave silence to mean anything specific.
>
>Thanks,
>Adrian
>
>
>






Envelope-to: [e-mail]
Delivery-date: Mon, 10 Mar 2008 23:30:49 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: GMPLS TLV Format
Date: Mon, 10 Mar 2008 16:29:27 -0700
Message-ID: <[e-mail]>
Thread-Topic: GMPLS TLV Format
Thread-Index: AciC8C7KY8r68SYySxCWDwwBM7h+3gAFmKuw
From: "Drake, John E" <[e-mail]>
To: "Lou Berger" <[e-mail]>, "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>

Indeed 

>-----Original Message-----
>From: Lou Berger [mailto:[e-mail]] 
>Sent: Monday, March 10, 2008 1:38 PM
>To: Adrian Farrel
>Cc: [e-mail]
>Subject: Re: GMPLS TLV Format
>
>Just to avoid any possible silence:
>
>I think fixing RFC 4420 *quickly* would be best.
>
>Lou
>
>At 04:02 PM 3/10/2008, Adrian Farrel wrote:
>>Hi,
>>
>>In today's meeting, we discussed again the issue of TLV formats in:
>>
>>- RFC 3209 and RFC 3471
>>- RFC 4420
>>- draft-ietf-ccamp-ethernet-traffic-parameters-03.txt
>>
>>The current position is:
>>- Base RSVP-TE and GMPLS carry the full length of the
>>  TLV in the Length field
>>- OSPF carries the length of the Value field only in the
>>  TLV
>>- RFC 4420 follows the OSPF form. This was an error
>>   that was not intended.
>>- draft-ietf-ccamp-ethernet-traffic-parameters followed
>>   RFC 4420 (assuming that the WG had made a deliberate
>>   change)
>>
>>The bottom line is that it is not helpful to implementers that one 
>>protocol has two different ways to encode TLVs.
>>
>>We must choose between three options.
>>1. All TLVs are encoded as per RFC 3209.
>>    RFC 4420 would need to be fixed.
>>   draft-ietf-ccamp-ethernet-traffic-parameters would
>>    need to be changed.
>>2. All TLVs *except* those in RFC 4420 use the
>>    RFC 3209 format. RFC 4420 remains an anomaly.
>>3. All old TLVs remain as per RFC 3209. All new
>>    TLVs (starting from RFC 4420) use the RFC 4420
>>    format.
>>
>>The meeting seemed to prefer option 1, but this is contingent on 
>>existing implementations. If there are too many existing and deployed 
>>implementations (too many == 1 ?) we may have to pick to option 2.
>>
>>So...
>>
>>How would you feel if we did an update to RFC 4420 that fixed the TLV 
>>encoding to be conformant with RFC 3209? Would this cause any 
>of you a 
>>problem?
>>
>>Reply on-list or to me in private if there is a confidentiality issue.
>>
>>It would be helpful to have opinions on both sides. Please 
>don't leave 
>>silence to mean anything specific.
>>
>>Thanks,
>>Adrian
>>
>>
>>
>
>
>



Envelope-to: [e-mail]
Delivery-date: Mon, 10 Mar 2008 23:18:14 +0000
Message-ID: <03bb01c88304$cad93700$3a87960a@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-ccamp-rfc4420bis-00.txt 
Date: Mon, 10 Mar 2008 23:16:35 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Having received comments in favour of fixing 4420 both on and off list, here 
is an I-D showing what we would have to do to fix the issue.

Comments please.

I don't see any reason to delay this in the process apart from to give you 
all a chance to comment.

Thanks,
Adrian
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, March 10, 2008 10:30 PM
Subject: I-D Action:draft-ietf-ccamp-rfc4420bis-00.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           : Encoding of Attributes for Multiprotocol Label Switching 
> (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE
> Author(s)       : A. Farrel, et al.
> Filename        : draft-ietf-ccamp-rfc4420bis-00.txt
> Pages           : 21
> Date            : 2008-03-10
>
> Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may
> be established using the Resource Reservation Protocol Traffic
> Engineering (RSVP-TE) extensions.  This protocol includes an object
> (the SESSION_ATTRIBUTE object) that carries a Flags field used to
> indicate options and attributes of the LSP.  That Flags field has
> eight bits allowing for eight options to be set.  Recent proposals in
> many documents that extend RSVP-TE have suggested uses for each of
> the previously unused bits.
>
> This document defines a new object for RSVP-TE messages that allows
> the signaling of further attribute bits and also the carriage of
> arbitrary attribute parameters to make RSVP-TE easily extensible to
> support new requirements.  Additionally, this document defines a way
> to record the attributes applied to the LSP on a hop-by-hop basis.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4420bis-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.
>


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


> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> 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
> 





Envelope-to: [e-mail]
Delivery-date: Mon, 10 Mar 2008 22:29:40 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-ccamp-rfc4420bis-00.txt 
Message-Id: <[e-mail]>
Date: Mon, 10 Mar 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           : Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE
	Author(s)       : A. Farrel, et al.
	Filename        : draft-ietf-ccamp-rfc4420bis-00.txt
	Pages           : 21
	Date            : 2008-03-10

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may
be established using the Resource Reservation Protocol Traffic
Engineering (RSVP-TE) extensions.  This protocol includes an object
(the SESSION_ATTRIBUTE object) that carries a Flags field used to
indicate options and attributes of the LSP.  That Flags field has
eight bits allowing for eight options to be set.  Recent proposals in
many documents that extend RSVP-TE have suggested uses for each of
the previously unused bits.

This document defines a new object for RSVP-TE messages that allows
the signaling of further attribute bits and also the carriage of
arbitrary attribute parameters to make RSVP-TE easily extensible to
support new requirements.  Additionally, this document defines a way
to record the attributes applied to the LSP on a hop-by-hop basis.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4420bis-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-rfc4420bis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Mon, 10 Mar 2008 21:01:05 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
Date: Mon, 10 Mar 2008 17:00:13 -0400
Message-ID: <[e-mail]>
Thread-Topic: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
Thread-Index: AciCFnTkfyv1mhdzTtaIOtv9EJPZbgA2v/xg
From: "Zafar Ali (zali)" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Anca Zamfir (ancaz)" <[e-mail]>, "Newton, Jonathan" <[e-mail]>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l05; t05182816; x06046816; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From: "Zafar Ali (zali)" <[e-mail]> |Subject: RE: WG last call on draft-ietf-ccam p-mpls-graceful-shutdown |Sender: ; bh=6NC8100uM7DYEFMOJXeMnvApwftjqaRW2Tw+U7FkIss=; bÝJEVPHIjZkdQaowM1dhOD7xMA/0D4IXgL8L9Ys1mpZuxW0KMCr4EyfyHw Q9eYrKMhVOFvUfF2vlhAwyFSWzOqblck+oXnZIasqykFMWimM8ISGYAFGTF9 bcC7wz1GZlTeRyv2Saj//ZqxsM8ibT8ky8c5F00KXBdgxZ6sVL5z8=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );

Adrian- 

On behalf of the authors, I am acking this action item on us. 

Thanks

Regards... Zafar  

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Sunday, March 09, 2008 2:48 PM
> To: [e-mail]
> Subject: Re: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
> 
> Hi,
> 
> This last call generated a lot of questions, issues and 
> discussions on the list.
> 
> Authors: I know you got involved in the debate, so thanks. 
> What you should do now is send mail to the list enumerating 
> and summarising the issues raised. For each you can say 
> whether resolved (and how), or your plan for resolution.
> 
> Thanks,
> Adrian
> ----- Original Message -----
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Sent: Wednesday, February 13, 2008 11:06 AM
> Subject: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
> 
> 
> > Hi,
> >
> > The authors of this draft have been indicating that they 
> thought it was 
> > complete for some time. They have now updated the document 
> to fix various 
> > formatting nits and minor issues raised in the working group.
> >
> > Therefore, this email marks the start of a working group 
> last call on
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-grac
> eful-shutdown-05.txt 
> > This is positioned to be an Informational RFC.
> >
> > The last call will end on Wednesday 5th March at 12 noon 
> GMT. Please send 
> > your comments to the list.
> >
> > Thanks,
> > Adrian
> >
> >
> > 
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Mon, 10 Mar 2008 20:38:31 +0000
Date: Mon, 10 Mar 2008 16:37:35 -0400
To: "Adrian Farrel" <[e-mail]>
From: Lou Berger <[e-mail]>
Subject: Re: GMPLS TLV Format
Cc: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <[e-mail]>

Just to avoid any possible silence:

I think fixing RFC 4420 *quickly* would be best.

Lou

At 04:02 PM 3/10/2008, Adrian Farrel wrote:
>Hi,
>
>In today's meeting, we discussed again the issue of TLV formats in:
>
>- RFC 3209 and RFC 3471
>- RFC 4420
>- draft-ietf-ccamp-ethernet-traffic-parameters-03.txt
>
>The current position is:
>- Base RSVP-TE and GMPLS carry the full length of the
>  TLV in the Length field
>- OSPF carries the length of the Value field only in the
>  TLV
>- RFC 4420 follows the OSPF form. This was an error
>   that was not intended.
>- draft-ietf-ccamp-ethernet-traffic-parameters followed
>   RFC 4420 (assuming that the WG had made a deliberate
>   change)
>
>The bottom line is that it is not helpful to implementers that one 
>protocol has two different ways to encode TLVs.
>
>We must choose between three options.
>1. All TLVs are encoded as per RFC 3209.
>    RFC 4420 would need to be fixed.
>   draft-ietf-ccamp-ethernet-traffic-parameters would
>    need to be changed.
>2. All TLVs *except* those in RFC 4420 use the
>    RFC 3209 format. RFC 4420 remains an anomaly.
>3. All old TLVs remain as per RFC 3209. All new
>    TLVs (starting from RFC 4420) use the RFC 4420
>    format.
>
>The meeting seemed to prefer option 1, but this is contingent on 
>existing implementations. If there are too many existing and 
>deployed implementations (too many = 1 ?) we may have to pick to option 2.
>
>So...
>
>How would you feel if we did an update to RFC 4420 that fixed the 
>TLV encoding to be conformant with RFC 3209? Would this cause any of 
>you a problem?
>
>Reply on-list or to me in private if there is a confidentiality issue.
>
>It would be helpful to have opinions on both sides. Please don't 
>leave silence to mean anything specific.
>
>Thanks,
>Adrian
>
>
>




Envelope-to: [e-mail]
Delivery-date: Mon, 10 Mar 2008 20:04:43 +0000
Message-ID: <030e01c882e9$b1cca9b0$3a87960a@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: GMPLS TLV Format
Date: Mon, 10 Mar 2008 20:02:21 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

In today's meeting, we discussed again the issue of TLV formats in:

- RFC 3209 and RFC 3471
- RFC 4420
- draft-ietf-ccamp-ethernet-traffic-parameters-03.txt

The current position is:
- Base RSVP-TE and GMPLS carry the full length of the
  TLV in the Length field
- OSPF carries the length of the Value field only in the
  TLV
- RFC 4420 follows the OSPF form. This was an error
   that was not intended.
- draft-ietf-ccamp-ethernet-traffic-parameters followed
   RFC 4420 (assuming that the WG had made a deliberate
   change)

The bottom line is that it is not helpful to implementers that one protocol 
has two different ways to encode TLVs.

We must choose between three options.
1. All TLVs are encoded as per RFC 3209.
    RFC 4420 would need to be fixed.
   draft-ietf-ccamp-ethernet-traffic-parameters would
    need to be changed.
2. All TLVs *except* those in RFC 4420 use the
    RFC 3209 format. RFC 4420 remains an anomaly.
3. All old TLVs remain as per RFC 3209. All new
    TLVs (starting from RFC 4420) use the RFC 4420
    format.

The meeting seemed to prefer option 1, but this is contingent on existing 
implementations. If there are too many existing and deployed implementations 
(too many = 1 ?) we may have to pick to option 2.

So...

How would you feel if we did an update to RFC 4420 that fixed the TLV 
encoding to be conformant with RFC 3209? Would this cause any of you a 
problem?

Reply on-list or to me in private if there is a confidentiality issue.

It would be helpful to have opinions on both sides. Please don't leave 
silence to mean anything specific.

Thanks,
Adrian 





Envelope-to: [e-mail]
Delivery-date: Mon, 10 Mar 2008 14:11:52 +0000
Message-ID: <028301c882b8$77d01ca0$3a87960a@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Getting the right copy of the agenda
Date: Mon, 10 Mar 2008 14:10:02 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Please use 
http://www.ietf.org/proceedings/08mar/agenda/ccamp.htm

NOT
http://www.ietf.org/proceedings/08mar/agenda/ccamp.txt


(No, I don't know why both are available)

A




Envelope-to: [e-mail]
Delivery-date: Mon, 10 Mar 2008 13:41:40 +0000
Message-ID: <020901c882b4$18fa4c40$3a87960a@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Slides for today
Date: Mon, 10 Mar 2008 13:38:54 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Most of the slides for today's session are now uploaded 
(https://datatracker.ietf.org/meeting/71/materials.html) and linked to from 
the agenda (http://www.ietf.org/proceedings/08mar/agenda/ccamp.htm)

A couple of presentations still missing. Hope to have them soon.

Adrian 





Envelope-to: [e-mail]
Delivery-date: Sun, 09 Mar 2008 18:50:22 +0000
Message-ID: <00df01c88216$21e75800$3a87960a@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Re: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
Date: Sun, 9 Mar 2008 18:48:11 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Hi,

This last call generated a lot of questions, issues and discussions on the 
list.

Authors: I know you got involved in the debate, so thanks. What you should 
do now is send mail to the list enumerating and summarising the issues 
raised. For each you can say whether resolved (and how), or your plan for 
resolution.

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, February 13, 2008 11:06 AM
Subject: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown


> Hi,
>
> The authors of this draft have been indicating that they thought it was 
> complete for some time. They have now updated the document to fix various 
> formatting nits and minor issues raised in the working group.
>
> Therefore, this email marks the start of a working group last call on
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-05.txt 
> This is positioned to be an Informational RFC.
>
> The last call will end on Wednesday 5th March at 12 noon GMT. Please send 
> your comments to the list.
>
> Thanks,
> Adrian
>
>
> 





Envelope-to: [e-mail]
Delivery-date: Sat, 08 Mar 2008 20:20:30 +0000
Message-ID: <013701c88159$55bb2660$9dac1cac@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Agenda updated
Date: Sat, 8 Mar 2008 20:16:35 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

An HTML agenda is now in place with a couple of minor updates because of 
folk not travelling.

Please check:
- Are you talking?
- Have you sent your slides?
- Have I posted them?

Cheers,
Adrian 






Envelope-to: [e-mail]
Delivery-date: Thu, 06 Mar 2008 15:12:38 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Agenda planning
Date: Thu, 6 Mar 2008 09:10:01 -0600
Message-ID: <[e-mail]>
Thread-Topic: Agenda planning
thread-index: Ach+SIxcGZ3nLJ5jTcyebxs4nrVVNwAkuScgADAjz+AFrom: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>
To: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>

Hi,

The agenda was updated (slightly)-

Adrian and Deborah 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Wednesday, March 05, 2008 11:15 AM
To: [e-mail]
Cc: Adrian Farrel
Subject: RE: Agenda planning

Hi,

A tentative agenda is uploaded:
http://www.ietf.org/proceedings/08mar/agenda/ccamp.txt

Please send any additional requests/comments to us and don't forget we
need your presentations (especially Monday's session) asap.

Thanks,
Adrian and Deborah



Envelope-to: [e-mail]
Delivery-date: Thu, 06 Mar 2008 09:29:42 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
Date: Thu, 6 Mar 2008 03:27:02 -0600
Message-ID: <[e-mail]>
Thread-Topic: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
Thread-Index: Ach5PAJyNCCsLW90RVGsQfj2WiuWNQFn2qKAACFStHAFrom: "AISSAOUI Mustapha" <[e-mail]>
To: <[e-mail]>

Dear all,
below are my comments on this draft. I apologize if some of these have
already been raised.

Mustapha.

1. Second paragraph in the introduction states:
   "Graceful shutdown of a resource may require several steps. These 
   steps can be broadly divided into two sets: disabling the 
   resource in the control plane and removing the resource for 
   forwarding."
I do not believe that this document achieves the disabling of the
resource in the control plane. What it provides is a way to facilitate
diverting LSPs away from the resource by making it a last resort
resource. After IGP advertized the max TE metric of 0xFFFFFF for a link,
a CSPF LSP with zero bandwidth can still have its path go over this
link.

2. Second paragraph of Section 3 reads:
"- Once an operator has initiated graceful shutdown of a network 
   resource, no new TE LSPs may be set up that use the resource. 
   Any signaling message for a new LSP that explicitly specifies the 
   resource, or that would require the use of the resource due to 
   local constraints, must be rejected as if the resource were 
   unavailable."
I do not believe this draft achieves this requirement. There is no
mechanism specified for a node to reject a new session reservation with
zero bandwidth over the resource being gracefully shutdown.

3. Second paragraph of Section 4 states:
"A node where a link or the whole node is being shutdown SHOULD 
   first trigger the IGP updates as described in Section 4.1, 
   introduce a delay to allow network convergence and only then use 
   the signaling mechanism described in Section 4.2. "
I propose to remove this altohgether. This does not guarantee that an
LSP for which a PathErr was sent will not be re-signaled over the
resource being shutdown. The reason being that most implementation
provide configurable delays between consecutive floodings of LSAs/LSPs.
It is up to the implementation at the headend node to decide how long to
hold for the list of interface address in the PathErr message to allow
for the flooding of the IGP TE information.

4. Last paragraph of Section 4.1.1 reads:
"Neighbors of the node where graceful shutdown procedure is in 
   progress SHOULD continue to advertise the actual unreserved 
   bandwidth of the TE links from the neighbors to that node, 
   without any routing adjacency change."
This is not exactly correct. If you wanted to have both outgoing LSPs
and incoming LSPs over the interface to be diverted, you will need to
enable the graceful shutdown procedures on both sides of the interface.
This means the procedures should be applied to the neigbour of a p2p
interface.

5. Section 4.2 states the following:
"The Graceful Shutdown 
   mechanism outlined in the following section, uses PathErr and 
   where available, Notify message, in order to achieve this 
   requirement. These mechanisms apply to both existing and new 
   LSPs."
As explained above, the mechanisms described in this document do not
prevent the establishment of new LSP over the resource being flagged for
graceful shutdown. Only existing LSPs at the time the user enables
graceful shutdown on a link are affected.

6. Second paragraph of Section 4.2.1 reads:
"When a graceful shutdown operation is performed along the path of 
   a protected LSP, based on a local decision, the PLR or branch 
   node MAY redirect the traffic onto the local detour or protecting 
   segment. In all cases, the PLR or branch node MUST forward the 
   PathErr to the head-end node, border node, or PCE."
This does not make sense. A PLR node will only take action on receipt of
the PathErr message for LSPs **it originates**. FRR procedures do not
react to PathErr messages unless you are proposing to change RFC 4379.

7. Last paragraph of Section 4.2.1 reads:
"When a head-end node, border node, or PCE receives a PathErr (or 
   Notify) message with error value of " Local link maintenance 
   required", it MAY trigger a make-before-break procedure. When 
   performing path computation for the new LSP, the head-end node, 
   border node, or PCE SHOULD avoid using the TE resources 
   identified by the IP address contained in the PathErr (or Notify 
   message)"
It should be clarified that the head-end node will exclude the use of TE
resource in path computation for a period of time only. The head-end
node has no way of knowing in the future if a link in a downstream node
is still flagged for graceful shutdown and thus cannot hold to the
information in PathErr forever. The fact that a metric of a link remains
set to 0xffffff in the TE database cannot be taken to mean that the link
is still in graceful shutdown. It just means that this link will
contibute to a high cost for a CSPF path using it. 
---------------------------------------------------------
> > >
> > > At 06:06 AM 2/13/2008, Adrian Farrel wrote:
> > >>Hi,
> > >>
> > >>The authors of this draft have been indicating that they
> > thought it was
> > >>complete for some time. They have now updated the document
> > to fix various
> > >>formatting nits and minor issues raised in the working group.
> > >>
> > >>Therefore, this email marks the start of a working group
> > last call on
> > >>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gr
> aceful-shutdown-05.txt 
> > >>This is positioned to be an Informational RFC.
> > >>
> > >>The last call will end on Wednesday 5th March at 12 noon
> > GMT. Please send
> > >>your comments to the list.
> > >>
> > >>Thanks,
> > >>Adrian



Envelope-to: [e-mail]
Delivery-date: Wed, 05 Mar 2008 16:16:16 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Agenda planning
Date: Wed, 5 Mar 2008 10:14:33 -0600
Message-ID: <[e-mail]>
Thread-Topic: Agenda planning
thread-index: Ach+SIxcGZ3nLJ5jTcyebxs4nrVVNwAkuScg
From: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>
To: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>

Hi,

A tentative agenda is uploaded:
http://www.ietf.org/proceedings/08mar/agenda/ccamp.txt

Please send any additional requests/comments to us and don't forget we
need your presentations (especially Monday's session) asap.

Thanks,
Adrian and Deborah

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Adrian Farrel
Sent: Tuesday, March 04, 2008 5:35 PM
To: [e-mail]
Subject: Agenda planning

Hi,

You may have noticed that your chairs are even more disorganised than
usual 
this time around.
(Plenty of excuses, but those are no help to you. Bring back Kireeti!
:-)

We have two sessions:
- Monday 13.00 - 15.00
- Wednesday 9.00 - 11.30

The provisional plan is to put routine working group business on the
Monday. 
This will include:
- working group status
- ITU-T liaison activity
- progress of working group drafts
- other assorted drafts

We will then split the Wednesday session between Ethernet and WSON.

Please send us your requests for slots and we will try to get a more 
detailed agenda out soon.

Thanks,
Adrian and Deborah 






Envelope-to: [e-mail]
Delivery-date: Wed, 05 Mar 2008 16:16:10 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
Date: Wed, 5 Mar 2008 16:11:58 -0000
Message-ID: <[e-mail]>
Thread-Topic: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
Thread-Index: Ach5PAJyNCCsLW90RVGsQfj2WiuWNQFn2qKA
From: "Newton, Jonathan" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, "Lou Berger" <[e-mail]>
Cc: <[e-mail]>

Hi Adrian / Lou,

With respect to the comments on the mechanism to trigger the ingress LSP
to perform a make-before-break, the draft already references 4736 for
definition of the required pathErr codes.

I have only had a quick look over 4920, but I would suggest that there
should not be overlap with crankback for a couple of reasons:
1/To me, crankback is targeted at LSP setup time rather than in-service
LSPs (stand to be corrected here!).
2/The ingress LSR seems to need to request the crankback information,
making this a much more involved implementation and requiring advanced
configuration at the ingress node.

With respect to Soft-preemption: Whilst I can clearly see the overlap,
to me there are some reasons why it may not be appropriate to combine
these in any way:
1/ We would want the ingress element to be aware of, in order to log,
the reason for the MBB request and soft-preemption only has a single
'soft preemption desired' flag.
2/ In the case of graceful shutdown, the actual removal of the resource
has not yet occurred and it may be up to operator discretion whether to
continue with the resource removal in the case that LSPs remain.  In the
case of soft-preemption, the event has already occurred (the pre-empting
LSP is already admitted).   

Cheers,
~Jon. 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: 27 February 2008 12:10
> To: Lou Berger
> Cc: [e-mail]
> Subject: Re: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
> 
> Lou,
> 
> What you say about "triggered make-before-break" is interesting.
> We should also look at the overlap between this work and RFC 
> 4736 and RFC 4920.
> 
> Adrian
> ----- Original Message -----
> From: "Lou Berger" <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Tuesday, February 26, 2008 9:13 PM
> Subject: Re: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
> 
> 
> > Here are some last call comments on this draft:
> >
> > - Opening/general comment:
> >   "Category: Informational" and
> >   "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]"
> >
> >    Given this is NOT a standards track document, the use of RFC2119
> >    style directives is misleading and should not be used.
> >
> > - Section 2, a nit:
> >   "temporarily or definitely".
> >
> >   I think you mean indefinitely.
> >
> > - Section 3:
> >   "- If the resource being shutdown is a last resort, it can be
> >    used. Time or decision for removal of the resource being shutdown
> >    is based on a local decision at the node initiating the graceful
> >    shutdown procedure. "
> >
> >   "Last resort" should be defined in technical terms.  Also it's not
> >   clear how this requirement is being met by the draft.
> >
> > - Section 4.2:
> >   "The Graceful Shutdown
> >    mechanism outlined in the following section, uses PathErr and
> >    where available, Notify message, in order to achieve this
> >    requirement. These mechanisms apply to both existing and new
> >    LSPs."
> >
> >    This comment really applies to the whole section.  This section
> >    seems to be quite a bit more than what you'd expect to find in
> >    an informational document.  I think this comment given the next
> >    comment:
> >
> >    From a high-level perspective, it seems to me what's trying to
> >    accomplish in this section is to trigger MBB based on a
> >    management plane directive to gracefully shutdown a
> >    resource/link/node.  Given this, it seems that this objective
> >    is the same as that which soft-preemption provides, and that it
> >    doesn't really make sense to have two documents (which just so
> >    happen to be going through last call at the same time) that
> >    provide the identical functionality.  As this document is
> >    targeted as an informational document, perhaps it would be best
> >    to replace all of 4.2 with a recommendation to use soft
> >    preemption signaling procedures to support graceful shutdown.
> >
> >    Given this comment - I'll skip detailed comments on 4.2...
> >
> > Lou
> >
> > At 06:06 AM 2/13/2008, Adrian Farrel wrote:
> >>Hi,
> >>
> >>The authors of this draft have been indicating that they 
> thought it was 
> >>complete for some time. They have now updated the document 
> to fix various 
> >>formatting nits and minor issues raised in the working group.
> >>
> >>Therefore, this email marks the start of a working group 
> last call on
> >>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gr
aceful-shutdown-05.txt 
> >>This is positioned to be an Informational RFC.
> >>
> >>The last call will end on Wednesday 5th March at 12 noon 
> GMT. Please send 
> >>your comments to the list.
> >>
> >>Thanks,
> >>Adrian
> >>
> >>
> >>
> >
> >
> > 
> 
> 
> 
> 

This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.
 
Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 7th Floor, The Point, 37 North Wharf Road, London W2 1LA



Envelope-to: [e-mail]
Delivery-date: Tue, 04 Mar 2008 22:38:15 +0000
Message-ID: <076401c87e48$0ae0f840$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Agenda planning
Date: Tue, 4 Mar 2008 22:35:17 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

You may have noticed that your chairs are even more disorganised than usual 
this time around.
(Plenty of excuses, but those are no help to you. Bring back Kireeti! :-)

We have two sessions:
- Monday 13.00 - 15.00
- Wednesday 9.00 - 11.30

The provisional plan is to put routine working group business on the Monday. 
This will include:
- working group status
- ITU-T liaison activity
- progress of working group drafts
- other assorted drafts

We will then split the Wednesday session between Ethernet and WSON.

Please send us your requests for slots and we will try to get a more 
detailed agenda out soon.

Thanks,
Adrian and Deborah 





Envelope-to: [e-mail]
Delivery-date: Sun, 02 Mar 2008 12:00:25 +0000
Message-ID: <049801c87c5c$de287d10$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: ITU-T Re-review of RFC 4258 and RFC 4652
Date: Sun, 2 Mar 2008 11:59:18 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We heard that the ITU-T SG15 was not happy with the analysis of ASON routing 
produced by the design team and captured in RFC 4258 and RFC 4652. We sent 
https://datatracker.ietf.org/liaison/356/ soliciting further review and 
input.

This has given rise to a response (asking us to act by 15th September 2008).

The text of the response is brief:

"ITU-T thanks IETF for the opportunity to review RFC 4258 and RFC 4652
to determine if the RFCs contain ITU-T's current requirements for
ASON routing.  Attached to this liaison is the result of the review,
which looks at the requirements in the current in-force versions of
G.8080, G.7715 and G.7715.1 and determines if RFC 4258 and RFC 4652
documents ITU-T's existing as well as new requirements.

We would appreciate collaborating with IETF in the review of the
attached table as well as resolving the gaps between the ITU-T
documents and the RFCs.

We look forward to work with the IETF to resolve this gap. Please
advise on the best method of working together to resolve this issue."

The analysis of the requirements is provided in an attachment which you can 
find at https://datatracker.ietf.org/documents/LIAISON/file531.pdf

Thanks,
Adrian






Envelope-to: [e-mail]
Delivery-date: Sun, 02 Mar 2008 11:54:31 +0000
Message-ID: <049401c87c5c$1cefc450$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Received liaison on VCAT from ITU-T
Date: Sun, 2 Mar 2008 11:53:59 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

The ITU-T SG15 has responded to our liaison on the VCAT/LCAS work. A 
response is requested by 15th September 2008.

The liaison also contains a short comment on our liaison about GMPLS calls.

You can see the liaison through the ccamp page www.olddog.co.uk/ccamp.htm

The text of the liaison is included below.

Adrian

=
Q14/15 thanks you for your liaison of 1st February 2008
(https://datatracker.ietf.org/public/liaison_detail.cgi?detail_idA5, which 
is TD515 (WP3/15)).

Here are our comments to the responses provided in your liaison:

a) Regarding your response to Question 1 on protocol extensibility to 
encompass technologies
other than SONET/SDH, we notice that the recent I-D 
(draft-ietf-ccamp-gmpls-vcat-lcas-
04.txt) limits the number of VCGs per call to one. We support this position 
and consider this
to be a VCAT call.

b) Regarding your response to Question 4 on multiple calls support, VCAT is 
viewed as a layer
of its own and has its own call controller. As per the interlayer 
architecture in G.8080
section 6.6, the VCAT call would be associated with a server layer call or 
calls, each of
which would have/own one or more server layer connections. It is these 
connections that
are part of the VCG. In retrospect, a single call is sufficient for diverse 
routing as it can hold
details of both connections so that they don't use the same resources.

An example where multiple server calls associated with one VCAT call would 
be useful is
when all VCAT connections are to be protected. Here, rather than one call 
maintain the
knowledge of all working/protection pairs, it is simpler to have multiple 
calls each of which
only maintains one working/protection pair. This is even more convenient 
when restoration
behavior is applied when the protection connection fails.

c) Regarding your response to Question 6 on IP address format in GMPLS, we 
suggest the I-D
clarifies that there are different name (or identifier) spaces even though 
they may all use the
same IP address format, e.g.

- Control component
  The identifiers used to identify the entities that perform the control 
plane
  functions, such as route computation, signaling, control plane message
  delivering, etc.

- Transport resource
  The identifiers used to identify transport resource when they are referred
  to in the control plane messages. Note that these identifiers may not be
  the same as those referred to in the management plane messages.

- SCN
  The addresses used to deliver control plane messages

Examples of a similar address format in use in two different name spaces can 
be seen in the
OSPF routing protocol, where router ID (control and transport link scope) 
and IP address
(used by the forwarder) do not have to be the same.

Regarding your liaison response on GMPLS Calls
(https://datatracker.ietf.org/public/liaison_detail.cgi?detail_idA4, which 
is TD516 (WP3/15)),
thank you for your response. We do not have any further reply at this time 
and appreciate the
invitation for future input to CCAMP.

An electronic copy of this liaison statement is available at:
ftp://ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html 





Envelope-to: [e-mail]
Delivery-date: Sun, 02 Mar 2008 11:49:18 +0000
Message-ID: <049001c87c5b$2025de80$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Liaison on ITU-T Work Plan
Date: Sun, 2 Mar 2008 11:46:32 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We have received a copy of the ITU-T's Optical Transport Networks and 
Technologies Standardization Work Plan for our review and comment.

The liaison reads:

"Thank you for your review and comments for "Optical Transport
Networks & Technologies Standardization Work Plan".  Attached is the
updated version from this SG15 meeting (Geneva, 11 - 22 February
2008).  This version reflects recent development of related standards
and your valuable input.  We appreciate your review of this version and
comments."

You can find a copy of the work plan at 
http://www.itu.int/ITU-T/studygroups/com15/otn/index.html

You can find all CCAMP correspondence at www.olddog.co.uk/ccamp.htm

Adrian 





Envelope-to: [e-mail]
Delivery-date: Sun, 02 Mar 2008 10:26:00 +0000
Message-ID: <044f01c87c4f$2d7852e0$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Incoming liaison from ITU-T
Date: Sun, 2 Mar 2008 10:19:17 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We have been copied on a liaison from the ITU-T Study Group 15 to the 
Routing Area Directors and the IAB.

The text of the liaison is:

"As the result of a break-out meeting to discuss existing and upcoming
ASON routing topics, it was agreed that the scope of this technology
crossed the domains of expertise of multiple IETF WGs but needs focused
attention.  Thus, we would like to request formation of an IETF
Exploratory Working Group, or other appropriate mechanism, to start
jointly addressing these topics."

As usual, all liaisons are tracked at http://www.olddog.co.uk/ccamp.htm

We will let you know more information as the ADs and IAB consider their 
response.

Cheers,
Adrian