Furthre draft to OIF : VCAT

["Adrian Farrel" <[e-mail]>]

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