Subject: IETF CCAMP Response to OIF on VCAT

From: "Adrian Farrel" <[email-masked]>
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