[CCAMP] Proposed communication to OIF on Inverse Multiplexing

["BRUNGARD, DEBORAH A (ATTLABS)" <[e-mail]>]

CCAMP,

We need to send a communication to OIF in response to their Oct. 22nd
communication.

Let us know if any comments on this proposal.

Deborah and Lou

--------Proposal---------------------

Dear Lyndon,

In your October 22nd communication, you requested consideration of a
draft on inverse multiplexing "draft-roch-ccamp-gmpls-inv-mux-00.txt".

This document was introduced at November's meeting.

During CCAMP's Working Group Last Call discussion of
"draft-ietf-ccamp-vcat-lcas", the use cases in
draft-roch-ccamp-gmpls-inv-mux-00.txt as compared to the scope of
draft-ietf-ccamp-vcat-lcas-08.txt were discussed. The use cases and 
ietms raised in draft-roch-ccamp-gmpls-inv-mux as we understand it are 
as follows:
1.  IMG members are (statically) provisioned.
2.  Members might be separately administered and policies may 
prevent signaling control information related to the IMG to be exchanged

in the member signaling.
3. Control plane does not allow piggybacking of IMG information onto 
its own signaling.

The use cases represented in 1. and 2. were considered out-of-scope of 
the CCAMP document.  The scope of the CCAMP document is to support only 
scenarios where all members are signaled using the defined mechanism.
CCAMP support for new functionality must be raised within the
Working Group. We suggest that further discussion on these use cases 
take place based on an updated Internet Draft which is based on existing

CCAMP work, i.e., draft-ietf-ccamp-vcat-lcas, which has passed last
call.

With respect to item 3, in the existing CCAMP work, only the VCAT 
end-points participate in signaling the IMG information, i.e., the 
intermediate signaling nodes do not participate in the VCAT call setup. 
If the end points do not support the CCAMP VCAT signaling mechanism, 
VCAT isn't provided.  Again, the scope of the current work is to support

only scenarios where all members are signaled using the defined
extension.

We welcome future contributions defining your requirements in the form 
of Internet-drafts.  Please note that draft-ietf-ccamp-vcat-lcas is a 
product of the Working Group.  As such, the Working Group will be 
focused on the reuse of this work in any future related work. As always,
we 
encourage you to follow RFC4929's defined process.

Regards,
Lou Berger and Deborah Brungard
IETF CCAMP Working Group Co-Chairs