[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IP-Optical] Re: Proposed text for the concatenation
Eric,
Let me try to clarify what I think Tony was saying:
- There is a great deal of installed SONET/SDH equipment in todays networks
that does not implement the non-standardized forms of concatenation. The
standardized forms (contiguous at the agreed multiples of the basic rates
and virtual, which involves only the endpoints) are pretty universally
available in todays networks.
- Arbitrary concatenation is not something that can be easily added to
the installed equipment. It generally needs different ASICs. While it may
be possible to build new port boards for existing NEs with the different
ASICs, this doesn't help you with respect to providing the capability on
installed links that are currently providing service. There is no graceful
way to replace port boards in service without creating a traffic hit on
that existing service. This is not something that can be added to most
installed NEs with only a software upgrade.
- Many of the operators of these existing networks would like to offer
switched SONET/SDH services using GMPLS or some other form of control and
signaling. There is a hope and expectation that this can be deployed in
existing networks through software upgrades to some existing NEs and perhaps
some additional controllers. If a fork lift replacement of every NE in the
switching path is needed, I don't think you will see rapid acceptance among
established operators. I think it is also expected that this capability
can be inserted gradually into existing networks - some NEs may simply
provide nailed up pipes between the NEs where the switching functions are
actually performed, and those NEs shouldn't require any kind of upgrade.
Basing the control plane on currently standardized forms of concationation
would provide a much smoother path to incorporate GMPLS capabilities into
many existing networks.
Let me reiterate the hope that the advocates of arbitrary concatenation
will be contributing a precise proposal to the June meeting of T1X1 and
the October meeting of ITU-T Study Group 15. We could save a lot of
emails if everyone had the same picture about what SONET/SDH really is.
Regards,
Steve Trowbridge
Chairman, ITU-T WP 3/15
"Mannie, Eric" wrote:
>
> Hello Tony
>
> >Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This
> >is the point I have been trying to make all along.
>
> To be more precise, arbitrary concatenation won't work over SONET/SDH nodes
> that don't implement it, whatever there is a control plane or not. Arbitray
> concatenation is not a feature of GMPLS, it is a feature of SONET/SDH ADM's,
> TM's, etc... Folks didn't wait for a control plane to implement it.
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: tony.flavin@bt.com [mailto:tony.flavin@bt.com]
> Sent: Friday, June 01, 2001 9:33 AM
> To: jdrake@calient.net; zwlin@lucent.com
> Cc: rcoltun@redback.com; ccamp@ops.ietf.org
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> Sorry,
>
> Arbitrary concatenation won't work over the non-GMPLS SONET/SDH nodes. This
> is the point I have been trying to make all along.
>
> Virtual will work. VC4-4c or VC4-16c will work. Arbitrary will not.
>
> Tony
>
> -----Original Message-----
> From: John Drake [mailto:jdrake@calient.net]
> Sent: 30 May 2001 15:45
> To: 'Zhi-Wei Lin'; John Drake
> Cc: 'Rob Coltun'; ccamp@ops.ietf.org
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> I didn't say that, and I don't think that it is true.
>
> It is my understanding that if there was a set of SONET/SDH pipes between a
> pair of GMPLS nodes across a non-GMPLS cloud, then the GMPLS nodes could use
> those pipes however they wished as long as they were consistent with
> SONET/SDH
> transport protocols and the non-GMPLS nodes wouldn't need to understand what
> they were doing.
>
> I think that this is exactly the same situation as virtual concatenation,
> where
> the endpoints are upgraded without disturbing the intermediate equipment.
>
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> Sent: Wednesday, May 30, 2001 7:32 AM
> To: John Drake
> Cc: 'Rob Coltun'; ccamp@ops.ietf.org
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
>
> Hi John,
>
> Yes I agree. As long as the GMPLS nodes are consistent with the
> non-GMPLS cloud, then there is no interop issue.
>
> As you said, to support arbitrary concat, the SONET/SDH non-GMPLS cloud
> would also need to support this. Then it not only impacts new equipment,
> but also require upgrades to embedded equipment as well for this to
> work?
>
> Zhi
>
> John Drake wrote:
> >
> > Since the non-GMPLS nodes don't understand GMPLS signalling, they are not
> > interacting with the GMPLS
> > nodes wrt signalling. This means that the links between the GMPLS nodes
> at
> > the edges of the non-GMPLS cloud
> > are pre-configured SONET/SDH pipes. This also means that as long as what
> > the GMPLS nodes are doing
> > with those pipes is consistent wrt SONET/SDH transport protocols, e.g.,
> > arbitrary concat, then there
> > is no interoperability issue.
> >
> > I think that this is the point that Eric has been making, which has tended
> > to get lost in the noise.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> > Sent: Wednesday, May 30, 2001 5:54 AM
> > To: John Drake
> > Cc: 'Rob Coltun'; ccamp@ops.ietf.org
> > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> >
> > Hi John,
> >
> > I'm not sure it's all new boxes. Would you consider this scenario valid?
> >
> > * 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you
> > might go over legacy systems. The no-GMPLS area is simply providing a
> > "tunnel" between the two GMPLS areas.
> >
> > Do we consider such examples?
> >
> > Zhi
> >
> > John Drake wrote:
> > >
> > > Rob,
> > >
> > > It was my understanding that that BGP Capabilities and BGP Multiprotocol
> > > extensions include a set of code points called "vendor-specific".
> > >
> > > For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for
> OSPF),
> > > there is the following:
> > >
> > > Sub-TLV type Length (octets) Name
> > >
> > > 250-254 Reserved for cisco specific
> > > extensions
> > >
> > > More importantly, what I thought Eric was saying was that the
> capabilities
> > > under
> > > discussion, i.e., transparency and arbitrary concatenation, didn't
> require
> > > any
> > > changes to the SONET/SDH standards. Rather, it would require changes to
> > the
> > > cross-connects between the SONET/SDH spans. Since these are new boxes,
> it
> > > doesn't
> > > sound like such a big deal.
> > >
> > > Thanks,
> > >
> > > John
> > > -----Original Message-----
> > > From: Rob Coltun [mailto:rcoltun@redback.com]
> > > Sent: Friday, May 25, 2001 4:20 PM
> > > 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