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

["Bernstein, Greg" <GregB@ciena.com>]

Hi Eric (Gray), Ciena supports all the concatenation extensions discussed in
the draft. Note that LTE only equipment doesn't need to do anything special
to support the transport of virtually concatenated signals.
The transparency options are larger and apply to more than one type of
equipment. Hence, I might not offer all types on the same box (DWDM, Core
Switching, Metro Switch). 

Are the complaints from BT, Lucent, Siemens and AT&T primarily directed at:
(1) Extended concatenation types
(2) Semi-transparency feature
(3) Path group/AUG-N signal type
Are there other problems?  Would leaving these for further study get us out
of this deadlock? I.e., some don't want these in a separate specification,
some do. Note that various companies have implemented an earlier less mature
form of this spec and acheived some measure of interoperability, i.e., the
closed door UNH OIF session and the upcomming supercom demo. It would be
very helpful for the industry in general to move this forward now even
without some of the more "advanced features". 

Note, however, I do receive pressure from carriers to be open and to provide
these features.

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 



-----Original Message-----
From: Eric Gray [mailto:eric.gray@sandburst.com]
Sent: Tuesday, May 29, 2001 10:26 AM
To: Bernstein, Greg
Cc: 'tony.flavin@bt.com'; ccamp@ops.ietf.org; tsg15q11@itu.int
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation


Greg,

    I think it is fair to both ask and answer the question -

        'which companies support feature X'

- on these mailing lists.  An answer is certainly relevant, it
need not be in the form of a product announcement and it is
much better than a choice of poking around in the dark at
shadows of 'some vendors' or being one of a few hundred
people to call the oracle.

    For once, I'd like to see a straight forward answer.  How
naive I must be...

--
Eric Gray

You wrote:

> Hi Tony, I didn't think we were supposed to advertise on these e-mail
> exploders so I didn't name names. See comments below.
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation
> Phone: (510) 573-2237
>
> -----Original Message-----
> From: tony.flavin@bt.com [mailto:tony.flavin@bt.com]
> Sent: Tuesday, May 29, 2001 8:32 AM
> To: ccamp@ops.ietf.org; tsg15q11@itu.int
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> Greg,
>
> From your points:
>
> (1) progressive loosening ... equates to non-compliant.
> >> Actually not, this equipment is completely G.707/T1.105 compliant. This
> is an extension not a further restriction.
>
> (2) Which vendors? Let's here some names. Or even better, from the vendors
> themselves.
> >> Don't want to plug any particular company, but feel free to give me a
> call.
>
> (3) How does this equipment negotiate feature availability?
> >> Numerous ways: with "end systems (across a UNI)" this is what the
service
> discovery part of the OIF UNI is about, with "peers" this is what the
> routing extensions are partially about.
> (4) Of course it's proprietary!
> >> Actually "proprietary" means "no one else can offer it". Like in the
old
> PBX days where the manufacturers would patent a "feature" like
"distinctive
> ringing" so that no one else could offer it or that license fees would
need
> to be paid.  I took this definition from Randy Bush. I would say this is a
> non-standard feature.
> (5) Has this level of signalling been proposed yet?
> >> Partially, via GMPLS SONET/SDH extensions.
>
> Still nobody answers the question of why not use virtual concatenation,
> which does all that is required and more. Or do people have too much half
> baked silicon!
> >> Virtual concatenation is really a PTE function that uses path overhead
> and is not "path transparent". The concatenation extensions (arbitrary and
> flexible) are fairly straight forward line (MS) layer extensions that
> prevent the need for re-grooming.
>
> Regards
>
>         Tony
>
> -----Original Message-----
> From: Bernstein, Greg [mailto:GregB@ciena.com]
> Sent: 29 May 2001 16:26
> To: 'tony.flavin@bt.com'; ccamp@ops.ietf.org; tsg15q11@itu.int
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> I think there is some confusion in the intention of introducing the
> concatenation options.  A few points:
> (1) The two additional concatenation options introduced in Eric's proposal
> "arbitrary contiguous" and "flexible arbitrary" are the progressive
> loosening of the existing "contiguous concatenation" restrictions of G.707
> or T1.105.
> (2) Several vendors offer one or both of these extensions.
> (3) Equipment that offers these extensions can always work with equipment
> that doesn't offer these extensions.
> (4) These are not proprietary features using the definition of
"proprietary"
> as furnished by Randy Bush in a recent e-mail.
> (5) GMPLS routing and signaling can be used to negotiate the use of these
> features within a network of mixed equipment and hence make the best use
of
> all types of equipment.
>
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation
>
> -----Original Message-----
> From: tony.flavin@bt.com [mailto:tony.flavin@bt.com]
> Sent: Tuesday, May 29, 2001 1:51 AM
> To: ccamp@ops.ietf.org; tsg15q11@itu.int
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> Eric,
>
> This is not describing just a way to use SONET/SDH as it changes every box
> in the network! To use this there are changes/additions required to G,707
> and G.783.
>
> Neither is this a new feature. Concatenation is already described and
> explained.
>
> I do not understand the linkage between GMPLS and concatenation. the two
are
> independent up to the point that you may wish to attempt variable
bandwidth
> allocation. At this point extensions to concatenation are requires, and as
I
> have already stated this work is already under discussion in ITU.
>
> Regards
>
>         Tony
>
> -----Original Message-----
> From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
> Sent: 28 May 2001 12:06
> To: 'Rob Coltun'; John Drake
> Cc: ccamp@ops.ietf.org
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> Hello Rob,
>
> > Is it really that big an issue to just keep them in a separate RFC?
>
> Even if there is absolutely no standard required from ITU-T ? Nothing is
> needed for arbitrary concatenation, AUG-X, TUG, etc. We are just
describing
> a way to use SDH/SONET. There was no technical discussion about that.
>
> Do you mean that any feature that is not defined by ITU-T should not be
> published in the standard track ? For instance the concept of waveband
> switching ? The signal types ? The link protection ? The protection and
> restoration ?
>
> What is the added-value of GMPLS if we cannot take some freedom with the
> existing standards ? Our added-value is to match the new developments of
the
> industry, with the added-value that was added and not only the published
> standards from ITU-T.
>
> We already agreed on the following approach:
>
> - all mechanisms are optional (zero means I don't care).
> - we indicate clearly what is not defined in ITU-T/T1X1 standards.
>
> Can we simply use this approach ?
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Rob Coltun [mailto:rcoltun@redback.com]
> Sent: Saturday, May 26, 2001 1:20 AM
> To: John Drake
> Cc: ccamp@ops.ietf.org
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
>
> Hi John,
>     valid question -  I don't think this is true for BGP. There are
> extensions
> to BGP that the working group has adopted.
> Which TE drafts are you referring to?
>
> We've said from the beginning that we didn't want to define new "data
plane"
> functionality for technologies where the data plane is being defined
> elsewhere
> - whereas some of the functions aren't really new, and in cases might be
> de-facto standard
> we recognize that certain "data plane" functionality are beyond the scope
> of the IETF to define - so this keeps us more in line with (in this case)
> the ITU.
>
> Note that IETF has defined the
> MPLS data plane - if some other body were to define new functionality
> for the MPLS data plane it would certainly cause confusion in the
industry.
> This standard stuff is certainly not easy.
>
> Is it really that big an issue to just keep them in a separate RFC?
>
> thanks,
> ---rob
>
> John Drake wrote:
>
> > Rob,
> >
> > Why isn't the proposed disclaimer sufficient?  If you look in the base
TE
> > drafts, for example, there are codepoints defined for use by specific,
> > named, vendors.  I think the same is also true for BGP.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Rob Coltun [mailto:rcoltun@redback.com]
> > Sent: Thursday, May 24, 2001 6:54 PM
> > To: ccamp@ops.ietf.org
> > Subject: 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