RE: [IP-Optical] RE: Proposed text for the concatenation

[Vishal Sharma <vsharma87@yahoo.com>]

Eric, Greg,

I agree with your thoughs and summary. I see nothing wrong in deferring a 
couple
items for further study (FFS), and moving the basic draft forward. As Greg 
observed,
vendors are already implementing some of the basic signaling (and even
routing) specifications.

Also, Eric, your summary appears very good to me. I think it would be 
constructive
to try to wrap this discussion up, and proceed with the basic specifications.
The items left for futher study can, of course, continue to be discussed
(or better yet, written about).

I too would be happy to work on the FFS items to work through the issues,
and ensure that they are  progressed to the satisfaction of vendors and
providers.

Thanks,
-Vishal

On Thursday, May 24, 2001 4:17 PM, Bernstein, Greg [SMTP:GregB@ciena.com] 
wrote:
> Very good summary Eric. Like yourself, I'm not sure what's wrong with the
> signaling protocol including industry practices even if they are not covered
> by existing standards.  In some cases the extensions are perhaps too minor
> in scope or too controversial to warrant extension of ITU/ANSI standards.
> The "arbitrary contiguous concatenation" and the "flexible arbitrary
> concatenation" examples are cases in point.  In both cases we are just
> talking about an optional loosening of specified constraints.
>
> I didn't realize that others already supported "arbitrary contiguous
> concatenation". You probably have a better view into the wide range of SDH
> products than I.  I think your proposed text is good.  I'd be happy to work
> with yourself and others in bringing these items into ITU/ANSI/ETSI or
> wherever, but I don't think that the GMPLS SDH/SONET draft needs to wait on
> such an effort, i.e., folks are implementing these specs now and
> demonstrating interoperability.
>
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation
>
> -----Original Message-----
> From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
> Sent: Monday, May 21, 2001 8:15 PM
> To: 'Stephen Trowbridge'
> Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; 'Eric Gray';
> 'tony.flavin@bt.com'; Bernstein, Greg; 't1x15@t1.org';
> 'tsg15q11@itu.int'
> Subject: RE: Proposed text for the concatenation
>
>
> Hello Stephen,
>
> >I think this goes against earlier email that says T1X1 and ITU-T
> >are responsible for specification of SONET/SDH. There are two
> >standardized forms of concatenation. Your proposal includes only
> >one of the standardized forms and two that are, for the moment,
> >proprietary. If we accept that SONET/SDH is the responsibility
> >of T1X1/ITU-T...the other concatenation proposals must go to
> >T1X1/ITU-T before they can be considered standardized.
>
> Transparency and contiguous arbitrary concatenation were done in the current
> draft with the significant participation of ITU-T experts that regularly
> attend and participate to ITU-T meetings (several of them working for your
> company by the way). We reached a consensus for the current draft between a
> significant number of people working on different sides, all were SDH/SONET
> experts. The most active co-authors even hold an half-day editing session in
> parallel with the last OIF meeting in Paris. See the explanations hereafter.
>
> We should stop the debate ITU-T against IETF, my company is member of both
> and the folks that work on GMPLS to control SDH/SONET since one year and a
> half are SDH/SONET experts !
>
> We gave some explanations in our document to better describe what we are
> speaking about, it has *nothing* to do with the way to implement it. Anybody
> is free to describe what he/she is talking about. We gave our explanation of
> a few interesting SDH/SONET behaviours in order to be sure that people will
> understand what we are talking about.
>
> Moreover, it is not because something is not defined in an SDH standard that
> it doesn't work or doesn't exist, specially if this doesn't require any
> change to the standards ! Note that there is a life outside of the G.707
> standard.
>
> Sending flames to mailing lists without trying to understand how it works is
> confusing for everybody.
>
> In that context, one should make the difference between:
>
> 1) SDH/SONET features that need an additional standard to be able to
> interoperate:
> ----------------------------------------------------------------------------
> ------
>
> In that case this is NOT at all in the scope of the IETF of course. I never
> heard anybody at the IETF proposing to do SDH/SONET standards, it does not
> make sense. The IETF management was *very* clear about that. It is well
> understood and agreed. There is non reason to come back to this point
> constantly, and there is no reason to use it as an argument each time we
> speak about SDH/SONET at the IETF !
>
> 2) SDH/SONET features that don't need any new SDH/SONET standard:
> -----------------------------------------------------------------
>
> Let's speak about the three features that are disturbing a *few* folks.
>
>
> About arbitrary contiguous concatenation:
> ----------------------------------------
>
> Arbitrary contiguous concatenation (as described it in the proposed text)
> don't need any standard, it is just a way to use SDH/SONET. It is already
> implemented since a while by many manufacturers in legacy equipment's. In
> that case there is NO reason why we should not define features to control it
> in the GMPLS signaling. It is not because it is not described in G.707 that
> you cannot do it, or that it doesn't work. What do you want to standardize,
> a written permission to do it maybe ?
>
> About transparency:
> -------------------
>
> Transparency at the GMPLS UNI does NOT require any SDH/SONET standard
> because it is NOT implemented at the UNI, it is 100% about signaling. We
> never said that GMPLS MUST be used at both the UNI and NNI. The NNI could be
> in a proprietary cloud of a single manufacturer. So, there is NO reason to
> remove it from the GMPLS signaling.
>
> If REQUESTED at the UNI, it has to be implemented at the NNI. Transparency
> at the NNI between two manufacturers needs an agreement to interoperate.
> This agreement can be achieved in very different ways: through the use of a
> standard, an implementation agreement made by a forum, or an implementation
> agreement between two manufacturers (e.g. at the request of an operator).
>
> ITU-T is not the only standardization body that produced SDH standards, ETSI
> also made SDH standards that were published as ETSI standards. T1X1 is not
> the only body with ITU-T that can work on SDH, ETSI is there as well. The
> OIF is also publishing standards, and at the last OIF there was a session
> dedicated to transparency. We can expect to see more contributions at the
> next OIF meeting. Some contributions could also be presented to T1X1.
> Anyway, that's not the business of IETF and has nothing to do with
> transparency in the GMPLS signaling at the UNI.
>
> About flexible arbitrary contiguous concatenation:
> --------------------------------------------------
>
> What is the additional standard that we need to support flexible arbitrary
> contiguous concatenation. Could someone describe what should be standardized
> and why two implementations could not interoperate ?
>
> The GMPLS signaling gives the type, the number, the order, and the position
> of all components. Flexible arbitrary contiguous concatenation in GMPLS is
> only an indication send to the downstream node that it could use this
> feature. The upstream node doesn't request it, it simply says to the
> downstream node that it supports it. The downstream node can either decide
> to ignore it and use a standard contiguous concatenation, or an arbitrary
> contiguous concatenation; or it could refuse the connection request. This is
> a local optimization to deal with local external fragmentation of the
> multiplex that will happen if you route very dynamic demands. Traditional
> ITU-T folks don't understand the interest since they don't think in terms of
> dynamic circuit establishment.
>
> There is NO interoperability issue between nodes that implement it and nodes
> that doesn't implement it. Again, a written permission to do it doesn't need
> to be written in a standard.
>
> Kind regards,
>
> Eric
>
> Eric Mannie
> EBONE (GTS)
>
> -----Original Message-----
> From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> Sent: Friday, May 18, 2001 11:06 PM
> To: Mannie, Eric
> Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com
> Subject: Re: Proposed text for the concatenation
>
>
> Eric,
> I think this goes against earlier email that says T1X1 and ITU-T
> are responsible for specification of SONET/SDH. There are two
> standardized forms of concatenation. Your proposal includes only
> one of the standardized forms and two that are, for the moment,
> proprietary. If we accept that SONET/SDH is the responsibility
> of T1X1/ITU-T, then for the moment I think the options can only
> be:
> - No concatenation
> - Standard Contiguous concatenation
> - Standard Virtual concatenation
> - (all others are, for the moment proprietary) vendor specific
>   concatenation types
> The other concatenation proposals must go to T1X1/ITU-T before
> they can be considered standardized.
> Regards,
> Steve Trowbridge
>
> "Mannie, Eric" wrote:
> >
> > Dear All,
> >
> > I am pleased to see so many people discussing so much on these mailing
> > lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> > would like to make some progress.
> >
> > Please, carefully read the following text that clarifies the contiguous
> > concatenation part of the draft and that introduces one simple new
> > concatenation type.
> >
> > "This field indicates the type of SONET/SDH contiguous concatenation to
> > apply on the Elementary Signal. It is set to zero to indicate that no
> > contiguous concatenation is requested (default value). The values are
> > defined in the following table:
> >
> >        Bits   Contiguous Concatenation Type
> >       -----   ----------------------------------
> >        000     No contiguous concatenation requested
> >        001     Standard contiguous concatenation
> >        010     Arbitrary contiguous concatenation
> >        011     Flexible arbitrary contiguous concatenation
> >       others   Vendor specific concatenation types
> >
> > Standard contiguous concatenation refers to the contiguous concatenation
> as
> > it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
> > concatenation relaxes the limitations of these standards in terms of the
> > location where a contiguous signal can start, and in terms of the number
> of
> > concatenated VC's/SPE's that can compose this signal.
> >
> > Flexible arbitrary contiguous concatenation is an optimisation of the
> > arbitrary contiguous concatenation that allows to "inverse multiplex" a
> > contiguously concatenated signal on a per multiplex section/line basis. In
> > order to be effectively used, an upstream node must indicate that its
> > supports this feature to its immediate downstream node, using the CCT
> field.
> > The downstream node can in that case use that feature and return a list of
> > labels, one for each element of the "inverse multiplex"; instead of one
> > single label indicating the beginning of the contiguous signal.
> >
> > The three types of contiguous concatenation defined here before defines
> > indeed a hierarchy of flexibility in the contiguous concatenation. If
> > selected, the flexible arbitrary contiguous concatenation, indicates that
> > any of the three types of contiguous concatenation can be chosen by the
> > downstream node. It is up to the downstream node to choose the one that it
> > wants to use. The upstream node, when receiving the labels from the
> > downstream node, may accept or refuse what was proposed."
> >
> > Please send me your technical comments about the technical correctness of
> > this text only. Please, delay discussions about the usefulness of these
> > features and the way to implement them to another time. What is important
> is
> > that each feature works. Your profile, implementation, or configuration
> > should determine what you like and what you want to support, not this
> > signalling.
> >
> > Take your time to read the text and to answer, it is 10PM in my time zone
> > and I will leave my office. I'll be back on Monday morning to read your
> > answers.
> >
> > Many thanks to all of you and have a nice week-end.
> >
> > Kind regards,
> >
> > Eric
> >
> > Eric Mannie
> > Technology & Standards Strategy Manager
> > Network Engineering Strategy
> > EBONE
> >
> > Terhulpsesteenweg 6A
> > 1560 Hoeilaart - Belgium
> >
> > Tel:    +32 2 658 56 52
> > Mobile: +32 496 58 56 52
> > Fax:    +32 2 658 51 18
> > E-mail: eric.mannie@ebone.com
> >
> >
>
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical