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

["Mannie, Eric" <Eric.Mannie@ebone.com>]

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