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

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