Subject: [CCAMP] Request for review: draft-roch-ccamp-gmpls-inv-mux-00

From: "Sadler, Jonathan B." <[email-masked]>
Date: Wed, 11 Nov 2009 21:07:14 -0600

Hello all,

In today's CCAMP session, I presented a draft that was mentioned in the liaison from the OIF on signaling for inverse multiplexing groups.  This draft can be found here:
  http://www.ietf.org/id/draft-roch-ccamp-gmpls-inv-mux-00.txt

As mentioned in section 3 of the draft as well as the presentation, this is being proposed as a generalized mechanism that can be used by different technologies (e.g. IEEE 802.1AX, BONDING or IMA configuration) as well as different business relationships between the:
 - provider of the underlying connections
 - provider of the inverse multiplexing service
 - provider of the end-to-end service which in part is utilizing the inverse multiplexing service

The draft states that while the VCAT configuration mechanism proposed in draft-ietf-ccamp-gmpls-vcat-lcas provides for configuration of VCAT, it does not meet the conditions above.  This stems from an assumption that the control plane used for the underlying connections is available for the signaling for the inverse multiplexing service (the draft calls this "piggybacking").  This is not a safe assumption when the underlying connections are provided by a separate business entity, it is possible that:
 - the endpoints of the underlying connections are statically configured (e.g. a control plane may or may not be used in the middle but is definitely not available to the endpoint.  This is similar to the use case described in draft-jenkins-mpls-tp-bt-requirements)
 - this entity may not be interested in providing the end-to-end signaling of anything other than the individual STS-1s (i.e. it will not pass the NOTIFY containing CALL setup).
Hence, the proposal of this alternate method.

My co-author and myself would appreciate the review of this draft by CCAMP participants and any comments you may have.  Please feel free to send them on or off list.

Jonathan Sadler

---

From: "Stephen Shew" <[email-masked]>
Date: Mon, 16 Nov 2009 16:42:28 -0500

Jonathan, I support the proposal in draft-roch-ccamp-gmpls-inv-mux-00 as
I agree with the independence assumptions between the inverse mux group
and possible constituents of the group.  Signalling protocols I have
worked on have been quite careful to not support carriage of information
that is not strictly associated with just the service as it could
compromise the value/revenue of the payload itself and possibly be a
security hole.  From a design perspective, if the inverse mux service
itself is a constituent of an inverse mux, then you get into the problem
of larger and larger signalling messages if the piggybacking method is
used.
 
Stephen

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sadler, Jonathan B.
Sent: 11 November, 2009 22:07
To: [email-masked]
Subject: [CCAMP] Request for review: draft-roch-ccamp-gmpls-inv-mux-00

Hello all,
 
In today's CCAMP session, I presented a draft that was mentioned in the
liaison from the OIF on signaling for inverse multiplexing groups.  This
draft can be found here:
  http://www.ietf.org/id/draft-roch-ccamp-gmpls-inv-mux-00.txt
 
As mentioned in section 3 of the draft as well as the presentation, this
is being proposed as a generalized mechanism that can be used by
different technologies (e.g. IEEE 802.1AX, BONDING or IMA configuration)
as well as different business relationships between the:
 - provider of the underlying connections
 - provider of the inverse multiplexing service
 - provider of the end-to-end service which in part is utilizing the
inverse multiplexing service
 
The draft states that while the VCAT configuration mechanism proposed in
draft-ietf-ccamp-gmpls-vcat-lcas provides for configuration of VCAT, it
does not meet the conditions above.  This stems from an assumption that
the control plane used for the underlying connections is available for
the signaling for the inverse multiplexing service (the draft calls this
"piggybacking").  This is not a safe assumption when the underlying
connections are provided by a separate business entity, it is possible
that:
 - the endpoints of the underlying connections are statically configured
(e.g. a control plane may or may not be used in the middle but is
definitely not available to the endpoint.  This is similar to the use
case described in draft-jenkins-mpls-tp-bt-requirements)
 - this entity may not be interested in providing the end-to-end
signaling of anything other than the individual STS-1s (i.e. it will not
pass the NOTIFY containing CALL setup).
Hence, the proposal of this alternate method.
 
My co-author and myself would appreciate the review of this draft by
CCAMP participants and any comments you may have.  Please feel free to
send them on or off list.
 
Jonathan Sadler