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

[Eric Gray <eric.gray@sandburst.com>]

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