RE: Moving right along ...

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

Hi Juergen,

More about the SDH and SONET labels:

We designed them using the same principles to have as much compatibility as
possible between SDH and SONET, this was our objective. But they will never
be the same as explained hereafter.

For the Sonet label we have the choice between the single stage interleaving
and the two stage interleaving approach. One must choose either one or the
other.

Your proposal is to use the two stage interleaving to define the Sonet
label. We chosen the single stage Sonet interleaving. The advantage of using
the single stage interleaving as a basis is that it works in both cases in
the same way, i.e. it just point to the first STS-1 and the label doesn't
care if a single or two stage interleaving is used, it results that S has
exactly the same *semantic* for SDH and SONET, but not the same *value* of
course.

Another reason to use the single stage interleaving is to avoid to introduce
a particular case just for SONET. If we introduce a STS-3 group we could
also introduce AUG-4, AUG-16, AUG-64 and AUG-256. If we do that (to be
compatible with the two stage SONET approach), the label needs three
additional artificial fields. Each time we add an additional level, we need
to add a field. It becomes more complex without adding any new feature and
we loose the flexibility.

One main driver for our solution is that the label doesn't need to know
about the grouping of STS-1 or AUG, there is no need to encode that
information in the label because nobody is going to use it. So we obtained
an easier coding.

More important: the label structure will NEVER be the same for SONET and SDH
because this is physically not possible: there is not TUG-3 equivalent in
SONET, there is no VT-3 equivalent in SDH. So whatever is the label coding,
K and M will ALWAYS be different. Nobody can change it.

The C code for coding and dealing with the multiplex allocation will never
be the same neither. A link will never be operated at the same time as SDH
and SONET.

The label is always local to a link and there is no interoperability issue
between SONET and SDH for that reason (because they are physically
separated).

We had the same desire to have the SDH and SONET label as compatible as
possible, and this is what we think we achieved while taking into
consideration the purpose of the label, why we need a label and where we
need a label.

Kind regards,

Eric

-----Original Message-----
From: Juergen Heiles [mailto:[e-mail]]
Sent: Tuesday, October 23, 2001 6:08 PM
To: Mannie, Eric; 'Juergen Heiles'; 'Kireeti Kompella';
[e-mail]
Subject: AW: Moving right along ...




> -----Ursprüngliche Nachricht-----
> Von: Mannie, Eric [mailto:[e-mail]]
> Gesendet: Dienstag, 23. Oktober 2001 17:12
> An: 'Juergen Heiles'; 'Kireeti Kompella'; [e-mail]
> Betreff: RE: Moving right along ...
>
>
> 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.

As this is not a question of rough consensus let the chairs sort this out.


>
> 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.
>
What does a STS-4 SPE Forwarding Adjacency provide capacity for 4 STS-1
SPEs?
Ok, how about a 4xAU-3 Forwarding Adjacency, the SDH equivalent. It should
be also possible (Japan for example uses SDH AU3).
How would you use it with the current SDH lable. If you consider such
features I agree that my proposal has problems, but the current proposal
also for AU3. To cover it for both SONET and SDH AU3 we have to use the
current SONET labels also for SDH AU3. Again we would have identical SONET
and SDH labels.
And this example clearly shows to me that we need the same lables. Otherwise
we end up with some features that are only possible in SDH or only possible
in SONET because of different restrictions due to the different lables. What
can be done in SONET can also be done in SDH.


> 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.
>
If a co-author has to keep quiet on the mailing list or during the meeting
with comments on the document it is fine with me to be removed as co-author.


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