Title: RE: Response to Liaison Concerning the Comparison of LMP and ASON Discovery 
Date:16 Jan 2005
From:  Lam, Hing-Kam (Kam) <hklam@lucent.com> 

Dear Adrian and Kireeti,

Thank you for the Response to the Q14/15 Liaison Concerning the Comparison of LMP and ASON Discovery. Q14/15 will address the LS in its upcoming meeting on January 24-28, 2005.

Regards,
Kam Lam, Q14/15 Rapporteur

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Sunday, January 16, 2005 12:52 PM
> To: Lam, Hing-Kam (Kam)
> Cc: 'Kireeti Kompella'; zinin@psg.com; Bill Fenner; Scott Bradner;
> statements@ietf.org; ccamp@ops.ietf.org
> Subject: Response to Liaison Concerning the Comparison of LMP and ASON
> Discovery
> 
> 
> 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
>