Response to Liaison Concerning the Comparison of LMP and ASON Discovery

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

To: Mr. Kam Lam, Rapporteur Q14/15
From: Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs
Cc: Alex Zinin and Bill Fenner, IETF Routing Area Directors
    Scott Bradner, IETF liaison to ITU-T
For: Information
Subject: Response to Liaison Concerning the Comparison of LMP and ASON
Discovery

Dear Kam,

The IETF CCAMP Working Group thanks ITU-T Q14/15 for their feedback on
draft-ietf-ccamp-transport-lmp-00.txt. It is always useful to have extra
review of our drafts, and since this draft attempts to explain ITU-T
concepts to the IETF audience, it is particularly helpful to your input.

>Q14/15 thanks the IETF CCAMP WG for providing us the draft document
><draft-ietf-ccamp-transport-lmp-00.txt>. This I-D was discussed at the
>meeting and several of the comments are provided below. Based upon
>this discussion we believe it would be highly beneficial to have some
>joint discussions on terminology to ensure an aligned view to
>facilitate our future work efforts.

Events have overtaken this liaison response and a meeting has been set up.
See the end of this liaison response for more comments.

Please see the reply to your specific issues in the following text.

>We have several questions of clarification, e.g., in section 3.1
>(paragraph 2) of the I-D, "The separation between the two processes and
>corresponding two name spaces has the advantage that the discovery of
>the transport plane can be performed independent from that of the
>control plane (and vice-versa), and independent of the method used in
>each name space. This allows assigning link connections in the control
>plane without the link connection being physically connected."
>
>What is the intention of the term independent, for example, could it be
>indicating at a different time or different approaches? In the last
>sentence, is "assign" used in the context of the management plane,
>meaning management plane provisioning? Is it assumed that the
>transport plane resources supporting the link connection endpoints
>exist or do not exist? In section 4.2 (paragraph 2) of the I-D, "G.8080
>refers to a component link as a variable adaptation function i.e. a
>single server layer trail dynamically supporting different multiplexing
>structures." This could be interpreted as indicating G.8080
>defines the term "component link". G.8080 does not use this
>term. Some clarification would be beneficial.

As this section of the draft indicates, it is summarizing G.8080 Discovery
(not LMP). The description is directly based on G.8080's text,
i.e.:

" This separation allows control plane names to be completely
  separate from transport plane names, and completely independent
  of the method used to populate the DAs with those transport names."

" In order to assign an SNP-SNP link connection to an SNPP link, it
  is only necessary for the transport name for the link connection to
  exist. Thus, it is possible to assign link connections to the control
  plane without the link connection being physically connected."

The authors will clarify for these paragraphs that we are quoting from
G.8080 (not describing LMP). In particular:

"G.8080 refers to a component link as a variable adaptation function" was
worded to present an interpretation of G.8080 from an IETF terminology
perspective; i.e. the LMP component link is referred to by G.8080 as a
variable adaptation function. The authors will clarify the text to say
"G.8080's variable adaptation function is broadly equivalent to LMP's
component link."

>Initial reviews of the draft document have raised concerns about the
>possible misinterpretation in the usage of the term 'TE link'. As the
>draft notes, the definition of a TE link is concise. Some more clarity
>would be appreciated. Our current understanding of this term includes
>the following: A TE link may be composed of resource from multiple
>(G.805) layers in parallel. If so, this is an important distinction as
>an SNPP link is in a single layer only. An SNPP link may contain SNP
>link connections from various links (e.g., different STS-1s from
>a set of parallel OC-48 trails). It is not clear if this is
>also true for TE links. We think it may, but it is not stated.
>SNPPs exist at different routing levels (not layers) and thus an
>SNPP link at a higher level can encompass SNPPs at a lower level
>(see Section 6.2.2 of G.8080 Amendment 2, which is attached for
>your convenience). We think TE links may do this with bundles
>and FAs, but the definition is not clear to us.
>
>Please advise if this is a correct understanding or not. This may have
>an impact on the terminology mapping in the draft. We think it would
>be beneficial to have a TE link definition that enables these
>distinctions to be understood.

It is not the intention of this draft to define a TE link. The TE link is
defined in the LMP draft (draft-ietf-ccamp-lmp-10.txt) through a
restatement of the definition in the GMPLS Routing draft
(draft-ietf-ccamp-gmpls-routing-09.txt).

At the request of several individuals we tried to bring clarity to the TE
link concept by additional explanation within this draft. The IETF
definition of the TE link describes the way that resources are grouped and
mapped for the purpose of path computation. Constraints on the physical
resources define what is possible rather than defining any elaborate
structures within the TE link.

Therefore an SNPP link could easily be mapped to a TE link.

There is a separation between the constraints of the physical resources
and the information aggregation of TE link. Bundling is a mechanism to
efficiently aggregate TE resources within the constraints of the physical
technology.

An LSP created across an LSP region (see
draft-ietf-mpls-lsp-hierarchy-08.txt) in the network may be assigned as a
TE link by an upper region and so appear as TE resources within the upper
region (just as any other TE link). Such a TE link is referred to as a
Forwarding Adjacency.

A TE link may contain STS-1s from parallel OC-48 trails.

The authors will add text to clarify.

>In the table in section 4.2 "CP" is mapped to "Interface". A
>Connection Point is more closely related to a timeslot, wavelength,
>etc. rather than to an entire interface. Similarly "CP Name" is mapped
>to "Interface ID" while it might more closely relate to a "Label".

LMP distinguishes data links depending on the multiplexing capability of
the endpoint on that link: "ports" are not multiplexing capable,
"component links" are multiplexing capable. Following this reasoning, the
data link for SDH/SONET networks is not the "timeslot" (this is the label)
but the SDH/SONET section on which the timeslot (i.e. label) gets
allocated. This is clearly described in draft-ietf-ccamp-lmp-10.txt.

A Connection Point (CP) most closely maps to an interface in terms of the
IETF definitions.

>Joint discussion of the terminology mapping may be beneficial in
>reaching alignment on the most accurate mapping. As noted above, these
>represent several of the comments discussed. In order to progress our
>mutual understanding, we would like to invite IETF participants to
>attend the January 24-28, 2005 Q14/15 interim meeting, in New Jersey,
>USA, where we could devote a session to terminology alignment. We
>believe this effort will greatly benefit our future collaboration on
>control plane standards development.  We welcome IETF experts'
>participation in other sessions of the interim meeting as well.
>Details of the meeting agenda will be provided prior to the meeting.
>For those interested in further information and/or attending the
>interim meeting should contact the Rapporteur for Q.14/15 (H. Kam Lam,
>hklam@lucent.com) by 10th January 2005.

We welcome the efforts by Q14/15 to improve mutual understanding of
terminology.

This meeting and the clarification of general GMPLS/ASON terminology is
distinct from the review of draft-ietf-ccamp-transport-lmp. This draft has
fairly limited scope and does not need to be dependent on a full and
mutual exchange of terminology.

Various members of the CCAMP working group including some of the authors
of this draft plan to attend your meeting on January 25th and 26th.


Thank you once again for your feedback on this draft.
If you have further comments, we would certainly like to hear them. The
easiest way for individuals to contribute to the discussion of this topic
is by sending mail to the CCAMP mailing list. Details of how to subscribe
to this list can be found at
http://www.ietf.org/html.charters/ccamp-charter.html

Yours sincerely,
Adrian Farrel and Kireeti Kompella