Subject: Vacheron Constantin watch for a New Year Gift!

From: "Leola Costa" <[email-masked]>
Date: Tue, 30 Dec 2008 11:15:54 -0500

Dear Leola,

How about buying yourself a two Patek Phillipe watches the same day? It's not impossible, mostly when you can get them for a couple hundred bucks
http://www.clipcape.com/

With top notch customer service and super warranty, we stand behind our watches.
http://www.clipcape.com/

Our Patek Phillipe have Weights/feels and looks exactly same as original.

Sincerely,
Mr Costa

Delivery-date: Sat, 27 Dec 2008 11:22:06 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Liaison Received - ITU0T SG15 OTNT Standardization Work Plan
Date: Sat, 27 Dec 2008 11:21:10 -0000

Hi,

We have previously sent comments to the ITU-T on their work plan for Optical 
Transport Networks and Technologies. Our most recent comments can be seen at 
https://datatracker.ietf.org/liaison/469/

The ITU-T have updated their plan and are sharing it with us through this 
liaison. We are invited to comment.

If you look through the document you will find a number of references to 
CCAMP drafts and RFCs. Some of these references are out of date, and Deborah 
and I will need to send them an update. I have also looked to see whether 
our suggestion (made in our liaison) to add asymmetric switches such as 
ROADMs to their plan has been included - I can't find any reference.

As usual, the liaison and attachment (the work plan itself) can be found at 
www.olddog.co.uk/ccamp.htm

Adrian
----- Original Message ----- 
From: "Greg Jones (ITU-T SG 15)" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, December 25, 2008 7:13 PM
Subject: New Liaison Statement, "LS29 - SG15 OTNT Standardization Work Plan"

>
> Title: LS29 - SG15 OTNT Standardization Work Plan
> Submission Date: 2008-12-25
> URL of the IETF Web page: 
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=490
> Please reply by 2009-08-31
>
> From: Greg Jones(ITU-T SG 15) <[email-masked]>
> To: IETF CCAMP, PCE and MPLS 
> WGs([email-masked],[email-masked],[email-masked],[email-masked],[email-masked])
> Cc: [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> Reponse Contact: [email-masked]
> [email-masked]
> Technical Contact: [email-masked]
> Purpose: For comment
> Body: 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, 1 � 12 December 2008). 
> This version reflects recent development of related standards and your 
> valuable input.  We appreciate your review of this version and comments.
>
>
> Attachment: OTNT Standardization Work Plan (TD62(PLEN))
> Attachment(s):
>     LS29 - SG15 OTNT Standardization Work Plan - body text 
> (https://datatracker.ietf.org/documents/LIAISON/file593.pdf)
>     LS29 - SG15 OTNT Standardization Work Plan - liaison attachment 
> (https://datatracker.ietf.org/documents/LIAISON/file594.pdf)
>
>
>
> 

Delivery-date: Sat, 27 Dec 2008 11:11:06 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Liaison Statement Received - MPLS-TP Signalling Communication Channel
Date: Sat, 27 Dec 2008 11:10:30 -0000

Hi,

We have been copied on a liaison to the MPLS working group from ITU-T Study 
Group 15 Question 14. CCAMP is copied for Information and is not required to 
do anything. The MPLS working group is required to respond by 18 May 2009.

You can find this liaison at www.olddog.co.uk/ccamp.htm

Adrian
===

Title: LS28 - Generic Associated Channel (G-ACH) Requirement to Provide a 
Signalling Communication Channel (SCC) and a Management Communication 
Channel (MCC) for MPLS-TP
Submission Date: 2008-12-25
URL of the IETF Web page: 
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=491
Please reply by 2009-05-18

From: Greg Jones(ITU-T SG 15) <[email-masked]>
To: IETF MPLS WG Co Chairs (Info: CCAMP WG Co Chairs, MEAD 
team)[email-masked], [email-masked], [email-masked], [email-masked], 
[email-masked]
Cc: [email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked]
Reponse Contact: [email-masked], [email-masked]
Technical Contact: [email-masked]
Purpose: For action
Body:

Q14/15 would like to inform the IETF MPLS WG that it has added the following 
new study point to the Living List for ITU-T Recommendation G.7712 
(Architecture and specification of data communication network):

Build upon the development of the new MPLS Generic Associated Channel 
(G-ACH) at the IETF and amend
G.7712 to align MCN and SCN aspects for MPLS-TP packet transport technology 
with the outcome of the IETF work on MPLS-TP.

In section 3.4.1 of the Internet Draft draft-ietf-mpls-tp-framework-00.txt 
it is already stated that the G-ACH will provide a signalling communication 
channel (SCC) and a management communication channel (MCC) for MPLS-TP.

The G-ACH as defined in draft-ietf-mpls-tp-gach-gal-00.txt is capable to 
distinguish OAM, APS, SCC, and MCC packets from each other. Moreover, it is 
also necessary for the SCC and MCC to distinguish between different layer 3 
PDUs such as IPv4, IPv6, and OSI CLNP PDUs as it is the case for other 
technologies supporting the data communication network. Examples can be 
found in ITU-T Recommendation G.7712.

Q14/15 is looking forward to the progression of MPLS-TP SCC and MCC work in 
the IETF, and is aware that contributions are being prepared in the form of 
an Internet-Draft. Q14/15 looks forward to being able to add to G.7712 
accordingly as soon as the MPLS-TP SCC and MCC definitions are stable. 

Delivery-date: Sat, 27 Dec 2008 11:03:59 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Liaison received from ITU-T SG15 Q6 - Lambda Switch Capable Equipment
Date: Sat, 27 Dec 2008 11:01:22 -0000

Hi,

We have received the following liaison statement from Question 6 of Study 
Group 15 of the ITU-T.
The liaison is for Information and so does not require any response from us, 
but if anyone has questions we can reply.

Please note that Question 6 is inviting us to meet with them to discuss 
optical parameters at a joint meeting in March 2009. The current provisional 
plan is to hold the Q6 meeting on the West Coast in the week before the IETF 
(i.e., 16-20 March) inviting the CCAMP people to attend on the Thursday. 
Note that this is still at an early stage of planning - we will update you 
as firmer plans are made.

At this stage, we understand that space may be limited and we will need to 
restrict CCAMP attendance to only those heavily involved in optical 
impairments work, and perhaps to only one or two people per company. In 
order to make this go more smoothly, please email Deborah and me if you are 
considering attending.

You may also want to look closely at Q6's proposed encoding of wavelength 
I-Ds in the Annexe to the Liaison to see how it differs from the CCAMP 
proposal and whether there is any scope for convergence.

As usual, you can get to all communications to and from CCAMP via 
www.olddog.co.uk/ccamp.htm

Adrian

===

Title: LS19 - Lambda Switch Capable Equipment
Submission Date: 2008-12-25
URL of the IETF Web page: 
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=495

From: Greg Jones(ITU-T SG 15) <[email-masked]>
To: IETF CCAMP WG([email-masked],[email-masked])
Cc: [email-masked], [email-masked], [email-masked],
   [email-masked], [email-masked]
Reponse Contact: [email-masked], [email-masked]
Technical Contact: [email-masked]
Purpose: For information
 Body:

Q.6/15 would like to thank IETF’s CCAMP Working Group for having provided a 
communication on Lambda Switch Capable Equipment to Q.6/15 last summer.

Q.6/15 would like to inform the IETF that Q.6/15 has agreed to add an 
encoding scheme for optical parameter values to a future revision of ITU-T 
Recommendation G.697. Q.6/15 intends to consent a revision of Recommendation 
G.697 during the SG15 Plenary Meeting, 28 September – 9 October 2009. An 
interim meeting of Q.6/15 is expected to be held in the March 2009 timeframe 
with the intent to progress the work on the revision of Recommendation 
G.697, in addition to many other topics currently under discussion within 
Q.6/15.

Furthermore Q.6/15 would like to draw the attention of IETF’s CCAMP Working 
Group on Lambda Switch Capable Equipment to ITU-T Recommendation G.680, 
entitled “Physical transfer functions of optical network elements”. The 
summary from the in-force version of this Recommendation is included below:

   ITU-T Recommendation G.680 defines a "degradation function" of optical
   network elements (ONEs) such as photonic cross-connects (PXCs),
   optical add-drop multiplexers (OADMs), etc. making up an optical
   network. This is done in terms of a list of parameters which characterize
   physical impairments such as optical noise, chromatic dispersion, etc., 
and
   is intended to be independent from the network architecture that the
   devices are deployed in. For each kind of ONE considered in this
   Recommendation, the general functional description and the reference
   diagram is provided. Principles for calculating the effect of cascading 
multiple
   ONEs on the degradation of the optical signal quality are given and 
example
   transfer parameter values for OADMs and PXCs are also provided.

   This version of the Recommendation covers the situation where the optical
   path between two consecutive electrical regenerators is composed of dense
   wavelength division multiplexing (DWDM) line segments from a single
   vendor and OADMs and PXCs from other vendors.

Also, included in the scope section of G.680 is:

   A future revision of the Recommendation is expected to cover the 
reference
   situation:

   Situation 2 – The optical path between two consecutive 3R regenerators is
   composed of DWDM line segments from different vendors and OADMs and
   PXCs from different vendors as shown in Figure 1-2.

   This will enable the degradation of the signal quality due to the optical 
path for
   an arbitrary route through an all-optical network (or sub-network) 
consisting of
   optical network elements including DWDM line segments to be assessed
   thereby enabling routing decisions in an all-optical network (or 
sub-network) to
   be made.

Q.6/15 would like to invite IETF’s CCAMP Working Group on Lambda Switch 
Capable Equipment to consider a joint meeting with Q.6/15 during the March 
2009 timeframe, in conjunction with its interim meeting, with the intent to 
share each others work related to monitoring of optical parameters in 
optical transmission equipment and other topics that are of common interest 
in this area.

A provision outline of what Q.6/15 intends to incorporate into revised 
Recommendation G.697 with respect to the encoding scheme for optical 
parameters is indicated in Annex 1 to this Liaison Statement.

- - - - - - - - -

Annex 1

Encoding of monitoring parameters

[Text should be added to underline that this is only an encoding definition 
and it doesn’t imply that the measurements must be made or what the 
parameters listed are used for]

Wavelength ID (32 bits):

This field contains the Wavelength label and is composed of 5 sub-fields:

Grid (3 bits): The value for grid is set to 1 for the ITU-T DWDM Grid as 
defined in G.694.1, set to 2 for the ITU-T CWDM Grid as defined in G.694.2 
and the values 3 to 7 are for future use.

Channel Spacing (4 bits):
  DWDM channel spacing
    Channel spacing (GHz)    Value
    12.5                     1
    25                       2
    50                       3
    100                      4
    Future use               0, 5 to 15

  CWDM channel spacing
    Channel spacing (nm)     Value
    20                       1
    Future use               0, 2 to 15

S (1 bit): Sign for the value n, set to 1 for (-) and 0 for (+)

n (16 bits): The value used to compute the frequency as shown below:

When the grid is “1”, Frequency (THz) = 193.1 + n * channel spacing (THz)
When the grid is “2”, Wavelength (nm) = 1470 + n * channel spacing (nm)

(8 bits): for future use.

Parameter ID source (x bits):
This field defines the source of the parameter ID lookup table. The value 1 
is G.697

Parameter ID (8 bits): When the parameter ID source is equal to 1, the 
following lookup table applies:

  Value  Parameter      Unit
  1      Total power    dBm
  2      Channel power  dBm
  3      etc.
  4
  5
  etc.

[Others values and parameters to be added]

Value of parameters (32 bits):
[How to encode the parameter values into the 32 bit number, to be inserted 
here, one proposal is:
Monitoring parameter value (IEEE 754 standard). The  IEEE 754 mantissa, an 
integer with values from 2^n_mant to 2*2^n_mant-1, where n_mant is the 
number of bits available for the mantissa, is termed a normalized number and 
allows for integer embedding suitable for all the sensor ranges involved in 
G.697 parameters. This embedding is error prone only for very small 
numbers. ] 

Delivery-date: Fri, 26 Dec 2008 18:35:17 +0000
Content-class: urn:content-classes:message
Subject: RE: IETF CCAMP Respons to OIF on Inter-Level Routing
Date: Fri, 26 Dec 2008 13:33:02 -0500
From: "Ong, Lyndon" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Lucille Goldiner" <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>

Dear Adrian and Deborah,

Thank you for the series of liaison responses, OIF will review them in
our 1Q09 meeting in January.  As always, we appreciate CCAMP's time and
attention.

Wishing everyone Happy Holidays and a productive New Year!

Best regards,

Lyndon Ong
OIF Technical Committee Chair

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]=20
Sent: Monday, December 22, 2008 1:59 PM
To: Ong, Lyndon; Lucille Goldiner
Cc: Brungard, Deborah A, ALABS; [email-masked]
Subject: IETF CCAMP Respons to OIF on Inter-Level Routing

Dear Lyndon,

 Here is a final response to the issues raised by the OIF. This one
relates=20
to ASON routing and multi-layer networks, and comes from your
communication=20
oif2008.063.02.pdf.

> in our discussions of multilayer networks and impacts on the control=20
> plane, we took note of ITU-T Recommendation
> G.7715.1 requirements to advertise:
> a) Local Connection Type; and
> b) Local Client Adaptations Supported.
> We believe that this functionality would be very useful for
> applications that have been discussed in OIF (see
> attachment). We would appreciate further clarification as to
> whether both requirements have been addressed in the current
> CCAMP work on ASON routing support (local connection type in
> particular is not explicitly identified in the current draft). We
would=20
> also appreciate more information on the
> relationship between support of adaptation in the ASON routing draft
and=20
> in the multilayer/multiregion networking
> drafts also being developed in the CCAMP WG.

 We note that G.7715.1 discusses the operation of multi-layer networks
in an=20
appendix and observes:

   This appendix provides illustrative examples of different
   methods of carrying multiple layer information between two
   systems. It does not mandate a particular method of
   implementation for link state routing protocols.

   From the perspective of ITU-T Rec. G.8080/Y.1304, each layer
   network has its own instance of a control plane.

 It can also be observed that a single routing level cannot span
multiple=20
network layers within the ASON architecture.

 draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt addresses the
distribution=20
of routing information between Routing Areas (in the ASON sense), but is

agnostic to the routing information passed. For more details of the
exchange=20
of "local connection type" and "local client adaptations" we need to
look=20
into the base GMPLS routing specifications and the CCAMP work on
multi-layer=20
networks.

As pointed out in RFC 4652, the Switching Capability field of the
Interface=20
Switching Capability Descriptor (see RFC 4202) describes the
capabilities of=20
the receiver with regard to any specific TE link (e.g., PSC, TDM, etc.).

Your question also opens up the issue of distinguishing between what
signal=20
types an LSR can terminate (through adaptation) as distinct from switch=20
(onto another TE link). This function is addressed in another CCAMP
draft,=20
draft-ietf-ccamp-gmpls-mln-extensions-03.txt, which will go to CCAMP
working=20
group last call soon. This draft introduces the Interface Adaptation=20
Capability Descriptor (IACD) to carry the necessary information.

Both the ISCD and the IACD can be exchanged between routing levels using
the=20
techniques described in draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt.
You=20
may, however, also like to look at the appropriateness of the PCE=20
architecture (RFC 4655) in the role of inter-level routing as it seems
to=20
fit well with the architecture as described by the ITU-T in G.7715.2.

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

Delivery-date: Tue, 23 Dec 2008 14:46:48 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt 
Date: Tue, 23 Dec 2008 06:45:01 -0800 (PST)

--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 RSVP-TE Extensions for Ethernet OAM Configuration
	Author(s)       : A. Takacs, et al.
	Filename        : draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt
	Pages           : 19
	Date            : 2008-12-23

The GMPLS controlled Ethernet Label Switching (GELS) work is
extending GMPLS RSVP-TE to support the establishment of Ethernet
LSPs.  IEEE Ethernet Connectivity Fault Management (CFM) specifies an
adjunct OAM flow to check connectivity in Ethernet networks.  CFM can
be also used with Ethernet LSPs for fault detection and triggering
recovery mechanisms.  The ITU-T Y.1731 specification builds on CFM
and specifies additional OAM mechanisms, including Performance
Monitoring, for Ethernet networks.  This document specifies
extensions of GMPLS RSVP-TE to support the setup of the associated
Ethernet OAM (CFM and Y.1731) entities adding a technology specific
TLV to [OAM-CONF-FWK].Changes from previous version

Technology independent extensions were moved to a separate framework
document leaving only the Ethernet specific extensions in this
document.Requirements Language

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

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

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

--NextPart--

Delivery-date: Tue, 23 Dec 2008 14:46:37 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-oam-configuration-fwk-00.txt 
Date: Tue, 23 Dec 2008 06:45:01 -0800 (PST)

--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           : OAM Configuration Framework and Requirements for GMPLS RSVP-TE
	Author(s)       : A. Takacs, et al.
	Filename        : draft-ietf-ccamp-oam-configuration-fwk-00.txt
	Pages           : 19
	Date            : 2008-12-23

OAM functions are essential to ensure that the desired service level
of traffic engineered connections are met.  In certain technologies
OAM entities are inherently established once the connection is set
up.  However other technologies, especially OAM for packet switched
networks, require an extra configuration step after connection
establishment to setup OAM entities.  This document specifies
extensions to RSVP-TE to support the establishment and configuration
of OAM entities along with LSP signalling.Requirements Language

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

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

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

--NextPart--

Delivery-date: Tue, 23 Dec 2008 11:31:05 +0000
From: Yechiel Rosengarten <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Tue, 23 Dec 2008 13:28:46 +0200
Subject: RE: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt 
Accept-Language: en-US
acceptlanguage: en-US

Hi
I would like to get some clarification:
By the end of procedure for scenario 1 its written:

   							.....	Note that if Node C=20
   restarts after this operation, the RecoveryPath message that it=20
   sends to Node B will not be matched with any state on Node B and=20
   will receive a PathTear as its response resulting in the teardown=20
   of the LSP at all downstream nodes.

How comes that node C, which is now the restarting node, sends RecoveryPath=
 that should be sent by downstream normal node and not by restarting node?

Same question for the other scenarios that mention similar behavior.

Best Regards,

Yechiel Rosengarten
System Engineering
ECI Telecom Ltd
30 Hasivim St. Petach Tikva 49517 Israel
Tel:  +972 3 926 8794
Fax: +972 3 926 6200
e-mail: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf =
Of [email-masked]
Sent: Monday, May 19, 2008 7:30 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt=20

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 Worki=
ng Group of the IETF.

        Title           : Description of the RSVP-TE Graceful Restart Proce=
dures
        Author(s)       : D. Li
        Filename        : draft-ietf-ccamp-gr-description-03.txt
        Pages           : 19
        Date            : 2008-5-19

The Hello message for the Resource Reservation Protocol (RSVP) has
   been defined to establish and maintain basic signaling node
   adjacencies for Label Switching Routers (LSRs) participating in a
   Multiprotocol Label Switching (MPLS) traffic engineered (TE)
   network. The Hello message has been extended for use in Generalized
   MPLS (GMPLS) network for state recovery of control channel or nodal
   faults.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-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.

Delivery-date: Mon, 22 Dec 2008 22:02:42 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lyndon Ong" <[email-masked]>, "Lucille Goldiner" <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>
Subject: IETF CCAMP Respons to OIF on Inter-Level Routing
Date: Mon, 22 Dec 2008 21:59:24 -0000

Dear Lyndon,

 Here is a final response to the issues raised by the OIF. This one relates 
to ASON routing and multi-layer networks, and comes from your communication 
oif2008.063.02.pdf.

> in our discussions of multilayer networks and impacts on the control 
> plane, we took note of ITU-T Recommendation
> G.7715.1 requirements to advertise:
> a) Local Connection Type; and
> b) Local Client Adaptations Supported.
> We believe that this functionality would be very useful for
> applications that have been discussed in OIF (see
> attachment). We would appreciate further clarification as to
> whether both requirements have been addressed in the current
> CCAMP work on ASON routing support (local connection type in
> particular is not explicitly identified in the current draft). We would 
> also appreciate more information on the
> relationship between support of adaptation in the ASON routing draft and 
> in the multilayer/multiregion networking
> drafts also being developed in the CCAMP WG.

 We note that G.7715.1 discusses the operation of multi-layer networks in an 
appendix and observes:

   This appendix provides illustrative examples of different
   methods of carrying multiple layer information between two
   systems. It does not mandate a particular method of
   implementation for link state routing protocols.

   From the perspective of ITU-T Rec. G.8080/Y.1304, each layer
   network has its own instance of a control plane.

 It can also be observed that a single routing level cannot span multiple 
network layers within the ASON architecture.

 draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt addresses the distribution 
of routing information between Routing Areas (in the ASON sense), but is 
agnostic to the routing information passed. For more details of the exchange 
of "local connection type" and "local client adaptations" we need to look 
into the base GMPLS routing specifications and the CCAMP work on multi-layer 
networks.

As pointed out in RFC 4652, the Switching Capability field of the Interface 
Switching Capability Descriptor (see RFC 4202) describes the capabilities of 
the receiver with regard to any specific TE link (e.g., PSC, TDM, etc.).

Your question also opens up the issue of distinguishing between what signal 
types an LSR can terminate (through adaptation) as distinct from switch 
(onto another TE link). This function is addressed in another CCAMP draft, 
draft-ietf-ccamp-gmpls-mln-extensions-03.txt, which will go to CCAMP working 
group last call soon. This draft introduces the Interface Adaptation 
Capability Descriptor (IACD) to carry the necessary information.

Both the ISCD and the IACD can be exchanged between routing levels using the 
techniques described in draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt. You 
may, however, also like to look at the appropriateness of the PCE 
architecture (RFC 4655) in the role of inter-level routing as it seems to 
fit well with the architecture as described by the ITU-T in G.7715.2.

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

Delivery-date: Mon, 22 Dec 2008 22:02:35 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lyndon Ong" <[email-masked]>, "Lucille Goldiner" <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>
Subject: IETF CCAMP Response to OIF on Resv Usage
Date: Mon, 22 Dec 2008 21:49:36 -0000

Dear Lyndon,

CCAMP owes the OIF responses to several communications. Apologies for the 
delay in producing formal responses. The issues raised were discussed at 
some length during the months after we received the communication both on 
and off the CCAMP mailing list, and I know you were involved in some of 
those discussions, but we forgot to send the formal responses.

We will generate a series of responses with the technical issues broken out 
into separate threads. This first one addresses the issue of Resv usage 
during make-before-break as raised in oif2008.063.02.pdf.

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

---

> OIF thanks CCAMP for its prompt and very informative response
> to our liaison on OIF interoperability demo findings, sent
> from our 4Q2007 meeting. We appreciate CCAMP's offer to use
> the CCAMP mailing list for questions during our demo planning
> and testing, although more structured liaisons are still
> useful in our view to reflect meeting results and issues or
> comments that are agreed across OIF members (as opposed to
> individual views).

 [SNIP]

> Based on your response liaison, it is our understanding that
> per-LSP RESV messages should be expected for the "make-
> before-break" scenario of modification. However, some members
> have commented that it appears to be possible in the
> specifications to use a single RESV message for multiple LSPs
> because:
> a) RFC 2205 allows the RESV message to carry multiple
>    FILTER_SPEC objects, specifically with the Shared Explicit
>    (SE) style that supports reservation sharing; and
> b) The FILTER_SPEC object was extended in RFC 3209 to carry
>    the LSP_ID.
>
> Clarification would be appreciated as to whether we should
> allow for receiving a single RESV message with multiple
> FILTER_SPEC objects in the "make-before-break" scenario using
> the SE style.

 We believe this issue is substantially the same as the following issue 
raised in the OIF correspondence dated November 29, 2007 with the subject 
"Liaison to IETF Regarding 2007 Interop Test Findings". Here you wrote:

>> - How many RESV messages are expected to be generated? Is it
>>   one since the resources in use by both LSPs are the same,
>>   or two since the LSPs are handled through separate
>>   signaling sessions.

 In our response, dated January 3, 2008, we stated:

>>   In make-before-break, each LSP is signaled independently.
>>   Per LSP Resv messages should be expected.  Assuming the
>>   old LSP is in-place at the time of signaling the new LSP,
>>   and only one Path message is issued, then only one Resv
>>   would be expected. That is, a Resv for the new LSP, but no
>>   further Resv for the existing LSP.
>>
>>   When the old LSP is also modified as part of the make-
>>   before-break, e.g., to update administrative status prior
>>   to alarm-free tear-down, then a Resv message on the old
>>   LSP may also be generated.

 To help clarify this point, we draw your attention to RFC 3209 which 
states:

     The SESSION object uniquely defines a traffic engineered
     tunnel. The SENDER_TEMPLATE and FILTER_SPEC objects carry
     an LSP ID. The SENDER_TEMPLATE (or FILTER_SPEC) object
     together with the SESSION object uniquely identifies an
     LSP tunnel.

 As LSP tunnels (or LSPs for short) are identified using different LSP IDs 
(as carried in SENDER_TEMPLATE and FILTER_SPEC objects) and each LSP is 
signaled independently, multiple FILTER_SPEC objects SHOULD NOT be allowed 
as part of make-before-break. 

Delivery-date: Mon, 22 Dec 2008 22:02:26 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lyndon Ong" <[email-masked]>, "Lucille Goldiner" <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>
Subject: IETF CCAMP Response to OIF on VCAT
Date: Mon, 22 Dec 2008 21:57:07 -0000

Dear Lyndon,

In your communication oif2007.377.02.pdf you made several comments about our 
VCAT/LCAS work, but did not specifically request any response.

In communication oif2008.063.02.pdf you said:

> We would also appreciate any feedback that you might have on
> our liaison from the 4Q2007 meeting on VCAT/LCAS requirements,
> especially whether these were incorporated into your work on VCAT/LCAS 
> support.

 This response addresses the points you made in the earlier communication. 
You wrote:

> We have been monitoring with great interest the work on
> VCAT/LCAS support in the IETF CCAMP WG, as we have done
> prototyping work on control of VCAT/LCAS for interoperability
> events in 2005 and 2007. As a result of our internal
> discussion and prototyping work, we have identified a number
> of requirements on VCAT/LCAS support that we believe are
> important and may be helpful input to your work.
>
> In general, we agree with the requirements already identified
> in draft-ietf-ccamp-gmpls-vcat-lcas-03.txt.

 Please note that this draft is now at the 07 revision and may be found as 
draft-ietf-ccamp-gmpls-vcat-lcas-07.txt

> The following have been identified as important functionality
> for control plane support for VCAT/LCAS that is not currently
> identified in the CCAMP draft:
>
> - Ability to identify link endpoint capabilities associated with VCAT such 
> as support of LCAS functionality
>   - Possible additional requirement on ASON routing support to be taken 
> into account in CCAMP work on ASON routing
>     extensions rather than the VCAT/LCAS draft itself
>   - This might be generalizable to advertising inverse multiplexing 
> capabilities in addition to VCAT/LCAS

 CCAMP did consider extensions to IGPs to distribute inverse multiplexing, 
VCAT, and LCAS capabilities. This information would allow the initiator of a 
VCG to understand the capabilities of the egress that it is attempting to 
connect to.

However, we decided that the LSP will not be set up to a different 
destination based on the VCAT capabilities. The LSP is required between a 
pair of LSRs, and there is no benefit to routing in distributing the 
end-point capabilities. Thus, we decided that if any negotiation is needed, 
it should be performed on the Call.

> - Clean separation of VCG (VCAT Group) control from the
>   control of VCG members
>   - Supports the ability to create and modify the VCG independent of its 
> members

 We believe that this is exactly what our draft does.

>   - Supports potentially different sequences of creation, e.g., creation 
> of members first followed by VCG creation
>     or creation of VCG first followed by its members

 We believe that the ITU Recommendations that define VCAT do not support 
this behavior. We are also not convinced that this would be a valid way of 
operating a network - trails are not created on the off-chance that they 
will be used as part of a VCG at some time in the future.

>   - A single separate signaling session associated with the
>     VCG is an approach that has been prototyped successfully
>     in OIF interop events and may be a possible approach.

 While the use of a separate signaling session to establish the VCG is a 
fine way to conduct an experiment to establish data plane interoperability, 
this is not a good architectural solution for RSVP-TE. The signaling 
exchange of an RSVP-TE Path and Resv message is intended to establish an 
LSP. The coordination between end points for VCAT is far closer to the 
processes necessary for a Call, and that is why we have used the RSVP-TE 
Notify message exchange in our draft.

>   - We believe the current approach in the CCAMP draft has
>     limitations in this respect due to the incorporation of multiple VCGs 
> within a single call, as this does not cleanly separate the VCG state and 
> the state of its component members. We suggest that CCAMP consider using a
>     single call per VCG instead, based on our prototyping
>     experiences.

 This may reflect some misunderstanding of the CCAMP draft. The draft 
currently allows a one-to-one correlation between Call and VCG. Component 
members are, of course, associated with the VCG and so the state of the 
component members is directly associated with the state of the VCG itself.

>   - Separation of VCG and member sessions will allow unambiguous semantics 
> for VCG characteristics vs. member
>     characteristics such as support of recovery modes

 Again, this may represent some misunderstanding of the CCAMP draft. The 
draft allows each LSP (VCG member) to be maintained with distinct 
characteristics.

> - Ability to identify VCG members within VCG-related signaling
>   - Note that it may be common in ASON environments for a VCG
>     connection to span multiple domains and RSVP sessions in series, in 
> which case session-specific objects such as
>     the LSP ID and Tunnel ID are not guaranteed to have
>     unique values end-to-end
>   - Manipulation of VCG characteristics requires the ability to clearly 
> and unambiguously identify the VCG members at each end of the VCG

 We note that "session shuffling" is peculiar to the OIF way of addressing 
the ASON architecture, and the CCAMP working group has previously expressed 
its view that such a way of building a network, while functional, is not 
advisable.

Since the OIF presumably has a solution to the fact that any one connection 
must be unambiguously identifiable at each end of the connection, we do not 
consider that the problem is exacerbated by the construction of a VCG.

Indeed, session shuffling can only work if there is a consistent, coherent, 
repeatable, and reversible mapping of the various parameters (such as 
addresses, Tunnel ID, and LSP ID) at domain boundaries.

> - Ability to maintain VCG state across control plane failures
>   - It is important to be able to maintain the VCG in the
>     event of temporary loss of control plane connectivity or control plane 
> state
>   - We believe that graceful restart-like capabilities in RSVP need to be 
> supported to maintain VCG state across control plane failure.

 You are correct that the control plane state must be recoverable after 
control plane component restart, and must be resynchronized after control 
plane connectivity recovery. Further, the data plane state must not be 
perturbed by control plane failure or restart.

Graceful restart is a standard part of GMPLS RSVP-TE. It can be found in RFC 
5063. A more detailed description (including a discussion of the handling of 
multiple failures) can be found in draft-ietf-ccamp-gr-description-03.txt 
which is currently being reviewed by the IESG prior to publication as an 
RFC.

Restart processing for GMPLS Calls is covered in RFC 4974.

The VCAT work simply re-uses these mechanisms and no further description is 
required.

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

Delivery-date: Mon, 22 Dec 2008 22:02:19 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lyndon Ong" <[email-masked]>, "Lucille Goldiner" <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>
Subject: IETF CCAMP Response to OIF on MEF-Related Work
Date: Mon, 22 Dec 2008 21:51:25 -0000

Dear Lyndon,

In your communication oif2008.063.02.pdf dated February 14, 2008 you noted:

> Finally, we noted the discussion on the CCAMP mailing list
> regarding the computation of the Length field for TLVs, especially for the 
> Ethernet Bandwidth Profile TLV used in
> the Ethernet Traffic Parameters draft. As this draft is considered to be 
> very important for support of MEF defined
> Ethernet services, we request that this issue be resolved
> as soon as possible within CCAMP.
> Our preference would be to compute the Length field for all
> TLVs (except those in RFC 4420) based on the full TLV rather
> than the Value alone, as this is the method commonly used in
> the past for length computation in RSVP.

 Please note that RFC 4420 has been revised as 
draft-ietf-ccamp-rfc4420-bis-03.txt. This draft is in the RFC Editor's 
queue, and will shortly be published as an RFC that obsoletes RFC 4420. The 
change is to make the processing of all RSVP-TE TLVs consistent so that the 
Length field accounts for the full length of the TLV.

This change has also been incorporated into the work on traffic parameters 
for Ethernet as described in 
draft-ietf-ccamp-ethernet-traffic-parameters-06.txt.

You will be pleased to hear that we consider our work on MEF-related 
protocol extensions to be stable, and we will shortly issue working group 
last calls on the following drafts:

 draft-ietf-ccamp-ethernet-traffic-parameters-06.txt
draft-ietf-ccamp-gmpls-ether-svcs-02.txt
draft-ietf-ccamp-gmpls-mef-uni-01.txt
draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt

In view of the imminent last call on this work, we would welcome any input 
from OIF members. Input should be made either by official communication from 
the OIF, or by email from any individual to the CCAMP mailing list 
(subscription details are found at 
http://www.ietf.org/html.charters/ccamp-charter.html).

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

Delivery-date: Thu, 18 Dec 2008 17:15:36 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-vcat-lcas-07.txt 
Date: Thu, 18 Dec 2008 09:15:01 -0800 (PST)

--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-gmpls-vcat-lcas-07.txt
	Author(s)       : G. Bernstein, et al.
	Filename        : draft-ietf-ccamp-gmpls-vcat-lcas-07.txt
	Pages           : 21
	Date            : 2008-12-18

This document describes requirements for, and use of, the Generalized 
Multi-Protocol Label Switching (GMPLS) control plane in conjunction 
with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing 
mechanism and its companion Link Capacity Adjustment Scheme (LCAS) 
which can be used for hitless dynamic resizing of the inverse 
multiplex group.  These techniques apply to Optical Transport Network 
(OTN), Synchronous Optical Network (SONET), Synchronous Digital 
Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. 

Conventions used in this document 

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-07.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-vcat-lcas-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Thu, 18 Dec 2008 17:00:23 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-rwa-wson-encode-00.txt 
Date: Thu, 18 Dec 2008 09:00:01 -0800 (PST)

--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           : Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks
	Author(s)       : G. Bernstein
	Filename        : draft-ietf-ccamp-rwa-wson-encode-00.txt
	Pages           : 21
	Date            : 2008-12-18

A wavelength switched optical network (WSON) requires that certain 
key information elements are made available to facilitate path 
computation and the establishment of label switching paths (LSPs). 
The information model described in "Routing and Wavelength Assignment 
Information for Wavelength Switched Optical Networks" shows what 
information is required at specific points in the WSON. 

The information may be used in Generalized Multiprotocol Label 
Switching (GMPLS) signaling protocols, and may be distributed by 
GMSPL routing protocols. Other distribution mechanisms (for example, 
XML-based protocols) may also be used. 

This document provides efficient, protocol-agnostic encodings for the 
information elements necessary to operate a WSON. It is intended that 
protocol-specific documents will reference this memo to describe how 
information is carried for specific uses. 

Conventions used in this document 

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

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

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

--NextPart--

Delivery-date: Thu, 18 Dec 2008 16:53:46 +0000
Date: Thu, 18 Dec 2008 10:52:21 -0600
From: Young Lee <[email-masked]>
Subject: RE: draft-bernstein-ccamp-wson-encode accepted as WG I-D
To: 'Adrian Farrel' <[email-masked]>, [email-masked]
Cc: 'Greg Bernstein' <[email-masked]>

We will submit the update with the clear scope spelled out. Thanks.

Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: Thursday, December 18, 2008 4:18 AM
To: [email-masked]
Cc: Greg Bernstein
Subject: draft-bernstein-ccamp-wson-encode accepted as WG I-D

Hi,

draft-bernstein-ccamp-wson-encode-01.txt is accepted as a working group
draft.

Authors, please resubmit as draft-ietf-ccamp-rwa-wson-encode-00.txt to 
indicate
that the problem space you address is just the RWA portion of WSON.

Thanks,
Adrian

Delivery-date: Thu, 18 Dec 2008 14:42:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Accepting OAM Configuration I-Ds
Date: Thu, 18 Dec 2008 15:40:36 +0100
From: "Attila Takacs" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi Adrian,

> We see reasonable consensus for adoption, but are aware that=20
> several people expressed a concern that this work would=20
> deprecate LSP Ping as a bootstrap mechanism for OAM in=20
> certain environments.
>=20
> We believe that it is not the authors' intention to deprecate=20
> the use of LSP Ping in this way, and that it would not be=20
> wise to make such a change.
>=20

Agreed.

> Therefore, we accept these two I-Ds as working group drafts,=20
> but request the authors to add to=20
> draft-takacs-ccamp-oam-configuration-fwk-01.txt to say:
>=20
> The mechansim described in this document provides an=20
> additional option for bootstrapping OAM that is not intended=20
> to replace or deprecate the use of other OAM bootstrapping=20
> techniques such as LSP Ping [RFC4379]. The procedures=20
> specified in this document are intended only for use in=20
> environments where RSVP-TE signaling is already in use to set=20
> up the LSPs that are to be monitored using OAM.
>=20

Will add the note and resubmit.

Thanks and best regards,
Attila

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Thursday, December 18, 2008 11:32 AM
> To: [email-masked]
> Subject: Accepting OAM Configuration I-Ds
>=20
> Hi,
>=20
> Deborah and I have listened to the discussion about accepting=20
> the two OAM configuration I-Ds=20
> (draft-takacs-ccamp-oam-configuration-fwk-01.txt and
> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt) as working=20
> group drafts.
>=20
> We see reasonable consensus for adoption, but are aware that=20
> several people expressed a concern that this work would=20
> deprecate LSP Ping as a bootstrap mechanism for OAM in=20
> certain environments.
>=20
> We believe that it is not the authors' intention to deprecate=20
> the use of LSP Ping in this way, and that it would not be=20
> wise to make such a change.
>=20
> Therefore, we accept these two I-Ds as working group drafts,=20
> but request the authors to add to=20
> draft-takacs-ccamp-oam-configuration-fwk-01.txt to say:
>=20
> The mechansim described in this document provides an=20
> additional option for bootstrapping OAM that is not intended=20
> to replace or deprecate the use of other OAM bootstrapping=20
> techniques such as LSP Ping [RFC4379]. The procedures=20
> specified in this document are intended only for use in=20
> environments where RSVP-TE signaling is already in use to set=20
> up the LSPs that are to be monitored using OAM.
>=20
>=20
> We believe that this text goes some way to address the=20
> concerns raised and we note that the draft will be the=20
> property of the working group allowing additional changes to=20
> be made according to working group consensus.
>=20
>=20
> Authors, please make the textual change and submit
>=20
> draft-takacs-ccamp-oam-configuration-fwk-01.txt
> as
> draft-ietf-ccamp-oam-configuration-fwk-00.txt
>=20
> and
> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> as
> draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt
>=20
>=20
> Thanks,
> Adrian and Deborah=20
>=20
>=20
>=20

Delivery-date: Thu, 18 Dec 2008 10:32:41 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Accepting OAM Configuration I-Ds
Date: Thu, 18 Dec 2008 10:31:54 -0000

Hi,

Deborah and I have listened to the discussion about accepting the two OAM 
configuration I-Ds (draft-takacs-ccamp-oam-configuration-fwk-01.txt and 
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt) as working group drafts.

We see reasonable consensus for adoption, but are aware that several people 
expressed a concern that this work would deprecate LSP Ping as a bootstrap 
mechanism for OAM in certain environments.

We believe that it is not the authors' intention to deprecate the use of LSP 
Ping in this way, and that it would not be wise to make such a change.

Therefore, we accept these two I-Ds as working group drafts, but request the 
authors to add to draft-takacs-ccamp-oam-configuration-fwk-01.txt to say:

The mechansim described in this document provides an additional option for 
bootstrapping OAM that is not intended to replace or deprecate the use of 
other OAM bootstrapping techniques such as LSP Ping [RFC4379]. The 
procedures specified in this document are intended only for use in 
environments where RSVP-TE signaling is already in use to set up the LSPs 
that are to be monitored using OAM.

We believe that this text goes some way to address the concerns raised and 
we note that the draft will be the property of the working group allowing 
additional changes to be made according to working group consensus.

Authors, please make the textual change and submit

draft-takacs-ccamp-oam-configuration-fwk-01.txt
as
draft-ietf-ccamp-oam-configuration-fwk-00.txt

and
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
as
draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt

Thanks,
Adrian and Deborah 

Delivery-date: Thu, 18 Dec 2008 10:21:08 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Greg Bernstein" <[email-masked]>
Subject: draft-bernstein-ccamp-wson-encode accepted as WG I-D
Date: Thu, 18 Dec 2008 10:18:17 -0000

Hi,

draft-bernstein-ccamp-wson-encode-01.txt is accepted as a working group
draft.

Authors, please resubmit as draft-ietf-ccamp-rwa-wson-encode-00.txt to 
indicate
that the problem space you address is just the RWA portion of WSON.

Thanks,
Adrian

Delivery-date: Thu, 18 Dec 2008 00:12:46 +0000
Content-class: urn:content-classes:message
Subject: Working Group Last Call ends: draft-ietf-ccamp-path-key-ero-02.txt
Date: Wed, 17 Dec 2008 19:11:09 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

This ends the Last Call. There were no comments.

Thanks-
Deborah

_____________________________________________
From: BRUNGARD, DEBORAH A, ATTLABS=20
Sent: Thursday, November 20, 2008 7:36 PM
To: [email-masked]'
Subject: Working Group Last Call: draft-ietf-ccamp-path-key-ero-02.txt

This is to initiate a Working Group Last Call on:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-path-key-ero-02.txt

Please send your comments to the mailing list prior to EOB Dec 5.

Thanks,
Deborah and Adrian

Delivery-date: Wed, 17 Dec 2008 22:21:41 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Last of 4 drafts to OIF : inter-level routing
Date: Wed, 17 Dec 2008 22:19:13 -0000

Hi,

A fourth and final draft for you to review...

Thanks,
Adrian

===

Dear Lyndon,

Here is a final response to the issues raised by the OIF. This
one relates to ASON routing and multi-layer networks, and comes
from your communication oif2008.063.02.pdf.

> in our discussions of multilayer networks and impacts 
> on the control plane, we took note of ITU-T Recommendation
> G.7715.1 requirements to advertise:
> a) Local Connection Type; and
> b) Local Client Adaptations Supported.
> We believe that this functionality would be very useful for
> applications that have been discussed in OIF (see
> attachment). We would appreciate further clarification as to
> whether both requirements have been addressed in the current
> CCAMP work on ASON routing support (local connection type in
> particular is not explicitly identified in the current 
> draft). We would also appreciate more information on the
> relationship between support of adaptation in the ASON 
> routing draft and in the multilayer/multiregion networking
> drafts also being developed in the CCAMP WG.

We note that G.7715.1 discusses the operation of multi-layer
networks in an appendix and observes:

   This appendix provides illustrative examples of different 
   methods of carrying multiple layer information between two
   systems. It does not mandate a particular method of 
   implementation for link state routing protocols.

   From the perspective of ITU-T Rec. G.8080/Y.1304, each layer
   network has its own instance of a control plane.

It can also be observed that a single routing level cannot span
multiple network layers within the ASON architecture.

draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt addresses the 
distribution of routing information between Routing Areas (in 
the ASON sense), but is agnostic to the routing information
passed. For more details of the exchange of "local connection
type" and "local client adaptations" we need to look into the
base GMPLS routing specifications and the CCAMP work on multi-
layer networks.

As pointed out in RFC 4652, the Switching Capability field of 
the Interface Switching Capability Descriptor (see RFC 4202)
describes the capabilities of the receiver with regard to any
specific TE link (e.g., PSC, TDM, etc.).

Your question also opens up the issue of distinguishing 
between what signal types an LSR can terminate (through 
adaptation) as distinct from switch (onto another TE link).
This function is addressed in another CCAMP draft, 
draft-ietf-ccamp-gmpls-mln-extensions-03.txt, which will go to
CCAMP working group last call soon. This draft introduces the
Interface Adaptation Capability Descriptor (IACD) to carry the
necessary information.

Both the ISCD and the IACD can be exchanged between routing 
levels using the techniques described in draft-ietf-ccamp-
gmpls-ason-routing-ospf-06.txt. You may, however, also like to
look at the appropriateness of the PCE architecture (RFC 4655)
in the role of inter-level routing as it seems to fit well with
the architecture as described by the ITU-T in G.7715.2.

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

Delivery-date: Tue, 16 Dec 2008 17:29:56 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Furthre draft to OIF : VCAT
Date: Tue, 16 Dec 2008 17:28:12 -0000

Hi,

Review and comment please.

Thanks,
Adrian

====
Dear Lyndon,

In your communication oif2007.377.02.pdf you made several
comments about our VCAT/LCAS work, but did not specifically
request any response.

In communication oif2008.063.02.pdf you said:

> We would also appreciate any feedback that you might have on
> our liaison from the 4Q2007 meeting on VCAT/LCAS requirements,
> especially whether these were incorporated into your work on 
> VCAT/LCAS support.

This response addresses the points you made in the earlier
communication. You wrote:

> We have been monitoring with great interest the work on
> VCAT/LCAS support in the IETF CCAMP WG, as we have done
> prototyping work on control of VCAT/LCAS for interoperability
> events in 2005 and 2007. As a result of our internal
> discussion and prototyping work, we have identified a number
> of requirements on VCAT/LCAS support that we believe are
> important and may be helpful input to your work.
>
> In general, we agree with the requirements already identified
> in draft-ietf-ccamp-gmpls-vcat-lcas-03.txt.

Please note that this draft is now at the 06 revision and may 
be found as draft-ietf-ccamp-gmpls-vcat-lcas-06.txt

> The following have been identified as important functionality
> for control plane support for VCAT/LCAS that is not currently
> identified in the CCAMP draft:
>
> - Ability to identify link endpoint capabilities associated 
>   with VCAT such as support of LCAS functionality
>   - Possible additional requirement on ASON routing support 
>     to be taken into account in CCAMP work on ASON routing
>     extensions rather than the VCAT/LCAS draft itself
>   - This might be generalizable to advertising inverse 
>     multiplexing capabilities in addition to VCAT/LCAS

CCAMP did consider extensions to IGPs to distribute inverse
multiplexing, VCAT, and LCAS capabilities. This information
would allow the initiator of a VCG to understand the 
capabilities of the egress that it is attempting to connect to.

However, we decided that the LSP will not be set up to a 
different destination based on the VCAT capabilities. The LSP
is required between a pair of LSRs, and there is no benefit to
routing in distributing the end-point capabilities. Thus, we 
decided that if any negotiation is needed, it should be
performed on the Call.

> - Clean separation of VCG (VCAT Group) control from the
>   control of VCG members
>   - Supports the ability to create and modify the VCG 
>     independent of its members

We believe that this is exactly what our draft does.

>   - Supports potentially different sequences of creation, 
>     e.g., creation of members first followed by VCG creation
>     or creation of VCG first followed by its members

We believe that the ITU Recommendations that define VCAT do not
support this behavior. We are also not convinced that this
would be a valid way of operating a network - trails are not 
created on the off-chance that they will be used as part of a 
VCG at some time in the future.

>   - A single separate signaling session associated with the
>     VCG is an approach that has been prototyped successfully
>     in OIF interop events and may be a possible approach.

While the use of a separate signaling session to establish the
VCG is a fine way to conduct an experiment to establish data 
plane interoperability, this is not a good architectural 
solution for RSVP-TE. The signaling exchange of an RSVP-TE
Path and Resv message is intended to establish an LSP. The
coordination between end points for VCAT is far closer to the
processes necessary for a Call, and that is why we have used
the RSVP-TE Notify message exchange in our draft.

>   - We believe the current approach in the CCAMP draft has
>     limitations in this respect due to the incorporation of 
>     multiple VCGs within a single call, as this does not 
>     cleanly separate the VCG state and the state of its 
>     component members. We suggest that CCAMP consider using a
>     single call per VCG instead, based on our prototyping
>     experiences.

This may reflect some misunderstanding of the CCAMP draft. The
draft currently allows a one-to-one correlation between Call 
and VCG. Component members are, of course, associated with the
VCG and so the state of the component members is directly 
associated with the state of the VCG itself.

>   - Separation of VCG and member sessions will allow 
>     unambiguous semantics for VCG characteristics vs. member
>     characteristics such as support of recovery modes

Again, this may represent some misunderstanding of the CCAMP
draft. The draft allows each LSP (VCG member) to be maintained
with distinct characteristics.

> - Ability to identify VCG members within VCG-related 
>   signaling
>   - Note that it may be common in ASON environments for a VCG
>     connection to span multiple domains and RSVP sessions in 
>     series, in which case session-specific objects such as
>     the LSP ID and Tunnel ID are not guaranteed to have
>     unique values end-to-end
>   - Manipulation of VCG characteristics requires the ability 
>     to clearly and unambiguously identify the VCG members at 
>     each end of the VCG

We note that "session shuffling" is peculiar to the OIF way of
addressing the ASON architecture, and the CCAMP working group
has previously expressed its view that such a way of building a
network, while functional, is not advisable.

Since the OIF presumably has a solution to the fact that any 
one connection must be unambiguously identifiable at each end 
of the connection, we do not consider that the problem is
exacerbated by the construction of a VCG.

Indeed, session shuffling can only work if there is a
consistent, coherent, repeatable, and reversible mapping of the
various parameters (such as addresses, Tunnel ID, and LSP ID)
at domain boundaries.

That said, we believe that the ASON architecture is currently
struggling with issues of diverse routes of connections that
provide protection. It has normally been the case that 
protection is terminated at domain boundaries (at E-NNIs), and
this may also be the case for VCGs.

> - Ability to maintain VCG state across control plane failures
>   - It is important to be able to maintain the VCG in the
>     event of temporary loss of control plane connectivity or 
>     control plane state
>   - We believe that graceful restart-like capabilities in 
>     RSVP need to be supported to maintain VCG state across 
>     control plane failure.

You are correct that the control plane state must be 
recoverable after control plane component restart, and must be
resynchronized after control plane connectivity recovery.
Further, the data plane state must not be perturbed by control
plane failure or restart.

Graceful restart is a standard part of GMPLS RSVP-TE. It can be
found in RFC 5063. A more detailed description (including a
discussion of the handling of multiple failures) can be found 
in draft-ietf-ccamp-gr-description-03.txt which is currently
being reviewed by the IESG prior to publication as an RFC.

Restart processing for GMPLS Calls is covered in RFC 4974.

The VCAT work simply re-uses these mechanisms and no further
description is required.

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

Delivery-date: Mon, 15 Dec 2008 13:33:14 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Draft response to OIF on MEF-Related Work
Date: Mon, 15 Dec 2008 13:32:04 -0000

Hi,

Please also comment on this draft response to the OIF.

Thanks,
Adrian

===

Dear Lyndon,

In your communication oif2008.063.02.pdf dated February 14,
2008 you noted:

> Finally, we noted the discussion on the CCAMP mailing list
> regarding the computation of the Length field for TLVs, 
> especially for the Ethernet Bandwidth Profile TLV used in
> the Ethernet Traffic Parameters draft. As this draft is 
> considered to be very important for support of MEF defined
> Ethernet services, we request that this issue be resolved
> as soon as possible within CCAMP. 
>
> Our preference would be to compute the Length field for all
> TLVs (except those in RFC 4420) based on the full TLV rather
> than the Value alone, as this is the method commonly used in
> the past for length computation in RSVP.

Please note that RFC 4420 has been revised as
draft-ietf-ccamp-rfc4420-bis-03.txt. This draft is in the RFC 
Editor's queue, and will shortly be published as an RFC that
obsoletes RFC 4420. The change is to make the processing of
all RSVP-TE TLVs consistent so that the Length field accounts
for the full length of the TLV.

This change has also been incorporated into the work on traffic
parameters for Ethernet as described in 
draft-ietf-ccamp-ethernet-traffic-parameters-06.txt.

You will be pleased to hear that we consider our work on MEF-
related protocol extensions to be stable, and we will shortly
issue working group last calls on the following drafts:

draft-ietf-ccamp-ethernet-traffic-parameters-06.txt
draft-ietf-ccamp-gmpls-ether-svcs-02.txt
draft-ietf-ccamp-gmpls-mef-uni-01.txt
draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt

In view of the imminent last call on this work, we would 
welcome any input from OIF members. Input should be made either
by official communication from the OIF, or by email from any
individual to the CCAMP mailing list (subscription details are
found at http://www.ietf.org/html.charters/ccamp-charter.html).

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

Delivery-date: Mon, 15 Dec 2008 13:16:16 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Draft Response to OIF on Resv Usage
Date: Mon, 15 Dec 2008 13:15:04 -0000

Hi,

We (well, mainly Deborah and I) have been delinquent in responding to the 
OIF's communication http://www.olddog.co.uk/oif2008_063_02.pdf

Here is a draft response. Please comment this week and we will send the 
response as a Christmas present.

Thanks,
Adrian

===

Dear Lyndon,

CCAMP owes the OIF responses to several communications. Apologies for the 
delay in producing formal responses. The issues raised were discussed at 
some length during the months after we received the communication both on 
and off the CCAMP mailing list, and I know you were involved in some of 
those discussions, but we forgot to send the formal responses.

We will generate a series of responses with the technical issues broken out 
into separate threads. This first one addresses the issue of Resv usage 
during make-before-break as raised in oif2008.063.02.pdf.

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

---

> OIF thanks CCAMP for its prompt and very informative response
> to our liaison on OIF interoperability demo findings, sent
> from our 4Q2007 meeting. We appreciate CCAMP's offer to use
> the CCAMP mailing list for questions during our demo planning
> and testing, although more structured liaisons are still
> useful in our view to reflect meeting results and issues or
> comments that are agreed across OIF members (as opposed to
> individual views).

[SNIP]

> Based on your response liaison, it is our understanding that
> per-LSP RESV messages should be expected for the "make-
> before-break" scenario of modification. However, some members
> have commented that it appears to be possible in the
> specifications to use a single RESV message for multiple LSPs
> because:
> a) RFC 2205 allows the RESV message to carry multiple
>    FILTER_SPEC objects, specifically with the Shared Explicit
>    (SE) style that supports reservation sharing; and
> b) The FILTER_SPEC object was extended in RFC 3209 to carry
>    the LSP_ID.
>
> Clarification would be appreciated as to whether we should
> allow for receiving a single RESV message with multiple
> FILTER_SPEC objects in the "make-before-break" scenario using
> the SE style.

We believe this issue is substantially the same as the
following issue raised in the OIF correspondence dated November
29, 2007 with the subject "Liaison to IETF Regarding 2007
Interop Test Findings". Here you wrote:

>> - How many RESV messages are expected to be generated? Is it
>>   one since the resources in use by both LSPs are the same,
>>   or two since the LSPs are handled through separate
>>   signaling sessions.

In our response, dated January 3, 2008, we stated:

>>   In make-before-break, each LSP is signaled independently.
>>   Per LSP Resv messages should be expected.  Assuming the
>>   old LSP is in-place at the time of signaling the new LSP,
>>   and only one Path message is issued, then only one Resv
>>   would be expected. That is, a Resv for the new LSP, but no
>>   further Resv for the existing LSP.
>>
>>   When the old LSP is also modified as part of the make-
>>   before-break, e.g., to update administrative status prior
>>   to alarm-free tear-down, then a Resv message on the old
>>   LSP may also be generated.

To help clarify this point, we draw your attention to RFC 3209
which states:
     The SESSION object uniquely defines a traffic engineered
     tunnel. The SENDER_TEMPLATE and FILTER_SPEC objects carry
     an LSP ID. The SENDER_TEMPLATE (or FILTER_SPEC) object
     together with the SESSION object uniquely identifies an
     LSP tunnel.

As LSP tunnels (or LSPs for short) are identified using
different LSP IDs (as carried in SENDER_TEMPLATE and
FILTER_SPEC objects) and each LSP is signaled independently,
multiple FILTER_SPEC objects SHOULD NOT be allowed as part of
make-before-break.

Delivery-date: Mon, 15 Dec 2008 12:29:46 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Working group last call draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt
Date: Mon, 15 Dec 2008 12:27:37 -0000

This email starts the working group last call on 
draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt

The last call will run for three weeks to give people a little extra time 
over the Christmas period. Thus the call will end on 5th January 2009 at 
noon GMT.

Please send your comments to the CCAMP mailing list.

Note that the I-D is positioned as Experimental. This is appropriate for a 
modification to the use of a routing protocol where we do not have 
significant experience of the impact of the change to the way the routing 
protocol works.

Thanks,
Adrian

PS. This will be copied to the OSPF working group.

Delivery-date: Fri, 12 Dec 2008 21:28:02 +0000
Date: Fri, 12 Dec 2008 15:26:14 -0600
From: Lucy Yong <[email-masked]>
Subject: RE: comments on the draft of LSP hierarchy
To: 'Adrian Farrel' <[email-masked]>, [email-masked], [email-masked]

Hi Adrian,

I would like to clarify on the use of IGP instance Identifier.

If there is no such TLV listed in LSP_TUNNEL_INFERFACE_ID object, the LSP is
to be advertised in the same instance of the IGP as was used to advertise
the TE links that the LSP traverse, or 
If there are such TLVs listed in LSP_TUNNEL_INFERFACE_ID object, the LSP is
to be advertised in those IGPs in TLV list. In order to advertise in the IGP
as was used to advertise the TE links that the LSP traverses, an TLV has to
be used but just fill value as 0xffffff. 

Is my understanding correct?

I think how client/server network (1.1.6) can apply to inter AS case. In
this case, the LSP is created in server network (IGP A) as inter-AS link
between AS B and AS C. Each end point of LSP connects IGP B and IGP C,
respectively, i.e. one end need to advertise in IGP B and another end
advertises in IGP C. In this case, only ingress end point needs to know its
side IGP identifier so no needs to list IGP B and IGP C in TLVs. But we also
don't want to advertise this LSP in the IGP A. Can we address this case?

Regards,
Lucy

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Tuesday, December 09, 2008 11:27 AM
> To: Lucy Yong; [email-masked]; [email-masked]
> Subject: Re: comments on the draft of LSP hierarchy
> 
> Hi Lucy,
> 
> >> > 1) When LSP is used for Client/Server Network: the server network
sets
> >> > LSP as private link with one or more client IGP instances; When LSP
> >> > is used as routing adjacency: the network sets LSP as non-private
link
> >> > with routing adjacency. Is this correct?
> >>
> >> I think that if the link is private, there is no need and possibly no
> >> meaning to set a client IGP instance. Setting an IGP instance implies
> >> that
> >> the link is to be advertised in some IGP instance, and a private link
> >> will
> >> not be advertised.
> >
> > [Lucy:] I though that signaling is within an IGP (say IGP A). So if
> > signaling a LSP for client/server network (say IGP B), RSVP needs set
> > action
> > as private link (not adv in IGP A), FA, and lists other IGP instances
(IGP
> > B).  It seems my understanding is not correct.
> > Are you saying that RSVP signaling is not tight to an IGP instance?
> > Without
> > using private link indication, how does the LSA of IGP A know if it
should
> > advertise in IGP A or not?
> 
> I am a bit confused by your question.
> 
> When an LSP is signaled in RSVP-TE it can be used to create a link in one
or
> more other networks.
> 
> If the link is to be advertised in the same instance of the IGP that was
> used to advertise the links that were used by RSVP-TE when it signaled the
> LSP, then this is a Forwarding Adjacency as already described.
> 
> If the link is to be advertised in a separate instance of an IGP (perhaps
an
> IGP that advertises links in another network layer) then the IGP instance
is
> indicated in the signaling message used to set up the LSP as described in
> this draft.
> 
> If the link is not to be advertised (i.e. is a private link) then you do
not
> include the IGP instance because it is not needed.
> 
> >> > 3) A component link in a link bundle has component link identifier.
> >> > This
> >> > identifier is the link ID that is advertised in LSA. Is that correct?
> >>
> >> Section 2.4 says...
> >>
> >>    When an LSP is to be used as a component link of a link bundle, the
> >>    LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how
> >>    the bundle is addressed and used, and a new TLV indicates the
> >>    component link identifier for the link that the LSP creates.
> >>
> >> Only the component link identifier is advertised by the IGP. The
> >> component
> >> link identifier is used locally (between link end points), but may also
> >> be
> >> present in an ERO and RRO in signaling with the assumption that this
> >> inormaiton is coordinated by some other means.
> >
> > [Lucy:] If component link identifier is used locally, why does it be
> > advertised in the IGP?
> 
> I'm sorry, I mistyped (that will teach me to try to write emails to you
> while concentrating on ITU-T politics ;-)
> 
> I should have written...
> 
> Only the *bundle* link identifier is advertised by the IGP. The component
> link identifier is used locally (between link end points), but may also be
> present in an ERO and RRO in signaling with the assumption that this
> information is coordinated by some other means.
> 
> >> > 4) In section 3.3, it states:
> >> >
> >> >   If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID
> >> >   object is set, the other fields of the object apply to the link
> >> >   bundle itself. That is, the interface identifiers (numbered or
> >> >   unnumbered) and the other flags in the Actions field apply to the
> >> >   link bundle and not to the component link that the LSP will form.
> >> >
> >> >   Furthermore, the IGP Instance Identifier TLV (if present) also
> >> >   applies to the link bundle and not to the component link.
> >> >
> >> > It seems odd way to set actions for link bundle. Should we first set
> >> > the
> >> > link bundle with the action, then add component link to the link
bundle
> >> > without action?
> >>
> >> The issue is that the link bundle itself is not signaled. Only the
> >> component links correspond to LSPs that are signaled. Thus,
> >> when the first component link is signaled, there is no link bundle
> >> in existence.
> >
> > [Lucy:] Yes, it is the issue. Would it be nice to have a way to signal a
> > link bundle first? It can apply to composite link as well.
> 
> You could come up with a way to do that. You should not use LSP signaling
to
> do this - the bundle or composite link should not be known at transit
points
> of the LSP. You might want to use a GMPLS call to achieve this function if
> (and only if?) the bundle/composite link needs to be communicated in
> advance.
> 
> > If we stay as it is, when adding the second component link to a link
> > bundle,
> > RSVP has to make sure all the actions have to be the exact same, is that
> > right? Or we only require the first signaled component link to indicate
a
> > link bundle properties.
> 
> I think that might depend on application.
> 
> > If we want to add a component link in a link bundle to an IGP instance,
we
> > will use LSP_TUNNEL_INTERFACE_ID with IGP TLV and component link TLV,
> how
> > to
> > distinguish two type of TLV within an LSP_TUNNEL_INTERFACE_ID object?
> 
> They have different TLV type values.
> 
> >> > 6) For CTG scenarios, we create a set of LSPs to form a single
> >> > composite
> >> > link to client/server network. We can first create a composite link
as
> >> > a
> >> > private link with one or more client IGP instances with (at least one
> >> > component link); then individual component link can be added to and
> >> > removed from the composite link. Component links are also private
link
> >> > (different from component link in link bundle) and have different TE
> >> > properties. We can also create composite link for routing adjacency
> >> > (single IGP case). We need some extension to cover these scenarios.
> >> > Could we consider adding this into the document?
> >>
> >> I believe that the mechanisms in the hierarchy bis draft will be
> >> applicable to the creation of LSPs that are used as components of
> >> CTGs. In my view (as an author) it would be premature to add this
> >> to the draft at this stage as it would create a normative reference to
> >> the CTG work which has not yet been adopted by any working group
> >> and is bound to take some time to complete.
> >
> > [Lucy:] Operator want to implement CTG soon and hope the framework and
> > requirement draft can be completed soon. Although CTG can be manually
> > configured at beginning, it would be nice to have an GMPLS way to
> > configure
> > it as well.
> 
> Yes. I agree.
> 
> Hence my proposal below.
> 
> >> My preferred approach is that the hierarchy bis draft creates the
> >> framework and a registry of actions carried in the flags field (see
> >> section 5.2).
> >> Any new work, such as your CTG work, can then request the
> >> allocation of a further bit and can define the behavior if the bit
> >> is set.
> >
> > [Lucy:] Thank you for the suggestion.
> 
> Regards,
> Adrian
> 

Delivery-date: Fri, 12 Dec 2008 03:38:12 +0000
Content-class: urn:content-classes:message
Subject: RE: new version of LSP DPPM draft
Date: Fri, 12 Dec 2008 04:32:16 +0100
From: "Monique Morrow (mmorrow)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C95C0A.9E8A562A
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Adrian,

1. Thanks for the forward.

2. Observation: nice productive dialogue on the technical merits of the =
draft=20

Best/m

Monique Jeanne Morrow
SP APAC CTO/Distinguished Consulting Engineer

-----Original Message-----
From: [email-masked] on behalf of Adrian Farrel
Sent: Tue 12/9/2008 2:56 AM
To: [email-masked]
Subject: Fw: new version of LSP DPPM draft
=20
Forwarded on behalf of Guoying Zhang:

----- Original Message -----=20
From: "gyzhang" <[email-masked]>
Sent: Tuesday, December 09, 2008 2:14 AM
Subject: new version of LSP DPPM draft

Hi all,

A new version of DPPM draft (LSP Dynamic Provisioning Performance =
Metrics in=20
GMPLS Networks) has just been posted on the IETF website. This draft was =

discussed in the Dublin meeting. The authors have now updated the draft=20
according to the discussions during and after the meeting. The following =
are=20
the summary of discussion and modifications made to the draft.

 1. During and after the meeting, some discussion was made about the =
data=20
plane and control plane synchronization. Thanks to Adrian, some rules=20
clarifying their relations were identified in existing documents.

 (1) Three documents stated the rules in the forward direction
RFC 3471 section 3.4: an ingress node should not transmit data traffic =
on a=20
suggested label until the downstream node passes a label upstream. The=20
implication here is that an ingress node may (safely) start to transmit =
data=20
when it receives a label in a Resv message.

 This also shows in RFC 3473 section 2.5:  An ingress node SHOULD NOT=20
transmit data traffic using a suggested label until the downstream node=20
passes a corresponding label upstream.

 Also in RFC3209 section 4.1.1.1: The node then sends the new LABEL =
object=20
as part of the Resv message to the previous hop. The node SHOULD be =
prepared=20
to forward packets carrying the assigned label prior to sending the Resv =

message. "before" is very telling. It means that the XC must be in place =
to=20
forward traffic before Resv is sent.

 (2) For the reverse direction
We have RFC 3473 section 3.1: The Upstream_Label object MUST indicate a=20
label that is valid for forwarding at the time the Path message is sent. =

"valid for forwarding" should be taken to mean that it is OK to receive =
data=20
and it will be forwarded. But it can also be taken to mean "acceptable =
for=20
use" i.e. available to be cross-connected.

 This is clarified later in RFC 3473 section 3.1: Terminator nodes =
process=20
Path messages as usual, with the exception that the upstream label can=20
immediately be used to transport data traffic associated with the LSP=20
upstream towards the initiator. This is pretty clear. When a Path =
message=20
has been fully processed by an egress node, it is completely safe to=20
transmit data toward the ingress (i.e. reverse path data).

  (3) To clarify this assumption (that the these rules are followed) we=20
include the following text into the discussion section (section 15)
This document assumes that the correct procedures for installing the =
data=20
plane are followed as described in [RFC3209], [RFC3471], and [RFC3473]. =
That=20
is, that by the time the egress receives and processes a Path message, =
it is=20
safe for the egress to transmit data on the reverse path, and that by =
the=20
time the ingress receives and processes a Resv message it is safe for =
the=20
ingress to transmit data on the forward path. This document does not =
include=20
any verification that the implementations of the control plane software =
are=20
conformant, although such tests could be constructed with the use of=20
suitable signal generation test equipment.

 2. During the Dublin meeting, the authors raised the open issue of =
using=20
two way signaling or three way signaling. After some discussions within =
the=20
editor team, an agreement has been reached and the following text was =
added=20
to the discussion section (section 15)

  o Bidirectional LSPs may be setup using three way signaling, where the =

initiate node will send a RESV_CONF message downstream upon receiving =
the=20
RESV message. The RESV_CONF message is used to notify the terminate node =

that it can transfer data upstream. Actually, both directions should be=20
ready to transfer data when the RESV message is received by the initiate =

node. Therefore, the bidirectional LSP setup delay defined in this =
document,=20
does not take the confirmation procedure into account.

We thank to Lou, Igor and Adrian for their valuable comments and =
discussions=20
during and after the meeting. The authors would like to have more =
experts=20
from the WG to review this draft. And we hope to request a WG last call=20
soon.

 best regards,
 ????????Guoying Zhang
 ????????[email-masked]
 ??????????2008-12-08

------_=_NextPart_001_01C95C0A.9E8A562A
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: new version of LSP DPPM draft</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Adrian,<BR>
<BR>
1. Thanks for the forward.<BR>
<BR>
2. Observation: nice productive dialogue on the technical merits of the =
draft<BR>
<BR>
Best/m<BR>
<BR>
<BR>
<BR>
Monique Jeanne Morrow<BR>
SP APAC CTO/Distinguished Consulting Engineer<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of Adrian Farrel<BR>
Sent: Tue 12/9/2008 2:56 AM<BR>
To: [email-masked]<BR>
Subject: Fw: new version of LSP DPPM draft<BR>
<BR>
Forwarded on behalf of Guoying Zhang:<BR>
<BR>
----- Original Message -----<BR>
From: &quot;gyzhang&quot; &lt;[email-masked]&gt;<BR>
Sent: Tuesday, December 09, 2008 2:14 AM<BR>
Subject: new version of LSP DPPM draft<BR>
<BR>
<BR>
Hi all,<BR>
<BR>
A new version of DPPM draft (LSP Dynamic Provisioning Performance =
Metrics in<BR>
GMPLS Networks) has just been posted on the IETF website. This draft =
was<BR>
discussed in the Dublin meeting. The authors have now updated the =
draft<BR>
according to the discussions during and after the meeting. The following =
are<BR>
the summary of discussion and modifications made to the draft.<BR>
<BR>
&nbsp;1. During and after the meeting, some discussion was made about =
the data<BR>
plane and control plane synchronization. Thanks to Adrian, some =
rules<BR>
clarifying their relations were identified in existing documents.<BR>
<BR>
&nbsp;(1) Three documents stated the rules in the forward direction<BR>
RFC 3471 section 3.4: an ingress node should not transmit data traffic =
on a<BR>
suggested label until the downstream node passes a label upstream. =
The<BR>
implication here is that an ingress node may (safely) start to transmit =
data<BR>
when it receives a label in a Resv message.<BR>
<BR>
&nbsp;This also shows in RFC 3473 section 2.5:&nbsp; An ingress node =
SHOULD NOT<BR>
transmit data traffic using a suggested label until the downstream =
node<BR>
passes a corresponding label upstream.<BR>
<BR>
&nbsp;Also in RFC3209 section 4.1.1.1: The node then sends the new LABEL =
object<BR>
as part of the Resv message to the previous hop. The node SHOULD be =
prepared<BR>
to forward packets carrying the assigned label prior to sending the =
Resv<BR>
message. &quot;before&quot; is very telling. It means that the XC must =
be in place to<BR>
forward traffic before Resv is sent.<BR>
<BR>
&nbsp;(2) For the reverse direction<BR>
We have RFC 3473 section 3.1: The Upstream_Label object MUST indicate =
a<BR>
label that is valid for forwarding at the time the Path message is =
sent.<BR>
&quot;valid for forwarding&quot; should be taken to mean that it is OK =
to receive data<BR>
and it will be forwarded. But it can also be taken to mean =
&quot;acceptable for<BR>
use&quot; i.e. available to be cross-connected.<BR>
<BR>
&nbsp;This is clarified later in RFC 3473 section 3.1: Terminator nodes =
process<BR>
Path messages as usual, with the exception that the upstream label =
can<BR>
immediately be used to transport data traffic associated with the =
LSP<BR>
upstream towards the initiator. This is pretty clear. When a Path =
message<BR>
has been fully processed by an egress node, it is completely safe to<BR>
transmit data toward the ingress (i.e. reverse path data).<BR>
<BR>
&nbsp; (3) To clarify this assumption (that the these rules are =
followed) we<BR>
include the following text into the discussion section (section 15)<BR>
This document assumes that the correct procedures for installing the =
data<BR>
plane are followed as described in [RFC3209], [RFC3471], and [RFC3473]. =
That<BR>
is, that by the time the egress receives and processes a Path message, =
it is<BR>
safe for the egress to transmit data on the reverse path, and that by =
the<BR>
time the ingress receives and processes a Resv message it is safe for =
the<BR>
ingress to transmit data on the forward path. This document does not =
include<BR>
any verification that the implementations of the control plane software =
are<BR>
conformant, although such tests could be constructed with the use of<BR>
suitable signal generation test equipment.<BR>
<BR>
<BR>
&nbsp;2. During the Dublin meeting, the authors raised the open issue of =
using<BR>
two way signaling or three way signaling. After some discussions within =
the<BR>
editor team, an agreement has been reached and the following text was =
added<BR>
to the discussion section (section 15)<BR>
<BR>
&nbsp; o Bidirectional LSPs may be setup using three way signaling, =
where the<BR>
initiate node will send a RESV_CONF message downstream upon receiving =
the<BR>
RESV message. The RESV_CONF message is used to notify the terminate =
node<BR>
that it can transfer data upstream. Actually, both directions should =
be<BR>
ready to transfer data when the RESV message is received by the =
initiate<BR>
node. Therefore, the bidirectional LSP setup delay defined in this =
document,<BR>
does not take the confirmation procedure into account.<BR>
<BR>
<BR>
We thank to Lou, Igor and Adrian for their valuable comments and =
discussions<BR>
during and after the meeting. The authors would like to have more =
experts<BR>
from the WG to review this draft. And we hope to request a WG last =
call<BR>
soon.<BR>
<BR>
&nbsp;best regards,<BR>
&nbsp;????????Guoying Zhang<BR>
&nbsp;????????[email-masked]<BR>
&nbsp;??????????2008-12-08<BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C95C0A.9E8A562A--

Envelope-to: [email-masked]
Delivery-date: Thu, 11 Dec 2008 23:14:00 +0000
To: [email-masked], [email-masked]
Subject: RFC 5316 on ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Thu, 11 Dec 2008 15:12:26 -0800 (PST)

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

        RFC 5316

        Title:      ISIS Extensions in Support of 
                    Inter-Autonomous System (AS) MPLS and GMPLS 
                    Traffic Engineering 
        Author:     M. Chen, R. Zhang, X. Duan
        Status:     Standards Track
        Date:       December 2008
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked]
        Pages:      19
        Characters: 45408
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-isis-interas-te-extension-04.txt

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

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

No support for flooding information from within one AS to another AS
is proposed or defined in this document.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

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

The RFC Editor Team
USC/Information Sciences Institute

Delivery-date: Thu, 11 Dec 2008 01:38:40 +0000
Date: Thu, 11 Dec 2008 10:36:16 +0900
From: "Ogaki, Kenichi" <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt

Hello All,

Please find the new revision (01) of "Service Provider Requirements for
Ethernet control with GMPLS".

We have added some new sections,
(4.1.3. Addressing)
4.2.4. Asymmetric bandwidth
4.2.5. QoS control.

and modified some texts in
4.2.3. P2MP and MP2MP requirements
4.4. Protection and Restoration related functionality.

We would welcome your feedback and thoughts.

Best regards,
Yoshiaki & Kenichi

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.
>
>
> 	Title           : Service Provider Requirements for Ethernet control with GMPLS
> 	Author(s)       : W. Imajuku, et al.
> 	Filename        : draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt
> 	Pages           : 19
> 	Date            : 2008-12-10
>
> Generalized Multi-Protocol Label Switching (GMPLS) is applicable to
> Ethernet switches supporting Provider Backbone Bridge Traffic
> Engineering (PBB-TE) networks.  The GMPLS controlled Ethernet label
> switch network not only automates creation of Ethernet Label Switched
> Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery
> Mechanisms such as protection and restoration of an Eth-LSP.  This
> document describes the requirements for the set of solutions of GMPLS
> controlled Ethernet label switch networks.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-gmpls-provider-reqs-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.
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>   

Delivery-date: Wed, 10 Dec 2008 18:01:07 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt 
Date: Wed, 10 Dec 2008 10:00:01 -0800 (PST)

--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           : Service Provider Requirements for Ethernet control with GMPLS
	Author(s)       : W. Imajuku, et al.
	Filename        : draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt
	Pages           : 19
	Date            : 2008-12-10

Generalized Multi-Protocol Label Switching (GMPLS) is applicable to
Ethernet switches supporting Provider Backbone Bridge Traffic
Engineering (PBB-TE) networks.  The GMPLS controlled Ethernet label
switch network not only automates creation of Ethernet Label Switched
Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery
Mechanisms such as protection and restoration of an Eth-LSP.  This
document describes the requirements for the set of solutions of GMPLS
controlled Ethernet label switch networks.

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

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

--NextPart--

Delivery-date: Wed, 10 Dec 2008 14:24:33 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Letters of Invitation to IETF 74 now available to past attendees
Date: Wed, 10 Dec 2008 14:22:43 -0000

----- Original Message ----- 
From: "Alexa Morris" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, December 09, 2008 6:31 PM
Subject: Letters of Invitation to IETF 74 now available to past attendees

> If you need a letter of invitation (LOI) in order to obtain a visa to  
> come to IETF 74 in San Francisco  -- and if you have attended at least  
> one IETF meeting in the past -- you can now request a LOI via this  
> webform: https://www.amsl.com/ietf/ietf74-loi.html. The LOI will be  
> sent to you via email unless you specifically request a hard copy. You  
> can also access the webform from the Meetings page of the IETF website.
> 
> As soon as we officially open registration for the meeting, anyone who  
> registers for IETF 74 (regardless of whether or not they've attended a  
> past meeting) will be able to request and receive a letter of  
> invitation to attend.
> 
> Regards,
> Alexa
> 
> -----------
> Alexa Morris / Executive Director / IETF
> 48377 Fremont Blvd., Suite 117, Fremont, CA  94538
> Phone: +1.510.492.4089 / Fax: +1.510.492.4001
> Email: [email-masked]
> 
> Managed by Association Management Solutions (AMS)
> Forum Management, Meeting and Event Planning
> www.amsl.com <http://www.amsl.com/>
> 
>

Delivery-date: Tue, 09 Dec 2008 23:43:48 +0000
Date: Tue, 09 Dec 2008 17:41:32 -0600
From: Lucy Yong <[email-masked]>
Subject: RE: comments on the draft of LSP hierarchy
To: 'Adrian Farrel' <[email-masked]>, [email-masked], [email-masked]

Hello Adrian,

Thank again. See below.

Regards,
Lucy

 [Snipped]
> 
> I am a bit confused by your question.
> 
> When an LSP is signaled in RSVP-TE it can be used to create a link in one
or
> more other networks.
[Lucy:]  yes. 
> 
> If the link is to be advertised in the same instance of the IGP that was
> used to advertise the links that were used by RSVP-TE when it signaled the
> LSP, then this is a Forwarding Adjacency as already described.

[Lucy:] I would like to better understand client/server network case
(1.1.6). As described, the server network LSP does not form FA because
client and server network run separate instances of the control plane
routing protocols.
Now, I guess "instances of the control plane routing protocols" are
different from IGP instances. (I thought they mean the same before). 
Could you give an example to use LSP_TUNNEL_INTERFACE_ID object for a LSP
that is created in one network and used in another network as a virtual
link? 
[Snipped]
> 
> I'm sorry, I mistyped (that will teach me to try to write emails to you
> while concentrating on ITU-T politics ;-)
> 
> I should have written...
> 
> Only the *bundle* link identifier is advertised by the IGP. The component
> link identifier is used locally (between link end points), but may also be
> present in an ERO and RRO in signaling with the assumption that this
> information is coordinated by some other means.
[Lucy:] Make sense. So without this extension, operator has to configure
component link identifier at link end points. So a component link in a link
bundle is never advertised.
[snipped]
> >
> > [Lucy:] Yes, it is the issue. Would it be nice to have a way to signal a
> > link bundle first? It can apply to composite link as well.
> 
> You could come up with a way to do that. You should not use LSP signaling
to
> do this - the bundle or composite link should not be known at transit
points
> of the LSP. You might want to use a GMPLS call to achieve this function if
> (and only if?) the bundle/composite link needs to be communicated in
> advance.
[Lucy:] All the actions are indications for LSP egress point not transit
points, right?
> 
> > If we stay as it is, when adding the second component link to a link
> > bundle,
> > RSVP has to make sure all the actions have to be the exact same, is that
> > right? Or we only require the first signaled component link to indicate
a
> > link bundle properties.
> 
> I think that might depend on application.
> 
> > If we want to add a component link in a link bundle to an IGP instance,
we
> > will use LSP_TUNNEL_INTERFACE_ID with IGP TLV and component link TLV,
> how
> > to
> > distinguish two type of TLV within an LSP_TUNNEL_INTERFACE_ID object?
> 
> They have different TLV type values.
[Lucy:] where are they specified?

Delivery-date: Tue, 09 Dec 2008 17:28:27 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lucy Yong" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: comments on the draft of LSP hierarchy
Date: Tue, 9 Dec 2008 17:27:19 -0000

Hi Lucy,

>> > 1) When LSP is used for Client/Server Network: the server network sets
>> > LSP as private link with one or more client IGP instances; When LSP
>> > is used as routing adjacency: the network sets LSP as non-private link
>> > with routing adjacency. Is this correct?
>>
>> I think that if the link is private, there is no need and possibly no
>> meaning to set a client IGP instance. Setting an IGP instance implies 
>> that
>> the link is to be advertised in some IGP instance, and a private link 
>> will
>> not be advertised.
>
> [Lucy:] I though that signaling is within an IGP (say IGP A). So if
> signaling a LSP for client/server network (say IGP B), RSVP needs set 
> action
> as private link (not adv in IGP A), FA, and lists other IGP instances (IGP
> B).  It seems my understanding is not correct.
> Are you saying that RSVP signaling is not tight to an IGP instance? 
> Without
> using private link indication, how does the LSA of IGP A know if it should
> advertise in IGP A or not?

I am a bit confused by your question.

When an LSP is signaled in RSVP-TE it can be used to create a link in one or 
more other networks.

If the link is to be advertised in the same instance of the IGP that was 
used to advertise the links that were used by RSVP-TE when it signaled the 
LSP, then this is a Forwarding Adjacency as already described.

If the link is to be advertised in a separate instance of an IGP (perhaps an 
IGP that advertises links in another network layer) then the IGP instance is 
indicated in the signaling message used to set up the LSP as described in 
this draft.

If the link is not to be advertised (i.e. is a private link) then you do not 
include the IGP instance because it is not needed.

>> > 3) A component link in a link bundle has component link identifier. 
>> > This
>> > identifier is the link ID that is advertised in LSA. Is that correct?
>>
>> Section 2.4 says...
>>
>>    When an LSP is to be used as a component link of a link bundle, the
>>    LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how
>>    the bundle is addressed and used, and a new TLV indicates the
>>    component link identifier for the link that the LSP creates.
>>
>> Only the component link identifier is advertised by the IGP. The 
>> component
>> link identifier is used locally (between link end points), but may also 
>> be
>> present in an ERO and RRO in signaling with the assumption that this
>> inormaiton is coordinated by some other means.
>
> [Lucy:] If component link identifier is used locally, why does it be
> advertised in the IGP?

I'm sorry, I mistyped (that will teach me to try to write emails to you 
while concentrating on ITU-T politics ;-)

I should have written...

Only the *bundle* link identifier is advertised by the IGP. The component
link identifier is used locally (between link end points), but may also be
present in an ERO and RRO in signaling with the assumption that this
information is coordinated by some other means.

>> > 4) In section 3.3, it states:
>> >
>> >   If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID
>> >   object is set, the other fields of the object apply to the link
>> >   bundle itself. That is, the interface identifiers (numbered or
>> >   unnumbered) and the other flags in the Actions field apply to the
>> >   link bundle and not to the component link that the LSP will form.
>> >
>> >   Furthermore, the IGP Instance Identifier TLV (if present) also
>> >   applies to the link bundle and not to the component link.
>> >
>> > It seems odd way to set actions for link bundle. Should we first set 
>> > the
>> > link bundle with the action, then add component link to the link bundle
>> > without action?
>>
>> The issue is that the link bundle itself is not signaled. Only the
>> component links correspond to LSPs that are signaled. Thus,
>> when the first component link is signaled, there is no link bundle
>> in existence.
>
> [Lucy:] Yes, it is the issue. Would it be nice to have a way to signal a
> link bundle first? It can apply to composite link as well.

You could come up with a way to do that. You should not use LSP signaling to 
do this - the bundle or composite link should not be known at transit points 
of the LSP. You might want to use a GMPLS call to achieve this function if 
(and only if?) the bundle/composite link needs to be communicated in 
advance.

> If we stay as it is, when adding the second component link to a link 
> bundle,
> RSVP has to make sure all the actions have to be the exact same, is that
> right? Or we only require the first signaled component link to indicate a
> link bundle properties.

I think that might depend on application.

> If we want to add a component link in a link bundle to an IGP instance, we
> will use LSP_TUNNEL_INTERFACE_ID with IGP TLV and component link TLV, how 
> to
> distinguish two type of TLV within an LSP_TUNNEL_INTERFACE_ID object?

They have different TLV type values.

>> > 6) For CTG scenarios, we create a set of LSPs to form a single 
>> > composite
>> > link to client/server network. We can first create a composite link as 
>> > a
>> > private link with one or more client IGP instances with (at least one
>> > component link); then individual component link can be added to and
>> > removed from the composite link. Component links are also private link
>> > (different from component link in link bundle) and have different TE
>> > properties. We can also create composite link for routing adjacency
>> > (single IGP case). We need some extension to cover these scenarios.
>> > Could we consider adding this into the document?
>>
>> I believe that the mechanisms in the hierarchy bis draft will be
>> applicable to the creation of LSPs that are used as components of
>> CTGs. In my view (as an author) it would be premature to add this
>> to the draft at this stage as it would create a normative reference to
>> the CTG work which has not yet been adopted by any working group
>> and is bound to take some time to complete.
>
> [Lucy:] Operator want to implement CTG soon and hope the framework and
> requirement draft can be completed soon. Although CTG can be manually
> configured at beginning, it would be nice to have an GMPLS way to 
> configure
> it as well.

Yes. I agree.

Hence my proposal below.

>> My preferred approach is that the hierarchy bis draft creates the
>> framework and a registry of actions carried in the flags field (see
>> section 5.2).
>> Any new work, such as your CTG work, can then request the
>> allocation of a further bit and can define the behavior if the bit
>> is set.
>
> [Lucy:] Thank you for the suggestion.

Regards,
Adrian 

Delivery-date: Tue, 09 Dec 2008 16:32:50 +0000
Date: Tue, 09 Dec 2008 10:31:02 -0600
From: Lucy Yong <[email-masked]>
Subject: RE: comments on the draft of LSP hierarchy
To: 'Adrian Farrel' <[email-masked]>, [email-masked], [email-masked]

Hi Adrian,

Thank very much for the explanation. See below.

Regards,
Lucy

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Tuesday, December 09, 2008 4:51 AM
> To: Lucy Yong; [email-masked]; [email-masked]
> Subject: Re: comments on the draft of LSP hierarchy
> 
> Hi Lucy,
> 
> > I study through this draft and appreciate that you specify many
necessary
> > MLN scenarios that LSP can be used for. Some of them can apply to CTG
> > (composite transport group) scenario. Here are some clarification and
> > questions:
> >
> > 1) When LSP is used for Client/Server Network: the server network sets
LSP
> > as private link with one or more client IGP instances; When LSP is used
as
> > routing adjacency: the network sets LSP as non-private link with routing
> > adjacency. Is this correct?
> 
> I think that if the link is private, there is no need and possibly no
> meaning to set a client IGP instance. Setting an IGP instance implies that
> the link is to be advertised in some IGP instance, and a private link will
> not be advertised.
> 
[Lucy:] I though that signaling is within an IGP (say IGP A). So if
signaling a LSP for client/server network (say IGP B), RSVP needs set action
as private link (not adv in IGP A), FA, and lists other IGP instances (IGP
B).  It seems my understanding is not correct.
Are you saying that RSVP signaling is not tight to an IGP instance? Without
using private link indication, how does the LSA of IGP A know if it should
advertise in IGP A or not?

> > 2) Should section 2.2 add one more categories: -LSP is used as a
component
> > link in a link bundle? The doc. is described it but not considers it as
> > category.
> 
> Good catch.
> The overview text was not updated to reflect updates to the main body.
> I will update.
> 
> > 3) A component link in a link bundle has component link identifier. This
> > identifier is the link ID that is advertised in LSA. Is that correct?
> 
> Section 2.4 says...
> 
>    When an LSP is to be used as a component link of a link bundle, the
>    LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how
>    the bundle is addressed and used, and a new TLV indicates the
>    component link identifier for the link that the LSP creates.
> 
> Only the component link identifier is advertised by the IGP. The component
> link identifier is used locally (between link end points), but may also be
> present in an ERO and RRO in signaling with the assumption that this
> inormaiton is coordinated by some other means.
[Lucy:] If component link identifier is used locally, why does it be
advertised in the IGP? 
> 
> > 4) In section 3.3, it states:
> >
> >   If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID
> >   object is set, the other fields of the object apply to the link
> >   bundle itself. That is, the interface identifiers (numbered or
> >   unnumbered) and the other flags in the Actions field apply to the
> >   link bundle and not to the component link that the LSP will form.
> >
> >   Furthermore, the IGP Instance Identifier TLV (if present) also
> >   applies to the link bundle and not to the component link.
> >
> > It seems odd way to set actions for link bundle. Should we first set the
> > link bundle with the action, then add component link to the link bundle
> > without action?
> 
> The issue is that the link bundle itself is not signaled. Only the
component
> links correspond to LSPs that are signaled. Thus, when the first component
> link is signaled, there is no link bundle in existence.
[Lucy:] Yes, it is the issue. Would it be nice to have a way to signal a
link bundle first? It can apply to composite link as well.
If we stay as it is, when adding the second component link to a link bundle,
RSVP has to make sure all the actions have to be the exact same, is that
right? Or we only require the first signaled component link to indicate a
link bundle properties. 

If we want to add a component link in a link bundle to an IGP instance, we
will use LSP_TUNNEL_INTERFACE_ID with IGP TLV and component link TLV, how to
distinguish two type of TLV within an LSP_TUNNEL_INTERFACE_ID object? 
> 
> > 5) LSA should not advertise LSP used as private link. Should this be
> > explicitly stated in section 3.4?
> 
> OK.
> I'll add this to the definition of a private link in section 1.1.3.
> 
> > 6) For CTG scenarios, we create a set of LSPs to form a single composite
> > link to client/server network. We can first create a composite link as a
> > private link with one or more client IGP instances with (at least one
> > component link); then individual component link can be added to and
> > removed
> > from the composite link. Component links are also private link
(different
> > from component link in link bundle) and have different TE properties. We
> > can
> > also create composite link for routing adjacency (single IGP case). We
> > need
> > some extension to cover these scenarios. Could we consider adding this
> > into
> > the document?
> 
> I believe that the mechanisms in the hierarchy bis draft will be
applicable
> to the creation of LSPs that are used as components of CTGs. In my view
(as
> an author) it would be premature to add this to the draft at this stage as
> it would create a normative reference to the CTG work which has not yet
been
> adopted by any working group and is bound to take some time to complete.
[Lucy:] Operator want to implement CTG soon and hope the framework and
requirement draft can be completed soon. Although CTG can be manually
configured at beginning, it would be nice to have an GMPLS way to configure
it as well.
> 
> My preferred approach is that the hierarchy bis draft creates the
framework
> and a registry of actions carried in the flags field (see section 5.2).
Any
> new work, such as your CTG work, can then request the allocation of a
> further bit and can define the behavior if the bit is set.
[Lucy:] Thank you for the suggestion. 
> Cheers,
> Adrian

Delivery-date: Tue, 09 Dec 2008 11:00:37 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-lsp-hierarchy-bis-06.txt 
Date: Tue,  9 Dec 2008 03:00:01 -0800 (PST)

--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           : Procedures for Dynamically Signaled Hierarchical Label Switched Paths
	Author(s)       : K. Shiomoto, et al.
	Filename        : draft-ietf-ccamp-lsp-hierarchy-bis-06.txt
	Pages           : 28
	Date            : 2008-12-09

Label Switched Paths (LSPs) set up in Multiprotocol Label Switching
(MPLS) or Generalized MPLS (GMPLS) networks can be used to form links
for carrying traffic in those networks or in other (client) networks.

Protocol extensions already exist to facilitate the establishment of
an LSP as a numbered traffic engineering (TE) link within the same
instance of the routing as is used to advertise the links that it
traverses creating a Forwarding Adjacency (FA). This document extends
those mechanisms to support unnumbered FAs.

This document also defines how to indicate that an LSP should be
advertised as a link in another instance of the routing protocol (for
instance in a client network) and which instance to use. Furthermore,
mechanisms are defined to indicate when an LSP is to be used as a
component link of a TE link bundle and to identify the bundle.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-lsp-hierarchy-bis-06.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-hierarchy-bis-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Tue, 09 Dec 2008 10:57:12 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: new version of LSP DPPM draft
Date: Tue, 9 Dec 2008 10:56:23 -0000

Forwarded on behalf of Guoying Zhang:

----- Original Message ----- 
From: "gyzhang" <[email-masked]>
Sent: Tuesday, December 09, 2008 2:14 AM
Subject: new version of LSP DPPM draft

Hi all,

A new version of DPPM draft (LSP Dynamic Provisioning Performance Metrics in 
GMPLS Networks) has just been posted on the IETF website. This draft was 
discussed in the Dublin meeting. The authors have now updated the draft 
according to the discussions during and after the meeting. The following are 
the summary of discussion and modifications made to the draft.

 1. During and after the meeting, some discussion was made about the data 
plane and control plane synchronization. Thanks to Adrian, some rules 
clarifying their relations were identified in existing documents.

 (1) Three documents stated the rules in the forward direction
RFC 3471 section 3.4: an ingress node should not transmit data traffic on a 
suggested label until the downstream node passes a label upstream. The 
implication here is that an ingress node may (safely) start to transmit data 
when it receives a label in a Resv message.

 This also shows in RFC 3473 section 2.5:  An ingress node SHOULD NOT 
transmit data traffic using a suggested label until the downstream node 
passes a corresponding label upstream.

 Also in RFC3209 section 4.1.1.1: The node then sends the new LABEL object 
as part of the Resv message to the previous hop. The node SHOULD be prepared 
to forward packets carrying the assigned label prior to sending the Resv 
message. "before" is very telling. It means that the XC must be in place to 
forward traffic before Resv is sent.

 (2) For the reverse direction
We have RFC 3473 section 3.1: The Upstream_Label object MUST indicate a 
label that is valid for forwarding at the time the Path message is sent. 
"valid for forwarding" should be taken to mean that it is OK to receive data 
and it will be forwarded. But it can also be taken to mean "acceptable for 
use" i.e. available to be cross-connected.

 This is clarified later in RFC 3473 section 3.1: Terminator nodes process 
Path messages as usual, with the exception that the upstream label can 
immediately be used to transport data traffic associated with the LSP 
upstream towards the initiator. This is pretty clear. When a Path message 
has been fully processed by an egress node, it is completely safe to 
transmit data toward the ingress (i.e. reverse path data).

  (3) To clarify this assumption (that the these rules are followed) we 
include the following text into the discussion section (section 15)
This document assumes that the correct procedures for installing the data 
plane are followed as described in [RFC3209], [RFC3471], and [RFC3473]. That 
is, that by the time the egress receives and processes a Path message, it is 
safe for the egress to transmit data on the reverse path, and that by the 
time the ingress receives and processes a Resv message it is safe for the 
ingress to transmit data on the forward path. This document does not include 
any verification that the implementations of the control plane software are 
conformant, although such tests could be constructed with the use of 
suitable signal generation test equipment.

 2. During the Dublin meeting, the authors raised the open issue of using 
two way signaling or three way signaling. After some discussions within the 
editor team, an agreement has been reached and the following text was added 
to the discussion section (section 15)

  o Bidirectional LSPs may be setup using three way signaling, where the 
initiate node will send a RESV_CONF message downstream upon receiving the 
RESV message. The RESV_CONF message is used to notify the terminate node 
that it can transfer data upstream. Actually, both directions should be 
ready to transfer data when the RESV message is received by the initiate 
node. Therefore, the bidirectional LSP setup delay defined in this document, 
does not take the confirmation procedure into account.

We thank to Lou, Igor and Adrian for their valuable comments and discussions 
during and after the meeting. The authors would like to have more experts 
from the WG to review this draft. And we hope to request a WG last call 
soon.

 best regards,
 ����������������Guoying Zhang
 ����������������[email-masked]
 ��������������������2008-12-08

Delivery-date: Tue, 09 Dec 2008 10:54:27 +0000
Date: Tue, 09 Dec 2008 11:53:34 +0100
From: Loa Andersson <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: CCAMP drafts for adoption

support for all

/Loa

Adrian Farrel wrote:
> Hi,
> 
> Can you please express your opinion on the adoption of the following
> three drafts as WG drafts.
> 
> Thanks,
> Adrian
> 
> draft-takacs-ccamp-oam-configuration-fwk-01.txt
> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)
> 
> Cheers,
> Adrian and Deborah
> 
> 

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Redback Networks                      phone: +46 8 632 77 14
An Ericsson Company

Delivery-date: Tue, 09 Dec 2008 10:53:22 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lucy Yong" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: comments on the draft of LSP hierarchy
Date: Tue, 9 Dec 2008 10:50:37 -0000

Hi Lucy,

> I study through this draft and appreciate that you specify many necessary
> MLN scenarios that LSP can be used for. Some of them can apply to CTG
> (composite transport group) scenario. Here are some clarification and
> questions:
>
> 1) When LSP is used for Client/Server Network: the server network sets LSP
> as private link with one or more client IGP instances; When LSP is used as
> routing adjacency: the network sets LSP as non-private link with routing
> adjacency. Is this correct?

I think that if the link is private, there is no need and possibly no 
meaning to set a client IGP instance. Setting an IGP instance implies that 
the link is to be advertised in some IGP instance, and a private link will 
not be advertised.

> 2) Should section 2.2 add one more categories: -LSP is used as a component
> link in a link bundle? The doc. is described it but not considers it as
> category.

Good catch.
The overview text was not updated to reflect updates to the main body.
I will update.

> 3) A component link in a link bundle has component link identifier. This
> identifier is the link ID that is advertised in LSA. Is that correct?

Section 2.4 says...

   When an LSP is to be used as a component link of a link bundle, the
   LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how
   the bundle is addressed and used, and a new TLV indicates the
   component link identifier for the link that the LSP creates.

Only the component link identifier is advertised by the IGP. The component 
link identifier is used locally (between link end points), but may also be 
present in an ERO and RRO in signaling with the assumption that this 
inormaiton is coordinated by some other means.

> 4) In section 3.3, it states:
>
>   If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID
>   object is set, the other fields of the object apply to the link
>   bundle itself. That is, the interface identifiers (numbered or
>   unnumbered) and the other flags in the Actions field apply to the
>   link bundle and not to the component link that the LSP will form.
>
>   Furthermore, the IGP Instance Identifier TLV (if present) also
>   applies to the link bundle and not to the component link.
>
> It seems odd way to set actions for link bundle. Should we first set the
> link bundle with the action, then add component link to the link bundle
> without action?

The issue is that the link bundle itself is not signaled. Only the component 
links correspond to LSPs that are signaled. Thus, when the first component 
link is signaled, there is no link bundle in existence.

> 5) LSA should not advertise LSP used as private link. Should this be
> explicitly stated in section 3.4?

OK.
I'll add this to the definition of a private link in section 1.1.3.

> 6) For CTG scenarios, we create a set of LSPs to form a single composite
> link to client/server network. We can first create a composite link as a
> private link with one or more client IGP instances with (at least one
> component link); then individual component link can be added to and 
> removed
> from the composite link. Component links are also private link (different
> from component link in link bundle) and have different TE properties. We 
> can
> also create composite link for routing adjacency (single IGP case). We 
> need
> some extension to cover these scenarios. Could we consider adding this 
> into
> the document?

I believe that the mechanisms in the hierarchy bis draft will be applicable 
to the creation of LSPs that are used as components of CTGs. In my view (as 
an author) it would be premature to add this to the draft at this stage as 
it would create a normative reference to the CTG work which has not yet been 
adopted by any working group and is bound to take some time to complete.

My preferred approach is that the hierarchy bis draft creates the framework 
and a registry of actions carried in the flags field (see section 5.2). Any 
new work, such as your CTG work, can then request the allocation of a 
further bit and can define the behavior if the bit is set.

Cheers,
Adrian 

Delivery-date: Mon, 08 Dec 2008 22:35:01 +0000
Date: Mon, 08 Dec 2008 16:33:29 -0600
From: Lucy Yong <[email-masked]>
Subject: comments on the draft of LSP hierarchy
To: [email-masked], 'Adrian Farrel' <[email-masked]>, [email-masked]

This is a multi-part message in MIME format.

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

Hi Shiomoto and Adrian,

I study through this draft and appreciate that you specify many necessary
MLN scenarios that LSP can be used for. Some of them can apply to CTG
(composite transport group) scenario. Here are some clarification and
questions:

1) When LSP is used for Client/Server Network: the server network sets LSP
as private link with one or more client IGP instances; When LSP is used as
routing adjacency: the network sets LSP as non-private link with routing
adjacency. Is this correct?

2) Should section 2.2 add one more categories: -LSP is used as a component
link in a link bundle? The doc. is described it but not considers it as
category.

3) A component link in a link bundle has component link identifier. This
identifier is the link ID that is advertised in LSA. Is that correct?

4) In section 3.3, it states:

   If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID

   object is set, the other fields of the object apply to the link

   bundle itself. That is, the interface identifiers (numbered or

   unnumbered) and the other flags in the Actions field apply to the

   link bundle and not to the component link that the LSP will form.

   Furthermore, the IGP Instance Identifier TLV (if present) also

   applies to the link bundle and not to the component link.

It seems odd way to set actions for link bundle. Should we first set the
link bundle with the action, then add component link to the link bundle
without action? 

5) LSA should not advertise LSP used as private link. Should this be
explicitly stated in section 3.4?

6) For CTG scenarios, we create a set of LSPs to form a single composite
link to client/server network. We can first create a composite link as a
private link with one or more client IGP instances with (at least one
component link); then individual component link can be added to and removed
from the composite link. Component links are also private link (different
from component link in link bundle) and have different TE properties. We can
also create composite link for routing adjacency (single IGP case). We need
some extension to cover these scenarios. Could we consider adding this into
the document?

Cheers,

Lucy 

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

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

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

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

<div class=Section1>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>Hi Shiomoto and <st1:City w:st="on"><st1:place w:st="on">Adrian</st1:place></st1:City>,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>I study through this draft and appreciate that you specify
many necessary MLN scenarios that LSP can be used for. Some of them can apply
to CTG (composite transport group) scenario. Here are some clarification and
questions:<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>1) When LSP is used for Client/Server Network: the server
network sets LSP as private link with one or more client IGP instances; When
LSP is used as routing adjacency: the network sets LSP as non-private link with
routing adjacency. Is this correct?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>2) Should section 2.2 add one more categories: -LSP is used
as a component link in a link bundle? The doc. is described it but not considers
it as category.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>3) A component link in a link bundle has component link identifier.
This identifier is the link ID that is advertised in LSA. Is that correct?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>4) In section 3.3, it states:<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>&nbsp;&nbsp; If the B-flag in the Actions field of the
LSP_TUNNEL_INTERFACE_ID<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>&nbsp;&nbsp; object is set, the other fields of the object
apply to the link<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>&nbsp;&nbsp; bundle itself. That is, the interface
identifiers (numbered or<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>&nbsp;&nbsp; unnumbered) and the other flags in the Actions
field apply to the<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>&nbsp;&nbsp; link bundle and not to the component link that
the LSP will form.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>&nbsp;&nbsp; Furthermore, the IGP Instance Identifier TLV
(if present) also<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>&nbsp;&nbsp; applies to the link bundle and not to the component
link.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>It seems odd way to set actions for link bundle. Should we
first set the link bundle with the action, then add component link to the link
bundle without action? <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>5) LSA should not advertise LSP used as private link. Should
this be explicitly stated in section 3.4?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>6) For CTG scenarios, we create a set of LSPs to form a
single composite link to client/server network. We can first create a composite
link as a private link with one or more client IGP instances with (at least one
component link); then individual component link can be added to and removed
from the composite link. Component links are also private link (different from
component link in link bundle) and have different TE properties. We can also
create composite link for routing adjacency (single IGP case). We need some extension
to cover these scenarios. Could we consider adding this into the document?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>Cheers,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'>Lucy <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

--Boundary_(ID_G0bW96lybl6woaba+XqNvg)--

Delivery-date: Mon, 08 Dec 2008 02:17:20 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-lsp-dppm-03.txt 
Date: Sun,  7 Dec 2008 18:15:01 -0800 (PST)

--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) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks
	Author(s)       : W. Sun, et al.
	Filename        : draft-ietf-ccamp-lsp-dppm-03.txt
	Pages           : 48
	Date            : 2008-12-04

Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
promising candidate technologies for future data transmission
network.  GMPLS has been developed to control and operate 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 Dynamicly provisioned connections is
increasing because optical networks are being deployed in metro
areas.  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 Dynamic LSP setup/release performance.  These
metrics can depict the features of GMPLS networks 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-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-lsp-dppm-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Sat, 06 Dec 2008 10:59:30 +0000
From: "Post Office" <[email-masked]>
To: [email-masked]
Subject: Returned mail: see transcript for details
Date: Sat, 6 Dec 2008 11:57:44 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_0008_97328B29.D57D50D2
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

------=_NextPart_000_0008_97328B29.D57D50D2
Content-Type: application/octet-stream;
	name="psg.com.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="psg.com.zip"

------=_NextPart_000_0008_97328B29.D57D50D2--

Delivery-date: Fri, 05 Dec 2008 17:02:09 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-rwa-wson-framework-00.txt 
Date: Fri,  5 Dec 2008 09:00:02 -0800 (PST)

--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           : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)
	Author(s)       : G. Bernstein
	Filename        : draft-ietf-ccamp-rwa-wson-framework-00.txt
	Pages           : 37
	Date            : 2008-12-05

This memo provides a framework for applying Generalized Multi-
Protocol Label Switching (GMPLS) and the Path Computation Element 
(PCE) architecture to the control of wavelength switched optical 
networks (WSON).  In particular we provide control plane models for 
key wavelength switched optical network subsystems and processes. The 
subsystems include wavelength division multiplexed links, tunable 
laser transmitters, reconfigurable optical add/drop multiplexers 
(ROADM) and wavelength converters.  

Lightpath provisioning, in general, requires the routing and 
wavelength assignment (RWA) process. This process is reviewed and the 
information requirements, both static and dynamic for this process 
are presented, along with alternative implementation scenarios that 
could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. 
This memo does NOT address optical impairments in any depth and 
focuses on topological elements and path selection constraints that 
are common across different WSON environments.  It is expected that a 
variety of different techniques will be applied to optical 
impairments depending on the type of WSON, such as access, metro or 
long haul.

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

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

--NextPart--

Delivery-date: Thu, 04 Dec 2008 14:57:47 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Thu, 4 Dec 2008 15:55:50 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hello.

I support the 3 of them.

I also think that some of the arguments highlighted by Attila, Igor, =
Dave, Adrian... may deserve to be incorporated in the 1st I-D to avoid =
looping again on this kind of clarification.

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Adrian Farrel

Hi,

Can you please express your opinion on the adoption of the following =
three=20
drafts as WG drafts.

Thanks,
Adrian

draft-takacs-ccamp-oam-configuration-fwk-01.txt
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)

Cheers,
Adrian and Deborah=20

Delivery-date: Thu, 04 Dec 2008 08:06:04 +0000
Date: Thu, 04 Dec 2008 00:03:21 -0800
From: hejia 48726 <[email-masked]>
Subject: Re: CCAMP drafts for adoption
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]

Support All to become WG drafts. 
Thanks!

B.R.
Jia

> 
> ----- Original Message ----- 
> From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, December 02, 2008 10:01 AM
> Subject: CCAMP drafts for adoption
> 
> 
> > Hi,
> > 
> > Can you please express your opinion on the adoption of the 
> following three 
> > drafts as WG drafts.
> > 
> > Thanks,
> > Adrian
> > 
> > draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)
> > 
> > Cheers,
> > Adrian and Deborah 
> > 
> > 
> > 
> >
> 
> 

Delivery-date: Thu, 04 Dec 2008 07:23:37 +0000
Date: Thu, 4 Dec 2008 09:20:34 +0200
From: "peter moore" <[email-masked]>
Subject: Department of Mining

------=_Part_4072_17692769.1228375235127
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

I am Engr. Peter Moore, Director of Project, South Africa Department of
Minerals and Energy. I am making this contact with you based on the
Committee need for an individual/company who is willing to assist us with a
solution to a money transfer.

This amount $28.5m represents the balance of the total contract Value
Executed on behalf of Department by a foreign

contracting firm, which we the officials over-invoiced deliberately, of
which the actual sum has been paid.

Should you be willing to assist us in the transaction Your share of the sum
will be 25% of the $28.5million, 70% for us and 5% for taxation and
miscellaneous expenses.

To enable us commence, I will need your personal telephone/fax number.

I await your immediate response.

Best Regards,

Engr. Moore Pete

------=_Part_4072_17692769.1228375235127
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><font size="3"><font face="Times New Roman">Hi,</font></font></p>
<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><font face="Times New Roman" size="3">&nbsp;</font></p>
<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><font size="3"><font face="Times New Roman">I am Engr. Peter Moore, Director of Project, South Africa Department of Minerals and Energy. I am making this contact with you </font></font><font size="3"><font face="Times New Roman">based on the Committee need for an individual/company who is willing to assist us with a solution to a money transfer.</font></font></p>

<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><font face="Times New Roman" size="3">&nbsp;</font></p>
<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><font size="3"><font face="Times New Roman">This amount $28.5m represents the balance of the total contract Value Executed on behalf of Department by a foreign</font></font></p>

<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><font size="3"><font face="Times New Roman">contracting firm, which we the officials over-invoiced deliberately, of which the actual sum has been paid.</font></font></p>
<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><font face="Times New Roman" size="3">&nbsp;</font></p>
<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><font size="3"><font face="Times New Roman">Should you be willing to assist us in the transaction Your share of the sum will be 25% of the $28.5million, 70% for us and 5% for taxation and miscellaneous expenses.</font></font></p>

<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><font size="3"><font face="Times New Roman">To enable us commence, I will need your personal telephone/fax number.</font></font></p>
<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><font face="Times New Roman" size="3">&nbsp;</font></p>
<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><font size="3"><font face="Times New Roman">I await your immediate response.</font></font></p>
<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><font size="3"><font face="Times New Roman">Best Regards,</font></font></p>
<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><font face="Times New Roman" size="3">&nbsp;</font></p>
<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><font face="Times New Roman" size="3">Engr. Moore Pete</font></p>

------=_Part_4072_17692769.1228375235127--

Delivery-date: Thu, 04 Dec 2008 01:36:18 +0000
Date: Thu, 04 Dec 2008 10:34:00 +0900
From: "Ogaki, Kenichi" <[email-masked]>
To: [email-masked]
Subject: Re: CCAMP drafts for adoption

Hi,

Yes to All.

Kenichi

Adrian Farrel wrote:
> Hi,
>
> Can you please express your opinion on the adoption of the following 
> three drafts as WG drafts.
>
> Thanks,
> Adrian
>
> draft-takacs-ccamp-oam-configuration-fwk-01.txt
> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)
>
> Cheers,
> Adrian and Deborah
>
>
>

Delivery-date: Wed, 03 Dec 2008 19:21:01 +0000
Date: Wed, 3 Dec 2008 14:19:35 -0500
From: "Greg Mirsky" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Subject: Re: CCAMP drafts for adoption
Cc: [email-masked]

------=_Part_13614_6381331.1228331975178
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Support oam-configuration and eth-oam
Abstain wson-encode

Regards,
Greg

On Tue, Dec 2, 2008 at 11:01 AM, Adrian Farrel <[email-masked]> wrote:

> Hi,
>
> Can you please express your opinion on the adoption of the following three
> drafts as WG drafts.
>
> Thanks,
> Adrian
>
> draft-takacs-ccamp-oam-configuration-fwk-01.txt
> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)
>
> Cheers,
> Adrian and Deborah
>
>
>

------=_Part_13614_6381331.1228331975178
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Support oam-configuration and eth-oam<br>Abstain wson-encode<br><br>Regards,<br>Greg<br><br><div class="gmail_quote">On Tue, Dec 2, 2008 at 11:01 AM, Adrian Farrel <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
<br>
Can you please express your opinion on the adoption of the following three drafts as WG drafts.<br>
<br>
Thanks,<br>
Adrian<br>
<br>
draft-takacs-ccamp-oam-configuration-fwk-01.txt<br>
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt<br>
draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)<br>
<br>
Cheers,<br>
Adrian and Deborah <br>
<br>
<br>
</blockquote></div><br>

------=_Part_13614_6381331.1228331975178--

Delivery-date: Wed, 03 Dec 2008 15:42:50 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Wed, 3 Dec 2008 07:41:43 -0800
From: "Drake, John E" <[email-masked]>
To: "Attila Takacs" <[email-masked]>, "Nitin Bahadur" <[email-masked]>, <[email-masked]>

Attila,

Very well put.  I think I-Ds in question should become working group
drafts.

Thanks,

John=20

>-----Original Message-----
>From: Attila Takacs [mailto:[email-masked]]=20
>Sent: Wednesday, December 03, 2008 7:28 AM
>To: Nitin Bahadur; [email-masked]
>Subject: RE: CCAMP drafts for adoption
>
>Hi Nitin,=20
>
>>=20
>> If you add a new-TLV to the PATH msg, then you need to send it on=20
>> every PATH msg...
>> You really need to signal the parameters once during LSP-setup time=20
>> (and perhaps when the parameters are changed).
>>=20
>
>There are some options here.=20
>
>First it has clear benefits to have the OAM config bound to=20
>the Path message and so to the actual LSP establishment as=20
>this ensures that the connection and its OAM is coupled. This=20
>is something you cannot ensure with LSP Ping.
>
>Alternatively, if one just wants to configure MEPs one may=20
>carry the proposed TLVs as part of Call establishment, this=20
>way only the endpoints will take part in signaling.
>
>On the other hand, if one needs to configure MIPs, the=20
>signaling needs to pass intermediate nodes hence the need to=20
>use the Path message is obvious.
>
>> LSP-Ping has a whole bunch of stuff defined. Most of it is not=20
>> needed/applicable in various scenarios. But the advantage is=20
>that it's=20
>> all there. As you go ahead with defining a new mechanism, you will=20
>> gradually see other requirements/needs and you might end up=20
>> re-inventing lsp-ping in another form.
>>=20
>
>How would you configure MIPs with LSP Ping? I assume you would=20
>need to use at least as many transactions (and as such have as=20
>many failure
>scenarios) as many intermediate nodes the LSP has. (Not to=20
>mention that you need to get the list of intermediate nodes=20
>and the info on the success/failure of LSP establishment from=20
>another protocol.)
>
>Compare this to a single Path message in the case of RSVP-TE.
>
>Best regards,
>Attila
>
>
>
>
>> > Best regards,
>> > Attila
>> >=20
>> >=20
>> >=20
>> >=20
>> > > -----Original Message-----
>> > > From: Nitin Bahadur [mailto:[email-masked]]
>> > > Sent: Tuesday, December 02, 2008 11:01 PM
>> > > To: Attila Takacs; Adrian Farrel; [email-masked]
>> > > Subject: RE: CCAMP drafts for adoption
>> > >=20
>> > >=20
>> > > Hi Attlia,
>> > >=20
>> > >    What is the limitation of lsp-ping that prevents it=20
>from being=20
>> > > applied to GMPLS?
>> > > If an existing mechanism can be applied, then why not? If
>> lsp-ping
>> > > needs extensions to support GMPLS LSPs, feel free to=20
>make/specify=20
>> > > those extensions.
>> > >=20
>> > > Thanks
>> > > Nitin
>> > >=20
>> > > > -----Original Message-----
>> > > > From: Attila Takacs [mailto:[email-masked]]
>> > > > Sent: Tuesday, December 02, 2008 1:52 PM
>> > > > To: Nitin Bahadur; Adrian Farrel; [email-masked]
>> > > > Subject: RE: CCAMP drafts for adoption
>> > > >=20
>> > > > Hi Nitin,
>> > > >=20
>> > > > Please note that these mechanisms are proposed for GMPLS
>> > > and as such
>> > > > to provide support for any data plane technology specific OAM=20
>> > > > mechanism. As you noted LSP Ping is for MPLS and BFD only.
>> > > >=20
>> > > > Best regards,
>> > > > Attila
>> > > >=20
>> > > > > -----Original Message-----
>> > > > > From: [email-masked]=20
>> > > > > [mailto:[email-masked]] On Behalf Of Nitin Bahadur
>> > > > > Sent: Tuesday, December 02, 2008 10:35 PM
>> > > > > To: Adrian Farrel; [email-masked]
>> > > > > Subject: RE: CCAMP drafts for adoption
>> > > > >=20
>> > > > >=20
>> > > > >=20
>> > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt
>> > > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
>> > > > >=20
>> > > > > Do not support either of these.
>> > > > >=20
>> > > > > From the oam-config-fwk draft:
>> > > > > > A new useful application of RSVP-TE is OAM configuration
>> > > > > and control
>> > > > > > for transport networks.
>> > > > >=20
>> > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20
>> > > Why do we
>> > > > > need another mechanism? What are the limitations of
>> > lsp-ping that
>> > > > > warrant this new mechanism?
>> > > > >=20
>> > > > > > When RSVP-TE is used for LSP establishment it is desirable
>> > > > > to bind OAM
>> > > > > > setup to connection establishment signalling to avoid two
>> > > > separate
>> > > > > > management/configuration steps
>> > > > >=20
>> > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for
>> > > > automatic setup
>> > > > > of BFD-based OAM.
>> > > > > We should go along the same path for Ethernet OAM.
>> > > > >=20
>> > > > > Thanks
>> > > > > Nitin
>> > > > >=20
>> > > > >=20
>> > > >=20
>> > >=20
>> >=20
>>=20
>
>

Delivery-date: Wed, 03 Dec 2008 15:42:42 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Wed, 3 Dec 2008 07:41:43 -0800
From: "Drake, John E" <[email-masked]>
To: "Attila Takacs" <[email-masked]>, "Nitin Bahadur" <[email-masked]>, <[email-masked]>

Attila,

Very well put.  I think I-Ds in question should become working group
drafts.

Thanks,

John=20

>-----Original Message-----
>From: Attila Takacs [mailto:[email-masked]]=20
>Sent: Wednesday, December 03, 2008 7:28 AM
>To: Nitin Bahadur; [email-masked]
>Subject: RE: CCAMP drafts for adoption
>
>Hi Nitin,=20
>
>>=20
>> If you add a new-TLV to the PATH msg, then you need to send it on=20
>> every PATH msg...
>> You really need to signal the parameters once during LSP-setup time=20
>> (and perhaps when the parameters are changed).
>>=20
>
>There are some options here.=20
>
>First it has clear benefits to have the OAM config bound to=20
>the Path message and so to the actual LSP establishment as=20
>this ensures that the connection and its OAM is coupled. This=20
>is something you cannot ensure with LSP Ping.
>
>Alternatively, if one just wants to configure MEPs one may=20
>carry the proposed TLVs as part of Call establishment, this=20
>way only the endpoints will take part in signaling.
>
>On the other hand, if one needs to configure MIPs, the=20
>signaling needs to pass intermediate nodes hence the need to=20
>use the Path message is obvious.
>
>> LSP-Ping has a whole bunch of stuff defined. Most of it is not=20
>> needed/applicable in various scenarios. But the advantage is=20
>that it's=20
>> all there. As you go ahead with defining a new mechanism, you will=20
>> gradually see other requirements/needs and you might end up=20
>> re-inventing lsp-ping in another form.
>>=20
>
>How would you configure MIPs with LSP Ping? I assume you would=20
>need to use at least as many transactions (and as such have as=20
>many failure
>scenarios) as many intermediate nodes the LSP has. (Not to=20
>mention that you need to get the list of intermediate nodes=20
>and the info on the success/failure of LSP establishment from=20
>another protocol.)
>
>Compare this to a single Path message in the case of RSVP-TE.
>
>Best regards,
>Attila
>
>
>
>
>> > Best regards,
>> > Attila
>> >=20
>> >=20
>> >=20
>> >=20
>> > > -----Original Message-----
>> > > From: Nitin Bahadur [mailto:[email-masked]]
>> > > Sent: Tuesday, December 02, 2008 11:01 PM
>> > > To: Attila Takacs; Adrian Farrel; [email-masked]
>> > > Subject: RE: CCAMP drafts for adoption
>> > >=20
>> > >=20
>> > > Hi Attlia,
>> > >=20
>> > >    What is the limitation of lsp-ping that prevents it=20
>from being=20
>> > > applied to GMPLS?
>> > > If an existing mechanism can be applied, then why not? If
>> lsp-ping
>> > > needs extensions to support GMPLS LSPs, feel free to=20
>make/specify=20
>> > > those extensions.
>> > >=20
>> > > Thanks
>> > > Nitin
>> > >=20
>> > > > -----Original Message-----
>> > > > From: Attila Takacs [mailto:[email-masked]]
>> > > > Sent: Tuesday, December 02, 2008 1:52 PM
>> > > > To: Nitin Bahadur; Adrian Farrel; [email-masked]
>> > > > Subject: RE: CCAMP drafts for adoption
>> > > >=20
>> > > > Hi Nitin,
>> > > >=20
>> > > > Please note that these mechanisms are proposed for GMPLS
>> > > and as such
>> > > > to provide support for any data plane technology specific OAM=20
>> > > > mechanism. As you noted LSP Ping is for MPLS and BFD only.
>> > > >=20
>> > > > Best regards,
>> > > > Attila
>> > > >=20
>> > > > > -----Original Message-----
>> > > > > From: [email-masked]=20
>> > > > > [mailto:[email-masked]] On Behalf Of Nitin Bahadur
>> > > > > Sent: Tuesday, December 02, 2008 10:35 PM
>> > > > > To: Adrian Farrel; [email-masked]
>> > > > > Subject: RE: CCAMP drafts for adoption
>> > > > >=20
>> > > > >=20
>> > > > >=20
>> > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt
>> > > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
>> > > > >=20
>> > > > > Do not support either of these.
>> > > > >=20
>> > > > > From the oam-config-fwk draft:
>> > > > > > A new useful application of RSVP-TE is OAM configuration
>> > > > > and control
>> > > > > > for transport networks.
>> > > > >=20
>> > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20
>> > > Why do we
>> > > > > need another mechanism? What are the limitations of
>> > lsp-ping that
>> > > > > warrant this new mechanism?
>> > > > >=20
>> > > > > > When RSVP-TE is used for LSP establishment it is desirable
>> > > > > to bind OAM
>> > > > > > setup to connection establishment signalling to avoid two
>> > > > separate
>> > > > > > management/configuration steps
>> > > > >=20
>> > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for
>> > > > automatic setup
>> > > > > of BFD-based OAM.
>> > > > > We should go along the same path for Ethernet OAM.
>> > > > >=20
>> > > > > Thanks
>> > > > > Nitin
>> > > > >=20
>> > > > >=20
>> > > >=20
>> > >=20
>> >=20
>>=20
>
>

Delivery-date: Wed, 03 Dec 2008 15:42:30 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Wed, 3 Dec 2008 07:41:43 -0800
From: "Drake, John E" <[email-masked]>
To: "Attila Takacs" <[email-masked]>, "Nitin Bahadur" <[email-masked]>, <[email-masked]>

Attila,

Very well put.  I think I-Ds in question should become working group
drafts.

Thanks,

John=20

>-----Original Message-----
>From: Attila Takacs [mailto:[email-masked]]=20
>Sent: Wednesday, December 03, 2008 7:28 AM
>To: Nitin Bahadur; [email-masked]
>Subject: RE: CCAMP drafts for adoption
>
>Hi Nitin,=20
>
>>=20
>> If you add a new-TLV to the PATH msg, then you need to send it on=20
>> every PATH msg...
>> You really need to signal the parameters once during LSP-setup time=20
>> (and perhaps when the parameters are changed).
>>=20
>
>There are some options here.=20
>
>First it has clear benefits to have the OAM config bound to=20
>the Path message and so to the actual LSP establishment as=20
>this ensures that the connection and its OAM is coupled. This=20
>is something you cannot ensure with LSP Ping.
>
>Alternatively, if one just wants to configure MEPs one may=20
>carry the proposed TLVs as part of Call establishment, this=20
>way only the endpoints will take part in signaling.
>
>On the other hand, if one needs to configure MIPs, the=20
>signaling needs to pass intermediate nodes hence the need to=20
>use the Path message is obvious.
>
>> LSP-Ping has a whole bunch of stuff defined. Most of it is not=20
>> needed/applicable in various scenarios. But the advantage is=20
>that it's=20
>> all there. As you go ahead with defining a new mechanism, you will=20
>> gradually see other requirements/needs and you might end up=20
>> re-inventing lsp-ping in another form.
>>=20
>
>How would you configure MIPs with LSP Ping? I assume you would=20
>need to use at least as many transactions (and as such have as=20
>many failure
>scenarios) as many intermediate nodes the LSP has. (Not to=20
>mention that you need to get the list of intermediate nodes=20
>and the info on the success/failure of LSP establishment from=20
>another protocol.)
>
>Compare this to a single Path message in the case of RSVP-TE.
>
>Best regards,
>Attila
>
>
>
>
>> > Best regards,
>> > Attila
>> >=20
>> >=20
>> >=20
>> >=20
>> > > -----Original Message-----
>> > > From: Nitin Bahadur [mailto:[email-masked]]
>> > > Sent: Tuesday, December 02, 2008 11:01 PM
>> > > To: Attila Takacs; Adrian Farrel; [email-masked]
>> > > Subject: RE: CCAMP drafts for adoption
>> > >=20
>> > >=20
>> > > Hi Attlia,
>> > >=20
>> > >    What is the limitation of lsp-ping that prevents it=20
>from being=20
>> > > applied to GMPLS?
>> > > If an existing mechanism can be applied, then why not? If
>> lsp-ping
>> > > needs extensions to support GMPLS LSPs, feel free to=20
>make/specify=20
>> > > those extensions.
>> > >=20
>> > > Thanks
>> > > Nitin
>> > >=20
>> > > > -----Original Message-----
>> > > > From: Attila Takacs [mailto:[email-masked]]
>> > > > Sent: Tuesday, December 02, 2008 1:52 PM
>> > > > To: Nitin Bahadur; Adrian Farrel; [email-masked]
>> > > > Subject: RE: CCAMP drafts for adoption
>> > > >=20
>> > > > Hi Nitin,
>> > > >=20
>> > > > Please note that these mechanisms are proposed for GMPLS
>> > > and as such
>> > > > to provide support for any data plane technology specific OAM=20
>> > > > mechanism. As you noted LSP Ping is for MPLS and BFD only.
>> > > >=20
>> > > > Best regards,
>> > > > Attila
>> > > >=20
>> > > > > -----Original Message-----
>> > > > > From: [email-masked]=20
>> > > > > [mailto:[email-masked]] On Behalf Of Nitin Bahadur
>> > > > > Sent: Tuesday, December 02, 2008 10:35 PM
>> > > > > To: Adrian Farrel; [email-masked]
>> > > > > Subject: RE: CCAMP drafts for adoption
>> > > > >=20
>> > > > >=20
>> > > > >=20
>> > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt
>> > > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
>> > > > >=20
>> > > > > Do not support either of these.
>> > > > >=20
>> > > > > From the oam-config-fwk draft:
>> > > > > > A new useful application of RSVP-TE is OAM configuration
>> > > > > and control
>> > > > > > for transport networks.
>> > > > >=20
>> > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20
>> > > Why do we
>> > > > > need another mechanism? What are the limitations of
>> > lsp-ping that
>> > > > > warrant this new mechanism?
>> > > > >=20
>> > > > > > When RSVP-TE is used for LSP establishment it is desirable
>> > > > > to bind OAM
>> > > > > > setup to connection establishment signalling to avoid two
>> > > > separate
>> > > > > > management/configuration steps
>> > > > >=20
>> > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for
>> > > > automatic setup
>> > > > > of BFD-based OAM.
>> > > > > We should go along the same path for Ethernet OAM.
>> > > > >=20
>> > > > > Thanks
>> > > > > Nitin
>> > > > >=20
>> > > > >=20
>> > > >=20
>> > >=20
>> >=20
>>=20
>
>

Delivery-date: Wed, 03 Dec 2008 15:40:26 +0000
Date: Wed, 03 Dec 2008 09:39:34 -0600
From: Rebecca Han <[email-masked]>
Subject: Re: CCAMP drafts for adoption
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]

Support all to become WG documents.

Rebecca Han

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, December 02, 2008 10:01 AM
Subject: CCAMP drafts for adoption

> Hi,
> 
> Can you please express your opinion on the adoption of the following three 
> drafts as WG drafts.
> 
> Thanks,
> Adrian
> 
> draft-takacs-ccamp-oam-configuration-fwk-01.txt
> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)
> 
> Cheers,
> Adrian and Deborah 
> 
> 
> 
>

Delivery-date: Wed, 03 Dec 2008 15:30:53 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Wed, 3 Dec 2008 16:28:00 +0100
From: "Attila Takacs" <[email-masked]>
To: "Nitin Bahadur" <[email-masked]>, <[email-masked]>

Hi Nitin,=20

>=20
> If you add a new-TLV to the PATH msg, then you need to send=20
> it on every PATH msg...
> You really need to signal the parameters once during=20
> LSP-setup time (and perhaps when the parameters are changed).
>=20

There are some options here.=20

First it has clear benefits to have the OAM config bound to the Path
message and so to the actual LSP establishment as this ensures that the
connection and its OAM is coupled. This is something you cannot ensure
with LSP Ping.

Alternatively, if one just wants to configure MEPs one may carry the
proposed TLVs as part of Call establishment, this way only the endpoints
will take part in signaling.

On the other hand, if one needs to configure MIPs, the signaling needs
to pass intermediate nodes hence the need to use the Path message is
obvious.

> LSP-Ping has a whole bunch of stuff defined. Most of it is=20
> not needed/applicable in various scenarios. But the advantage=20
> is that it's all there. As you go ahead with defining a new=20
> mechanism, you will gradually see other requirements/needs=20
> and you might end up re-inventing lsp-ping in another form.
>=20

How would you configure MIPs with LSP Ping? I assume you would need to
use at least as many transactions (and as such have as many failure
scenarios) as many intermediate nodes the LSP has. (Not to mention that
you need to get the list of intermediate nodes and the info on the
success/failure of LSP establishment from another protocol.)

Compare this to a single Path message in the case of RSVP-TE.

Best regards,
Attila

> > Best regards,
> > Attila
> >=20
> >=20
> >=20
> >=20
> > > -----Original Message-----
> > > From: Nitin Bahadur [mailto:[email-masked]]
> > > Sent: Tuesday, December 02, 2008 11:01 PM
> > > To: Attila Takacs; Adrian Farrel; [email-masked]
> > > Subject: RE: CCAMP drafts for adoption
> > >=20
> > >=20
> > > Hi Attlia,
> > >=20
> > >    What is the limitation of lsp-ping that prevents it from being=20
> > > applied to GMPLS?
> > > If an existing mechanism can be applied, then why not? If=20
> lsp-ping=20
> > > needs extensions to support GMPLS LSPs, feel free to make/specify=20
> > > those extensions.
> > >=20
> > > Thanks
> > > Nitin
> > >=20
> > > > -----Original Message-----
> > > > From: Attila Takacs [mailto:[email-masked]]
> > > > Sent: Tuesday, December 02, 2008 1:52 PM
> > > > To: Nitin Bahadur; Adrian Farrel; [email-masked]
> > > > Subject: RE: CCAMP drafts for adoption
> > > >=20
> > > > Hi Nitin,
> > > >=20
> > > > Please note that these mechanisms are proposed for GMPLS
> > > and as such
> > > > to provide support for any data plane technology specific OAM=20
> > > > mechanism. As you noted LSP Ping is for MPLS and BFD only.
> > > >=20
> > > > Best regards,
> > > > Attila
> > > >=20
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]] On Behalf Of Nitin Bahadur
> > > > > Sent: Tuesday, December 02, 2008 10:35 PM
> > > > > To: Adrian Farrel; [email-masked]
> > > > > Subject: RE: CCAMP drafts for adoption
> > > > >=20
> > > > >=20
> > > > >=20
> > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> > > > >=20
> > > > > Do not support either of these.
> > > > >=20
> > > > > From the oam-config-fwk draft:
> > > > > > A new useful application of RSVP-TE is OAM configuration
> > > > > and control
> > > > > > for transport networks.
> > > > >=20
> > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20
> > > Why do we
> > > > > need another mechanism? What are the limitations of
> > lsp-ping that
> > > > > warrant this new mechanism?
> > > > >=20
> > > > > > When RSVP-TE is used for LSP establishment it is desirable
> > > > > to bind OAM
> > > > > > setup to connection establishment signalling to avoid two
> > > > separate
> > > > > > management/configuration steps
> > > > >=20
> > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for
> > > > automatic setup
> > > > > of BFD-based OAM.
> > > > > We should go along the same path for Ethernet OAM.
> > > > >=20
> > > > > Thanks
> > > > > Nitin
> > > > >=20
> > > > >=20
> > > >=20
> > >=20
> >=20
>=20

Delivery-date: Wed, 03 Dec 2008 14:42:38 +0000
Date: Wed, 3 Dec 2008 06:42:15 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: Re: CCAMP drafts for adoption
To: David Allan <[email-masked]>, Nitin Bahadur <[email-masked]>, [email-masked]

--0-680914809-1228315335=:39765
Content-Type: text/plain; charset=us-ascii

Dave,

I completely agree with you. For me, as a GMPLS vendor, it would be very easy to add a couple of objects to GMPLS RSVP ( by the way, I also agree that GMPLS RSVP is very, very different from IP/MPLS RSVP-TE) so that I could automate OAM configuration. To add LSP Ping to my GMPLS offering is a completely diffirent scale of effort, and  I believe, there should be reasons for this much more serious than the fact this could be also done using some existing IP/MPLS technology which so far was never part of my solution.

On more general note, I think, it would be a good idea to agree within the CCAMP WG what is it, actually, GMPLS? Specifically, which components of IP/MPLS control plane belong to GMPLS, which do not, and which parts of GMPLS are specific to transport networks and have nothing to do with IP/MPLS. For instance, does LSP Ping belong to GMPLS? How about BGP? LDP? If the answer is yes, than which production GMPLS deployments feature them? I think after 8 years of working on GMPLS we can answer these questions. If the answer is no, that let's solve transport network control plane problems within existing GMPLS framework.

Igor

________________________________
From: David Allan <[email-masked]>
To: Nitin Bahadur <[email-masked]>; [email-masked]
Sent: Tuesday, December 2, 2008 7:40:55 PM
Subject: RE: CCAMP drafts for adoption

Hi Nitin:

My reaction is that spreading state over a number of protocols may keep
one superficially simple but drives up the total cost of the
solution...from the POV of lines of code, amount to test, amount of
state, additional race conditions, delayed setup time etc. so is a
specious optimization....

If the path is not up until OAM says so, it is useful to get there in as
few transactions as possible...

My 2 cents.
Dave

-----Original Message-----
From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2008 6:38 PM
To: Allan, David (CAR:NS00); [email-masked]
Subject: RE: CCAMP drafts for adoption

Hi David,

> > David, all that I am asking is that one can use the basic-bare-bones
> definitions in lsp-ping to setup the Ethernet OAM
> > params. I am not talking about applicability nor I am
> saying that one
> needs to use ping and trace based off lsp-ping for > PBB-TE LSPs. 
> 
> But this still requires implementing a new protocol where it does not 
> already exist,

I agree. It does require implementing lsp-ping. But the way these 2
drafts are going, they will end up defining a new
mini-oam-boot-strapping protocol on top of RSVP path messages. And once
we have a precedence, it will just keep growing. I am basically against
using RSVP path message as an OAM related PDU transfer agent. The drafts
already specify 3-4 sub-TLVs and a bunch of error codes. This list can
grow. The framework draft is generic in nature. So tomorrrow I can use
BFD or XXX on top of RSVP (why just ethernet-oam) and I can add 10 more
TLVs and 5 more error codes.

It's all about keeping RSVP clean. Your requirement is to automate OAM
on a GMPLS LSP. Why dirty this poor Path msg.

If you do not wish to use Lsp-ping (for whatever reason)...I recommend
using something other than a RSVP path msg.

> which also requires a *new* bare
> bones definition...

I think that would be easy. You just need to send the lsp-ping msg along
the control-plane. The LSP details can be put in the existing defined
TLVs. The ethernet OAM details can be directly copied from these new
drafts into a lsp-ping based draft.

> <snipped>
> 
> > I am not asking you to use lsp-ping for LB/LT. I agree that ethernet
> OAM already has that and indeed once should use
> > that. I am just saying that the setup can be done using lsp-ping.
> 
> I think the point was GMPLS applies to a lot of technologies that 
> cannot do LSP-PING in the first place, which means such a signalling 
> extension will be required nonetheless...

As I said earlier, use LSP-Ping not for OAM, but for signaling the OAM
params.
Given that you are using RSVP for signaling the GMPLS LSP via the
control plane, you can use LSP-Ping (via control plane) to do the OAM
signaling.

> can I suggest you
> withdraw your objections to the Eth-Oam draft and move the TP parts of

> this discussion over to the MPLS list?

My main objections to the Eth-oam drafts are not TP related. 
They are related to using RSVP Path as a transmission mechanism for OAM
setup. OAM is complex and tomorrow we might need more TLVs to indicate
remote failure or some other condition via the control plane. 
Dave, you are the co-author of draft-ietf-pwe3-oam-msg-map. Look at the
amount of stuff that has gone in there.

As a side-note, I am just *a person*. It's the ccamp wg mailing list
that needs to say *yes*/*no*. It's all rough consensus right?

Thanks
Nitin

--0-680914809-1228315335=:39765
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Dave,<br><br>I completely agree with you. For me, as a GMPLS vendor, it would be very easy to add a couple of objects to GMPLS RSVP ( by the way, I also agree that GMPLS RSVP is very, very different from IP/MPLS RSVP-TE) so that I could automate OAM configuration. To add LSP Ping to my GMPLS offering is a completely diffirent scale of effort, and&nbsp; I believe, there should be reasons for this much more serious than the fact this could be also done using some existing IP/MPLS technology which so far was never part of my solution.<br><br>On more general note, I think, it would be a good idea to agree within the CCAMP WG what is it, actually, GMPLS? Specifically, which components of IP/MPLS control plane belong to GMPLS, which do not, and which parts of GMPLS are specific to transport networks
 and have nothing to do with IP/MPLS. For instance, does LSP Ping belong to GMPLS? How about BGP? LDP? If the answer is yes, than which production GMPLS deployments feature them? I think after 8 years of working on GMPLS we can answer these questions. If the answer is no, that let's solve transport network control plane problems within existing GMPLS framework.<br><br>Igor<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> David Allan &lt;[email-masked]&gt;<br><b><span style="font-weight: bold;">To:</span></b> Nitin Bahadur &lt;[email-masked]&gt;; [email-masked]<br><b><span style="font-weight: bold;">Sent:</span></b> Tuesday, December 2, 2008 7:40:55 PM<br><b><span style="font-weight: bold;">Subject:</span></b> RE: CCAMP drafts for
 adoption<br></font><br>
Hi Nitin:<br><br>My reaction is that spreading state over a number of protocols may keep<br>one superficially simple but drives up the total cost of the<br>solution...from the POV of lines of code, amount to test, amount of<br>state, additional race conditions, delayed setup time etc. so is a<br>specious optimization....<br><br>If the path is not up until OAM says so, it is useful to get there in as<br>few transactions as possible...<br><br>My 2 cents.<br>Dave<br><br><br><br> <br><br>-----Original Message-----<br>From: Nitin Bahadur [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>] <br>Sent: Tuesday, December 02, 2008 6:38 PM<br>To: Allan, David (CAR:NS00); <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>Subject: RE: CCAMP drafts for adoption<br><br><br>Hi David,<br><br>&gt; &gt; David, all that I am asking is that one can use the
 basic-bare-bones<br>&gt; definitions in lsp-ping to setup the Ethernet OAM<br>&gt; &gt; params. I am not talking about applicability nor I am<br>&gt; saying that one<br>&gt; needs to use ping and trace based off lsp-ping for &gt; PBB-TE LSPs. <br>&gt; <br>&gt; But this still requires implementing a new protocol where it does not <br>&gt; already exist,<br><br>I agree. It does require implementing lsp-ping. But the way these 2<br>drafts are going, they will end up defining a new<br>mini-oam-boot-strapping protocol on top of RSVP path messages. And once<br>we have a precedence, it will just keep growing. I am basically against<br>using RSVP path message as an OAM related PDU transfer agent. The drafts<br>already specify 3-4 sub-TLVs and a bunch of error codes. This list can<br>grow. The framework draft is generic in nature. So tomorrrow I can use<br>BFD or XXX on top of RSVP (why just ethernet-oam) and I can add 10 more<br>TLVs and 5 more error
 codes.<br><br>It's all about keeping RSVP clean. Your requirement is to automate OAM<br>on a GMPLS LSP. Why dirty this poor Path msg.<br><br>If you do not wish to use Lsp-ping (for whatever reason)...I recommend<br>using something other than a RSVP path msg.<br><br>&gt; which also requires a *new* bare<br>&gt; bones definition...<br><br>I think that would be easy. You just need to send the lsp-ping msg along<br>the control-plane. The LSP details can be put in the existing defined<br>TLVs. The ethernet OAM details can be directly copied from these new<br>drafts into a lsp-ping based draft.<br><br>&gt; &lt;snipped&gt;<br>&gt; <br>&gt; &gt; I am not asking you to use lsp-ping for LB/LT. I agree that ethernet<br>&gt; OAM already has that and indeed once should use<br>&gt; &gt; that. I am just saying that the setup can be done using lsp-ping.<br>&gt; <br>&gt; I think the point was GMPLS applies to a lot of technologies that <br>&gt; cannot do LSP-PING in the
 first place, which means such a signalling <br>&gt; extension will be required nonetheless...<br><br>As I said earlier, use LSP-Ping not for OAM, but for signaling the OAM<br>params.<br>Given that you are using RSVP for signaling the GMPLS LSP via the<br>control plane, you can use LSP-Ping (via control plane) to do the OAM<br>signaling.<br><br>&gt; can I suggest you<br>&gt; withdraw your objections to the Eth-Oam draft and move the TP parts of<br><br>&gt; this discussion over to the MPLS list?<br><br>My main objections to the Eth-oam drafts are not TP related. <br>They are related to using RSVP Path as a transmission mechanism for OAM<br>setup. OAM is complex and tomorrow we might need more TLVs to indicate<br>remote failure or some other condition via the control plane. <br>Dave, you are the co-author of draft-ietf-pwe3-oam-msg-map. Look at the<br>amount of stuff that has gone in there.<br><br>As a side-note, I am just *a person*. It's the ccamp wg
 mailing list<br>that needs to say *yes*/*no*. It's all rough consensus right?<br><br>Thanks<br>Nitin<br><br></div></div></div><br>

      </body></html>
--0-680914809-1228315335=:39765--

Delivery-date: Wed, 03 Dec 2008 14:38:37 +0000
Date: Wed, 03 Dec 2008 09:36:59 -0500
To: "Thomas D. Nadeau" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: CCAMP drafts for adoption
Cc: David Allan <[email-masked]>,Nitin Bahadur <[email-masked]>, <[email-masked]>

Tom,
         You might want to look at what's happening with OAM for TP, 
it != LSP Ping.  As TP is currently drafted, Attila's documents will 
make more sense than LSP ping.

Lou

At 06:41 PM 12/2/2008, Thomas D. Nadeau wrote:

>     Dave,
>
>     As an operator with a very big deployment of MPLS and a lot of money
>invested in OSS to manage said network, I do not want a different mechanism
>to the one that has been deployed today to control OAM for any MPLS
>networks, MPLS-TP included.
>
>     --Tom
>
>
>
>On 12/2/08 6:01 PM, "David Allan" <[email-masked]> wrote:
>
> > HI Nitin:
> >
> > Thanks for replying....
> > <snipped>
> >
> >> David, all that I am asking is that one can use the basic-bare-bones
> > definitions in lsp-ping to setup the Ethernet OAM
> >> params. I am not talking about applicability nor I am saying that one
> > needs to use ping and trace based off lsp-ping for > PBB-TE LSPs.
> >
> > But this still requires implementing a new protocol where it does not
> > already exist, which also requires a *new* bare bones definition...
> >
> >> We have a whole bunch of stuff defined in RSVP. Obviously some of them
> > are not applicable for GMPLS LSPs. But that does > not mean that we go
> > define G-RSVP (for GMPLS LSPs).
> >
> > Isn't that CCAMPs mandate?
> >
> > <snipped>
> >
> >> I am not asking you to use lsp-ping for LB/LT. I agree that ethernet
> > OAM already has that and indeed once should use
> >> that. I am just saying that the setup can be done using lsp-ping.
> >
> > I think the point was GMPLS applies to a lot of technologies that cannot
> > do LSP-PING in the first place, which means such a signalling extension
> > will be required nonetheless...
> >
> > <snipped>
> >> LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping
> > has a reply-mode of *application channel* which can > be used for things
> > like bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies
> > would go on the LSP reverse path > (label-switched and not IP
> > forwarded).
> >
> > OK, I can see that such an approach could be made to work and would be
> > desirable to some. On that basis, can I suggest you withdraw your
> > objections to the Eth-Oam draft and move the TP parts of this discussion
> > over to the MPLS list? That would seem appropriate...
> >
> > Cheers
> > Dave
> >
> >

Delivery-date: Wed, 03 Dec 2008 13:05:30 +0000
Date: Wed, 3 Dec 2008 14:04:42 +0100
From: "Francesco Fondelli" <[email-masked]>
To: "Nitin Bahadur" <[email-masked]>
Subject: Re: CCAMP drafts for adoption
Cc: "Adrian Farrel" <[email-masked]>, [email-masked]

On Tue, Dec 2, 2008 at 10:35 PM, Nitin Bahadur <[email-masked]> wrote:
>
>
>> > draft-takacs-ccamp-oam-configuration-fwk-01.txt
>> > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
>
> Do not support either of these.

Given this statement

a)
--- draft-ietf-mpls-tp-framework-00 ---
The MPLS-TP control plane is based on a combination of
the MPLS control plane for pseudowires and the GMPLS
control plane for MPLS-TP LSPs, respectively.  More
specifically, LDP is used for PW signaling and
*GMPLS based RSVP-TE for LSP signaling*.
---

and this requirement

b)
--- draft-ietf-mpls-tp-requirements-00 --
The MPLS-TP control pane MUST support the configuration
and modification of OAM maintenance points as well as
the activation/deactivation of OAM *when the transport
path is established or modified*.
---

RSVP-TE is the tool that has to be used for OAM
configuration in a MPLS-TP context, IMHO.

Above I-Ds are mpls working group documents... so
my opinion on the adoption of the following two drafts

draft-takacs-ccamp-oam-configuration-fwk-01.txt
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt

is yes

and my opinion on the adoption of the following draft

draft-bernstein-ccamp-wson-encode-01.txt

is yes

> Thanks
> Nitin

thanks
Ciao
FF

Delivery-date: Wed, 03 Dec 2008 12:36:51 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "ccamp" <[email-masked]>
Subject: Reiterating Thanks to Note-takers
Date: Wed, 3 Dec 2008 12:35:29 -0000

Can I reiterate thanks to the note-takers. I often go back to the minutes to 
establish who said what, and what opinions were expressed. Accurate and 
detailed notes are a great asset.

Thanks,
Adrian

----- Original Message ----- 
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: "ccamp" <[email-masked]>
Sent: Wednesday, December 03, 2008 10:51 AM
Subject: CCAMP minutes

Hi all,

The ccamp minutes are available:
http://www.ietf.org/proceedings/08nov/minutes/ccamp.htm

Much thanks to our note takers: Lyndon Ong (both sessions!), Eric Gray
(session I) and Don Fedyk (session II).

Let us know if any comments-
Deborah and Adrian

Delivery-date: Wed, 03 Dec 2008 10:54:02 +0000
Content-class: urn:content-classes:message
Subject: CCAMP minutes
Date: Wed, 3 Dec 2008 05:51:47 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: "ccamp" <[email-masked]>

Hi all,

The ccamp minutes are available:
http://www.ietf.org/proceedings/08nov/minutes/ccamp.htm

Much thanks to our note takers: Lyndon Ong (both sessions!), Eric Gray
(session I) and Don Fedyk (session II).

Let us know if any comments-
Deborah and Adrian

Delivery-date: Wed, 03 Dec 2008 10:09:55 +0000
Date: Wed, 03 Dec 2008 19:08:53 +0900
From: Sugang XU <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: Re: CCAMP drafts for adoption

Support all to become WG documents.

Sugang

Adrian Farrel さんは書きました:
> Hi,
> 
> Can you please express your opinion on the adoption of the following 
> three drafts as WG drafts.
> 
> Thanks,
> Adrian
> 
> draft-takacs-ccamp-oam-configuration-fwk-01.txt
> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)
> 
> Cheers,
> Adrian and Deborah
> 
> 
> 

Delivery-date: Wed, 03 Dec 2008 09:57:23 +0000
Date: Wed, 03 Dec 2008 17:55:10 +0800
From: Mach Chen <[email-masked]>
Subject: Re: CCAMP drafts for adoption
To: Adrian Farrel <[email-masked]>, [email-masked]

Yes to all three drafts.

Best regards,
Mach

--------------------------------------------------
From: "Adrian Farrel" <[email-masked]>
Sent: Wednesday, December 03, 2008 12:01 AM
To: <[email-masked]>
Subject: CCAMP drafts for adoption

> Hi,
>
> Can you please express your opinion on the adoption of the following three 
> drafts as WG drafts.
>
> Thanks,
> Adrian
>
> draft-takacs-ccamp-oam-configuration-fwk-01.txt
> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)
>
> Cheers,
> Adrian and Deborah
>
>
> 

Delivery-date: Wed, 03 Dec 2008 09:28:23 +0000
Date: Wed, 03 Dec 2008 17:27:40 +0800
From: lidan 37133 <[email-masked]>
Subject: =?gb2312?B?u9i4tA==?=:CCAMP drafts for adoption
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]

Yes to all of three=2E

Dan Li
 =

Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co=2E=2C LTD=2E
Huawei Base=2C Bantian=2C Longgang=2C
Shenzhen 518129 P=2ER=2EChina
Tel=3A +86-755-28973237
Fax=3A +86-755-28972935

----- =D4=AD=D3=CA=BC=FE -----
=B7=A2=BC=FE=C8=CB=3A Adrian Farrel =3Cadrian=40olddog=2Eco=2Euk=3E
=C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =CA=AE=B6=FE=D4=C2 3=C8=D5=2C 2008 =
=C9=CF=CE=E70=3A03
=D6=F7=CC=E2=3A CCAMP drafts for adoption
=CA=D5=BC=FE=C8=CB=3A ccamp=40ops=2Eietf=2Eorg

=3E Hi=2C
=3E =

=3E Can you please express your opinion on the adoption of the =

=3E following three =

=3E drafts as WG drafts=2E
=3E =

=3E Thanks=2C
=3E Adrian
=3E =

=3E draft-takacs-ccamp-oam-configuration-fwk-01=2Etxt
=3E draft-takacs-ccamp-rsvp-te-eth-oam-ext-03=2Etxt
=3E draft-bernstein-ccamp-wson-encode-01=2Etxt (to become -rwa-encode-00)=

=3E =

=3E Cheers=2C
=3E Adrian and Deborah =

=3E =

=3E =

=3E =

=3E 

Delivery-date: Wed, 03 Dec 2008 09:01:29 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Nitin Bahadur" <[email-masked]>, <[email-masked]>
Subject: OAM control
Date: Wed, 3 Dec 2008 09:00:42 -0000

Hi Nitin,

Have you tried running LSP Ping on a lambda?
In practice, many data plane technologies have existing OAM techniques, and 
it is these that the draft proposes to control.

Are you suggesting that the LSP Ping echo request should be sent out of band 
and used to manage data plane OAM?

Thanks,
Adrian
----- Original Message ----- 
From: "Nitin Bahadur" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Tuesday, December 02, 2008 9:35 PM
Subject: RE: CCAMP drafts for adoption

> > draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt

Do not support either of these.

>From the oam-config-fwk draft:
> A new useful application of RSVP-TE is OAM configuration
> and control for transport networks.

LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we need
another mechanism? What are the limitations of lsp-ping that warrant
this new mechanism?

> When RSVP-TE is used for LSP establishment it is desirable to bind
> OAM setup to connection establishment signalling to avoid two
> separate management/configuration steps

draft-ietf-bfd-mpls specifies how to use LSP-Ping for automatic setup of
BFD-based OAM.
We should go along the same path for Ethernet OAM.

Thanks
Nitin 

Delivery-date: Wed, 03 Dec 2008 08:36:53 +0000
Date: Wed, 03 Dec 2008 09:34:52 +0100
From: longhao 48034 <[email-masked]>
Subject: Re:CCAMP drafts for adoption
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]

Hi=2C

I support all of the three drafts to become WG drafts=2E

When I read the mailing discussion=2C some experts opposed the two I-Ds r=
elated to oam configuration=3A
 draft-takacs-ccamp-oam-configuration-fwk-01=2Etxt
 draft-takacs-ccamp-rsvp-te-eth-oam-ext-03=2Etxt

My understanding is these two I-Ds are very useful for oam deployment=2E =
As you know=2C there are many things are needed to be preconfigured befor=
e you activate the oam function=2E This is actually a tough thing for use=
rs because the configuration involoves all the nodes on the lsp and so ma=
ny parameters=2C e=2Eg=2E MEG level=2C MEP ID=2C MD name =2C MA name =2E=2E=
=2E=2E=2E Some experts argues that this will lead to add more TLVs to RSV=
P-TE=2E However=2C if looking at the
 LSP setup=2C it is also a way to simplify the configuration=2E LSP setup=
 and OAM configuration are similar thing=2E They are both the work of REV=
P-TE signaling=2E As this=2C I support the two I-Ds=2E

Thanks=2C
Hao

----- =D4=AD=D3=CA=BC=FE -----
=B7=A2=BC=FE=C8=CB=3A Adrian Farrel =3Cadrian=40olddog=2Eco=2Euk=3E
=C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =CA=AE=B6=FE=D4=C2 2=C8=D5=2C 2008 =
=CF=C2=CE=E75=3A03
=D6=F7=CC=E2=3A CCAMP drafts for adoption
=CA=D5=BC=FE=C8=CB=3A ccamp=40ops=2Eietf=2Eorg

=3E Hi=2C
=3E =

=3E Can you please express your opinion on the adoption of the =

=3E following three =

=3E drafts as WG drafts=2E
=3E =

=3E Thanks=2C
=3E Adrian
=3E =

=3E draft-takacs-ccamp-oam-configuration-fwk-01=2Etxt
=3E draft-takacs-ccamp-rsvp-te-eth-oam-ext-03=2Etxt
=3E draft-bernstein-ccamp-wson-encode-01=2Etxt (to become -rwa-encode-00)=

=3E =

=3E Cheers=2C
=3E Adrian and Deborah =

=3E =

=3E =

=3E =

=3E 

Delivery-date: Wed, 03 Dec 2008 07:53:09 +0000
From: Anders Gavler <[email-masked]>
To: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 3 Dec 2008 08:52:26 +0100
Subject: RE: CCAMP drafts for adoption
Accept-Language: sv-SE, en-US
acceptlanguage: sv-SE, en-US

Yes to all three.

/Anders

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behal=
f
> Of Adrian Farrel
> Sent: den 2 december 2008 17:02
> To: [email-masked]
> Subject: CCAMP drafts for adoption
>
> Hi,
>
> Can you please express your opinion on the adoption of the following thre=
e
> drafts as WG drafts.
>
> Thanks,
> Adrian
>
> draft-takacs-ccamp-oam-configuration-fwk-01.txt
> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)
>
> Cheers,
> Adrian and Deborah
>
>
>
>

Delivery-date: Wed, 03 Dec 2008 07:33:03 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Wed, 3 Dec 2008 08:31:18 +0100
From: "Daniele Ceccarelli" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

I support all of them.

Cheers,
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Adrian Farrel
Sent: marted=EC 2 dicembre 2008 17.02
To: [email-masked]
Subject: CCAMP drafts for adoption

Hi,

Can you please express your opinion on the adoption of the following =
three=20
drafts as WG drafts.

Thanks,
Adrian

draft-takacs-ccamp-oam-configuration-fwk-01.txt
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)

Cheers,
Adrian and Deborah=20

Delivery-date: Wed, 03 Dec 2008 04:35:00 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 23:34:13 -0500
From: "Don Fedyk" <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>, "Nitin Bahadur" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi Tom
Please see inline,=20

>On 12/2/08 5:32 PM, "Don Fedyk" <[email-masked]> wrote:
>
>> Hi Nitin=20
>>=20
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Nitin Bahadur
>>>=20
>>>=20
>>>>> draft-takacs-ccamp-oam-configuration-fwk-01.txt
>>>>> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
>>>=20
>>> Do not support either of these.
>>>=20
>>> From the oam-config-fwk draft:
>>>> A new useful application of RSVP-TE is OAM configuration
>>>> and control for transport networks.
>>>=20
>>> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why
>>> do we need
>>> another mechanism? What are the limitations of lsp-ping that warrant
>>> this new mechanism?
>>=20
>> These drafts support configuration of data plane OAM functions when
you
>> are using RSVP-TE to setup the paths.  The alternative is operator
>> configuration. It has nothing to do with LSP Ping.
>>=20
>>>=20
>>>> When RSVP-TE is used for LSP establishment it is desirable to bind
>>>> OAM setup to connection establishment signalling to avoid two
>>>> separate management/configuration steps
>>>=20
>>> draft-ietf-bfd-mpls specifies how to use LSP-Ping for
>>> automatic setup of
>>> BFD-based OAM.
>>=20
>> So LSP Ping sets up BFD? Interesting.  While I can see this might be
>> useful in the case of LDP when debugging a problem you do have issues
>> with LSP-Ping reaching all path combinations and certain error
>> scenarios. I don't think this is a comprehensive mechanism.
>
>    Don,
>
>    LSP ping is used to "bootstrap" BFD for MPLS networks. It is a
perfectly
>sound method of solving the problem it sought to solve. Please take a
look
>at this draft-ietf-bfd-mpls-07 for a description of how this works if
you
>are unfamiliar.  =20

Tom,

When I read this draft what I read is that an MPLS LSP may take one or=20
more paths and that a BFD session is set up for one or more of these
paths.=20
Since the network may change, the MPLS LSP may vary the number of paths=20
it takes from time to time (ECMP may come and go). So if you have a=20
problem you may fined you have not set up the BFD session on a LSP path=20
or there may well be even 2 BFD sessions running on what is now a single

LSP path.  In a big network I think this may be a bit of an issue.=20

>
>> This is clearly different than what we are specifying in the Ethernet
>> OAM case.=20
>
>    While not a comprehensive mechanism for doing Ethernet OAM, don't
you
>think that defining how Ethernet OAM works (or is configured) should be
done
>by the IEEE?  What you are proposing here by combining these different
>things together is what at least smells like what was thrown out in
L2VPN a
>number of years ago due to a layer violation when it was tried for
>Ethernet/VPLS PWs.=20

We absolutely have left OAM for the IEEE. In fact the whole data plane=20
and OAM is specified in the IEEE. All we are proposing is to optionally=20
signal a IEEE OAM profile of the type of MIPs and MEPs on the
connection.=20
This is the point of GMPLS. Generalized control of other technologies.

RSVP-TE sessions that don't use these objects would use normal RSVP-TE=20
processing. That is why we have extensible protocols.  As Attila points=20
out OAM for other technologies such as optical could also use these=20
GMPLS mechanisms.=20

When you setup paths and CCM in this manner there is no doubt it is=20
protecting the traffic path.=20

Regards,
Don=20

>    --Tom

Delivery-date: Wed, 03 Dec 2008 04:09:38 +0000
Cc: Nitin Bahadur <[email-masked]>, Adrian Farrel <[email-masked]>, <[email-masked]>
From: Shane Amante <[email-masked]>
To: Thomas D. Nadeau <[email-masked]>
Subject: Re: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 21:07:42 -0700

Do not support.

-shane

On Dec 2, 2008, at 2:49 PM, Thomas D. Nadeau wrote:

>
>    I agree with Nitin and do not support the adoption of these drafts.
>
>    --Tom
>
>
>
> On 12/2/08 4:35 PM, "Nitin Bahadur" <[email-masked]> wrote:
>
>>>> draft-takacs-ccamp-oam-configuration-fwk-01.txt
>>>> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
>>
>> Do not support either of these.
>>
>> From the oam-config-fwk draft:
>>> A new useful application of RSVP-TE is OAM configuration
>>> and control for transport networks.
>>
>> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we  
>> need
>> another mechanism? What are the limitations of lsp-ping that warrant
>> this new mechanism?
>>
>>> When RSVP-TE is used for LSP establishment it is desirable to bind
>>> OAM setup to connection establishment signalling to avoid two
>>> separate management/configuration steps
>>
>> draft-ietf-bfd-mpls specifies how to use LSP-Ping for automatic  
>> setup of
>> BFD-based OAM.
>> We should go along the same path for Ethernet OAM.
>>
>> Thanks
>> Nitin
>>
>
>

Delivery-date: Wed, 03 Dec 2008 00:42:48 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 19:40:55 -0500
From: "David Allan" <[email-masked]>
To: "Nitin Bahadur" <[email-masked]>, <[email-masked]>

Hi Nitin:

My reaction is that spreading state over a number of protocols may keep
one superficially simple but drives up the total cost of the
solution...from the POV of lines of code, amount to test, amount of
state, additional race conditions, delayed setup time etc. so is a
specious optimization....

If the path is not up until OAM says so, it is useful to get there in as
few transactions as possible...

My 2 cents.
Dave

=20

-----Original Message-----
From: Nitin Bahadur [mailto:[email-masked]]=20
Sent: Tuesday, December 02, 2008 6:38 PM
To: Allan, David (CAR:NS00); [email-masked]
Subject: RE: CCAMP drafts for adoption

Hi David,

> > David, all that I am asking is that one can use the basic-bare-bones
> definitions in lsp-ping to setup the Ethernet OAM
> > params. I am not talking about applicability nor I am
> saying that one
> needs to use ping and trace based off lsp-ping for > PBB-TE LSPs.=20
>=20
> But this still requires implementing a new protocol where it does not=20
> already exist,

I agree. It does require implementing lsp-ping. But the way these 2
drafts are going, they will end up defining a new
mini-oam-boot-strapping protocol on top of RSVP path messages. And once
we have a precedence, it will just keep growing. I am basically against
using RSVP path message as an OAM related PDU transfer agent. The drafts
already specify 3-4 sub-TLVs and a bunch of error codes. This list can
grow. The framework draft is generic in nature. So tomorrrow I can use
BFD or XXX on top of RSVP (why just ethernet-oam) and I can add 10 more
TLVs and 5 more error codes.

It's all about keeping RSVP clean. Your requirement is to automate OAM
on a GMPLS LSP. Why dirty this poor Path msg.

If you do not wish to use Lsp-ping (for whatever reason)...I recommend
using something other than a RSVP path msg.

> which also requires a *new* bare
> bones definition...

I think that would be easy. You just need to send the lsp-ping msg along
the control-plane. The LSP details can be put in the existing defined
TLVs. The ethernet OAM details can be directly copied from these new
drafts into a lsp-ping based draft.

> <snipped>
>=20
> > I am not asking you to use lsp-ping for LB/LT. I agree that ethernet
> OAM already has that and indeed once should use
> > that. I am just saying that the setup can be done using lsp-ping.
>=20
> I think the point was GMPLS applies to a lot of technologies that=20
> cannot do LSP-PING in the first place, which means such a signalling=20
> extension will be required nonetheless...

As I said earlier, use LSP-Ping not for OAM, but for signaling the OAM
params.
Given that you are using RSVP for signaling the GMPLS LSP via the
control plane, you can use LSP-Ping (via control plane) to do the OAM
signaling.

> can I suggest you
> withdraw your objections to the Eth-Oam draft and move the TP parts of

> this discussion over to the MPLS list?

My main objections to the Eth-oam drafts are not TP related.=20
They are related to using RSVP Path as a transmission mechanism for OAM
setup. OAM is complex and tomorrow we might need more TLVs to indicate
remote failure or some other condition via the control plane.=20
Dave, you are the co-author of draft-ietf-pwe3-oam-msg-map. Look at the
amount of stuff that has gone in there.

As a side-note, I am just *a person*. It's the ccamp wg mailing list
that needs to say *yes*/*no*. It's all rough consensus right?

Thanks
Nitin

Delivery-date: Tue, 02 Dec 2008 23:55:14 +0000
Date: Tue, 02 Dec 2008 18:54:27 -0500
Subject: Re: CCAMP drafts for adoption
From: "Thomas D. Nadeau" <[email-masked]>
To: Don Fedyk <[email-masked]>, Nitin Bahadur <[email-masked]>, Adrian Farrel <[email-masked]>, <[email-masked]>

On 12/2/08 5:32 PM, "Don Fedyk" <[email-masked]> wrote:

> Hi Nitin 
> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Nitin Bahadur
>> 
>> 
>>>> draft-takacs-ccamp-oam-configuration-fwk-01.txt
>>>> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
>> 
>> Do not support either of these.
>> 
>> From the oam-config-fwk draft:
>>> A new useful application of RSVP-TE is OAM configuration
>>> and control for transport networks.
>> 
>> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why
>> do we need
>> another mechanism? What are the limitations of lsp-ping that warrant
>> this new mechanism?
> 
> These drafts support configuration of data plane OAM functions when you
> are using RSVP-TE to setup the paths.  The alternative is operator
> configuration. It has nothing to do with LSP Ping.
> 
>> 
>>> When RSVP-TE is used for LSP establishment it is desirable to bind
>>> OAM setup to connection establishment signalling to avoid two
>>> separate management/configuration steps
>> 
>> draft-ietf-bfd-mpls specifies how to use LSP-Ping for
>> automatic setup of
>> BFD-based OAM.
> 
> So LSP Ping sets up BFD? Interesting.  While I can see this might be
> useful in the case of LDP when debugging a problem you do have issues
> with LSP-Ping reaching all path combinations and certain error
> scenarios. I don't think this is a comprehensive mechanism.

    Don,

    LSP ping is used to "bootstrap" BFD for MPLS networks. It is a perfectly
sound method of solving the problem it sought to solve. Please take a look
at this draft-ietf-bfd-mpls-07 for a description of how this works if you
are unfamiliar.    

> This is clearly different than what we are specifying in the Ethernet
> OAM case. 

    While not a comprehensive mechanism for doing Ethernet OAM, don't you
think that defining how Ethernet OAM works (or is configured) should be done
by the IEEE?  What you are proposing here by combining these different
things together is what at least smells like what was thrown out in L2VPN a
number of years ago due to a layer violation when it was tried for
Ethernet/VPLS PWs. 

    --Tom

> Regards,
> Don    
> 
> 
> 
>> We should go along the same path for Ethernet OAM.
>> 
>> Thanks
>> Nitin
>> 
>> 
> 

Delivery-date: Tue, 02 Dec 2008 23:41:57 +0000
Content-Class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 15:37:46 -0800
From: Nitin Bahadur <[email-masked]>
To: "David Allan" <[email-masked]>, <[email-masked]>

Hi David,

> > David, all that I am asking is that one can use the basic-bare-bones
> definitions in lsp-ping to setup the Ethernet OAM=20
> > params. I am not talking about applicability nor I am=20
> saying that one
> needs to use ping and trace based off lsp-ping for > PBB-TE LSPs.=20
>=20
> But this still requires implementing a new protocol where it=20
> does not already exist,

I agree. It does require implementing lsp-ping. But the way these 2
drafts are going, they will end up defining a new
mini-oam-boot-strapping protocol on top of RSVP path messages. And once
we have a precedence, it will just keep growing. I am basically against
using RSVP path message as an OAM related PDU transfer agent. The drafts
already specify 3-4 sub-TLVs and a bunch of error codes. This list can
grow. The framework draft is generic in nature. So tomorrrow I can use
BFD or XXX on top of RSVP (why just ethernet-oam) and I can add 10 more
TLVs and 5 more error codes.

It's all about keeping RSVP clean. Your requirement is to automate OAM
on a GMPLS LSP. Why dirty this poor Path msg.

If you do not wish to use Lsp-ping (for whatever reason)...I recommend
using something other than a RSVP path msg.

> which also requires a *new* bare=20
> bones definition...

I think that would be easy. You just need to send the lsp-ping msg=20
along the control-plane. The LSP details can be put in the existing
defined TLVs. The ethernet OAM details can be directly copied from these
new drafts into a lsp-ping based draft.

> <snipped>
>=20
> > I am not asking you to use lsp-ping for LB/LT. I agree that ethernet
> OAM already has that and indeed once should use=20
> > that. I am just saying that the setup can be done using lsp-ping.
>=20
> I think the point was GMPLS applies to a lot of technologies=20
> that cannot do LSP-PING in the first place, which means such=20
> a signalling extension will be required nonetheless...

As I said earlier, use LSP-Ping not for OAM, but for signaling the OAM
params.
Given that you are using RSVP for signaling the GMPLS LSP via the
control plane, you can use LSP-Ping (via control plane) to do the OAM
signaling.

> can I suggest you=20
> withdraw your objections to the Eth-Oam draft and move the TP=20
> parts of this discussion over to the MPLS list?

My main objections to the Eth-oam drafts are not TP related.=20
They are related to using RSVP Path as a transmission mechanism for=20
OAM setup. OAM is complex and tomorrow we might need more TLVs to
indicate remote failure=20
or some other condition via the control plane.=20
Dave, you are the co-author of draft-ietf-pwe3-oam-msg-map. Look at the
amount of stuff that has gone in there.

As a side-note, I am just *a person*. It's the ccamp wg mailing list
that
needs to say *yes*/*no*. It's all rough consensus right?

Thanks
Nitin

Delivery-date: Tue, 02 Dec 2008 23:41:49 +0000
Date: Tue, 02 Dec 2008 18:41:04 -0500
Subject: Re: CCAMP drafts for adoption
From: "Thomas D. Nadeau" <[email-masked]>
To: David Allan <[email-masked]>, Nitin Bahadur <[email-masked]>, <[email-masked]>

    Dave, 

    As an operator with a very big deployment of MPLS and a lot of money
invested in OSS to manage said network, I do not want a different mechanism
to the one that has been deployed today to control OAM for any MPLS
networks, MPLS-TP included.

    --Tom

On 12/2/08 6:01 PM, "David Allan" <[email-masked]> wrote:

> HI Nitin:
> 
> Thanks for replying....
> <snipped>
> 
>> David, all that I am asking is that one can use the basic-bare-bones
> definitions in lsp-ping to setup the Ethernet OAM
>> params. I am not talking about applicability nor I am saying that one
> needs to use ping and trace based off lsp-ping for > PBB-TE LSPs.
> 
> But this still requires implementing a new protocol where it does not
> already exist, which also requires a *new* bare bones definition...
> 
>> We have a whole bunch of stuff defined in RSVP. Obviously some of them
> are not applicable for GMPLS LSPs. But that does > not mean that we go
> define G-RSVP (for GMPLS LSPs).
> 
> Isn't that CCAMPs mandate?
>  
> <snipped>
> 
>> I am not asking you to use lsp-ping for LB/LT. I agree that ethernet
> OAM already has that and indeed once should use
>> that. I am just saying that the setup can be done using lsp-ping.
> 
> I think the point was GMPLS applies to a lot of technologies that cannot
> do LSP-PING in the first place, which means such a signalling extension
> will be required nonetheless...
> 
> <snipped>
>> LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping
> has a reply-mode of *application channel* which can > be used for things
> like bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies
> would go on the LSP reverse path > (label-switched and not IP
> forwarded).
> 
> OK, I can see that such an approach could be made to work and would be
> desirable to some. On that basis, can I suggest you withdraw your
> objections to the Eth-Oam draft and move the TP parts of this discussion
> over to the MPLS list? That would seem appropriate...
> 
> Cheers
> Dave
> 
> 

Delivery-date: Tue, 02 Dec 2008 23:12:04 +0000
Content-Class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 15:08:43 -0800
From: Nitin Bahadur <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, "Attila Takacs" <[email-masked]>, <[email-masked]>

------_=_NextPart_001_01C954D2.EBBD444E
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi Igor,
=20
  I like your clear explanation (no pun intended). I understand your
view-point....my views are as below...
=20
> The difference is that GMPLS is a control plane, while OAM is supposed
to work in the data plane. In transport =20
> networks  control plane and data plane are separated. In fact, OAM
should work without and should not depend upon=20
>  control plane at all. You can not send Ping messages over lambda
layer network connection, can you?=20
=20
Agreed.=20
=20
>  On the other hand, you can use GMPLS to consistently configire OAM
function on the connection NEs, and that's what =20
> these drafts as I understand are about.
=20
I understand the motivation of these drafts and I totally agree with
that.
=20
>  In other words, in MPLS ,  LSP Ping is OAM, while GMPLS can only
automate OAM configuration, it can not relalize =20
>  OAM  on its own.

I agree that LSP-Ping may not be the OAM mechanism for GMPLS LSPs. All I
am saying is that LSP-Ping can be used to automate the OAM
configuration. There is enough machinery available in lsp-ping to enable
that. So why re-invent a new protocol? One could send lsp-ping messages
(control-plane routed) containing the information needed to automate
OAM.
=20
Question: Isn't it simpler to use RSVP path messages to automate this ?
Answer: Yes it looks simpler.
=20
Question: Then why is Nitin opposed ?
Answer: Because as this draft progresses, you will end up adding a whole
bunch of TLVs/sub-TLVs and related error codes. And all these have
nothing to do with a RSVP path message. The draft already has 3-4
sub-TLVs. In effect, the 2 drafts are defining a mini-OAM-boot-strapping
protocol on top of RSVP path message.

Nitin=20

=09
=09
=09
________________________________

	From: Nitin Bahadur <[email-masked]>
	To: Attila Takacs <[email-masked]>; Adrian Farrel
<[email-masked]>; [email-masked]
	Sent: Tuesday, December 2, 2008 5:01:11 PM
	Subject: RE: CCAMP drafts for adoption
=09
=09
	Hi Attlia,
=09
	  What is the limitation of lsp-ping that prevents it from being
	applied to GMPLS?
	If an existing mechanism can be applied, then why not? If
lsp-ping needs
	extensions to support GMPLS LSPs, feel free to make/specify
those
	extensions.
=09
	Thanks
	Nitin =20
=09
	> -----Original Message-----
	> From: Attila Takacs [mailto:[email-masked]]=20
	> Sent: Tuesday, December 02, 2008 1:52 PM
	> To: Nitin Bahadur; Adrian Farrel; [email-masked]
	> Subject: RE: CCAMP drafts for adoption
	>=20
	> Hi Nitin,
	>=20
	> Please note that these mechanisms are proposed for GMPLS and=20
	> as such to provide support for any data plane technology=20
	> specific OAM mechanism. As you noted LSP Ping is for MPLS and=20
	> BFD only. =20
	>=20
	> Best regards,
	> Attila
	>=20
	> > -----Original Message-----
	> > From: [email-masked]
	> > [mailto:[email-masked]] On Behalf Of Nitin Bahadur
	> > Sent: Tuesday, December 02, 2008 10:35 PM
	> > To: Adrian Farrel; [email-masked]
	> > Subject: RE: CCAMP drafts for adoption
	> >=20
	> >=20
	> >=20
	> > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt
	> > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
	> >=20
	> > Do not support either of these.
	> >=20
	> > From the oam-config-fwk draft:
	> > > A new useful application of RSVP-TE is OAM configuration
	> > and control
	> > > for transport networks.
	> >=20
	> > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why
do we=20
	> > need another mechanism? What are the limitations of lsp-ping
that=20
	> > warrant this new mechanism?
	> >=20
	> > > When RSVP-TE is used for LSP establishment it is desirable
	> > to bind OAM
	> > > setup to connection establishment signalling to avoid two=20
	> separate=20
	> > > management/configuration steps
	> >=20
	> > draft-ietf-bfd-mpls specifies how to use LSP-Ping for=20
	> automatic setup=20
	> > of BFD-based OAM.
	> > We should go along the same path for Ethernet OAM.
	> >=20
	> > Thanks
	> > Nitin
	> >=20
	> >=20
	>=20
=09
=09

------_=_NextPart_001_01C954D2.EBBD444E
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.3790.4357" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
class=3D002434722-02122008>Hi Igor,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT><SPAN =
class=3D002434722-02122008></SPAN></FONT><SPAN=20
class=3D002434722-02122008><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>&nbsp; I like your clear explanation (no pun =
intended). I=20
understand your view-point....my views are as =
below...</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D002434722-02122008>&nbsp;</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D002434722-02122008>&gt;&nbsp;</SPAN>The=20
difference is that GMPLS is a control plane, while OAM is supposed to =
work in=20
the data plane. In transport&nbsp;<SPAN class=3D002434722-02122008><FONT =

face=3DArial color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D002434722-02122008>&gt;&nbsp;</SPAN>networks&nbsp;<SPAN=20
class=3D002434722-02122008><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN>control plane and data plane are separated. =
In fact,=20
OAM should work without and should not depend upon<SPAN=20
class=3D002434722-02122008><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>&gt;</FONT>&nbsp;</SPAN> control plane at all. =
You can not=20
send Ping messages over lambda layer network connection, can you?<SPAN=20
class=3D002434722-02122008><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Agreed.</FONT>&nbsp;</SPAN><BR><SPAN=20
class=3D002434722-02122008><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008>&gt; =
&nbsp;</SPAN>On the=20
other hand, you can use GMPLS to consistently configire OAM function on =
the=20
connection NEs, and that's what&nbsp;<SPAN =
class=3D002434722-02122008><FONT=20
face=3DArial color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>&gt;</FONT>&nbsp;</SPAN>these drafts as I =
understand are=20
about.<BR><SPAN class=3D002434722-02122008><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I understand the motivation of these drafts and =
I totally=20
agree with that.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D002434722-02122008>&nbsp;</SPAN><BR><SPAN=20
class=3D002434722-02122008><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
face=3D"Times New Roman" color=3D#000000 size=3D3>&gt; =
</FONT>&nbsp;</FONT></SPAN>In=20
other words, in MPLS<SPAN class=3D002434722-02122008><FONT face=3DArial=20
color=3D#0000ff size=3D2>&nbsp;,&nbsp;</FONT></SPAN> LSP Ping is OAM, =
while GMPLS=20
can only automate OAM configuration, it can not relalize&nbsp;<SPAN=20
class=3D002434722-02122008><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>&gt; &nbsp;</FONT></SPAN>OAM&nbsp;<SPAN=20
class=3D002434722-02122008><FONT face=3DArial color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN>on its own.<BR><SPAN =
class=3D002434722-02122008><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I agree that LSP-Ping&nbsp;may not be the OAM =
mechanism for=20
GMPLS LSPs.</FONT>&nbsp;<FONT face=3DArial color=3D#0000ff size=3D2>All =
I am saying is=20
that LSP-Ping can be used to automate the OAM configuration. There is =
enough=20
machinery available in lsp-ping to enable that. So why re-invent a new =
protocol?=20
One could send lsp-ping messages (control-plane routed) containing the=20
information needed to automate OAM.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Question: Isn't it simpler to use RSVP path =
messages to=20
automate this ?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Answer: Yes it&nbsp;looks =
simpler.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Question: Then why&nbsp;is Nitin =
opposed</FONT>&nbsp;<FONT=20
face=3DArial color=3D#0000ff size=3D2>?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Answer:&nbsp;Because as this draft progresses, =
you will end=20
up adding a whole bunch of TLVs/sub-TLVs and related error codes. And =
all=20
these&nbsp;have nothing to do with a RSVP path message.&nbsp;The draft =
already=20
has 3-4 sub-TLVs. In effect, the 2 drafts are defining a =
mini-OAM-boot-strapping=20
protocol on top of RSVP path message.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D002434722-02122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><BR><SPAN=20
class=3D002434722-02122008><FONT face=3DArial color=3D#0000ff=20
size=3D2>Nitin&nbsp;</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif">
  <DIV=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman,new =
york,times,serif"><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><BR>
  <DIV style=3D"FONT-SIZE: 13px; FONT-FAMILY: =
arial,helvetica,sans-serif"><FONT=20
  face=3DTahoma size=3D2>
  <HR SIZE=3D1>
  <B><SPAN style=3D"FONT-WEIGHT: bold">From:</SPAN></B> Nitin Bahadur=20
  &lt;[email-masked]&gt;<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Attila Takacs=20
  &lt;[email-masked]&gt;; Adrian Farrel =
&lt;[email-masked]&gt;;=20
  [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Sent:</SPAN></B>=20
  Tuesday, December 2, 2008 5:01:11 PM<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: CCAMP drafts for=20
  adoption<BR></FONT><BR><BR>Hi Attlia,<BR><BR>&nbsp; What is the =
limitation of=20
  lsp-ping that prevents it from being<BR>applied to GMPLS?<BR>If an =
existing=20
  mechanism can be applied, then why not? If lsp-ping =
needs<BR>extensions to=20
  support GMPLS LSPs, feel free to make/specify=20
  those<BR>extensions.<BR><BR>Thanks<BR>Nitin&nbsp; <BR><BR>&gt; =
-----Original=20
  Message-----<BR>&gt; From: Attila Takacs [mailto:<A=20
  href=3D"mailto:[email-masked]"=20
  =
ymailto=3D"mailto:[email-masked]">[email-masked]<=
/A>]=20
  <BR>&gt; Sent: Tuesday, December 02, 2008 1:52 PM<BR>&gt; To: Nitin =
Bahadur;=20
  Adrian Farrel; <A href=3D"mailto:[email-masked]"=20
  ymailto=3D"mailto:[email-masked]">[email-masked]</A><BR>&gt; =
Subject:=20
  RE: CCAMP drafts for adoption<BR>&gt; <BR>&gt; Hi Nitin,<BR>&gt; =
<BR>&gt;=20
  Please note that these mechanisms are proposed for GMPLS and <BR>&gt; =
as such=20
  to provide support for any data plane technology <BR>&gt; specific OAM =

  mechanism. As you noted LSP Ping is for MPLS and <BR>&gt; BFD =
only.&nbsp;=20
  <BR>&gt; <BR>&gt; Best regards,<BR>&gt; Attila<BR>&gt; <BR>&gt; &gt;=20
  -----Original Message-----<BR>&gt; &gt; From: <A=20
  href=3D"mailto:[email-masked]"=20
  =
ymailto=3D"mailto:[email-masked]">[email-masked]</A><=
BR>&gt;=20
  &gt; [mailto:<A href=3D"mailto:[email-masked]"=20
  =
ymailto=3D"mailto:[email-masked]">[email-masked]</A>]=
 On=20
  Behalf Of Nitin Bahadur<BR>&gt; &gt; Sent: Tuesday, December 02, 2008 =
10:35=20
  PM<BR>&gt; &gt; To: Adrian Farrel; <A =
href=3D"mailto:[email-masked]"=20
  ymailto=3D"mailto:[email-masked]">[email-masked]</A><BR>&gt; =
&gt;=20
  Subject: RE: CCAMP drafts for adoption<BR>&gt; &gt; <BR>&gt; &gt; =
<BR>&gt;=20
  &gt; <BR>&gt; &gt; &gt; &gt;=20
  draft-takacs-ccamp-oam-configuration-fwk-01.txt<BR>&gt; &gt; &gt; &gt; =

  draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt<BR>&gt; &gt; <BR>&gt; =
&gt; Do=20
  not support either of these.<BR>&gt; &gt; <BR>&gt; &gt; From the=20
  oam-config-fwk draft:<BR>&gt; &gt; &gt; A new useful application of =
RSVP-TE is=20
  OAM configuration<BR>&gt; &gt; and control<BR>&gt; &gt; &gt; for =
transport=20
  networks.<BR>&gt; &gt; <BR>&gt; &gt; LSP-ping was designed as an OAM =
mechansim=20
  for MPLS LSPs. Why do we <BR>&gt; &gt; need another mechanism? What =
are the=20
  limitations of lsp-ping that <BR>&gt; &gt; warrant this new =
mechanism?<BR>&gt;=20
  &gt; <BR>&gt; &gt; &gt; When RSVP-TE is used for LSP establishment it =
is=20
  desirable<BR>&gt; &gt; to bind OAM<BR>&gt; &gt; &gt; setup to =
connection=20
  establishment signalling to avoid two <BR>&gt; separate <BR>&gt; &gt; =
&gt;=20
  management/configuration steps<BR>&gt; &gt; <BR>&gt; &gt; =
draft-ietf-bfd-mpls=20
  specifies how to use LSP-Ping for <BR>&gt; automatic setup <BR>&gt; =
&gt; of=20
  BFD-based OAM.<BR>&gt; &gt; We should go along the same path for =
Ethernet=20
  OAM.<BR>&gt; &gt; <BR>&gt; &gt; Thanks<BR>&gt; &gt; Nitin<BR>&gt; &gt; =

  <BR>&gt; &gt; <BR>&gt; =
<BR><BR></DIV></DIV></DIV><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C954D2.EBBD444E--

Delivery-date: Tue, 02 Dec 2008 23:03:02 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 18:01:25 -0500
From: "David Allan" <[email-masked]>
To: "Nitin Bahadur" <[email-masked]>, <[email-masked]>

HI Nitin:

Thanks for replying....
<snipped>

> David, all that I am asking is that one can use the basic-bare-bones
definitions in lsp-ping to setup the Ethernet OAM=20
> params. I am not talking about applicability nor I am saying that one
needs to use ping and trace based off lsp-ping for > PBB-TE LSPs.=20

But this still requires implementing a new protocol where it does not
already exist, which also requires a *new* bare bones definition...

> We have a whole bunch of stuff defined in RSVP. Obviously some of them
are not applicable for GMPLS LSPs. But that does > not mean that we go
define G-RSVP (for GMPLS LSPs).

Isn't that CCAMPs mandate?
=20
<snipped>

> I am not asking you to use lsp-ping for LB/LT. I agree that ethernet
OAM already has that and indeed once should use=20
> that. I am just saying that the setup can be done using lsp-ping.

I think the point was GMPLS applies to a lot of technologies that cannot
do LSP-PING in the first place, which means such a signalling extension
will be required nonetheless...

<snipped>
> LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping
has a reply-mode of *application channel* which can > be used for things
like bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies
would go on the LSP reverse path > (label-switched and not IP
forwarded).

OK, I can see that such an approach could be made to work and would be
desirable to some. On that basis, can I suggest you withdraw your
objections to the Eth-Oam draft and move the TP parts of this discussion
over to the MPLS list? That would seem appropriate...

Cheers
Dave

Delivery-date: Tue, 02 Dec 2008 22:46:58 +0000
Content-Class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 14:43:21 -0800
From: Nitin Bahadur <[email-masked]>
To: "David Allan" <[email-masked]>, <[email-masked]>

> > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we
> need another mechanism? What are the limitations of=20
> > lsp-ping that warrant this new mechanism? <snipped> We=20
> should go along
> the same path for Ethernet OAM.
>=20
> It is not applicable to either a PBB-TE switched path or, if=20
> you are of that persuasion, an MPLS-TP switched path...as it=20
> stands today. And it only goes downhill from there....

David, all that I am asking is that one can use the basic-bare-bones
definitions=20
in lsp-ping to setup the Ethernet OAM params. I am not talking about
applicability nor I am
saying that one needs to use ping and trace based off lsp-ping for
PBB-TE LSPs.=20

We have a whole bunch of stuff defined in RSVP. Obviously some of them
are not applicable for GMPLS LSPs. But that does not mean that we go
define G-RSVP (for GMPLS LSPs).
=20
> I would think the inappropriateness of applying LSP-PING to=20
> Ethernet OAM would be self evident...Ethernet OAM already has=20
> it's own LB/LT functionality so mandating another loopback=20
> exclusively for OAM configuration is gratuitously complex.

I am not asking you to use lsp-ping for LB/LT. I agree that ethernet OAM
already has that and indeed once should use that. I am just saying that
the setup can be done using lsp-ping.
=20
> As for MPLS-TP, LSP-PING would need recasting as a "non-IP"=20
> protocol to fit the mandated profile from the joint design=20
> team and likely would benefit from a trip to the fat farm to=20
> shed the other features it did not need within said profile...

LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping has
a reply-mode of *application channel* which can be used for things like
bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies would go
on the LSP reverse path (label-switched and not IP forwarded).

Thanks
Nitin

Delivery-date: Tue, 02 Dec 2008 22:38:16 +0000
Content-Class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 14:35:44 -0800
From: Nitin Bahadur <[email-masked]>
To: "Attila Takacs" <[email-masked]>, <[email-masked]>

> I would formulate this form the other way around. If we=20
> already have a technology agnostic solution, read GMPLS, it=20
> seems to be straightforward to continue using it. Then why not? :-)
>=20
> One key benefit of using RSVP-TE is that OAM configuration is=20
> bound to the actual LSP establishment this simplifies=20
> management and avoids misconfiguration. With LSP Ping we=20
> would need one mechanism to setup the LSPs (read *not* just=20
> MPLS) using GMPLS and then apply another solution say=20
> Generalized-LSP Ping to configure OAM; if I understand your=20
> proposal right.

Yes...your understanding of my proposal is correct.=20
But it would solve your issue of manual=20
OAM configuration. Agreed, it's a 2-step control-plane process.
=20
> From another perspective, what would be the use of LSP Ping=20
> over, e.g., an optical network or Ethernet using CFM?

Just for setup of the OAM parameters. Ethernet OAM provides a bunch of
capabilities
(like LT/LB) and you would use them as-is. The advantage of using
lsp-ping is that only the LSP egress sees the OAM parmeters.=20

If you add a new-TLV to the PATH msg, then you need to send it on every
PATH msg...
You really need to signal the parameters once during LSP-setup time (and
perhaps when the parameters are changed).

LSP-Ping has a whole bunch of stuff defined. Most of it is not
needed/applicable in various scenarios. But the advantage is that it's
all there. As you go ahead with defining a new mechanism, you will
gradually see other requirements/needs and you might end up re-inventing
lsp-ping in another form.

> Best regards,
> Attila
>=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: Nitin Bahadur [mailto:[email-masked]]
> > Sent: Tuesday, December 02, 2008 11:01 PM
> > To: Attila Takacs; Adrian Farrel; [email-masked]
> > Subject: RE: CCAMP drafts for adoption
> >=20
> >=20
> > Hi Attlia,
> >=20
> >    What is the limitation of lsp-ping that prevents it from being=20
> > applied to GMPLS?
> > If an existing mechanism can be applied, then why not? If lsp-ping=20
> > needs extensions to support GMPLS LSPs, feel free to make/specify=20
> > those extensions.
> >=20
> > Thanks
> > Nitin
> >=20
> > > -----Original Message-----
> > > From: Attila Takacs [mailto:[email-masked]]
> > > Sent: Tuesday, December 02, 2008 1:52 PM
> > > To: Nitin Bahadur; Adrian Farrel; [email-masked]
> > > Subject: RE: CCAMP drafts for adoption
> > >=20
> > > Hi Nitin,
> > >=20
> > > Please note that these mechanisms are proposed for GMPLS
> > and as such
> > > to provide support for any data plane technology specific OAM=20
> > > mechanism. As you noted LSP Ping is for MPLS and BFD only.
> > >=20
> > > Best regards,
> > > Attila
> > >=20
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Nitin Bahadur
> > > > Sent: Tuesday, December 02, 2008 10:35 PM
> > > > To: Adrian Farrel; [email-masked]
> > > > Subject: RE: CCAMP drafts for adoption
> > > >=20
> > > >=20
> > > >=20
> > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> > > >=20
> > > > Do not support either of these.
> > > >=20
> > > > From the oam-config-fwk draft:
> > > > > A new useful application of RSVP-TE is OAM configuration
> > > > and control
> > > > > for transport networks.
> > > >=20
> > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20
> > Why do we
> > > > need another mechanism? What are the limitations of=20
> lsp-ping that=20
> > > > warrant this new mechanism?
> > > >=20
> > > > > When RSVP-TE is used for LSP establishment it is desirable
> > > > to bind OAM
> > > > > setup to connection establishment signalling to avoid two
> > > separate
> > > > > management/configuration steps
> > > >=20
> > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for
> > > automatic setup
> > > > of BFD-based OAM.
> > > > We should go along the same path for Ethernet OAM.
> > > >=20
> > > > Thanks
> > > > Nitin
> > > >=20
> > > >=20
> > >=20
> >=20
>=20

Delivery-date: Tue, 02 Dec 2008 22:33:03 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 17:32:18 -0500
From: "Don Fedyk" <[email-masked]>
To: "Nitin Bahadur" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi Nitin=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nitin Bahadur
>=20
>=20
> > > draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
>=20
> Do not support either of these.
>=20
> From the oam-config-fwk draft:
> > A new useful application of RSVP-TE is OAM configuration
> > and control for transport networks.
>=20
> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why=20
> do we need
> another mechanism? What are the limitations of lsp-ping that warrant
> this new mechanism?

These drafts support configuration of data plane OAM functions when you
are using RSVP-TE to setup the paths.  The alternative is operator
configuration. It has nothing to do with LSP Ping.=20

>=20
> > When RSVP-TE is used for LSP establishment it is desirable to bind
> > OAM setup to connection establishment signalling to avoid two
> > separate management/configuration steps
>=20
> draft-ietf-bfd-mpls specifies how to use LSP-Ping for=20
> automatic setup of
> BFD-based OAM.

So LSP Ping sets up BFD? Interesting.  While I can see this might be
useful in the case of LDP when debugging a problem you do have issues
with LSP-Ping reaching all path combinations and certain error
scenarios. I don't think this is a comprehensive mechanism.=20

This is clearly different than what we are specifying in the Ethernet
OAM case.=20

Regards,
Don   =20

> We should go along the same path for Ethernet OAM.
>=20
> Thanks
> Nitin
>=20
>=20

Delivery-date: Tue, 02 Dec 2008 22:22:06 +0000
Date: Tue, 2 Dec 2008 14:21:51 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: Re: CCAMP drafts for adoption
To: Nitin Bahadur <[email-masked]>, Attila Takacs <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]

--0-1170914688-1228256511=:95032
Content-Type: text/plain; charset=us-ascii

Nitin,

The difference is that GMPLS is a control plane, while OAM is supposed to work in the data plane. In transport networks control plane and data plane are separated. In fact, OAM should work without and should not depend upon control plane at all. You can not send Ping messages over lambda layer network connection, can you?
On the other hand, you can use GMPLS to consistently configire OAM function on the connection NEs, and that's what these drafts as I understand are about.

In other words, in MPLS LSP Ping is OAM, while GMPLS can only automate OAM configuration, it can not relalize OAM on its own.

Cheers,
Igor

________________________________
From: Nitin Bahadur <[email-masked]>
To: Attila Takacs <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked]
Sent: Tuesday, December 2, 2008 5:01:11 PM
Subject: RE: CCAMP drafts for adoption

Hi Attlia,

   What is the limitation of lsp-ping that prevents it from being
applied to GMPLS?
If an existing mechanism can be applied, then why not? If lsp-ping needs
extensions to support GMPLS LSPs, feel free to make/specify those
extensions.

Thanks
Nitin  

> -----Original Message-----
> From: Attila Takacs [mailto:[email-masked]] 
> Sent: Tuesday, December 02, 2008 1:52 PM
> To: Nitin Bahadur; Adrian Farrel; [email-masked]
> Subject: RE: CCAMP drafts for adoption
> 
> Hi Nitin,
> 
> Please note that these mechanisms are proposed for GMPLS and 
> as such to provide support for any data plane technology 
> specific OAM mechanism. As you noted LSP Ping is for MPLS and 
> BFD only.  
> 
> Best regards,
> Attila
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Nitin Bahadur
> > Sent: Tuesday, December 02, 2008 10:35 PM
> > To: Adrian Farrel; [email-masked]
> > Subject: RE: CCAMP drafts for adoption
> > 
> > 
> > 
> > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> > 
> > Do not support either of these.
> > 
> > From the oam-config-fwk draft:
> > > A new useful application of RSVP-TE is OAM configuration
> > and control
> > > for transport networks.
> > 
> > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we 
> > need another mechanism? What are the limitations of lsp-ping that 
> > warrant this new mechanism?
> > 
> > > When RSVP-TE is used for LSP establishment it is desirable
> > to bind OAM
> > > setup to connection establishment signalling to avoid two 
> separate 
> > > management/configuration steps
> > 
> > draft-ietf-bfd-mpls specifies how to use LSP-Ping for 
> automatic setup 
> > of BFD-based OAM.
> > We should go along the same path for Ethernet OAM.
> > 
> > Thanks
> > Nitin
> > 
> > 
> 

--0-1170914688-1228256511=:95032
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Nitin,<br><br>The difference is that GMPLS is a control plane, while OAM is supposed to work in the data plane. In transport networks control plane and data plane are separated. In fact, OAM should work without and should not depend upon control plane at all. You can not send Ping messages over lambda layer network connection, can you?<br>On the other hand, you can use GMPLS to consistently configire OAM function on the connection NEs, and that's what these drafts as I understand are about.<br><br>In other words, in MPLS LSP Ping is OAM, while GMPLS can only automate OAM configuration, it can not relalize OAM on its own.<br><br>Cheers,<br>Igor<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif;
 font-size: 13px;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Nitin Bahadur &lt;[email-masked]&gt;<br><b><span style="font-weight: bold;">To:</span></b> Attila Takacs &lt;[email-masked]&gt;; Adrian Farrel &lt;[email-masked]&gt;; [email-masked]<br><b><span style="font-weight: bold;">Sent:</span></b> Tuesday, December 2, 2008 5:01:11 PM<br><b><span style="font-weight: bold;">Subject:</span></b> RE: CCAMP drafts for adoption<br></font><br>
<br>Hi Attlia,<br><br>&nbsp;  What is the limitation of lsp-ping that prevents it from being<br>applied to GMPLS?<br>If an existing mechanism can be applied, then why not? If lsp-ping needs<br>extensions to support GMPLS LSPs, feel free to make/specify those<br>extensions.<br><br>Thanks<br>Nitin&nbsp; <br><br>&gt; -----Original Message-----<br>&gt; From: Attila Takacs [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>] <br>&gt; Sent: Tuesday, December 02, 2008 1:52 PM<br>&gt; To: Nitin Bahadur; Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; Subject: RE: CCAMP drafts for adoption<br>&gt; <br>&gt; Hi Nitin,<br>&gt; <br>&gt; Please note that these mechanisms are proposed for GMPLS and <br>&gt; as such to provide support for any data plane technology <br>&gt; specific OAM mechanism. As you noted LSP Ping is for
 MPLS and <br>&gt; BFD only.&nbsp; <br>&gt; <br>&gt; Best regards,<br>&gt; Attila<br>&gt; <br>&gt; &gt; -----Original Message-----<br>&gt; &gt; From: <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt; [mailto:<a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a>] On Behalf Of Nitin Bahadur<br>&gt; &gt; Sent: Tuesday, December 02, 2008 10:35 PM<br>&gt; &gt; To: Adrian Farrel; <a ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]</a><br>&gt; &gt; Subject: RE: CCAMP drafts for adoption<br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; &gt; &gt; draft-takacs-ccamp-oam-configuration-fwk-01.txt<br>&gt; &gt; &gt; &gt; draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt<br>&gt; &gt; <br>&gt; &gt; Do not support either of these.<br>&gt; &gt; <br>&gt; &gt; From the oam-config-fwk draft:<br>&gt;
 &gt; &gt; A new useful application of RSVP-TE is OAM configuration<br>&gt; &gt; and control<br>&gt; &gt; &gt; for transport networks.<br>&gt; &gt; <br>&gt; &gt; LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we <br>&gt; &gt; need another mechanism? What are the limitations of lsp-ping that <br>&gt; &gt; warrant this new mechanism?<br>&gt; &gt; <br>&gt; &gt; &gt; When RSVP-TE is used for LSP establishment it is desirable<br>&gt; &gt; to bind OAM<br>&gt; &gt; &gt; setup to connection establishment signalling to avoid two <br>&gt; separate <br>&gt; &gt; &gt; management/configuration steps<br>&gt; &gt; <br>&gt; &gt; draft-ietf-bfd-mpls specifies how to use LSP-Ping for <br>&gt; automatic setup <br>&gt; &gt; of BFD-based OAM.<br>&gt; &gt; We should go along the same path for Ethernet OAM.<br>&gt; &gt; <br>&gt; &gt; Thanks<br>&gt; &gt; Nitin<br>&gt; &gt; <br>&gt; &gt; <br>&gt; <br><br></div></div></div><br>

      </body></html>
--0-1170914688-1228256511=:95032--

Delivery-date: Tue, 02 Dec 2008 22:21:28 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 22:20:52 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

You should not be using one DP OAM (heavyweight) function to activate
(deactivate??) another DP OAM (lightweight) function.  However, since
LDP does not create proper connections there is no concept of LSP (path)
set-up/tear-down...ergo LSP ping tries to treat it like a cl-ps mode
network case. This is NOT the case for GMPLS...esp when applied to any
co-cs mode technology (here proper connections are forced), and it is
not the case for the co-ps mode when proper connections are used (eg
RSVP-TE in MPLS).

Hopwever to be very clear here...it is operationally critical to be able
to activate/decativate OAM flows in sync with whatever CP or MP process
is responsible for connection set-up/tear-down in both co-cs and co-ps
mode layer networks....and LSP ping simply does not fit the bill here.

regards, Neil

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nitin Bahadur
> Sent: 02 December 2008 22:01
> To: Attila Takacs; Adrian Farrel; [email-masked]
> Subject: RE: CCAMP drafts for adoption
>=20
>=20
> Hi Attlia,
>=20
>    What is the limitation of lsp-ping that prevents it from=20
> being applied to GMPLS?
> If an existing mechanism can be applied, then why not? If=20
> lsp-ping needs extensions to support GMPLS LSPs, feel free to=20
> make/specify those extensions.
>=20
> Thanks
> Nitin =20
>=20
> > -----Original Message-----
> > From: Attila Takacs [mailto:[email-masked]]
> > Sent: Tuesday, December 02, 2008 1:52 PM
> > To: Nitin Bahadur; Adrian Farrel; [email-masked]
> > Subject: RE: CCAMP drafts for adoption
> >=20
> > Hi Nitin,
> >=20
> > Please note that these mechanisms are proposed for GMPLS=20
> and as such=20
> > to provide support for any data plane technology specific OAM=20
> > mechanism. As you noted LSP Ping is for MPLS and BFD only.
> >=20
> > Best regards,
> > Attila
> >=20
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Nitin Bahadur
> > > Sent: Tuesday, December 02, 2008 10:35 PM
> > > To: Adrian Farrel; [email-masked]
> > > Subject: RE: CCAMP drafts for adoption
> > >=20
> > >=20
> > >=20
> > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> > >=20
> > > Do not support either of these.
> > >=20
> > > From the oam-config-fwk draft:
> > > > A new useful application of RSVP-TE is OAM configuration
> > > and control
> > > > for transport networks.
> > >=20
> > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20
> Why do we=20
> > > need another mechanism? What are the limitations of lsp-ping that=20
> > > warrant this new mechanism?
> > >=20
> > > > When RSVP-TE is used for LSP establishment it is desirable
> > > to bind OAM
> > > > setup to connection establishment signalling to avoid two
> > separate
> > > > management/configuration steps
> > >=20
> > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for
> > automatic setup
> > > of BFD-based OAM.
> > > We should go along the same path for Ethernet OAM.
> > >=20
> > > Thanks
> > > Nitin
> > >=20
> > >=20
> >=20
>=20
>=20

Delivery-date: Tue, 02 Dec 2008 22:15:27 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 23:14:01 +0100
From: "Attila Takacs" <[email-masked]>
To: "Nitin Bahadur" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi Nitin,

I would formulate this form the other way around. If we already have a
technology agnostic solution, read GMPLS, it seems to be straightforward
to continue using it. Then why not? :-)

One key benefit of using RSVP-TE is that OAM configuration is bound to
the actual LSP establishment this simplifies management and avoids
misconfiguration. With LSP Ping we would need one mechanism to setup the
LSPs (read *not* just MPLS) using GMPLS and then apply another solution
say Generalized-LSP Ping to configure OAM; if I understand your proposal
right.

>From another perspective, what would be the use of LSP Ping over, e.g.,
an optical network or Ethernet using CFM?

Best regards,
Attila

> -----Original Message-----
> From: Nitin Bahadur [mailto:[email-masked]]=20
> Sent: Tuesday, December 02, 2008 11:01 PM
> To: Attila Takacs; Adrian Farrel; [email-masked]
> Subject: RE: CCAMP drafts for adoption
>=20
>=20
> Hi Attlia,
>=20
>    What is the limitation of lsp-ping that prevents it from=20
> being applied to GMPLS?
> If an existing mechanism can be applied, then why not? If=20
> lsp-ping needs extensions to support GMPLS LSPs, feel free to=20
> make/specify those extensions.
>=20
> Thanks
> Nitin =20
>=20
> > -----Original Message-----
> > From: Attila Takacs [mailto:[email-masked]]
> > Sent: Tuesday, December 02, 2008 1:52 PM
> > To: Nitin Bahadur; Adrian Farrel; [email-masked]
> > Subject: RE: CCAMP drafts for adoption
> >=20
> > Hi Nitin,
> >=20
> > Please note that these mechanisms are proposed for GMPLS=20
> and as such=20
> > to provide support for any data plane technology specific OAM=20
> > mechanism. As you noted LSP Ping is for MPLS and BFD only.
> >=20
> > Best regards,
> > Attila
> >=20
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Nitin Bahadur
> > > Sent: Tuesday, December 02, 2008 10:35 PM
> > > To: Adrian Farrel; [email-masked]
> > > Subject: RE: CCAMP drafts for adoption
> > >=20
> > >=20
> > >=20
> > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> > >=20
> > > Do not support either of these.
> > >=20
> > > From the oam-config-fwk draft:
> > > > A new useful application of RSVP-TE is OAM configuration
> > > and control
> > > > for transport networks.
> > >=20
> > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20
> Why do we=20
> > > need another mechanism? What are the limitations of lsp-ping that=20
> > > warrant this new mechanism?
> > >=20
> > > > When RSVP-TE is used for LSP establishment it is desirable
> > > to bind OAM
> > > > setup to connection establishment signalling to avoid two
> > separate
> > > > management/configuration steps
> > >=20
> > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for
> > automatic setup
> > > of BFD-based OAM.
> > > We should go along the same path for Ethernet OAM.
> > >=20
> > > Thanks
> > > Nitin
> > >=20
> > >=20
> >=20
>=20

Delivery-date: Tue, 02 Dec 2008 22:09:56 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 17:08:53 -0500
From: "David Allan" <[email-masked]>
To: "Nitin Bahadur" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi Nitin:

You wrote:

> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we
need another mechanism? What are the limitations of=20
> lsp-ping that warrant this new mechanism? <snipped> We should go along
the same path for Ethernet OAM.

It is not applicable to either a PBB-TE switched path or, if you are of
that persuasion, an MPLS-TP switched path...as it stands today. And it
only goes downhill from there....

I would think the inappropriateness of applying LSP-PING to Ethernet OAM
would be self evident...Ethernet OAM already has it's own LB/LT
functionality so mandating another loopback exclusively for OAM
configuration is gratuitously complex.

As for MPLS-TP, LSP-PING would need recasting as a "non-IP" protocol to
fit the mandated profile from the joint design team and likely would
benefit from a trip to the fat farm to shed the other features it did
not need within said profile...

Dave

Delivery-date: Tue, 02 Dec 2008 22:05:25 +0000
Content-Class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 14:01:11 -0800
From: Nitin Bahadur <[email-masked]>
To: "Attila Takacs" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi Attlia,

   What is the limitation of lsp-ping that prevents it from being
applied to GMPLS?
If an existing mechanism can be applied, then why not? If lsp-ping needs
extensions to support GMPLS LSPs, feel free to make/specify those
extensions.

Thanks
Nitin =20

> -----Original Message-----
> From: Attila Takacs [mailto:[email-masked]]=20
> Sent: Tuesday, December 02, 2008 1:52 PM
> To: Nitin Bahadur; Adrian Farrel; [email-masked]
> Subject: RE: CCAMP drafts for adoption
>=20
> Hi Nitin,
>=20
> Please note that these mechanisms are proposed for GMPLS and=20
> as such to provide support for any data plane technology=20
> specific OAM mechanism. As you noted LSP Ping is for MPLS and=20
> BFD only. =20
>=20
> Best regards,
> Attila
>=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Nitin Bahadur
> > Sent: Tuesday, December 02, 2008 10:35 PM
> > To: Adrian Farrel; [email-masked]
> > Subject: RE: CCAMP drafts for adoption
> >=20
> >=20
> >=20
> > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> >=20
> > Do not support either of these.
> >=20
> > From the oam-config-fwk draft:
> > > A new useful application of RSVP-TE is OAM configuration
> > and control
> > > for transport networks.
> >=20
> > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we=20
> > need another mechanism? What are the limitations of lsp-ping that=20
> > warrant this new mechanism?
> >=20
> > > When RSVP-TE is used for LSP establishment it is desirable
> > to bind OAM
> > > setup to connection establishment signalling to avoid two=20
> separate=20
> > > management/configuration steps
> >=20
> > draft-ietf-bfd-mpls specifies how to use LSP-Ping for=20
> automatic setup=20
> > of BFD-based OAM.
> > We should go along the same path for Ethernet OAM.
> >=20
> > Thanks
> > Nitin
> >=20
> >=20
>=20

Delivery-date: Tue, 02 Dec 2008 21:52:58 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 22:51:49 +0100
From: "Attila Takacs" <[email-masked]>
To: "Nitin Bahadur" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi Nitin,

Please note that these mechanisms are proposed for GMPLS and as such to
provide support for any data plane technology specific OAM mechanism. As
you noted LSP Ping is for MPLS and BFD only. =20

Best regards,
Attila

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nitin Bahadur
> Sent: Tuesday, December 02, 2008 10:35 PM
> To: Adrian Farrel; [email-masked]
> Subject: RE: CCAMP drafts for adoption
>=20
>=20
>=20
> > > draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
>=20
> Do not support either of these.
>=20
> From the oam-config-fwk draft:
> > A new useful application of RSVP-TE is OAM configuration=20
> and control=20
> > for transport networks.
>=20
> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why=20
> do we need another mechanism? What are the limitations of=20
> lsp-ping that warrant this new mechanism?
>=20
> > When RSVP-TE is used for LSP establishment it is desirable=20
> to bind OAM=20
> > setup to connection establishment signalling to avoid two separate=20
> > management/configuration steps
>=20
> draft-ietf-bfd-mpls specifies how to use LSP-Ping for=20
> automatic setup of BFD-based OAM.
> We should go along the same path for Ethernet OAM.
>=20
> Thanks
> Nitin
>=20
>=20

Delivery-date: Tue, 02 Dec 2008 21:49:40 +0000
Date: Tue, 02 Dec 2008 16:49:15 -0500
Subject: Re: CCAMP drafts for adoption
From: "Thomas D. Nadeau" <[email-masked]>
To: Nitin Bahadur <[email-masked]>, Adrian Farrel <[email-masked]>, <[email-masked]>

    I agree with Nitin and do not support the adoption of these drafts.

    --Tom

On 12/2/08 4:35 PM, "Nitin Bahadur" <[email-masked]> wrote:
 
>>> draft-takacs-ccamp-oam-configuration-fwk-01.txt
>>> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> 
> Do not support either of these.
> 
> From the oam-config-fwk draft:
>> A new useful application of RSVP-TE is OAM configuration
>> and control for transport networks.
> 
> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we need
> another mechanism? What are the limitations of lsp-ping that warrant
> this new mechanism?
> 
>> When RSVP-TE is used for LSP establishment it is desirable to bind
>> OAM setup to connection establishment signalling to avoid two
>> separate management/configuration steps
> 
> draft-ietf-bfd-mpls specifies how to use LSP-Ping for automatic setup of
> BFD-based OAM.
> We should go along the same path for Ethernet OAM.
> 
> Thanks
> Nitin
> 

Delivery-date: Tue, 02 Dec 2008 21:49:29 +0000
To: "Adrian Farrel" <[email-masked]>
CC: [email-masked]
Subject: Re: CCAMP drafts for adoption 
Date: Tue, 2 Dec 2008 13:45:51 -0800
From: Yakov Rekhter <[email-masked]>

Adrian,

> Hi,
> 
> Can you please express your opinion on the adoption of the following 
> three drafts as WG drafts. 
> 
> Thanks,
> Adrian
> 
> draft-takacs-ccamp-oam-configuration-fwk-01.txt
> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt

I am opposed accepting these drafts as WG drafts.

Yakov.

Delivery-date: Tue, 02 Dec 2008 21:38:48 +0000
Content-Class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 13:35:19 -0800
From: Nitin Bahadur <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

> > draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt

Do not support either of these.

>From the oam-config-fwk draft:
> A new useful application of RSVP-TE is OAM configuration
> and control for transport networks.

LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we need
another mechanism? What are the limitations of lsp-ping that warrant
this new mechanism?

> When RSVP-TE is used for LSP establishment it is desirable to bind
> OAM setup to connection establishment signalling to avoid two
> separate management/configuration steps

draft-ietf-bfd-mpls specifies how to use LSP-Ping for automatic setup of
BFD-based OAM.
We should go along the same path for Ethernet OAM.

Thanks
Nitin

Delivery-date: Tue, 02 Dec 2008 21:00:32 +0000
Date: Tue, 02 Dec 2008 14:59:07 -0600
From: Lucy Yong <[email-masked]>
Subject: RE: CCAMP drafts for adoption
To: [email-masked]

Support all to become WG documents.
Cheer,
Lucy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Young Lee
> Sent: Tuesday, December 02, 2008 10:58 AM
> To: 'Adrian Farrel'; [email-masked]
> Subject: RE: CCAMP drafts for adoption
> 
> Support for all.
> 
> Young (I'm co-author of wson-encode)
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Adrian Farrel
> Sent: Tuesday, December 02, 2008 10:02 AM
> To: [email-masked]
> Subject: CCAMP drafts for adoption
> 
> Hi,
> 
> Can you please express your opinion on the adoption of the following three
> drafts as WG drafts.
> 
> Thanks,
> Adrian
> 
> draft-takacs-ccamp-oam-configuration-fwk-01.txt
> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)
> 
> Cheers,
> Adrian and Deborah
> 
> 
> 
> 
> 

Delivery-date: Tue, 02 Dec 2008 18:41:42 +0000
Date: Tue, 02 Dec 2008 10:41:19 -0800
From: Greg Bernstein <[email-masked]>
To: [email-masked]
CC: Jishnu A <[email-masked]>, "'ccamp'" <[email-masked]>
Subject: Re: [BULK]  VCAT/LCAS draft update...

Hi folks, the differential delay compensation capability is a property 
of VCAT (not LCAS) hence independent of whether LCAS is implemented or 
not. In SDH the MFI is used with VCAT (part of the H4 byte).

This issue has come up before. And at the time it seemed to belong with 
some the MLN work that kept track of "adaptation" properties. Right now 
it seems that differential delay compensation limits would need to be 
handled by network planning rather than the control plane.

Regards

Greg

Huub van Helvoort wrote:
> Hi Jishnu,
>
> you replied:
>
>> Adding to Hubb's reply below
>> The MFI field in LCAS allows support upto a maximum of 256ms 
>> differential
>> delay compensation for HO VC. But the exact value is completely 
>> depending on
>> the vendor implementation and can be anything between 125us to 256ms.
>
> This is information that is well known.
>
> Reading your initial email again I am confused by the
> additional reponse.
>
> Can you please inform us of what the issue is that you
> would like to resolve.
> And make a distinction between the two modes:
> ==  VCAT without LCAS
> ==  VCAT with  LCAS.
>
> Thank you, Huub.
>
>> -----Original Message-----
>> From: Huub van Helvoort [mailto:[email-masked]] Sent: Tuesday, 
>> December 02, 2008 9:34 PM
>> To: BRUNGARD, DEBORAH A, ATTLABS
>> Cc: Jishnu A; Greg Bernstein; ccamp
>> Subject: Re: [BULK] VCAT/LCAS draft update...
>> Importance: Low
>>
>> Hi Deborah,
>>
>> You replied:
>>
>>> Shouldn't be a problem if the data plane is based on ITU - so it would
>>> need to support (at minimum) ITU's G.707 minimum differential delay
>>> requirements for VCAT.
>>
>> Minimum delay in G.707 is 125 usec (micro-seconds)...
>>
>> Maximum differential delay depends on implementation.
>> Differential is the difference between the largest
>> propagation delay of one of the members and the
>> smallest propagation delay of one of the members.
>> The sink VCAT/LCAS function is capable of detecting
>> and reporting whether one or more members does not fit
>> the differential delay capability.
>>
>> Cheers, Huub.
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Jishnu A
>>> Sent: Tuesday, December 02, 2008 10:03 AM
>>> To: 'Greg Bernstein'
>>> Cc: 'ccamp'
>>> Subject: RE: [BULK] VCAT/LCAS draft update...
>>>
>>> Dear Greg,
>>> One additional problem with VCAT/LCAS is the amount of differential
>>> delay
>>> supported at the destination node. Can it be mentioned as a note that
>>> co-routing or diversely routing is also based on the availability of
>>> enough
>>> sufficient differential delay buffer size at the destination node?
>>> Regards,
>>> Jishnu A
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf
>>> Of Greg Bernstein
>>> Sent: Wednesday, November 19, 2008 12:07 AM
>>> To: ccamp
>>> Subject: [BULK] VCAT/LCAS draft update...
>>> Importance: Low
>>>
>>> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES 
>>> object
>>>
>>> from the MLN extensions draft.
>>> We define a new VCAT TLV for use in the aforementioned object.  All 
>>> procedures and encodings otherwise are the same as the previous 
>>> draft. Note that the draft will now be contingent on the MLN 
>>> extensions draft moving forward.
>>>
>>> A URL for the Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. 
>>>
>>> txt
>>>
>>>
>>> Regards
>>>
>>> Greg
>>>
>>
>

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

Delivery-date: Tue, 02 Dec 2008 18:38:43 +0000
From: "Jishnu A" <[email-masked]>
To: <[email-masked]>
Cc: "'Greg Bernstein'" <[email-masked]>, "'ccamp'" <[email-masked]>
Subject: RE: [BULK]  VCAT/LCAS draft update...
Date: Wed, 3 Dec 2008 00:06:48 +0530

Dear Hubb,
As there is a note on Fixed co-routed about this being needed to minimize
the differential delay, same could be added for Dynamic, co-routed also.

"Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or decreased
via the addition or removal of member signals), transported over a co-routed
set of members.  The intent here is dynamic resizing and resilience of
bandwidth at the same time minimizing the differential delay."

Is it left out as it is obvious? 

Also the document does not mention why one needs to minimize the
differential delay. Again, is it assumed that this is well known and left
out? 

Regards,
Jishnu A

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2008 11:02 PM
To: Jishnu A
Cc: 'Greg Bernstein'; 'ccamp'
Subject: Re: [BULK] VCAT/LCAS draft update...
Importance: Low

Hi Jishnu,

you replied:

> Adding to Hubb's reply below
> The MFI field in LCAS allows support upto a maximum of 256ms differential
> delay compensation for HO VC. But the exact value is completely depending
on
> the vendor implementation and can be anything between 125us to 256ms.

This is information that is well known.

Reading your initial email again I am confused by the
additional reponse.

Can you please inform us of what the issue is that you
would like to resolve.
And make a distinction between the two modes:
==  VCAT without LCAS
==  VCAT with  LCAS.

Thank you, Huub.

> -----Original Message-----
> From: Huub van Helvoort [mailto:[email-masked]] 
> Sent: Tuesday, December 02, 2008 9:34 PM
> To: BRUNGARD, DEBORAH A, ATTLABS
> Cc: Jishnu A; Greg Bernstein; ccamp
> Subject: Re: [BULK] VCAT/LCAS draft update...
> Importance: Low
> 
> Hi Deborah,
> 
> You replied:
> 
>> Shouldn't be a problem if the data plane is based on ITU - so it would
>> need to support (at minimum) ITU's G.707 minimum differential delay
>> requirements for VCAT.
> 
> Minimum delay in G.707 is 125 usec (micro-seconds)...
> 
> Maximum differential delay depends on implementation.
> Differential is the difference between the largest
> propagation delay of one of the members and the
> smallest propagation delay of one of the members.
> The sink VCAT/LCAS function is capable of detecting
> and reporting whether one or more members does not fit
> the differential delay capability.
> 
> Cheers, Huub.
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Jishnu A
>> Sent: Tuesday, December 02, 2008 10:03 AM
>> To: 'Greg Bernstein'
>> Cc: 'ccamp'
>> Subject: RE: [BULK] VCAT/LCAS draft update...
>>
>> Dear Greg,
>> One additional problem with VCAT/LCAS is the amount of differential
>> delay
>> supported at the destination node. Can it be mentioned as a note that
>> co-routing or diversely routing is also based on the availability of
>> enough
>> sufficient differential delay buffer size at the destination node? 
>>
>> Regards,
>> Jishnu A
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf
>> Of Greg Bernstein
>> Sent: Wednesday, November 19, 2008 12:07 AM
>> To: ccamp
>> Subject: [BULK] VCAT/LCAS draft update...
>> Importance: Low
>>
>> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object
>>
>> from the MLN extensions draft.
>> We define a new VCAT TLV for use in the aforementioned object.  All 
>> procedures and encodings otherwise are the same as the previous draft. 
>> Note that the draft will now be contingent on the MLN extensions draft 
>> moving forward.
>>
>> A URL for the Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06.
>> txt
>>
>>
>> Regards
>>
>> Greg
>>
> 

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3658 (20081202) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3658 (20081202) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Delivery-date: Tue, 02 Dec 2008 17:33:28 +0000
Date: Tue, 02 Dec 2008 18:32:08 +0100
From: Huub van Helvoort <[email-masked]>
Reply-To: [email-masked]
To: Jishnu A <[email-masked]>
CC: "'Greg Bernstein'" <[email-masked]>, "'ccamp'" <[email-masked]>
Subject: Re: [BULK]  VCAT/LCAS draft update...

Hi Jishnu,

you replied:

> Adding to Hubb's reply below
> The MFI field in LCAS allows support upto a maximum of 256ms differential
> delay compensation for HO VC. But the exact value is completely depending on
> the vendor implementation and can be anything between 125us to 256ms.

This is information that is well known.

Reading your initial email again I am confused by the
additional reponse.

Can you please inform us of what the issue is that you
would like to resolve.
And make a distinction between the two modes:
==  VCAT without LCAS
==  VCAT with  LCAS.

Thank you, Huub.

> -----Original Message-----
> From: Huub van Helvoort [mailto:[email-masked]] 
> Sent: Tuesday, December 02, 2008 9:34 PM
> To: BRUNGARD, DEBORAH A, ATTLABS
> Cc: Jishnu A; Greg Bernstein; ccamp
> Subject: Re: [BULK] VCAT/LCAS draft update...
> Importance: Low
> 
> Hi Deborah,
> 
> You replied:
> 
>> Shouldn't be a problem if the data plane is based on ITU - so it would
>> need to support (at minimum) ITU's G.707 minimum differential delay
>> requirements for VCAT.
> 
> Minimum delay in G.707 is 125 usec (micro-seconds)...
> 
> Maximum differential delay depends on implementation.
> Differential is the difference between the largest
> propagation delay of one of the members and the
> smallest propagation delay of one of the members.
> The sink VCAT/LCAS function is capable of detecting
> and reporting whether one or more members does not fit
> the differential delay capability.
> 
> Cheers, Huub.
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Jishnu A
>> Sent: Tuesday, December 02, 2008 10:03 AM
>> To: 'Greg Bernstein'
>> Cc: 'ccamp'
>> Subject: RE: [BULK] VCAT/LCAS draft update...
>>
>> Dear Greg,
>> One additional problem with VCAT/LCAS is the amount of differential
>> delay
>> supported at the destination node. Can it be mentioned as a note that
>> co-routing or diversely routing is also based on the availability of
>> enough
>> sufficient differential delay buffer size at the destination node? 
>>
>> Regards,
>> Jishnu A
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf
>> Of Greg Bernstein
>> Sent: Wednesday, November 19, 2008 12:07 AM
>> To: ccamp
>> Subject: [BULK] VCAT/LCAS draft update...
>> Importance: Low
>>
>> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object
>>
>> from the MLN extensions draft.
>> We define a new VCAT TLV for use in the aforementioned object.  All 
>> procedures and encodings otherwise are the same as the previous draft. 
>> Note that the draft will now be contingent on the MLN extensions draft 
>> moving forward.
>>
>> A URL for the Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06.
>> txt
>>
>>
>> Regards
>>
>> Greg
>>
> 

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

Delivery-date: Tue, 02 Dec 2008 16:58:55 +0000
Date: Tue, 02 Dec 2008 10:58:15 -0600
From: Young Lee <[email-masked]>
Subject: RE: CCAMP drafts for adoption
To: 'Adrian Farrel' <[email-masked]>, [email-masked]

Support for all.

Young (I'm co-author of wson-encode)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: Tuesday, December 02, 2008 10:02 AM
To: [email-masked]
Subject: CCAMP drafts for adoption

Hi,

Can you please express your opinion on the adoption of the following three 
drafts as WG drafts.

Thanks,
Adrian

draft-takacs-ccamp-oam-configuration-fwk-01.txt
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)

Cheers,
Adrian and Deborah 

Delivery-date: Tue, 02 Dec 2008 16:52:52 +0000
Date: Tue, 02 Dec 2008 08:51:40 -0800
From: Greg Bernstein <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: CCAMP drafts for adoption

Support wson-encode. Yes, I'm a co-author...

Greg

Adrian Farrel wrote:
> Hi,
>
> Can you please express your opinion on the adoption of the following 
> three drafts as WG drafts.
>
> Thanks,
> Adrian
>
> draft-takacs-ccamp-oam-configuration-fwk-01.txt
> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)
>
> Cheers,
> Adrian and Deborah
>
>
>

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

Delivery-date: Tue, 02 Dec 2008 16:48:03 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 10:47:41 -0600
From: "Howard Green" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Yes to all three.
Howard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, December 02, 2008 8:02 AM
To: [email-masked]
Subject: CCAMP drafts for adoption

Hi,

Can you please express your opinion on the adoption of the following
three drafts as WG drafts.

Thanks,
Adrian

draft-takacs-ccamp-oam-configuration-fwk-01.txt
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)

Cheers,
Adrian and Deborah=20

Delivery-date: Tue, 02 Dec 2008 16:46:04 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 17:44:17 +0100
From: "Diego Caviglia" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Yes to all.

BR

Diego

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On =
Behalf
> Of Adrian Farrel
> Sent: marted=EC 2 dicembre 2008 17.02
> To: [email-masked]
> Subject: CCAMP drafts for adoption
>=20
> Hi,
>=20
> Can you please express your opinion on the adoption of the following =
three
> drafts as WG drafts.
>=20
> Thanks,
> Adrian
>=20
> draft-takacs-ccamp-oam-configuration-fwk-01.txt
> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)
>=20
> Cheers,
> Adrian and Deborah
>=20
>=20

Delivery-date: Tue, 02 Dec 2008 16:39:52 +0000
From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= <[email-masked]>
To: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 2 Dec 2008 17:39:17 +0100
Subject: RE: CCAMP drafts for adoption
Accept-Language: en-US
acceptlanguage: en-US

Hi,

I support wson-encode.

Regards,
Jonas

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: den 2 december 2008 17:02
> To: [email-masked]
> Subject: CCAMP drafts for adoption
>
> Hi,
>
> Can you please express your opinion on the adoption of the
> following three drafts as WG drafts.
>
> Thanks,
> Adrian
>
> draft-takacs-ccamp-oam-configuration-fwk-01.txt
> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)
>
> Cheers,
> Adrian and Deborah
>
>
>
>
>
>

Delivery-date: Tue, 02 Dec 2008 16:36:01 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "'ccamp'" <[email-masked]>
Subject: Re: VCAT/LCAS draft update...
Date: Tue, 2 Dec 2008 16:35:30 -0000

Questions:

Is this something that anyone would ever do without LCAS?

Are there information elements we need to exchange before LSPs are set up 
(i.e. on the Call)?

How much of this is dependent on measurements once LSPs are set up, rather 
than before they are set up?

Thanks,
Adrian
----- Original Message ----- 
From: "Jishnu A" <[email-masked]>
To: <[email-masked]>; "'BRUNGARD, DEBORAH A, ATTLABS'" 
<[email-masked]>
Cc: "'Greg Bernstein'" <[email-masked]>; "'ccamp'" 
<[email-masked]>
Sent: Tuesday, December 02, 2008 4:28 PM
Subject: RE: [BULK] VCAT/LCAS draft update...

> Adding to Hubb's reply below
> The MFI field in LCAS allows support upto a maximum of 256ms differential
> delay compensation for HO VC. But the exact value is completely depending 
> on
> the vendor implementation and can be anything between 125us to 256ms.
> Regards,
> Jishnu A
>
> -----Original Message-----
> From: Huub van Helvoort [mailto:[email-masked]]
> Sent: Tuesday, December 02, 2008 9:34 PM
> To: BRUNGARD, DEBORAH A, ATTLABS
> Cc: Jishnu A; Greg Bernstein; ccamp
> Subject: Re: [BULK] VCAT/LCAS draft update...
> Importance: Low
>
> Hi Deborah,
>
> You replied:
>
>> Shouldn't be a problem if the data plane is based on ITU - so it would
>> need to support (at minimum) ITU's G.707 minimum differential delay
>> requirements for VCAT.
>
> Minimum delay in G.707 is 125 usec (micro-seconds)...
>
> Maximum differential delay depends on implementation.
> Differential is the difference between the largest
> propagation delay of one of the members and the
> smallest propagation delay of one of the members.
> The sink VCAT/LCAS function is capable of detecting
> and reporting whether one or more members does not fit
> the differential delay capability.
>
> Cheers, Huub.
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Jishnu A
>> Sent: Tuesday, December 02, 2008 10:03 AM
>> To: 'Greg Bernstein'
>> Cc: 'ccamp'
>> Subject: RE: [BULK] VCAT/LCAS draft update...
>>
>> Dear Greg,
>> One additional problem with VCAT/LCAS is the amount of differential
>> delay
>> supported at the destination node. Can it be mentioned as a note that
>> co-routing or diversely routing is also based on the availability of
>> enough
>> sufficient differential delay buffer size at the destination node?
>>
>> Regards,
>> Jishnu A
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf
>> Of Greg Bernstein
>> Sent: Wednesday, November 19, 2008 12:07 AM
>> To: ccamp
>> Subject: [BULK] VCAT/LCAS draft update...
>> Importance: Low
>>
>> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object
>>
>> from the MLN extensions draft.
>> We define a new VCAT TLV for use in the aforementioned object.  All
>> procedures and encodings otherwise are the same as the previous draft.
>> Note that the draft will now be contingent on the MLN extensions draft
>> moving forward.
>>
>> A URL for the Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06.
>> txt
>>
>>
>> Regards
>>
>> Greg
>>
>
> -- 
> ================================================================
>                   http://www.van-helvoort.eu/
> ================================================================
> Always remember that you are unique...just like everyone else...
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature
> database 3658 (20081202) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus 
> signature
> database 3658 (20081202) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> 

Delivery-date: Tue, 02 Dec 2008 16:29:28 +0000
From: "Jishnu A" <[email-masked]>
To: <[email-masked]>, "'BRUNGARD, DEBORAH A, ATTLABS'" <[email-masked]>
Cc: "'Greg Bernstein'" <[email-masked]>, "'ccamp'" <[email-masked]>
Subject: RE: [BULK]  VCAT/LCAS draft update...
Date: Tue, 2 Dec 2008 21:58:34 +0530

Adding to Hubb's reply below
The MFI field in LCAS allows support upto a maximum of 256ms differential
delay compensation for HO VC. But the exact value is completely depending on
the vendor implementation and can be anything between 125us to 256ms.
Regards,
Jishnu A

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2008 9:34 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: Jishnu A; Greg Bernstein; ccamp
Subject: Re: [BULK] VCAT/LCAS draft update...
Importance: Low

Hi Deborah,

You replied:

> Shouldn't be a problem if the data plane is based on ITU - so it would
> need to support (at minimum) ITU's G.707 minimum differential delay
> requirements for VCAT.

Minimum delay in G.707 is 125 usec (micro-seconds)...

Maximum differential delay depends on implementation.
Differential is the difference between the largest
propagation delay of one of the members and the
smallest propagation delay of one of the members.
The sink VCAT/LCAS function is capable of detecting
and reporting whether one or more members does not fit
the differential delay capability.

Cheers, Huub.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jishnu A
> Sent: Tuesday, December 02, 2008 10:03 AM
> To: 'Greg Bernstein'
> Cc: 'ccamp'
> Subject: RE: [BULK] VCAT/LCAS draft update...
> 
> Dear Greg,
> One additional problem with VCAT/LCAS is the amount of differential
> delay
> supported at the destination node. Can it be mentioned as a note that
> co-routing or diversely routing is also based on the availability of
> enough
> sufficient differential delay buffer size at the destination node? 
> 
> Regards,
> Jishnu A
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> Of Greg Bernstein
> Sent: Wednesday, November 19, 2008 12:07 AM
> To: ccamp
> Subject: [BULK] VCAT/LCAS draft update...
> Importance: Low
> 
> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object
> 
> from the MLN extensions draft.
> We define a new VCAT TLV for use in the aforementioned object.  All 
> procedures and encodings otherwise are the same as the previous draft. 
> Note that the draft will now be contingent on the MLN extensions draft 
> moving forward.
> 
> A URL for the Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06.
> txt
> 
> 
> Regards
> 
> Greg
> 

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3658 (20081202) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3658 (20081202) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Delivery-date: Tue, 02 Dec 2008 16:23:05 +0000
Content-class: urn:content-classes:message
Subject: RE: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 11:22:20 -0500
From: "David Allan" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi Adrian:

Support oam-conf
Support oam-ext
Abstain wson-encode

Cheers
Dave=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, December 02, 2008 11:02 AM
To: [email-masked]
Subject: CCAMP drafts for adoption

Hi,

Can you please express your opinion on the adoption of the following
three drafts as WG drafts.

Thanks,
Adrian

draft-takacs-ccamp-oam-configuration-fwk-01.txt
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)

Cheers,
Adrian and Deborah=20

Delivery-date: Tue, 02 Dec 2008 16:16:34 +0000
Content-class: urn:content-classes:message
Subject: RE: [BULK]  VCAT/LCAS draft update...
Date: Tue, 2 Dec 2008 17:15:28 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi all.

I would even add that the diversely routing scenario is not different in =
GMPLS from configuration-based provisioning: from the data plane point =
of view, nothing is new.

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Huub van Helvoort

Hi Deborah,

You replied:

> Shouldn't be a problem if the data plane is based on ITU - so it would
> need to support (at minimum) ITU's G.707 minimum differential delay
> requirements for VCAT.

Minimum delay in G.707 is 125 usec (micro-seconds)...

Maximum differential delay depends on implementation.
Differential is the difference between the largest
propagation delay of one of the members and the
smallest propagation delay of one of the members.
The sink VCAT/LCAS function is capable of detecting
and reporting whether one or more members does not fit
the differential delay capability.

Cheers, Huub.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
>=20
> Dear Greg,
> One additional problem with VCAT/LCAS is the amount of differential
> delay
> supported at the destination node. Can it be mentioned as a note that
> co-routing or diversely routing is also based on the availability of
> enough
> sufficient differential delay buffer size at the destination node?=20
>=20
> Regards,
> Jishnu A
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> Of Greg Bernstein
> Sent: Wednesday, November 19, 2008 12:07 AM
> To: ccamp
> Subject: [BULK] VCAT/LCAS draft update...
> Importance: Low
>=20
> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES =
object
>=20
> from the MLN extensions draft.
> We define a new VCAT TLV for use in the aforementioned object.  All=20
> procedures and encodings otherwise are the same as the previous draft. =

> Note that the draft will now be contingent on the MLN extensions draft =

> moving forward.
>=20
> A URL for the Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06.
> txt
>=20
>=20
> Regards
>=20
> Greg
>=20

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
                   http://www.van-helvoort.eu/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Always remember that you are unique...just like everyone else...

Delivery-date: Tue, 02 Dec 2008 16:04:52 +0000
Date: Tue, 02 Dec 2008 17:04:02 +0100
From: Huub van Helvoort <[email-masked]>
Reply-To: [email-masked]
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
CC: Jishnu A <[email-masked]>, Greg Bernstein <[email-masked]>, ccamp <[email-masked]>
Subject: Re: [BULK]  VCAT/LCAS draft update...

Hi Deborah,

You replied:

> Shouldn't be a problem if the data plane is based on ITU - so it would
> need to support (at minimum) ITU's G.707 minimum differential delay
> requirements for VCAT.

Minimum delay in G.707 is 125 usec (micro-seconds)...

Maximum differential delay depends on implementation.
Differential is the difference between the largest
propagation delay of one of the members and the
smallest propagation delay of one of the members.
The sink VCAT/LCAS function is capable of detecting
and reporting whether one or more members does not fit
the differential delay capability.

Cheers, Huub.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jishnu A
> Sent: Tuesday, December 02, 2008 10:03 AM
> To: 'Greg Bernstein'
> Cc: 'ccamp'
> Subject: RE: [BULK] VCAT/LCAS draft update...
> 
> Dear Greg,
> One additional problem with VCAT/LCAS is the amount of differential
> delay
> supported at the destination node. Can it be mentioned as a note that
> co-routing or diversely routing is also based on the availability of
> enough
> sufficient differential delay buffer size at the destination node? 
> 
> Regards,
> Jishnu A
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> Of Greg Bernstein
> Sent: Wednesday, November 19, 2008 12:07 AM
> To: ccamp
> Subject: [BULK] VCAT/LCAS draft update...
> Importance: Low
> 
> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object
> 
> from the MLN extensions draft.
> We define a new VCAT TLV for use in the aforementioned object.  All 
> procedures and encodings otherwise are the same as the previous draft. 
> Note that the draft will now be contingent on the MLN extensions draft 
> moving forward.
> 
> A URL for the Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06.
> txt
> 
> 
> Regards
> 
> Greg
> 

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

Delivery-date: Tue, 02 Dec 2008 16:02:30 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: CCAMP drafts for adoption
Date: Tue, 2 Dec 2008 16:01:48 -0000

Hi,

Can you please express your opinion on the adoption of the following three 
drafts as WG drafts.

Thanks,
Adrian

draft-takacs-ccamp-oam-configuration-fwk-01.txt
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)

Cheers,
Adrian and Deborah 

Delivery-date: Tue, 02 Dec 2008 15:49:41 +0000
Content-class: urn:content-classes:message
Subject: RE: [BULK]  VCAT/LCAS draft update...
Date: Tue, 2 Dec 2008 10:48:50 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: "Jishnu A" <[email-masked]>, "Greg Bernstein" <[email-masked]>
Cc: "ccamp" <[email-masked]>

Shouldn't be a problem if the data plane is based on ITU - so it would
need to support (at minimum) ITU's G.707 minimum differential delay
requirements for VCAT.
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jishnu A
Sent: Tuesday, December 02, 2008 10:03 AM
To: 'Greg Bernstein'
Cc: 'ccamp'
Subject: RE: [BULK] VCAT/LCAS draft update...

Dear Greg,
One additional problem with VCAT/LCAS is the amount of differential
delay
supported at the destination node. Can it be mentioned as a note that
co-routing or diversely routing is also based on the availability of
enough
sufficient differential delay buffer size at the destination node?=20

Regards,
Jishnu A

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf
Of Greg Bernstein
Sent: Wednesday, November 19, 2008 12:07 AM
To: ccamp
Subject: [BULK] VCAT/LCAS draft update...
Importance: Low

Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object

from the MLN extensions draft.
We define a new VCAT TLV for use in the aforementioned object.  All=20
procedures and encodings otherwise are the same as the previous draft.=20
Note that the draft will now be contingent on the MLN extensions draft=20
moving forward.

A URL for the Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06.
txt

Regards

Greg

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

=20

__________ Information from ESET NOD32 Antivirus, version of virus
signature
database 3623 (20081118) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
=20
=20

__________ Information from ESET NOD32 Antivirus, version of virus
signature
database 3658 (20081202) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
=20

Delivery-date: Tue, 02 Dec 2008 15:05:52 +0000
From: "Jishnu A" <[email-masked]>
To: "'Greg Bernstein'" <[email-masked]>
Cc: "'ccamp'" <[email-masked]>
Subject: RE: [BULK]  VCAT/LCAS draft update...
Date: Tue, 2 Dec 2008 20:33:11 +0530

Dear Greg,
One additional problem with VCAT/LCAS is the amount of differential delay
supported at the destination node. Can it be mentioned as a note that
co-routing or diversely routing is also based on the availability of enough
sufficient differential delay buffer size at the destination node? 

Regards,
Jishnu A

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Greg Bernstein
Sent: Wednesday, November 19, 2008 12:07 AM
To: ccamp
Subject: [BULK] VCAT/LCAS draft update...
Importance: Low

Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object 
from the MLN extensions draft.
We define a new VCAT TLV for use in the aforementioned object.  All 
procedures and encodings otherwise are the same as the previous draft. 
Note that the draft will now be contingent on the MLN extensions draft 
moving forward.

A URL for the Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06.txt

Regards

Greg

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

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3623 (20081118) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3658 (20081202) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com