Hi
The Authors of the CCAMP draft "A Transport Network View of the Link Management Protocol" have prepared the following draft response to the Liaison from ITU SG15. The text is included below for WG comments.
Thanks,
Don Fedyk
>
>============
>From: ITU-T SG15
>To: CCAMP
>For: Action
>Deadline: 15 March 2005
>Subject: Response to IETF CCAMP WG on Comparison of LMP and ASON
>Discovery
>
>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.
IETF CCAMP thanks the Q14/15 for their feedback on the
<draft-ietf-ccamp-transport-lmp-00.txt>. Please see the reply to the
comments 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 indicates, it is summarizing G.8080 Discovery (not LMP). The description is directly based on G8080's text,
e.g.:
" 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
G8080 (not describing LMP).
"G8080 refers to a component link as a variable adaptation function"
was worded from an IETF terminology interpretation i.e. G8080 refers
to a LMP component link as a variable adaptation function. The authors
will clarify to say "G8080'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.
The intention of the draft is not to define a TE link. The TE link is
defined in the LMP draft. <draft-ietf-ccamp-lmp-10.txt> At the request
of several individuals we tried to bring clarity to the TE link concept. 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 any elaborate
structures in 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 inherited
as a TE link by an upper region and so appear as TE resources
(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 non multiplexing capable
versus "component links" which 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.
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.
This point is a separate point from the discussion of the specific draft.
The Transport View of LMP has a fairly limited scope of discussing
terminology. Some of the Authors of the Transport View of LMP will
attend the session on January 25th and 26th.