RE: Moving right along ...

["Mannie, Eric" <[e-mail]>]

Juergen,

I am answering to your e-mails exactly because I am the editor of these
documents. Some people don't want to answer anymore. Answering or not to
e-mails is a personal decision of each one, nobody is forced to answer.

You had the feedback from the mailing list. In general when people are happy
with what they saw they don't spend time to add more comments.

Your proposals were supported by you and Maarten. I answered with Dimitri.
It is easy of course (for all of us) to ask all our colleagues and friends
to flood a mailing list.

Concerning your request to move the group signals to the other draft: this
was answered publicly by Kireeti during the last CCAMP meeting and the
answer was no. I asked again to Kireeti a couple of weeks ago, same answer.
This is also the advice that I received from Rob.

Concerning your label proposal: details are not yet cooked from our (I and
Dimitri) point of view (e.g. when using an STS-4 SPE Forwarding Adjacency
there is no second STS-3 group, sorry if my example was confusing). Your
text needs to be corrected but that's a detail, it just shows that it is
quite difficult to write a text that works in all cases.

We spend a considerable amount of time reviewing the current label encoding
and we made sure that it works in the craziest cases. Indeed, this is the
most stable part of the SDH/SONET draft since a very long time. By adopting
your proposal we will have to do it again for no additional benefit and we
will need another WG last call (you know it perfectly). That's why I refused
during the WG last call some months ago, and why I am refusing again.

As an editor my job is also to keep the boat in the middle of the river and
to make sure that drafts are progressing and are not being constantly
re-worded. Also, I don't want to force all manufacturers to change their
implementations (prototypes:-) of the SONET label just because you found
another way of encoding it. One solution or the other is more a matter of
personal feeling.

At this stage, as a co-author you should be more concerned by finishing this
work. We can spend years having new ideas, improving and proposing
modifications to a draft.

It is a fact that we spend a huge amount of time (for me it represents
months of work since the beginning of year 2000) fine-tuning this draft. Now
it is time to publish it.

>From the technical point of view your proposals versus keeping the current
text will not change anything. It started as a political issue and I hope
that it didn't become a personal issue.

I am just asking you to help us to publish this work, even if it is not 100%
as you would like to see it.

Kind regards,

Eric

> -----Ursprüngliche Nachricht-----
> Von: Mannie, Eric [mailto:[e-mail]]
> Gesendet: Dienstag, 23. Oktober 2001 12:23
> An: 'Juergen Heiles'; 'Kireeti Kompella'; [e-mail]
> Betreff: RE: Moving right along ...
>
>
> Hi Juergen,
>
> We already discussed all these points (at least 5 times) :-)
even more


>
> - 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).
>
For groups the box has to discover the structure itself.


> 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.
>
SDH and Sonet standards define detailed equipment functionality in order to
ensure interworking.
ITU has for example G.783 that defeins in detail what to do in SDH
equipment. Even G.707 gives some details
on pointer processing (genration, interpretation). For SONET we have GR-253
from Telcordia which provides this details.
No of them mentiones automatic detection.


> 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.
>
I mentioned the case that the problem is outside your LSP. You get for
example a signal from a user and setup a group LSP.
Now due to problems on the user side one of the VCs has AIS, may be the user
isn't even using this VC currently. You cannot protect it as the problem is
outside the LSP. If you now drop all other VCs of this group your user would
be very happy I assume.


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

Are you defining what is in the scope of ITU/ANSI standards?
This is in the scope of ITU/ANSI/Telcordia standards. Look on G.707 pointer
interpretation, G.783 and GR-253 as mentioned above. When we talk about
standard SONET/SDH it includes the equipment functionality. For ETSI we even
have compliance statements that go down to these details.
I have no problems when soemone implements this feature, but we should no
give the impression that this is a standard SONET/SDH feature by putting it
into the standard features document. Move it to the non-standard document.

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

A SONET STS-1 and a SDH STM-0, a SONET STS-3n and a SDH STM-N with AU-3 have
the identical structure.
But with the current proposal we have to use different lables. Is this
simple?

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

I just took the SDH AU3 case and used it for SONET. So if you see a problem
it would already apply to the defined SDH lable.


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

Oh, suddently we have STS-4, STS-4 virtual links poping up, interesting. But
couldn't we also have virtual SDH signals with only 5 AU-3?
I don't know as I don't have any information about this virtual link
concept. But if you introduce something like this there should be no
difference between SONET and SDH. Otherwise we introduce new differences
between SONET and SDH that we tried to avoid now for some years (see
Deborahs e-mail). We learned from the mistakes made during the development
of SONET and SDH. In todays global world we don't want these differences.
And that is the reason why we propose to use a common lable. Don't make the
same mistakes again. So if you see a problem it also applies to the defined
SDH label.



> 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,
The proposal to use a common lable is already disucssed for several month
(over 1/2 year) as soon as we got involved in the GMPLS discussions.


> 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 ?
>

To use a common label is the only alternative proposal we have, no others.
It makes a lot of sense and is supported by several people on the list. Up
to know only oppossed by you. Again what is rough consensus?


> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Juergen Heiles [mailto:[e-mail]]
> Sent: Monday, October 22, 2001 3:01 PM
> To: Mannie, Eric; 'Kireeti Kompella'; [e-mail]
> 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:[e-mail]]
> > Gesendet: Donnerstag, 18. Oktober 2001 18:58
> > An: 'Heiles Juergen'; 'Kireeti Kompella'; [e-mail]
> > 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:[e-mail]]
> > > Gesendet: Mittwoch, 17. Oktober 2001 11:25
> > > An: [e-mail]
> > > 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.
> > >
> >