[CCAMP] Overdue announcement: Communications received from the OIF, 23rd July 2009 (1/2)

[Lou Berger <[e-mail]>]

The following was sent to the CCAMP WG chairs on July 23rd, 2009.  A
URL to the original communication (pdf) can be found below.  The text in
the communication is also enclosed.

This communication should have been announced prior to the last IETF.

A full list of Communications and Liaisons to and from CCAMP can be
found at:
http://trac.tools.ietf.org/wg/ccamp/trac/wiki/CommsLiasons

Lou
------------------------------------------------------------------
[http://trac.tools.ietf.org/wg/ccamp/trac/raw-attachment/ticket/14/oif2009.252.03.pdf]

July 23, 2009

Mr. Lou Berger, [e-mail], IETF CCAMP Co‐Chair
Ms. Deborah Brungard, [e-mail], IETF CCAMP Co‐Chair
Cc: Ross Callon, [e-mail], IETF Routing Area Director
David Ward, [e-mail], IETF Routing Area Director
From: Lyndon Ong, [e-mail], OIF Technical Committee Chair

Dear Lou and Deborah,

OIF has previously exchanged liaisons with IETF CCAMP WG regarding
support of routing extensions to meet OIF members’ needs for optical
network routing (see liaisons from OIF to CCAMP of Feb. 14, 2008 and
Feb. 5, 2009 and associated responses from IETF CCAMP WG).

Some of IETF CCAMP’s work following these interactions is being
incorporated into OIF work, esp.

a) The ability to specify additional identifiers for the endpoints of an
advertised link, using the Local and Remote TE Router ID sub‐TLV defined
in draft-ietf-ccamp-gmpls-ason-routing-ospf- 08.t

b) The ability to specify node local prefixes (in OIF associated with
client entities reachable from a particular link endpoint), using the
Node Attribute TLV, and its Local TE Router ID and Node Local Prefix
sub-TLVs, all defined in
draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt.

However, there continue to be some OIF requirements not yet met by the
extensions defined in the above CCAMP work, as we understand it. OIF
requests that IETF CCAMP consider additional extensions for the
following:

1. Layer-scoped link attributes, including layer-specific bandwidth or
connection availability

In previous discussion with CCAMP, there may have been some
miscommunication concerning what was meant by “layer-scoped” or
“layer-specific”. An example is for a link that may be used for VC-3 or
VC-4 connections, which are considered separate layers in the ITU-T
model.  An attribute such as number of available connections may not be
accurately derivable from the overall link bandwidth due to issues with
positioning of occupied timeslots. An attribute such as link metric and
link resource class may either be identical for all layers supported by
the link or be different depending on the specific layer
network. Current protocol does not support specification of attributes
in this level of detail.

2. Link associated local connection type

In previous discussion with CCAMP, the use of the ISCD and IACD sub-TLVs
was suggested as a way of advertising the ability of the link to either
switch or terminate and adapt an incoming signal. We believe that the
IACD, as defined in draft-ietf-ccamp-gmpls-mln-extensions-06.txt, may be
very helpful for control of multi-layer/multi-region networks and will
be looking at potential use of the IACD in future. However, we believe
that ISCD/IACD may not be the best method of supporting the local
connection type indication for the following reasons:

- When both ISCD and IACD are present, it is possible to determine
whether the endpoint supports Connection Point (CP) or Termination
Connection Point (TCP) functionality or both.  However, since only the
ISCD is required to be always present, it is not possible to assure that
this determination can be made. Also, if only the ISCD is received, it
is ambiguous as to whether this should be interpreted as the endpoint
supporting CP functionality only, or whether this should be interpreted
as the endpoint (or associated routing controller) not supporting IACD.

- The current application for local connection type in OIF is not
related to multi-layer/multiregion but control plane use within a
layer. It would be preferable to be able to advertise local connection
type without requiring the receiver to also understand
multi-layer/multi-region routing, and define a method for advertising
local connection type that is separable from advertising adaptation
capabilities.

Local connection type also falls under the category of potentially
layer-scoped link attributes discussed above.

3. Advertisement of node local prefixes using NSAP format

CCAMP has approved extensions to the routing protocol to carry node
local prefixes in IPv4 and IPv6 format, however OIF members have
indicated that they see a need to advertise prefixes that are in other
formats, especially in NSAP format. This is not currently supported by
CCAMP documents.

We would welcome opinions or guidance from CCAMP on these three points
and look forward to proposals from interested parties in CCAMP to
address these needs. Thank you for your continued attention.

Best regards,
Lyndon Ong
OIF Technical Committee Chair