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

[Stephen J Trowbridge <sjtrowbridge@lucent.com>]

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/COMMUNICATIONS/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).
> 
> 
> 
> 
> 
>