RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena tion

["Mannie, Eric" <Eric.Mannie@ebone.com>]

Hello Monica,

>Having the signaling standard
>support proprietary transport may jeopardize interoperability.

What interoperability issue are you talking about ? It is nice to repeat it
constantly but I would like to see a technical justification. About
arbitrary concatenation, what is needed for interoperability ?

I am not going to continue talking without technical arguments.

Do you think that the IETF can define a protection/restoration protocol
applicable to SDH/SONET ? Or is that proprietary as well ?

Could you give us the exact list of features in GMPLS (in all the signaling)
that have to be removed ?

Kind regards,

Eric

The issue is
not about GMPLS supporting non-standard rates, the issue is about putting in
formal and very specific support for a proprietary transport solution in a
standard document for signaling without taking the transport portion to a
standards body. Having formal signaling support for a proprietary
concatenation may cause interoperability issues when other vendors have a
different solution to the concatenation and while the signaling would
indicate the concatenation, the actual transport may not work.   On the
other hand we recognize that there may be a need for some interim support
for proprietary solutions.


Eric,
Below I have some additional specific comments for the document GMPLS
Extensions for SONET and SDH Control


CCT field (3 bits)
Since arbitrary contiguous concatenation is not a standard concatenation, it
falls within the vendor proprietary set of solutions.

So the CCT bits may be used as follows:
000	No contiguous concatenation requested
001	Standard contiguous concatenation
others	Vendor specific contiguous concatenation

Alternatively, a better solution is to use only 2 bits for this field and
use one bit to show whether contiguous concatenation is requested and the
second bit to show whether it is standard or non-standard contiguous
concatenation.


NCC field (16 bits)
This information is not sufficient. 
NCC needs better description than a zero or non-zero number.

SDH and SONET Labels

Text in this section (Section 3, paragraphs 5 and 6) indicates that the
GMPLS proposal limits virtual concatenation to remain within a single
(component) link. If I understand this correctly, it means that GMPLS will
not allow inverse multiplexing (virtual concatenation) in the transport
plane if it requires different component links. This is too limiting.

Annex 1 (sent out by Eric Mannie on 5/22)
Defines another type of concatenation - Flexible arbitrary contiguous
concatenation without describing precisely how it affects the OH bits. This
means that it will be impossible to have this type of concatenation in a
multi vendor environment based only on the GMPLS signaling. If the transport
plane is proprietary, having the option in the signaling message will not
fix the interoperability problem between two different vendors supporting
their proprietary versions of arbitrary concatenation.

Annex 2 (sent out by Eric Mannie on 5/22)
Arbitrary contiguous concatenation needs definition work for
interoperability.
Flexible arbitrary contiguous concatenation may be available today to
support contiguous signals, but it is not defined in the current standards.
Clear agreements on OH usage are needed between supporting vendors.
Maintenance and tracking of the signal needs to be well understood.



Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
mlazer@att.com


-----Original Message-----
From: Rob Coltun [mailto:rcoltun@redback.com]
Sent: Thursday, May 24, 2001 7:24 PM
To: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; q11/15; t1x1.5
Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatenation

All,
    despite the heated arguments I think the discussion is important to
have.

I suggest that instead of  tagging non/pre-standard items in the current
drafts
that they be put into a separate Informational document  - this is the
cleanest thing to do.
We (the IETF) do have a tradition of publishing company proprietary
protocols
but not as standard track documents.

thanks,
---rob



_______________________________________________
IP-Optical mailing list
IP-Optical@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/ip-optical

_______________________________________________
IP-Optical mailing list
IP-Optical@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/ip-optical