RE: Moving right along ...
"Mannie, Eric" <Eric.Mannie@ebone.com> Tue, 23 October 2001 10:23 UTC
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 23 Oct 2001 03:24:54 -0700
Message-ID: <D52BF6463BA3D311BFA700508B63C5AA04214A6E@brumsgpnt01.gtsgroup.com>
From: "Mannie, Eric" <Eric.Mannie@ebone.com>
To: 'Juergen Heiles' <juergen.heiles@ties.itu.int>, 'Kireeti Kompella' <kireeti@juniper.net>, ccamp@ops.ietf.org
Subject: RE: Moving right along ...
Date: Tue, 23 Oct 2001 12:23:24 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Hi Juergen, We already discussed all these points (at least 5 times) :-) - about automatic detection: Indeed, you either configure a box with a signal structure, or if implemented you can ask to the box to discover itself the structure (what you call automatic detection). Automatic detection is a process applied internally to a box, and this is totally invisible to any other box in the network. This is an implementation issue, not a protocol issue since the protocol defines everyhting you need to do it. I understand your frustration that SDH standards don't describe all the processes for an implementation, but in general standards don't touch that part. Automatic detection is a matter of reading the standard and understanding how the multiplexing works. By the way, you explained it yourself very well. The fact that a process is not described in some SDH standards has no meaning, it is simply not relevant. Every manufacturer is free to do its implementation as he likes if the protocol is fullfilled, and this is the case. - about the comparison of automatic detection and transparency: You are comparing apples with chocolates. Transparency may require to transport bytes in unused bytes, so in that case it changes the overhead. Automatic detection is an internal process. - You wrote: "During errors (defects, AIS condtions) of individual singals of a group (e.g. one VC-12 in a TUG3 fails) it can get problematic." and I already answered many times: a super signal (group signal) is one single LSP. If something fails inside everything fails. In that case you don't need to demultiplex anymore, you just protect/restore the whole (if required). A group signal is a signaling plane object, i.e. one single LSP. - Can you present me any ITU/ANSI standard that defines automatic detection of the group structure? No need, this is not in the scope of ITU/ANSI standards. - You wrote " You haven't provided a reason for different lables. We had several people that wanted to have the same label structure and only you opposed. So what is rough consensus?" The labels are local per interface, so they are "different" by definition since an SDH interface is not a Sonet interface. However, we defined the two label formats based on the same principles, i.e. the first field is the index of the first AUG-1/STS-1 (easy). We chosen not to indicate any level of higher order multiplexing (e.g. STM-4, STM-16, STS-3, etc) because this is not needed and less flexible. A label is just a simple pointer in the multiplex, how to interpret the content of what is pointed to is not defined by the label. Using your proposal we would introduce a particular case, and in that case there is no reason why we should not introduce other particular case (AUG-4, etc). At the end we would have something totally unreadable. Your proposal has also some issues, e.g. with your definition of the S field: "1. S is the index of a particular AUG-1/STS-3 group. S=1->N indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN multiplex. For example, S=1 indicates the first AUG-1/STS-3 group, and S=N indicates the last AUG-1/STS-3 group of this multiplex. S is not significant for STM-0/STS-1. What happens if a link is not a a multiple of 3xN STS-1 ? For instance, a virtual link (e.g. a Forwarding Adjacency) could be an STS-5 or an STS-4. There is no real second STS-3 group. Your proposal is not appropriate to the level of flexibility that we want to provide. Another observations: our undrestanding of the label is that it is defined before any interleaving, not after. I am opposed because your proposal doesn't bring any new functionality. There are probably 100 ways of coding such a label for SDH and Sonet. We discussed it during one year, we agreed on the current one because it is simple, easy to understand, easy to code and very flexible (and more important we never broke it !!!). We validate it, it is stable since a very long time. Why should we accept your way of coding it, and not the way of somebody else at this final stage ? Kind regards, Eric -----Original Message----- From: Juergen Heiles [mailto:juergen.heiles@ties.itu.int] Sent: Monday, October 22, 2001 3:01 PM To: Mannie, Eric; 'Kireeti Kompella'; ccamp@ops.ietf.org Subject: AW: Moving right along ... Hi Eric, sorry for the delayed answer, but I have problems with the remtoe LAN access here in Geneva. I am therefore sending the mail via my ITU e-mail account and hope it is accepted by the ccamp list server. You compare groups with the multiplier, this is wrong. The multiplier sets up n indivudal VC-n connections. The transport plane sees only the individual VCs and the VC type (VC-4/372712711) is explicitly defined. So no additional support at the transport plane is needed. It is a pure control plane feature. Groups are not a pure control plane feature. When you setup a group (AUG, TUG, VTG, STSG) the transport plane still has to handle the individual VCs/SPEs that are part of the group. Due the independent timing of each VC/STS-SPE pointer processing has to be done per individual VC/SPE. The transport plane cannot switch the group as a whole between STM/STS ports. The transport plane therefore has to automatically detect the structure of the group, a TUG3 for example can consist of VC-3, VC-2, VC-12, VC-11 or a mixture and that may change over the lifetime of the group. This automatic detection is not a standard SONET/SDH feature. As I described in previous e-mails it is possible to do it based on pointer values during non error situations. During errors (defects, AIS condtions) of individual singals of a group (e.g. one VC-12 in a TUG3 fails) it can get problematic. If a single VC-12 in a TUG3 group has AIS (note that the AIS could result from a failure outside the LSP), I assume that still all the other VCs of the group shall be connected without errors. No SONET/SDH standard covers the automatic detection. So in my view it is similarly to transparency of individual SOH bytes. G.707 defines the individual SOH bytes, however transparency it is not standard SONET/SDH and is therefore in the non-standard document. In the same way G.707 defines groups, but not the automatic detection of the group structure. So it should be moved to the non-standards document. At the London meeting Kireeti said the decision on standard/non-standard features is not based on rough consensus, but on what is in the ITU/ANSI documents. Can you present me any ITU/ANSI standard that defines automatic detection of the group structure? You say groups are cool, may be for some applications. But note that groups have the same fragementation problem as contiguous concatenation. The VCs in a group always have to stay together. If for a example a TUG2 consits of 3 VC-12 you cannot put them in arbitrary free time slots. They have stay in the time slots that belong to a single TUG2. Concering the lable, aligning the SONET labels with the SDH lables makes live easier. It is also a sign that SONET and SDH are identical for most parts. I also showed you that SONET uses the same two-stage interleaving process as SDH. If you look at the attached figure from T1.105 you see that the STS-1 time slots in an STS-N signal are not continously number. First 3 STS-1s are combiend to a STS3 groupg and then the STS3 groups are multiplexed. The same as SDH with AU3s and AUGs. As the SONET lables will become the same as the SDH labels we don't have to evaluate much. I already made a proposal some time ago. Why introduce different labels without a need? You haven't provided a reason for different lables. We had several people that wanted to have the same label structure and only you opposed. So what is rough consensus? See my proposal for the labels below. Juergen This is my proposal for the label: The format of the label for SDH and/or SONET TDM-LSR link is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S | U | K | L | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For SDH, this is an extension of the numbering scheme defined in G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the same signaling scheme is used in order to provide easy interworkign between SDH and SONET signaling. For the S field a STS-3 group,which corresponds with the SDH AUG-1 level is introduce. The U field indicates the position of the STS-3c-SPE or STS-1-SPE within the STS-3 group. The K field is not significant for SONET as it doesn't support structured STS-3c-SPEs and must be set to zero. Each letter indicates a possible branch number starting at the parent node in the multiplex structure. Branches are considered as numbered in increasing order, starting from the top of the multiplexing structure. The numbering starts at 1, zero is used to indicate a non-significant field. When a field is not significant in a particular context it MUST be set to zero when transmitted, and MUST be ignored when received. When hierarchical SDH/SONET LSPs are used, an LSP with a given bandwidth can be used to tunnel lower order LSPs. The higher order SDH/SONET LSP behaves as a virtual link with a given bandwidth (e.g. VC-3), it may also be used as a Forwarding Adjacency. A lower order SDH/SONET LSP can be established through that higher order LSP. Since a label is local to a (virtual) link, the highest part of that label is non-significant and is set to zero. For instance, a VC-3 LSP can be advertised as a forwarding adjacency. In that case the labels allocated between the two ends of that LSP (i.e. for that "link") will have S, U and K set to zero, i.e., non-significant, while L and M will be used to indicate the signal allocated in that VC-3. 1. S is the index of a particular AUG-1/STS-3 group. S=1->N indicates a specific AUG-1/STS-3 group inside an STM-N/STS-3xN multiplex. For example, S=1 indicates the first AUG-1/STS-3 group, and S=N indicates the last AUG-1/STS-3 group of this multiplex. S is not significant for STM-0/STS-1. 2. U indicates a specific VC/STS-SPE inside a given AUG-1/STS-3 group or STM-0/STS-1. U=1 indicates a single VC-4/STS-3c-SPE in a AUG-1/STS-3 or the single VC-3/STS-1-SPE in a STM-0/STS-1, while U=2->4 indicates a specific VC-3/STS-1-SPE inside the given AUG-1/STS-3 group. 3. K is only significant for SDH VC-4 and must be ignored for SONET and SDH HOVC-3. It indicates a specific branch of a VC-4. K=1 indicates that the VC-4 is not further subdivided and contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC- 4. K is not significant when the AUG-1 is divided into AU-3s (easy to read and test). 4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It is not significant for an unstructured VC-4 or VC-3/STS-1 SPE. L=1 indicates that the TUG-3/VC-3/STS-1 SPE is not further subdivided and contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8 indicates a specific TUG-2/VT Group inside the corresponding higher order signal. 5. M indicates a specific branch of a TUG-2/VT Group. It is not significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 SPE. M=1 indicates that the TUG-2/VT Group is not further subdivided and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3 inside the corresponding VT Group, these values MUST NOT be used for SDH since there is no equivalent of VT-3 with SDH. M=4->6 indicates a specific VC-12/VT-2 SPE inside the corresponding TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE inside the corresponding TUG-2/VT Group. Note that M=0 denotes an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging). The M encoding is summarized in the following table: M SDH SONET ---------------------------------------------------------- 0 unstructured VC-4/VC-3 unstructured STS-1 SPE 1 VC-2 VT-6 2 - 1st VT-3 3 - 2nd VT-3 4 1st VC-12 1st VT-2 5 2nd VC-12 2nd VT-2 6 3rd VC-12 3rd VT-2 7 1st VC-11 1st VT-1.5 8 2nd VC-11 2nd VT-1.5 9 3rd VC-11 3rd VT-1.5 10 4th VC-11 4th VT-1.5 In case of contiguous concatenation, the label that is used is the lowest label of the contiguously concatenated signal as explained before. The higher part of the label indicates where the signal starts and the lowest part is not significant. For instance, when requesting an STS-48c the label is S>0, U=0, K=0, L=0, M=0. Examples of labels: Example 1: S>0, U=1, K=1, L=0, M=0 Denotes the unstructured VC-4/STS-3c-SPE of the Sth AUG-1/STS-3 group. Example 2: S>0, U=1, K>1, L=1, M=0 Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1. Example 3: S>0, U>1, K=0, L=0, M=0 Denotes the Uth unstructured VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 4: S>0, U>1, K=0, L>1, M=1 Denotes the VC-2/VT-6 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 5: S>0, U>1, K=0, L>1, M=9 Denotes the 3rd VC-11/VT-1.5 in the Lth-1 TUG2/VT Group in the Uth VC-3/STS-1 SPE of the Sth AUG-1/STS-3 group. Example 6: S>0, U=1, K>1, L>1, M=5 Denotes the 2nd VC-12 in the Lth-1 TUG2 in the Kth TUG3 in the VC-4 of the Sth AUG-1. > -----Ursprüngliche Nachricht----- > Von: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Gesendet: Donnerstag, 18. Oktober 2001 18:58 > An: 'Heiles Juergen'; 'Kireeti Kompella'; ccamp@ops.ietf.org > Betreff: RE: Moving right along ... > > > Hello Juergen, > > Your comments are addressed hereafter. Note that you didn't raised any > technical problem or mistake in your comments (i.e. the draft "works" very > well as it is). > > - the first comment is not about a technical issue but an > "editorial" issue. > - the second comment is about a change that will not bring any new > capability. > > >Concerning the SDH/Sonet documents I want to raise a formal issue. > >We have now two documents, a document that covers ITU/ANSI standard > features (draft-ietf-ccamp-gmpls-sonet-sdh-02.txt) and a document that > covers non-standard features > (draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt). However in > Appendix 1 > of the standard feature document a non standard feature (Group signals) is > listed. It is even mentioned that the use of groups (AUG, STSG, > ...) is not > described in standards. So this feature should be moved to the > non-standards > document. Otherwise the split of the documents doesn't make sense. > > We spend a considerable amount of time speaking about this > particular issue > and I still don't see any technical justification for what you said. > > For those who are not SDH/SONET experts some quick explanation: > > We call a "super-circuit" a set of physical circuits in the > transport plane > all belonging to the same LSP in the signaling plane. We defined two kinds > of super-circuits: "group circuits" and "multiplicative circuits". > > Multiplicative circuits are setup using the multiplier field that > we defined > (e.g. to say "I want 5 STS-1 circuits in my LSP"). Juergen has no > objection > about these ones. > > Group circuits are setup using the SDH/SONET naming for groups, i.e. AUG, > TUG, VTG (we defined the equivalent signal type in the signaling). The > comment of Juergen is about these group circuits. A group circuit > represents > some bandwidth at a given place in the SDH/SONET multiplex. The > advantage of > such a super-circuit is that the customer can re-structure its content as > he/she likes. The operator doesn't care. > > Such an application is possible and is already implemented. SDH/SONET is > self-describing, i.e. by looking at the signal one can understand > how it is > structured (like Juergen explained on the mailing list), so one > can setup a > circuit without describing the content (very very cool). > > The transport plane ignores that the signaling plane uses an "abstraction" > (i.e. an LSP) representing several physical circuits. Note that > restoration > and management belong respectively to the signaling plane and to the > management plane in the IETF view (not to the transport plane like in the > ITU-T view). > > From that point of view, group circuits are a GMPLS signaling > plane feature > and not a transport plane feature. We put the comment on the fact > that this > is not defined (like GMPLS LSPs, etc) by ITU-T to make some guys happy. > > I could say clearly at the beginning of the draft that the signal > types that > we are defining in this document are not ITU-T signal types but > GMPLS signal > types (of course) whose have in some cases a direct relationship with the > ITU-T signal types. > > Any objection ? > > >For the Sonet and SDH labels in draft-ietf-ccamp-gmpls-sonet-sdh-02.txt I > prefer to have the same coding for Sonet and SDH. That makes the > implementation for Sonet and SDH simpler. Furthermore ITU and T1 > have tried > over the last years to align Sonet and SDH as much as possible. The > definition of different labels for Sonet and SDH contradicts these > activities. > > We discussed this one since a long time as well. Let me be clear: > > - labels are local to an interface (we all agree). > - a link (interface) is operated at one point in the time as either SDH or > SONET. > - your proposal will require to re-evaluate many things. > - and it took us a lot of time to fine-tune and to validate the current > label structure. > - we could have technical issues with your proposal that would impact more > than this draft (Dimitri saw some of them, please see with him). > - you never provided a complete analysis of your proposal. > > But more important: your proposal doesn't bring any additional > functionality > to the draft. > > At this very late stage, since this not bringing any new > functionality, and > since the label structure is very stable since a long time, I would prefer > not to restart a long technical discussion to change and re-validate the > draft. > > Kind regards, > > Eric > > > > > -----Ursprüngliche Nachricht----- > > Von: Kireeti Kompella [mailto:kireeti@juniper.net] > > Gesendet: Mittwoch, 17. Oktober 2001 11:25 > > An: ccamp@ops.ietf.org > > Betreff: Moving right along ... > > > > > > Despite the energetic subject line, we the WG chairs have been > > lax in our duties. So, here goes: > > > > Lou has submitted the latest versions of the generalized > > signaling documents quite some time ago (thanks, Lou): > > > > draft-ietf-mpls-generalized-cr-ldp-04.txt > > draft-ietf-mpls-generalized-rsvp-te-05.txt > > draft-ietf-mpls-generalized-signaling-06.txt > > > > Also, Eric has posted the SONET/SDH documents (merci, Eric): > > > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > > All of these should have addressed the issues raised in the earlier > > versions. Please read the new versions, and send your comments to > > the list by Tuesday Oct 23. At that point, when the final round > > of comments have been addressed, these docs will go to IESG Last > > Call. If any one objects to sending these docs to IESG Last Call, > > raise your issues now. > > > > I see that the GMPLS architecture document is a CCAMP WG doc, but > > the minutes say that we should look for consensus on the list. So, > > if you think this doc *shouldn't* be a WG doc, let us know. (If we > > arrived at a consensus, remind me :-)) If nothing is heard, the doc > > will progress to WG Last Call. > > > > The docs draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt and > > draft-fontana-ccamp-gmpls-g709-00.txt were under consideration to be > > CCAMP WG docs; consensus at the meeting was Yes. Please let the > > list know what your thinking is on these. (BTW, both these docs > > were to have some edits done. If the authors could do that before > > the next IETF, we can try to make more progress then.) > > > > The MIB overview doc was recently posted. Please read and comment > > to the list. > > > > The doc draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > was generally thought to be useful; it will be published as a > > CCAMP informational doc. This begins a two week Last Call on > > the doc, ending Tuesday Oct 30. > > > > There was no consensus on whether the GMPLS framework should be > > a CCAMP WG doc. Please indicate your pleasure. > > > > draft-ietf-ccamp-lmp-01.txt has been posted. The thought was > > raised that this draft is close to ready for WG Last Call. Please > > review it, and let us know if you disagree. > > > > The OLI requirements doc was broadly accepted. Please let the > > list know if you think this doc should be a WG doc. > > > > It's still open whether we (the IETF) should be working on > > LMP-WDM. I urge the authors to keep on working on the doc, and > > keeping it in sync with LMP; however, we will postpone making it > > a CCAMP WG doc until the issue is resolved. Hopefully that will > > happen in Salt Lake City. > > > > There was reasonable interest in the tunnel trace requirements > > doc. Let's formalize this: do you think this should be made a > > CCAMP WG document? > > > > Summary: > > > > 1) Final comments and IESG Last Call readiness for: > > draft-ietf-mpls-generalized-cr-ldp-04.txt > > draft-ietf-mpls-generalized-rsvp-te-05.txt > > draft-ietf-mpls-generalized-signaling-06.txt > > draft-ietf-ccamp-gmpls-sonet-sdh-02.txt > > draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt > > > > 2) Should the following documents be CCAMP WG docs? > > draft-bonica-tunneltrace-02.txt > > draft-fontana-ccamp-gmpls-g709-00.txt > > draft-ietf-ccamp-gmpls-architecture-00.txt > > draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt > > draft-many-ccamp-gmpls-framework-00.txt > > draft-many-oli-reqts-00.txt > > > > 3) Comment on MIB overview. > > > > 4) Two week Last Call comments on > > draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt > > > > 5) Last Call readiness of > > draft-ietf-ccamp-gmpls-architecture-00.txt > > draft-ietf-ccamp-lmp-01.txt > > > > Thanks, > > Kireeti. > > >
- RE: Moving right along ... neil.2.harrison
- RE: Moving right along ... John Drake
- Re: Moving right along ... Zhi-Wei Lin
- Re: Moving right along ... Stephen Trowbridge
- Re: Moving right along ... Sudheer Dharanikota
- Re: Moving right along ... Sudheer Dharanikota
- Re: Moving right along ... Sudheer Dharanikota
- Re: Moving right along ... mike.sexton
- RE: Moving right along ... neil.2.harrison
- Re: Moving right along ... Zhi-Wei Lin
- RE: Moving right along ... mike.sexton
- RE: Moving right along ... Mannie, Eric
- Re: Moving right along ... Zhi-Wei Lin
- RE: Moving right along ... neil.2.harrison
- Re: Moving right along ... mike.sexton
- Re: Moving right along ... Zhi-Wei Lin
- Re: Moving right along ... Zhi-Wei Lin
- Re: Moving right along ... Maarten Vissers
- Re: Moving right along ... Sudheer Dharanikota
- Re: Moving right along ... Sudheer Dharanikota
- Re: Moving right along ... Maarten Vissers
- RE: Moving right along ... Brungard, Deborah A, ALCTA
- RE: Moving right along ... Ash, Gerald R (Jerry), ALCTA
- Re: Moving right along ... Dimitri Papadimitriou
- RE: Moving right along ... Mannie, Eric
- RE: Moving right along ... Mannie, Eric
- Re: Moving right along ... Zhi-Wei Lin
- Re: Moving right along ... Irfan Lateef
- Re: Moving right along ... Sudheer Dharanikota
- Re: Moving right along ... Maarten Vissers
- RE: Moving right along ... Mannie, Eric
- FW: Moving right along ... Mannie, Eric
- RE: Moving right along ... Mannie, Eric
- RE: Moving right along ... Mannie, Eric
- RE: Moving right along ... Mannie, Eric
- RE: Moving right along ... Mannie, Eric
- RE: Moving right along ... Yanhe Fan
- Re: Moving right along ... Maarten Vissers
- RE: Moving right along ... Yanhe Fan
- Re: Moving right along ... Dimitri Papadimitriou
- Re: Moving right along ... manoj juneja
- Re: Moving right along ... manoj juneja
- Re: Moving right along ... Dimitri Papadimitriou
- Re: Moving right along ... Zhi-Wei Lin
- Re: Moving right along ... Dimitri Papadimitriou
- Re: Moving right along ... Zhi-Wei Lin
- Re: Moving right along ... Zhi-Wei Lin
- Re: Moving right along ... manoj juneja
- RE: Moving right along ... Yanhe Fan
- RE: Moving right along ... Mak, L (Leen)
- Re: Moving right along ... Dimitri Papadimitriou
- RE: Moving right along ... Mark.Jones
- RE: Moving right along ... Brungard, Deborah A, ALCTA
- Re: Moving right along ... Ping Pan
- Re: Moving right along ... Zhi-Wei Lin
- Re: Moving right along ... Zhi-Wei Lin
- RE: Moving right along ... John Drake
- Re: Moving right along ... Zhi-Wei Lin
- Re: Moving right along ... Zhi-Wei Lin
- Re: Moving right along ... Zhi-Wei Lin
- Re: Moving right along ... Maarten Vissers
- Re: Moving right along ... Maarten Vissers
- RE: Moving right along ... Mannie, Eric
- Re: Moving right along ... Kireeti Kompella
- Re: Moving right along ... Kireeti Kompella
- Re: Moving right along ... Ping Pan
- RE: Moving right along ... Debanjan Saha
- Re: Moving right along ... Yangguang Xu
- Re: Moving right along ... Ping Pan
- Re: Moving right along ... Ping Pan
- RE: Moving right along ... John Drake
- RE: Moving right along ... John Drake
- Re: Moving right along ... Yangguang Xu
- RE: Moving right along ... John Drake
- Re: Moving right along ... Zhi-Wei Lin
- Re: Moving right along ... Kireeti Kompella
- RE: Moving right along ... Kireeti Kompella
- RE: Moving right along ... Kireeti Kompella
- Re: Moving right along ... Kireeti Kompella
- RE: Moving right along ... Wijnen, Bert (Bert)
- Re: Moving right along ... Stephen Trowbridge
- Re: Moving right along ... Zhi-Wei Lin
- RE: Moving right along ... Mak, L (Leen)
- Re: Moving right along ... Sudheer Dharanikota
- Re: Moving right along ... Sudheer Dharanikota
- Re: Moving right along ... Yangguang Xu
- Re: Moving right along ... Kireeti Kompella
- RE: Moving right along ... Fugui Wang
- Re: Moving right along ... Yangguang Xu
- Re: Moving right along ... Kireeti Kompella
- RE: Moving right along ... Jonathan Lang
- RE: Moving right along ... Don Fedyk
- Re: Moving right along ... Dimitri Papadimitriou
- Re: Moving right along ... Zhi-Wei Lin
- RE: Moving right along ... Fugui Wang
- Re: Moving right along ... Sudheer Dharanikota
- Moving right along ... Kireeti Kompella