To: ITU-T SG15 Questions 12 and 14
From: IETF CCAMP Working Group
Subject: Response to your liaison on GMPLS/ASON Lexicography
For: Action
Deadline: September 30th 2005

The CCAMP Working Group would like to thank SG15 and especially Questions
12 and 14 for the time and effort they put into providing input and
feedback on the GMPLS/ASON lexicography Internet-Draft that is being
developed by CCAMP. Much of the material supplied as direct comments or as
mark-ups to the Internet-Draft has been incorporated into the latest
revision which is available at
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-03.txt
and is available for open discussion on the CCAMP mailing list.

In your liaison you state some assumptions which we would like to comment
on as follows.

- The purpose of the document is to enable those familiar with ASON
to understand GMPLS terminology in an ASON context

Correct.

- GMPLS terms are described informally in the document in a way that
is generally consistent with GMPLS (existing RFCs and work in progress)

While the definition of GMPLS terms would be helpful for understanding
GMPLS terms in a GMPLS context, that is not the purpose of this document.

- Based on these descriptions, interpretations of these GMPLS terms
in ASON terminology are provided

It is intended that the interpretation of the GMPLS terms is not based on
these descriptions, but based on the full meaning of the GMPLS terms. The
descriptions of the GMPLS terms are provided in this Internet-Draft for
context and a brief summary.

- CCAMP has primarily responsibility for the descriptions of GMPLS terms

CCAMP is primarily responsible for the specification of GMPLS protocols
and applicability, not just its terms. CCAMP is responsible for all of the
content of this Internet-Draft, but will depend heavily on SG15 for
assistance in providing suitable text for ASON interpretations as set out
below.

- Q12/15 has responsibility to provide input to the GMPLS-ASON
interpretations (based on the descriptions in this draft)

We welcome this assumption of responsibility by Q12/15 to provide input to
the Internet-Draft. While the Internet-Draft remains under the overall
editorial control of the CCAMP working group, we hope to be able to use
the text supplied by Q12/15 with only editorial changes.


Additionally, we welcome the pledge to continue work on this
Internet-Draft through correspondence on the Q12/15 mailing list, and
thank Q12/15 for assigning Ben Mack-Crane as the SG15 representative on
this matter. Ben has proved very helpful in clarifying and developing
comments received from SG15.


We have had several email exchanges with Ben about a few of the specific
comments made in your review of the 02 revision of the Internet-Draft.
Although he has taken these comments to the Q12/15 mailing list no
response has been received, perhaps due to pressure of time. We are taking
the opportunity to restate several questions here for your convenience and
would appreciate your answers as part of the response to this liaison.

1. Definition of a Resource (section 3.2)
You have supplied us with the simple text that says...
"In ASON applications:
A resource refers only to a link connection (e.g. VC-11,
VC-4 etc.)."

We would like to clarify this because we don't understand how
the original text is wrong. It used to say...
"ITU-T [should be ASON] terms for resource:
- Connection point (cp) in the context of link discovery
and resource management (allocation, binding into
cross-connects, etc.);
- Link connection or trail termination in the context of
routing, path computation and signaling."

Recall that we are talking about the ASON terms for what GMPLS
calls a resource. We think the following...
In ASON a link connection is an association of output cp on one
side of the link and input cp on the other side of the link. In
GMPLS by resource we mean in most of the cases the local end of
the resource (which is cp in ASON terminology). This is true in
the context of link discovery.

More importantly, this is also true in the context of a
signaling application. Specifically, when a GMPLS signaling
sub-system requests allocation of a resource, the GMPLS
Resource Manager allocates only the local end of the
resource. This happens on both sides of the link, that is, we
allocate input and output resources. This contrasts with ASON,
where there is a much more versatile LRM, and the connection
manager (signaling application) allocates link connections
only on the output side, leaving LRM to coordinate the
allocation with the neighbor.

However, in GMPLS TE advertisements we account only for
outgoing resources, that is, we don't advertise incoming
resources on the assumption that they match the outgoing
resources for the discovered TE links.

Bottom line: we believe that we should retain the previous
definitions, and have not made this change in the new
revision. We would like to discuss this point further with
Q12/15.

2. Link ends and Data links (Section 3.5 - was section 3.4)

2a.Although we understand that ASON does not require the concept
of a link end, GMPLS does. Therefore we should provide some
form of language to help people do the mapping.

The proposed new text from Q12/15 removes all reference to
link ends from the ASON section, and we feel this is a
mistake and propose the following text:
"In ASON, a GMPLS unidirectional data link end is a
collection of connection points from the same client
layer that are supported by a single trail termination
(access point)."

This text depends on the fact that a link end is described as
a set of resources that transfer traffic to a neighbor.

2b.The new text from Q12/15 gives us...
"A GMPLS data link is an ASON link supported by a single
server trail."

We are not sure that we understand this correctly. It
appears to say that a unidirectional data link could be
supported by multiple trail terminations (access points).
This seems to suggest that a client would have to make a
choice about where to send data, which seems to imply it
really has to choose between data links! We are confused!

We think some of this problem may come from the *need* in
GMPLS to identify data link ends. There may be some value in
stressing that a GMPLS link end is supported by exactly one
trail termination. When several trail terminations are
involved, we can still talk about single TE link (as a
bundle), but each component link will be a distinct data
link. We think that in ASON the SNPP (TE link in GMPLS
language) could be supported by multiple terminations.

3. Link interfaces (section 3.6 - was 3.5)
The new text from Q12/15 gives us...
"A GMPLS interface is "all the stuff between a physical
interface and a matrix in an ASON network element." More
precisely, it is a trail termination function and adaptation
function for which adapted client layer connection points
are bound to a matrix."

We think "physical interface" may be ambiguous in the multi-
layer context. We think the "stuff" should be between a link
and a matrix, since we are talking about links in distinct
layers.


In addition to your feedback on the specific points above, we would
welcome your continued comments and review of the Internet-Draft.

Regards,
Adrian Farrel and Kireeti Kompella
IETF CCAMP Working Group Co-chairs