[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



fine with me

-----Original Message-----
From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
Sent: Monday, May 28, 2001 4:06 AM
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