[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>
>