[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [IP-Optical] Re: Proposed text for the concatenation
Greg,
I don't have complaints about these features as such. My two concerns are
- we should clearly identify what is standard SDH/SONET and what not
- and we should be confident that we understand these features and their implications so that the signaling support is ok
Juergen
> -----Original Message-----
> From: Bernstein, Greg [SMTP:GregB@ciena.com]
> Sent: Tuesday, May 29, 2001 8:01 PM
> To: 'Eric Gray'
> Cc: 'tony.flavin@bt.com'; ccamp@ops.ietf.org; tsg15q11@itu.int
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> 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