[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