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

[tony.flavin@bt.com]

Greg,

>From your points:

(1) progressive loosening ... equates to non-compliant.

(2) Which vendors? Let's here some names. Or even better, from the vendors
themselves.

(3) How does this equipment negotiate feature availability?

(4) Of course it's proprietary!

(5) Has this level of signalling been proposed yet?

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!

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