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

[tony.flavin@bt.com]

So,

Two boxes which have the new features wish to use a link that traverses
older line systems. These do not support Arbitrary concatenation, so the
link won't work unless you upgrade the boxes!

You do have to change all of the boxes.

Of course, if you used virtual .......

Tony

> -----Original Message-----
> From:	Mannie, Eric [SMTP:Eric.Mannie@ebone.com]
> Sent:	Tuesday, May 29, 2001 11:22 AM
> To:	'tony.flavin@bt.com'; ccamp@ops.ietf.org; tsg15q11@itu.int
> Subject:	RE: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hello Tony,
> 
> >This is not describing just a way to use SONET/SDH as it changes every
> box
> >in the network!
> 
> No, it doesn't change any box if you don't use these features. A feature
> in
> GMPLS doesn't mean that you are obliged to use it or to implement it. But
> which control plane will you use in your existing boxes ?
> 
> I don't think that you will have GMPLS as a simple software upgrade in
> your
> existing ADM's. Obviously you will have to deploy a new cloud with boxes
> able to run the control plane (in general you have a dedicated redundant
> hardware to run the control plane and a dedicated redundant hardware to
> run
> the routing algorithm in real-time on carrier class equipment's).
> 
> Interworking between an "ION" cloud and a non "ION" cloud (i.e. a
> traditional SDH/SONET cloud) is another issue.  In that case the control
> plane doesn't run on the non ION cloud and you need a manual provisioning
> there. Of course you must find a common denominator between the ION cloud
> and the non-ION cloud to support end-to-end circuits. However, end-to-end
> circuits that stay in the ION cloud will take benefits of the GMPLS
> features
> implemented by your manufacturer.
> 
> >To use this there are changes/additions required to G.707 and G.783.
> 
> What is important for interoperability is not the definition of a concept
> in
> a document but what is actually send between two nodes.
> 
> For arbitrary concatenation you don't change anything to the frame format,
> only each node must be able to recognize and treat the pointers and the
> VC-4-Xc. This concept is not defined in G.707 and G.783 but this has no
> impact. You negotiate this capability between each pair of node, if there
> is
> a node that doesn't support it, the circuit is refused. In addition, we
> expect that you will know this capability for each node/interface via the
> routing protocol. So the routing algorithm will find directly the adequate
> path.
> 
> Of course the ASIC's on that path must support the capability, this is an
> ASIC implementation issue, not a document issue. A manufacturer can
> implement whatever he likes in his ASIC's. GMPLS doesn't define what must
> be
> implemented in the transmission plane to be interoperable (that's the job
> for a profile). GMPLS gives tools in the control plane, some tools are
> optional of course.
> 
> Transparency at the GMPLS UNI has absolutely no impact on existing
> standards, the transmission plane and on existing ASIC's. It is only
> implemented at NNI. At the UNI this capability is signaled in GMPLS and
> the
> transmission plane doesn't care. At the NNI that will require a standard
> or
> an implementation agreement if and only if multiple vendors are used. So
> there are already many interesting scenarios in the short term where this
> feature can be helpful. In the long term if you want to go to multiple
> vendors you will need to ask them to reach a consensus to be able to
> interoperate. That could be easier than you think because transparency is
> software selectable for several of them, so when you buy the equipment you
> specify where you want to tunnel the overhead bytes.
> 
> There is in fact absolutely NO interoperability issue with any of these
> features if the circuit is refused when you try to cross a link where the
> two ends are incompatible, or where on end doesn't support transparency.
> Once again the routing protocol can advertise such capabilities. You can
> keep the control of your network in any case.
> 
> All these features are "negotiated" when you try to open a circuit, if the
> downstream node doesn't support a feature that connection attempt is
> refused.
> 
> >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.
> 
> GMPLS allows to open a circuit, that circuit can be a concatenated circuit
> between two IP routers. Variable bandwidth is orthogonal with that feature
> and is also possible with GMPLS if it can be supported by the control
> plane.
> If you are referring to LCAS, this is not a control plane that allows to
> open circuits dynamically.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: tony.flavin@bt.com [mailto:tony.flavin@bt.com]
> Sent: Tuesday, May 29, 2001 10: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