[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Furthre draft to OIF : VCAT

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