Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

Please comment on this draft response liaison which I intend to send on
Monday 25th July.
You can see the original incoming liaison at
http://www.olddog.co.uk/incoming.htm

Thanks,
Adrian
=====
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: August 31st 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

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

Correct.

- 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