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

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

Adrian,

Please see comments in-line.

Regards,
Ben

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Tuesday, December 21, 2004 8:45 AM
> To: Mack-Crane, T. Benjamin; Stephen J Trowbridge; ccamp@ops.ietf.org
> Subject: Re: ITU-T SG15 comments on
draft-ietf-ccamp-transport-lmp-00.txt
> 
> Thanks Ben,
> 
> All paragraphs of the liaison are very relevant.
> 
> I note that the two paragraphs that you quote suggest a meeting to
resolve
> disconnects in terminology. I also note that the liaison suggests that
the
> value of such a meeting would be to facilitate our future work
efforts.
> This seems like an excellent idea.
> 
> You are right. The liaison appears to state that there were some
comments
> on the draft made at the meeting which have not been included in the
> liaison. I wonder why this would be?

The liaison was submitted late to the SG15 meeting, 2 working days
instead of the normal 7 (note the IETF's limit is 10), not giving
participants sufficient time to read/review it.  Thus it was not
possible to provide a liaison with a complete set of comments.  It was
decided that there would be value in discussing the draft and
communicating some comments nonetheless.

> 
> You say that...
> > 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.
> 
> Well, what can I say?
> The intention of liaising this draft to SG15 was to allow people who
had
> not previously seen the draft (which has been around for a while in
the
> public domain) 

Yes, since September as a WG draft.

> the opportunity to comment while the draft was in working
> group last call. Working group last call (as I explained during the
SG15
> Question 14 and joint Q12/14 meetings in Geneva earlier this month)
means
> that the authors believe that the draft is complete - it is a check
with
> the rest of the working group that they agree.
> We received some useful feedback from Q12/15 in this liaison and the
> authors will be able to enhance the draft accordingly.
> 
> Had the liaison said "We are very concerned that there is a
significant
> mismatch in terminology in this draft and believe that it should not
be
> published without further face-to-face discussions", this would have
been
> a very significant issue. I would, of course, have asked for some
examples
> so that we could qualify the problem. If the liaison had said "There
> appears to be a major disconnect on the following terms..." we would
> obviously have worked to resolve the disconnect and welcomed
face-to-face
> meetings as necessary.

Well, I think the liaison was meant to convey something along those
lines, albeit not in those words.

> 
> But the liaison hints (as you say) that there may be other issues that
are
> not mentioned in the liaison. So perhaps I can ask everyone to think
very
> hard and let me (or preferably the CCAMP mailing list) know what those
> issues are.

I presume the reason for providing a liaison to the ITU is that not all
members of the ITU participate in the CCAMP mailing list, and if they do
they cannot speak for the ITU, so there may be a problem with this
process.

> 
> The liaison also suggests that time at a future Q14/15 meeting could
be
> given over to align the views on terminology to facilitate future
> progress. This certainly does not imply to me that there are any
issues in
> the current draft (beyond those raised in the current liaison) that
need
> to be addressed before the draft is published.
> 

Well, if the I-D purports to provide "an 
   overview of LMP in the context of the ITU-T Automatically Switched 
   Optical Networks (ASON) and transport network terminology and 
   relates it to the ITU-T discovery work to promote a common 
   understanding for progressing the work of IETF and ITU-T."
then I would think that publishing it before reaching a common
understanding would be counter to the purpose.

> 
> I hope you don't think I'm being difficult, but when communications
are
> reduced to formal liaisons we must take the liaisons at face value. So
I
> would urge (again) that anyone who has any issues with the current
draft
> (or any CCAMP draft) should bring those issues to me or (preferably)
to
> the CCAMP mailing list without delay. If issues are raised I will do
my
> best to ensure that they are resolved.
> 

I am not trying to be difficult either.  I think the difficulty arises
from attempting to rush to publish the I-D.  If the liaison had been
sent with sufficient time to review, a more complete response could have
been given.  Even so, the need for further discussion has been
identified, and I agree that a face-to-face meeting would be much more
efficient than limiting the exchange to formal liaisons.  (In fact
achieving common understanding may be more in the process than in the
paper.)

> But this is not open season on delaying this draft. The reason for a
last
> call and a liaison are clear: they provide a line in the sand.
Discovery
> of defects after that time is welcomed (all defect discovery is always
> welcomed), but there is a time and a place to actively search for
> problems.
> 
> Regards,
> Adrian
> ----- Original Message -----
> From: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>
> To: "Adrian Farrel" <adrian@olddog.co.uk>; "Stephen J Trowbridge"
> <sjtrowbridge@lucent.com>; <ccamp@ops.ietf.org>
> Cc: "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: Monday, December 20, 2004 9:35 PM
> Subject: RE: ITU-T SG15 comments on
draft-ietf-ccamp-transport-lmp-00.txt
> 
> 
> 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
> ============================================================
> 
============================================================
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
============================================================