RE: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt

["Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>]

Adrian and all,

I think the first and last paragraphs of the liaison (see below) are
quite relevant as well.  In particular, they suggest that the liaison
does not provide all of the comments from SG15, and that joint
discussion is needed (an invitation to participate in an upcoming
meeting is included).  Just trying to answer the comments/questions that
were recorded in the liaison would seem to be inadequate to meet the
stated goal of the draft.

Regards,
Ben

"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."

"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."

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Adrian Farrel
Sent: Friday, December 17, 2004 1:48 PM
To: Stephen J Trowbridge; ccamp@ops.ietf.org
Cc: Don Fedyk; osama@nortelnetworks.com; Brungard, Deborah A, ALABS;
Jonathan Lang; Dimitri Papadimitriou
Subject: Re: ITU-T SG15 comments on
draft-ietf-ccamp-transport-lmp-00.txt

Thanks Steve,

And available in glorious HTML

Authors, the relevant text from the liaison is included below. I think
we
can assume it is no different to what will receive through the formal
channels.

Adrian

=======

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."
  1.. What is the intention of the term independent, for example, could
it
be indicating at a different time or different approaches?

  2.. 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.
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:

  1.. 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.

  2.. 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.

  3.. 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.
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".  Joint discussion of
the
terminology mapping may be beneficial in reaching alignment on the most
accurate mapping.


----- Original Message ----- 
From: "Stephen J Trowbridge" <sjtrowbridge@lucent.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>; "Don Fedyk" <dwfedyk@nortelnetworks.com>;
<osama@nortelnetworks.com>; "Brungard, Deborah A, ALABS"
<dbrungard@att.com>; "Jonathan Lang" <Jonathan.Lang@sonos.com>; "Dimitri
Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>
Sent: Friday, December 17, 2004 6:53 PM
Subject: Re: ITU-T SG15 comments on
draft-ietf-ccamp-transport-lmp-00.txt


> Adrian,
> I don't know why the TSB would not have sent out the liaison
statements
> generated from December 3. In any case, all of the liaison statements
to
ccamp
> that were generated in our meeting are available at the usual spot in
the FTP area:
>
>
ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICA
TIONS/index.html
>
> Follow the links for the ccamp working group.
> Regards,
> Steve
>
> On 12/17/2004 11:22 AM, Adrian Farrel wrote:
> > Hi,
> >
> > Please note that these are the unofficial comments from SG15.
> > I was present when this was discussed in the Q14/15 meeting in
Geneva
at
> > the end of November / start of December, but I have not seen the
final
> > version of the material that they intended to liaise to us.
> >
> > Unfortunatley, the liaison response missed the deadline (set to
allow
good
> > time after the Geneva meeting) and the WG last call (set to end
after
the
> > liaison deadline). No matter; let's see what we can do with my notes
from
> > the meeting.
> >
> > Thanks,
> > Adrian
> > ===
> >
> > Section 3.1
> >
> > "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."
> >
> > There were some questions about the term "independent". Does it
imply
a
> > different mechanism or a different timing?
> > Also, what is meant by the last sentence? Do the transport resource
exist
> > or not when the control plane assignment is made?
> >
> > My understanding of this paragraph is that:
> > - It is material extracted from G.8080 so Q14/15 should be better
> >   placed to answer these questions than us.
> > - The "independence" is precisely that raised in the final question.
> >    That is, assignment in the management plane is independent of
> >    connectivity in the data plane. The two discovery processes
> >    are fully independent (time and mechanism).
> >
> > Perhaps you can find a way to clarify the text.
> >
> >
> >
> > Section 4.2
> >
> > "G.8080 refers to a component link as a variable adaptation
function"
> >
> > It was pointed out that G.8080 does not use the term "component
link".
> > Obviously what your text means is that the term "variable adaptation
> > function" used in G.8080 is broadly equivalent to the term
"component
> > link" used in [LMP] and [BUNDLE]. Perhaps you can change the wording
so
> > that there is no misunderstanding possible.
> >
> >
> > Section 4.2 table
> >
> > CP---Interface
> > The meaning of the term "interface" was misunderstood in that it
appeared
> > to be applied in some non-IETF context, thus we are told that a CP
is
like
> > a timeslot or wavelength not an interface. Further, the two columns
for
> > port and component link terminology should make this clear.
> > I don't believe we can go through the pain of writing out an
explanation
> > of every IETF term. This draft is intended to bring LMP transport
within
> > the view of the IETF, not the other way around.
> >
> >
> > General comments on TE links
> >
> > There was (still) some considerable unquiet about the precise nature
of a
> > TE link and how it maps to G.805/8080 concepts. There are a bunch of
> > specific questions about the definition of a TE link, and it is not
clear
> > whether this is the right document to contain the answers. I suggest
that
> > you have a go at answering the questions (we can liaise them back to
> > Q14/15 when we recieve the questions :-) and include them in the
draft
if
> > you think it is appropriate.
> >
> > IMHO some of the questions are refusing to acknowledge the abstract
nature
> > of a TE link, and the fact that it is not material how it is
constructed
> > at a lower level because it simply exists at the higher level. In
any
> > case, as I say above, this draft is intended to explain transport
concepts
> > so that the IETF can understand them, not the other way around.
> >
> > q1: Can a TE link use parallel resources from different transport
layers?
> > For example, could a TE link between LSR A and LSR B use a lambda
and
a
> > timeslot from the same fiber? (Note that there is a claim that an
SNPP
> > cannot do this because it exists only within a single layer.)
> >
> > q2: Can a TE link use component resources from parallel links. For
> > example, could a TE link be built from all of the red lambdas from a
> > collection of parallel fibers? Or could a TE link be built from
different
> > STS-1s from parallel OC-48s? (This is said to be true of SNPPs.)
> >
> > q3: Is it possible to build a TE link out of other TE links at
different
> > routing levels? This might (I suppose) involve bundling FAs to
provide
> > another TE link. Or possibly we are talking about concatenating FAs
to
> > provide a path that is presented as a TE link. (Again, the claim is
that
> > an SNPP link at one level can include SNPPs from a lower level).
> >
> >
> >
> >
> >
> >
>
>
>
>
>
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================