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

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

Hello Zhi,

>* 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?

This one possible scenario. GMPLS is not intended to work for the lowest
common denominator at all. This is a difference with the ITU-T approach in
transmission where you have to accomodate all possible cases. Some features
in GMPLS will not make sense for some scenarios, but will make sense in
other scenarios (generic-general GMPLS). ITU-T made excatly the same with
plenty of their protocols (e.g. H.323). So you will not proof anything with
your example, we know that already and this is not an issue.

Rgds,

Eric

-----Original Message-----
From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
Sent: Wednesday, May 30, 2001 2:54 PM
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